This doc show how to use i.MX8QXP Display Controller GammaCor unit to tune gamma. HW: i.MX8QXP MEK board, HDMI monitor SW: i.MX Linux 4.14.98_2.2.0 BSP release, patch in this doc 1.Introduce gamma The gamma, gamma correction, gamma encoding, gamma compression , these words all related one kind operation , see wiki page of it: The device used for image capture/print/display follow this power-law. For example the camera captured image , to view this image on display device as good as original captured image : gamma encoding when camera saved sensor data to image file,  and  gamma decoding when that image file display on your PC LCD monitor. That is : 2. i.MX8QXP Display Controller Gamma Correction Unit The Gamma Correction unit position is located between Frame Gen unit and TCon unit.   More detail see below contents from i.MX8QXP RM: So GammaCor unit could be used as adjust display gamma , or brightness or contrast. To used it, need follow the steps at RM 15.9.2.4.4.8.3.   Something need to note: You need program 33 sample point value into the register, these sample point value range is from 0 to 1023. Note, first write is start sample point value , then the other is delta value: current sample point minus previous sample point value. You can use GammaCor unit on any channel of R/G/B. If you use normalized function f(x), the following formula should be used to clut[i = 0..32] = round( f(i * 32 / 1023) * 1023) 3. i.MX8QXP Linux device driver patch and test code Apply attached  patch 8qxp_dpu_gammacor_4.14.98_2.2.0.diff on Linux kernel. In the kernel patch, function dpu_gammacor_update, I choose not calculate delta value between each sample pint , let user space application calculate delta value and passed to kernel. Apply 8qxp-dpu-gammacor-modetst.diff on libdrm-imx, to get test application which is based on modetest.  Test app will read one greyscale image file 720P.rgb, put it under same folder of test application , calculate sample point value by pow function  , and calling drmModeCrtcSetGamma to pass related value to kernel,  next loop will change sample point value, and will see that greyscale image will changed on HDMI monitor. After system boot up, run below cmd to check result of test application systemctl stop weston ./gamma_show_rgba.out -P 29@32:1280x720@AB24 Reference: a>https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM b>https://www.nxp.com/webapp/Download?colCode=L4.14.98_2.2.0_MX8QXP&appType=license c> https://source.codeaurora.org/external/imx/libdrm-imx/ d> https://en.wikipedia.org/wiki/Gamma_correction

Test digital zoom with ipu for camera preview.   Board :sarbre-sd (imx6dq) BSP   : android 13.4ga In the above flow, one frame buffer is processed in four steps at camera preview. Add the step to change the frame buffer before step 4 , the added step which  zoom one preview frame.   The figure below shows the crop function of ipu lib, we use this function scale the frame.   Test result: preview zoom levle 0:   preview zoom level max:     When taking pictures with 5M pixels and the zoom is over level 1, the picture size is not 2592x1944 but 2016x1512. The underlying reason for it is that ipu crop function only supports the 2048x2048 maximum output .   Thumbnails of test result :  

The PICO-PI-IMX7 is a TechNexion board defined here. It is now supported in mainline U-Boot, mainline Kernel, FSL Community BSP and Buildroot. In mainline U-Boot it is supported since v2017.07. In mainline Linux Kernel it is supported since 4.13. To generate an image for PICO-PI-IMX7 using FSL Community BSP, please see: The imx7d-pico board is now supported in FSL Community BSP - i.MXDev Blog. To generate an image for PICO-PI-IMX7 using Buildroot, please see: The imx7d-pico board is now supported in Buildroot - i.MXDev Blog.

In the default release the SSI1 doesn't suport double FIFO in audio driver. Attached was the code to support double FIFO with updated DMA script.

1. When reusing the build directory, sometimes compilation errors are seen; to overcome these, a fast solution is to clean the Share State Cache of the particular recipe/package $ bitbake <name of the recipe> -c cleansstate 2. Re-run the recipe $ bitbake <name of the recipe> 3. Re-run the bitbake command you were running, before getting into trouble. For example: $ bitbake fsl-image-gui In case the problem persists, please send the log into the mailing list or check if this issue has been reported previously.

Summary: The i.MX 8M-Mini can boot from QSPI flash using a dedicated boot image. The boot config settings are not correctly documented in the EVK Board Hardware User's Guide Rev 0 from 02/2019. In the document i.MX_Linux_User's_Guide.pdf  in the BSP documentation 4.14.98 the settings are correctly given in Table 38 Details: To generate a bootable file for the QSPI with Yocto, you need to include the following setting into local.conf: UBOOT_CONFIG = "fspi" If you don't want/need to make a complete build, just rebuild u-boot: bitbake -c deploy u-boot-imx Alternatively the file imx-boot-imx8mmevk-fspi.bin-flash_evk_flexspi included already in the BSP demo packages will work as well Program the image into QSPI: With UUU:   uuu -b qspi imx-boot-imx8mmevk-fspi.bin-flash_evk_flexspi With u-boot: u-boot=> fatls mmc 0:1 14557696   Image    …   1446848   imx-boot-imx8mmevk-fspi.bin-flash_evk_flexspi 11 file(s), 0 dir(s) u-boot=> sf probe SF: Detected n25q256a with page size 256 Bytes, erase size 4 KiB, total 32 MiB u-boot=> fatload mmc 0:1 0x40480000 imx-boot-imx8mmevk-fspi.bin-flash_evk_flexspi 1446848 bytes read in 79 ms (17.5 MiB/s) u-boot=> sf erase 0x0 0x200000 SF: 2097152 bytes @ 0x0 Erased: OK u-boot=> sf write 0x40480000 0x0 0x200000 device 0 offset 0x0, size 0x200000 SF: 2097152 bytes @ 0x0 Written: OK u-boot=> sf read 0x50000000 0x0 0x200000 device 0 offset 0x0, size 0x200000 SF: 2097152 bytes @ 0x0 Read: OK u-boot=> cmp.b 0x40480000 0x50000000 0x200000 Total of 2097152 byte(s) were the same u-boot=> Set boot config jumpers correctly and power on the board (no SD-card in the slot) 8M-Mini Rev A and Rev B boards:  01xxxxx0 0000x001 8M-Mini Rev C boards: 0110xxxxxx 00100x0010

This document is a simple guide on one of the ways in which 3D models can be loaded and displayed using OpenGL.   Requirements - Blender (open source) or a similar program that allows to export 3D models in the .obj format. We’ll be using Blender to export the .obj file with the essential information to draw the 3D model, without information on textures, for example. https://www.blender.org/   - i.MX6 Linux BSP image with X11 support – For this document we’ll use the L3.10.31 BSP, which is compiled using Yocto 1.6.You may use a newer BSP. We’ll use the fsl-image-gui. You may use a Qt5 image with X11 from newer BSPs. - GCC Toolchain -You may either cross compile on a Host or compile on the same board by providing the necessary libraries and toolchain. On the L3.10.31 you need to manually add GCC to your baked image. In newer releases this may not necessary. For adding the GCC package to a Yocto image and compiling within the board itself please add the following line to the conf/local.conf file inside your build directory. IMAGE_INSTALL_append += " gcc libgcc" If you wish to cross compile from your host and then run on your board you first will need to extract the toolchain from the BSP, which can be done by following the instructions of the next document: https://community.nxp.com/docs/DOC-95122  - FreeGLUT – FreeGLUT is an open source alternative to the OpenGL Utility Toolkit (GLUT), a window system independent toolkit for writing OpenGL programs. It implements a simple windowing application programming interface (API) for OpenGL. This is not necessary for drawing the model on the window but foes allow for functions such as rotating it. You may install it on your host with the following command: $ sudo apt-get install freeglut3-dev For additional information and downloads of FreeGLUT please refer to the projects website: http://freeglut.sourceforge.net/   - i.MX6D/Q/DL/S/SX GPU Demo Framework SDK – We’ll use the GPU Test examples which are available at the following link. Source code for this document implementation is attached but for more examples of OpenGL ES please refer to this SDK. (Please note that you may need to login in order to download this file) https://www.nxp.com/webapp/Download?colCode=FSL_GPU_SDK_2.3&appType=license&location=null&fpsp=1&WT_TYPE=Software%20Development%20Kits&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&fileExt=.zip&Parent_nodeId=1337637154535695831062&Parent_pageType=product   - i.MX6Q Board – For this example we will be using the i.MX6Q SABRE Board, but you may run OpenGL ES on any i.MX6Q board provided that you provide the necessary packages to support OpenGL ES.   Brief introduction to OpenGL ES? OpenGL is a software interface to hardware accelerated graphics. The API of this interface consists of about 150 distinct commands that allow you to specify objects and perform operations on them in order to produce interactive three-dimensional applications. OpenGL ES is the OpenGL implementation for Embedded Systems. Somei.MX6 Processors like the i.MX6Q possess a Vivante GPU module that runs on OpenGL ES. When using OpenGL or OpenGL ES all 3D objects are descripted as a series of triangles. This is important to mention as it will make the instructions we will need for describing our model make more sense.   Step 1 - Exporting a model as .obj You may import a 3D model from other sources or make your own simple 3D model in blender. For this example we’ll make a simple 3D NXP logo and export it. Once you have your model ready, select the object in objet mode with a right click. Once selected select File > Export > Wavefront (.obj) You may now select where and with what name to export the object file. On the left panel you will have the export options. It’s important to leave all options unchecked except for: Write Normals Include UVs Triangulate Faces (You may change the scale of your model and it won’t negatively affect the process)     The .obj model may be opened with a text editor and we’ll see that it basically describes the object as a series of parameters that may include vertex data, free-form curve/surface attributes, elements, free-form curve/surface body statements, connectivity between free-form surfaces, grouping and display/render attribute information. For our example we’ll be using a simple file that just contains: - List of geometric vertices, with (x,y,z) coordinates v 0.292475 0.017345 -0.152653 - List of vertex normals in (x,y,z) form vn 0.0000 1.0000 -0.0000 - Polygonal face element f 3//1 113//1 4//1   Step 2- Converting .obj to OpenGL compatible information We’ll be using the following program that allows to convert from .obj format to a format compatible with OpenGL as the conversion from one format to the other is not part of the scope of this document. https://fr.jeffprod.com/obj-to-opengl.php This program does more than just changing the format on the file and do perform some operations to translate the parameters of the .obj file to the following OpenGL ES information: static GLfloat v_triangles[] static GLfloat vt_triangles[] static GLfloat vn_triangles[] We’ll be using these variables and also the number of triangles which for this example is 1440. This can be found at the end of the file on the following line which effectively draws the complete triangle array: glDrawArrays(GL_TRIANGLES, 0, 1440);   Step 3 – Loading the model arrays to the .C program. You will need to copy the three GLfloat arrays to your OpenGL ES .C code. (You may alternatively use an include to have it more neatly organized but this is outside the scope of this document) In our example we’ll copy them inside void render (). Inside this function we’ll find the Draw Array instruction in which we must specify the number of triangles in our array. You may just replace your model information AND also change the number of triangles, otherwise you will receive an error when running the program.   glDrawArrays(GL_TRIANGLES,0,1440); We are using a simple rotation using glRotate and incrementing the value of rotation with each flush of the screen.     glRotatef(rlogo, 2.0f, 1.0f, 1.0f); The variable rlogo gets increased each time the screen is drawn. Depending on your model you may need to change the view in order to be able to see your model. This example uses a very small model so we have a viewpoint just 1.25 units away from the screen (Z axis). Depending on your model you may need to be further away in order to see the model on the screen. glTranslatef(0.0f, 0.0f, -1.25f);    Step 4- Compiling the OpenGL example For this simple example we will be using the examples from the GPU  as base an add the information of the model we have just exported. We’ll use the two attached files for this: Makefile.x11 – A make file with the dependencies and attributes necessary to compile our C file. NXPlogo.c – C file with the information of the model and instructions on to draw it on the screen. You can compile using the following commands to first clean in case you built before and then compiling the code. make –f Makefile.x11 clean make Makefile.x11 Once the program has compiled you can run it from the command prompt by using: export DISPLAY=:0.0 ./NXPlogo The result will be as follows, where the 3D model is rotating,     Additional Resources 2D and 3D Graphics in NXP Devices http://www.nxp.com/files/training/doc/dwf/DWF13_AMF_CON_T1025.pdf   i.MX6D/Q/DL/S/SX GPU Demo Framework SDK – Which provides the source code for the demo in which this example was built upon and also contains good documentation for those interested in OpenGL ES. https://www.nxp.com/webapp/Download?colCode=FSL_GPU_SDK_2.3&appType=license&location=null&fpsp=1&WT_TYPE=Software%20Development%20Kits&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&fileExt=.zip&Parent_nodeId=1337637154535695831062&Parent_pageType=product    OpenGL Redbook – Which is the most comprehensive book documenting and explaining the OpenGL API. http://www.opengl-redbook.com/

OpenCV (Open Source Computer Vision Library) is released under a BSD license and hence it’s free for both academic and commercial use. It has C++, C, Python and Java interfaces and supports Windows, Linux, Mac OS, iOS and Android. OpenCV was designed for computational efficiency and with a strong focus on real-time applications. Written in optimized C/C++, the library can take advantage of multi-core processing. Enabled with OpenCL, it can take advantage of the hardware acceleration of the underlying heterogeneous compute platform In current bsp , which supports opencv 2.4, but some customer wants to use the opencv 3.1, then one can use the morty yocto bsp to install the opencv. step 1: for how to install the package on ubuntu and how to build the environment, pls refer to the bsp user guide, for how to build the branch morty, try to use the command as below: MACHINE=imx6qsabresd source fsl-setup-release.sh -b build_qt5 -e fb step 2: for how to enable the opencv, pls add the command as below in the local.conf, the path is fsl-release-bsp/build/conf, "CORE_IMAGE_EXTRA_INSTALL += "libopencv-core-dev libopencv-highgui-dev libopencv-imgproc-dev libopencv-objdetect-dev libopencv-ml-dev" CORE_IMAGE_EXTRA_INSTALL += "opencv-apps opencv-dev python-opencv python-modules"" then build again by bitbake. then you can find the image in the fsl-release-bsp/build/tmp/deploy/images/im6qsabresd/, one can find the opencv libary when extracting the rootfs file step 3: then you can use dd command or mfgtool downloading the image file to the board and use the opencv libary file. other usage: one can install the populate_sdk to build the source code, for opencv 3.1, maybe you will find some g++ issue to fix, so just simple introduce this use the command: bitbake -c populate_sdk fsl-image-gui(for example)  then you can find the sdk install file in the fsl-release-bsp/build_x11/tmp/deploy/sdk, run the install file, set the installation file in the /opt/poky, then you can find the toolchain in the /opt/poky after install successfully.

Here is the explaination of relationship of SD-CAN, SD-MAN, 6233, 6003, 3002: AR6003 + AR3002 = AR6233 AR6233 + RF Components = SX-SDMAN-2830S SX-SDMAN-2830S + SDIO CONN = SX-SDCAN-2830BT SX-SDCAN-2830BT card is inserted into SD3 slot. BT adaptor board (attached files) is inserted into SD1 slot. SX-SDCAN-2830BT card is connected with BT adaptor board via 20-pin FFC. Software: signals of SD1 are muxed into UART4 and GPIO for BT application. Below is the description of IO mux on SD1:

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   These are the detailed programming aids for the registers associated with DRAM initialization (DDR3 and LPDDR2) of the MX6DQP (also known as Rev 2 or Dual/Quad Plus), and covers the Sabre_SD boards and DDR3 based Auto Infotainment board. The last work sheet tab in the tool formats the register settings for use with the ARM RealView debugger (.inc) and the DDR Stress Test. It can be manually converted, by the user, to the DS5 .ds format or to a DCD file format used by uboot or other. The programming aids were developed based on NXP development boards and can be customized by the user for their board design. This tool serves as an aid to assist with programming the DDR interface of the MX6DQP and is based on the DDR initialization scripts developed by the R&D team and no guarantees are made by this tool. The following are some general notes regarding this tool: • Refer to the "How To Use" tab in the tool as a starting point to use this tool. • This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance. • The MX6DQP adds a new third party IP called the NoC. The programming for these registers are automatically updated in the tool given a set of user input MMDC parameters and should not be modified manually.

The Compatibility Test Suite Verifier is a supplement to the Compatibility Test Suite. The main difference lies in that the verifier is developed for tests that cannot run on their own so they require user input in order to be tested. These tests would include the audio quality, the touchscreen, accelerometer, camera, etc. There is no “best verifier option”, one CTS complements the other. In this document we will focus on how to perform the Verifier test. Requirements: A PC with the Android SDK installed. Your “Device Under Test” (your development board) Optional >> A second android device with compatible Wifi and Bluetooth Setup Steps: Install de Android SDK on your PC Download the appropriate CTS Verifier APK. The list of APK’s can be found here: https://source.android.com/compatibility/downloads.html Make sure that your Device Under Test has its system date and time set correctly. Install the CTS Verifier APK on the Device Under Test* For more information regarding ADB commands, follow this link: https://community.freescale.com/docs/DOC-102514 Initialization: After the setup is done, you should see the application installed: You will see the list of available tests for manual verification: Video Link : 4502 For each test, you will see detailed instructions to run it, and a “pass” and “fail” buttons. Video Link : 4530 Once you run each test, you will have the posibility to choose the outcome. (in some cases, pass/fail outcome will be determined automatically). The list of tests (for CTS Verifier 5.1_r2) is: Camera: FOV Calibration, Formats, ITS, Intents, Orientation, Video. Car: Car Dock Test Clock: Alarms and Timers Test Device Administration: Policy serialization test, screen lock test. Features: Hardware/Software feature summary Hardware: USB Accessory Test Job Scheduler: Charging constraints, connectivity constraints, idle mode constraints. Location: Battery saving mode test, location mode off test Managed provisioning: BYOD managed provisioning, device owner provisioning Networking: Bluetooth test, Wi-Fi direct test Notifications: CA Cert notification, CA Cert notificacion on boot, notification attention management, notification listener, notificacion package priority Other: Data backup, screen pinning, widget framework Projection: Projection cube, projection multitouch, projection offscreen, projection scrolling, projection video playback, projection widget Security: Keyguard password verification, SUID file scanner. Sensors: Accelerometer mearument, CTS Sensor batching, CTS Sensor integration, CTS sensor test, CTS single sensor test, magnetic field measurement, sensor batching. Streaming: Streaming video quality verifier. Exporting test results: Tap the “save disk” icon. A pop-up will show the path of the report that was created. Video Link : 4531 With the board connected to the PC through USB, pull the report using ADB: To download all reports run : adb pull /mnt/sdcard/ctsVerifierReports/ .

Check memory leakage in media server. Set libc debug level. So libc will record back trace for all memory allocate. setprop libc.debug.malloc 1 Kill mediaserver to let the libc debug take effect. Android will restart mediaserver. busybox killall -HUP mediaserver you will see below log if you setting right. I/libc    ( 3074): /system/bin/mediaserver using MALLOC_DEBUG = 1 (leak checker) Dump all used memory of mediaserver. dumpsys media.player -m Allocation count 297 Total memory 1483423 size   262144, dup    1, 0x401f4c18, 0x400b6152, 0x401a6568, 0x4061a95c, 0x40146cfa, 0x4019639c, 0x40146ec2, 0x4014a1ec, 0x4014a3ca, 0x00008a98, 0x400b67aa size   178192, dup    1, 0x401f4c18, 0x400b6152, 0x4280adae, 0x427ffcee, 0x4280ae6c, 0x427ec75a, 0x427f7e22, 0x42807648, 0x428082ea, 0x415144f0, 0x4151334a, 0x413381d0, 0x401dcbc, 0x401d438c, 0x4014d996, 0x405c3c46, 0x405c7516, 0x405c6ad4, 0x412c02ca, 0x412c0584, 0x4108c64c, 0x4107d622, 0x4107fbf2, 0x4107c19a, 0x400b2eac, 0x400b2a00 Diff two times of memory dump to check if there is any memory leakage. You can playback one video file between the dump. diff 1.txt 2.txt > diff.txt Get maps file of mediaserver. adb pull proc/<pid of mediaserver>/maps . Use attached script to map back trace to function symbols and file line. ./addr2func.py --root-dir=../../ --maps-file=./maps --product=sabresd_6dq diff.txt Notes: should use eng build for the debug.

** If you cannot access the www.youtube.com you may watch the Wi-Fi Display Sink Demo in here: ** ********      http://v.youku.com/v_show/id_XNzczMzQ2MTc2.html             ******** We already have the strong i.MX 6 to support the Android kitkat now. So we also develop the WiFi Display Sink in it. With Wi-FI Display technology we can cast the screen and audio to another one via Wi-Fi P2p. It's also named the Miracast. Freescale extends Android by offering a Wi-Fi Display Sink feature. The Wi-Fi hardware module used for this feature are the Realtek RTL8821AS , RTL8723AS and AR6233 SDIO Cards. But the design of this feature allows porting to any Wi-Fi hardware module. Using the Freescale Wi-Fi Display Sink API and the demonstration application, users can easily develop their own Sink Application. This feature has been verified using several of the most popular Android phones and tablets. Our Wi-Fi Display has the following highlight feature: Low latency Support UIBC (When Source device uses Freescale Android maddev_kk4.4.3-2.0.0) Rapid recovery from network congestion Compatibility to different vendor Wi-Fi chips and Wi-Fi Display devices From the demo video we can cast the stopwatch and measure the latency by it. Here are the high quality video shots and we can calculate the real latency which less than 200ms!      For the WiFi Display Spec the orange ones in below figure were achieved in our WiFi Display. Reference pages:       Miracast - Wikipedia       Wi-Fi CERTIFIED Miracast | Wi-Fi Alliance             For more information and details about Wi-Fi Display Sink in i.MX6, please send inquiry to [email protected] .

Some processor’s GPIO settings on the i.MX Pins Tool version 7 may not show allow to select direction and just show an option “Input/Output” as shown. This will be fixed, but the settings can be changed on the local processor data as a workaround. For more information and documentation for the Pins Tool for i.MX please visit its home page on the link below: https://www.nxp.com/design/designs/pins-tool-for-i-mx-application-processors:PINS-TOOL-IMX   First, find where the Pins Tool data package is stored. To do this open the Pins Tool and click Help > About. On the About screen click the Details button. Take also note of the name of the package that needs to be fixed.   Go to the location where the data package is stored and find the processor data. The file that would need to be updated is signal_configuration.xml    Find the GPIO pin data and change the directions from the string ““inOut”to the string “in out”. Then save this file.    Close and reopen the Pins Tool. The direction on the updated package should now show the options Input and Output.  

For IMX8QM and iMX8QXP, the DDR config is in SCFW porting kit with DDR script. After boot, for iMX8QM, the LPDDR4 clock is set to 1.6GHz, and for iMX8QXP, after boot, the LPDDR4 clock is set to 1.2GHz. Their clock source is a HPPLL (High Performance PLL) , the HPPLL work frequency range is 1.25GHz to 2.5GHz. But for some product, due to some EMC signal test requirement, sometimes we need adjust the DDR clock a little, the attached patches can be used as reference to do such test. iMX8QM:    HPPLL = 1600MHz, DRC clock = 800MHz, DDR clock = 1600MHz. iMX8QXP:    HPPLL = 2400MHz, DRC clock = 600MHz, DDR clock = 1200MHz. After applied attached two reference patches in SCFW porting kit, they will be: iMX8QM:    HPPLL = 1584MHz, DRC clock = 792MHz, DDR clock = 1584MHz. iMX8QXP:    HPPLL = 2388MHz, DRC clock = 597MHz, DDR clock = 1194MHz. If you want to try set other clock frequency for iMX8QM, you can change the followed lines: ......  uint32_t rate2 = SC_792MHZ;  /* DRC clock */ ......  DSC_AIRegisterWrite(0x12,0,4,0x00000084);  /* DRC_0: (24M*0x84/2) = 1584M, valid dividder: 0x68~0xD0 */  //This is the HPPLL frequency ......  DSC_AIRegisterWrite(0x28,0,4,0x00000084);  /* DRC_1: (24M*0x84/2) = 1584M, valid dividder: 0x68~0xD0 */  //This is the HPPLL frequency ...... If you want to try set other clock frequency for iMX8QXP, you can change the followed lines: ......  uint32_t rate2 = 597000000U;  /* DRC clock */ ......  DSC_AIRegisterWrite(0x24,0,4,0x000000C7);  /* DRC_0: (24M*0xC7/2) = 2388M, valid dividder: 0x68~0xD0 */  //This is the HPPLL frequency ......

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.

Default Ethernet feature is removed for Android Auto (both Android_Pie9.0 and Android10) Below are the patched to bring Ethernet feature back to Android Auto. Please try to apply the according patches if you want to enable Ethernet. For Android_Pie9.0_Auto(example with car2 build): --- a/arch/arm64/configs/android_car2_defconfig +++b/arch/arm64/configs/android_car2_defconfig @@ -245,7 +245,7 @@ CONFIG_DM_VERITY_FEC=y CONFIG_NETDEVICES=y CONFIG_MACVTAP=m CONFIG_TUN=y -# CONFIG_ETHERNET is not set +CONFIG_ETHERNET=y CONFIG_MDIO_BUS_MUX_MMIOREG=m CONFIG_AT803X_PHY=m CONFIG_MARVELL_PHY=m @@ -517,7 +517,7 @@ CONFIG_SQUASHFS=y CONFIG_SQUASHFS_DECOMP_MULTI=y CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_LZ4=y -# CONFIG_NETWORK_FILESYSTEMS is not set +CONFIG_NETWORK_FILESYSTEMS=y   --- a/imx8q/mek_8q/mek_8q.mk +++ b/imx8q/mek_8q/mek_8q.mk @@ -46,6 +46,7 @@ PRODUCT_COPY_FILES += \      $(IMX_DEVICE_PATH)/fstab.freescale.car:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.freescale \      $(IMX_DEVICE_PATH)/early.init_car.cfg:$(TARGET_COPY_OUT_VENDOR)/etc/early.init.cfg \      $(IMX_DEVICE_PATH)/required_hardware_auto.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/required_hardware.xml \ +    frameworks/native/data/etc/android.hardware.ethernet.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.ethernet.xml \      device/fsl/imx8q/init.recovery.freescale.car.rc:root/init.recovery.freescale.rc   For Android10_Auto,(example with car build): --- a/arch/arm64/configs/android_car_defconfig +++ b/arch/arm64/configs/android_car_defconfig @@ -23,6 +23,8 @@ CONFIG_SCHED_AUTOGROUP=y CONFIG_SCHED_TUNE=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y +CONFIG_FEC=y +CONFIG_AT803X_PHY=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set @@ -246,7 +248,6 @@ CONFIG_DM_VERITY=y CONFIG_DM_VERITY_FEC=y CONFIG_NETDEVICES=y CONFIG_TUN=y -# CONFIG_ETHERNET is not set   --- a/imx8q/mek_8q/mek_8q.mk +++ b/imx8q/mek_8q/mek_8q.mk @@ -46,6 +46,7 @@ PRODUCT_COPY_FILES += \      $(IMX_DEVICE_PATH)/fstab.freescale.car:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.freescale \      $(IMX_DEVICE_PATH)/early.init_car.cfg:$(TARGET_COPY_OUT_VENDOR)/etc/early.init.cfg \      $(IMX_DEVICE_PATH)/required_hardware_auto.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/required_hardware.xml \ +    frameworks/native/data/etc/android.hardware.ethernet.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.ethernet.xml \      device/fsl/imx8q/init.recovery.freescale.car.rc:root/init.recovery.freescale.rc   Note: Please also check for below file, if fec1 is disabled, please also apply below diff. --- a/arch/arm64/boot/dts/freescale/imx8qm-mek-car2.dts +++ b/arch/arm64/boot/dts/freescale/imx8qm-mek-car2.dts @@ -147,10 +147,6 @@ status = "disabled"; }; -&fec1 { - status = "disabled"; -}; - &fec2 { status = "disabled"; };

CLBlast (https://github.com/CNugteren/CLBlast) is a modern, lightweight, performant and tunable OpenCL BLAS library written in C++11. CLBlast implements BLAS routines: basic linear algebra subprograms operating on vectors and matrices. I enable the library on i.MX8MQ EVK/ i.MX8QXP MEK based on Vivante GPU GC7000L and  i.MX8QM MEK Vivante GPU GC7000XSVX. And I also tune its performance on i.MX8MQ/8QM/8QXP following https://github.com/CNugteren/CLBlast/blob/master/doc/tuning.md. The attached Yocto Recipe bb file base on L4.14.98 GA release.

The Linux L4.14.98_1.0.0_GA; and SDK2.5 for 8QM/8QXP Post GA, SDK2.5.1 for 7ULP GA3 release are now available. Linux on IMX_SW web page, Overview -> BSP Updates and Releases -> Linux L4.14.98_2.0.0 SDK on https://mcuxpresso.nxp.com Files available: Linux:  # Name Description 1 imx-yocto-L4.14.98_2.0.0_ga.zip L4.14.98_2.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 L4.14.98_2.0.0_ga_images_MX6QPDLSOLOX.zip i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo, i.MX 6Solox Linux Binary Demo Files 3 L4.14.98_2.0.0_ga_images_MX6SLLEVK.zip i.MX 6SLL EVK Linux Binary Demo Files 4 L4.14.98_2.0.0_ga_images_MX6UL7D.zip i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 L4.14.98_2.0.0_ga_images_MX7DSABRESD.zip i.MX 7Dual SABRESD Linux Binary Demo Files  6 L4.14.98_2.0.0_ga_images_MX7ULPEVK.zip i.MX 7ULP EVK Linux Binary Demo Files  7 L4.14.98_2.0.0_ga_images_MX8MMEVK.zip i.MX 8MMini EVK Linux Binary Demo Files  8 L4.14.98_2.0.0_ga_images_MX8MQEVK.zip i.MX 8MQuad EVK Linux Binary Demo files 9 L4.14.98_2.0.0_ga_images_MX8QMMEK.zip i.MX 8QMax MEK Linux Binary Demo files 10 L4.14.98_2.0.0_ga_images_MX8QXPMEK.zip i.MX 8QXPlus MEK Linux Binary Demo files 11 imx-scfw-porting-kit-1.2.tar.gz System Controller Firmware (SCFW) porting kit of L4.14.98_2.0.0 12 imx-aacpcodec-4.4.5.tar.gz Linux AAC Plus Codec v4.4.5 13 VivanteVTK-v6.2.4.p4.1.7.8.tgz Vivante Tool Kit v6.2.4.p4.1.7.8   SDK: On https://mcuxpresso.nxp.com/, click the Select Development Board, EVK-MCIMX7ULP//MEK-MIMX8QM/MEK-MIMX-8QX to customize the SDK based on your configuration then download the SDK package.  Target board: MX 8 Series MX 8QuadXPlus MEK Board MX 8QuadMax MEK Board MX 8M Quad EVK Board MX 8M Mini EVK Board MX 7 Series MX 7Dual SABRE-SD Board MX 7ULP EVK Board MX 6 Series MX 6QuadPlus SABRE-SD and SABRE-AI Boards MX 6Quad SABRE-SD and SABRE-AI Boards MX 6DualLite SDP SABRE-SD and SABRE-AI Boards MX 6SoloX SABRE-SD and SABRE-AI Boards MX 6UltraLite EVK Board MX 6ULL EVK Board MX 6ULZ EVK Board MX 6SLL EVK Board What’s New/Features: Please consult the Release Notes.   Known issues For known issues and more details please consult the Release Notes.   More information on changes of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-sumo ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-sumo#