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. i.MX 8M Family DDR Tools Overview The i.MX 8M Family DDR Tool is a Windows-based software to help users to do LPDDR4/DDR4/DDR3L training, stress test and DDR initial code generation for u-boot SPL.  This page contains the latest releases for the i.MX 8M Family DDR Tools and cover the following SoCs : i.MX 8M Quad and its derivatives i.MX 8 M Quadlite and i.MX 8M Dual i.MX 8M Mini Quad and its derivatives i.MX 8M Mini Quadlite/Dual/DualLite/Solo/SoloLite  i.MX 8M Nano Quad and   its derivatives i.MX 8M Nano Quadlite/Dual/DualLite/Solo/SoloLite  i.MX 8M Plus   NOTE: For the i.MX 8/8X Family of DDR tools please refer to the: i.MX 8/8X Family DDR Tools Release   The purpose of the i.MX 8M Family DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.).  This process equips the user to then proceed with the bring-up of a boot loader and an OS.  Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface.     The  i.MX 8M Family DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test   For more details regarding these DDR tools and their usage, refer to the i.MX 8M DDR Tools User Guide.   i.MX 8M Family DDR Register Programming Aid (RPA) The i.MX 8M DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization(in a separate Excel worksheet tab):   DDR Stress Test Script : This format is used specifically with the DDR stress test by first copying the contents in this worksheet tab and then pasting it to a text file, naming the document with the “.ds” file extension. The user will select this file when executing the DDR stress test. The How to Use  Excel worksheet tab provides instructions on using the RPA   i.MX 8M Family DDR Register Programming Aid (RPA): Current Versions To obtain the latest RPAs, please refer to the following links (note, existing RPAs have been removed from this main page and moved to the SoC specific links below): i.MX 8M Quad : https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8M-m850D-DDR-Register-Programming-Aid-RPA/ta-p/1172441 i.MX 8M Mini : https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MMini-m845S-DDR-Register-Programming-Aid-RPA/ta-p/1172443 i.MX 8M Nano: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MNano-m815S-DDR-Register-Programming-Aid-RPA/ta-p/1172444 i.MX 8M Plus: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MP-m865-DDR-Register-Programming-Aid-RPA/ta-p/1235352   Processor Mask Revisions Memory Supported Latest RPA Version * i.MX 8M Quad & Derivatives All LPDDR4 Rev 25 i.MX 8M Quad & Derivatives All DDR4 Rev 11 i.MX 8M Quad & Derivatives All DDR3L Rev 6 i.MX 8M Mini  & Derivatives A0 LPDDR4 Rev 16 i.MX 8M Mini  & Derivatives A0 DDR4 Rev 12 i.MX 8M Mini  & Derivatives A0 DDR3L Rev 7 i.MX 8M Nano  & Derivatives A0 LPDDR4 Rev 3 i.MX 8M  Nano   & Derivatives A0 DDR4 Rev 4 i.MX 8M  Nano   & Derivatives A0 DDR3L Rev 2 i.MX 8M Plus & Derivatives A1 LPDDR4 Rev 4 i.MX 8M Plus & Derivatives A1 DDR4 Rev 1 * For the details about the updates, please refer to the Revision History tab of the respective RPA.    To modify the DRAM Frequency for a custom setting refer to iMX 8M Mini Register Programming Aid DRAM PLL setting    i.MX 8M Family DDR Stress Test    The i.MX 8M Family  DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational for use with u-boot and OS bring-up. To install the DDR Stress Test, save and extract the zip file mscale_ddr_tool_vXXX_setup.exe.zip     (where 'xxx' is the current version number) and follow the on-screen installation instructions.     i.MX 8M Family DDR Stress Test   Requirements   The tool requires access to the Windows registry, hence  users must run it in administrator mode . When users design new i.MX 8M Family boards, please make sure to follow the rules outlined in the respective Hardware Developers Guide and the MSCALE_DDR_Tool_User_Guide , which can help users bring up DDR devices on their respective i.MX 8M boards.   i.MX 8M Family DDR Stress Test  User Guide   The i.MX 8M DDR Stress Test tool includes the document: MSCALE_DDR_Tool_User_Guide NOTE: Please read the MSCALE_DDR_Tool_User_Guide inside the package carefully before you use this tool.   DDR Stress Test Revision History   Rev Major Changes* (Features) Comments 3.20 Add support to i.MX 8M Plus   3.10 Fixed UART communication issues for some specific characters between the PC software and the target board. Fine-tune DDRPHY registers in generated C code.   3.00 Add support to i.MX8M-nano Add support to different PMIC or PMIC configuration Add support to stress test for all DDR frequency points RPA tools for Nano include support for DDR3L, DDR4, and LPDDR4.   Note that the DDR3L and LPDDR4 RPAs contain the name preliminary only to denote that these RPAs are based on internal NXP validation boards where the DDR4 RPA is based on the released EVK.   2.10 Change DDR4 capacity computing method   2.00 Add support to i.MX8M-mini   * Further details available in the release notes   Sample configuration in the .ds script for i.MX 8M debug UART2: ################step 0: configure debug uart port. Assumes use of UART IO Pads.   ##### ##### If using non-UART pads (i.e. using other pads to mux out the UART signals), ##### ##### then it is up to the user to overwrite the following IO register settings   ##### memory set 0x3033023C 32 0x00000000 #IOMUXC_SW_MUX_UART2_RXD memory set 0x30330240 32 0x00000000 #IOMUXC_SW_MUX_UART2_TXD memory set 0x303304A4 32 0x0000000E #IOMUXC_SW_PAD_UART2_RXD memory set 0x303304A8 32 0x0000000E #IOMUXC_SW_PAD_UART2_TXD memory set 0x303304FC 32 0x00000000 #IOMUXC_SW_MUX_UART2_SEL_RXD sysparam set debug_uart   1 #UART index from 0 ('0' = UART1, '1' = UART2, '2' = UART3, '3' = UART4)   Sample configuration in the front of the .ds script for i.MX 8M debug UART3  ################step 0: configure debug uart port. Assumes use of UART IO Pads.   ##### ##### If using non-UART pads (i.e. using other pads to mux out the UART signals), ##### ##### then it is up to the user to overwrite the following IO register settings   ##### memory set 0x30330244 32 0x00000000 #IOMUXC_SW_MUX_UART3_RXD memory set 0x30330248 32 0x00000000 #IOMUXC_SW_MUX_UART3_TXD memory set 0x303304AC 32 0x0000000E #IOMUXC_SW_PAD_UART3_RXD memory set 0x303304B0 32 0x0000000E #IOMUXC_SW_PAD_UART3_TXD memory set 0x30330504 32 0x00000002 #IOMUXC_SW_MUX_UART3_SEL_RXD sysparam set debug_uart   2 #UART index from 0 ('0' = UART1, '1' = UART2, '2' = UART3, '3' = UART4)   Sample configuration in the front of the .ds script for i.MX 8M Mini PMIC configuration: ##############step 0.5: configure I2C port IO pads according to your PCB design.   ##### ########### You can modify the following instructions to adapt to your board PMIC ####### memory set 0x30330214 32 0x00000010  #IOMUXC_SW_MUX_I2C1_SCL memory set 0x30330218 32 0x00000010  #IOMUXC_SW_MUX_I2C1_SDA memory set 0x3033047C 32 0x000000C6 #IOMUXC_SW_PAD_I2C1_SCL memory set 0x30330480 32 0x000000C6  #IOMUXC_SW_PAD_I2C1_SDA sysparam set pmic_cfg 0x004B #bit[7:0] = PMIC addr,bit[15:8]=I2C Bus. Bus index from 0 ('0' = I2C1, '1' = I2C2, '2' = I2C3, '3' = I2C4) sysparam set pmic_set 0x2F01 #bit[7:0] = Reg val, bit[15:8]=Reg addr. #REG(0x2F) = 0x01 sysparam set pmic_set 0x0C02   #REG(0x0C) = 0x02 sysparam set pmic_set 0x171E   #REG(0x17) = 0x1E sysparam set pmic_set 0x0C00   #REG(0x0C) = 0x00 sysparam set pmic_set 0x2F11    #REG(0x2F)=0x11   Related Resources Links: iMX 8M Mini Register Programming Aid DRAM PLL setting  i.MX 8/8X Series DDR Tool Release  i.MX 6/7 DDR Stress test GUI Tool i.MX 8M Application Processor Related Resources i.MX8M (m850D) DDR Register Programming Aid (RPA)  i.MX8MMini (m845S) DDR Register Programming Aid (RPA)  i.MX8MNano (m815S) DDR Register Programming Aid (RPA) 

Voltage overshoot (>1.8V) is found on VDD_ARM_SSOC_IN when the EVK board is powered down by POWER BUTTON long pressed after the Linux kernal loaded. It would not happen if only U-boot is run. It happens also when the system recovers from idle. The overshoot is out of i.MX6UL maximum rating.

  This is a detailed programming aid for the registers associated with i.MX 8M (m850D) DDR initialization.  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467  

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. i.MX 8/8X DDR Tools Overview   This page contains the latest releases for the i.MX 8/8X DDR Tools. The tools described on this page cover the following i.MX 8/8X Family SoCs with the System Controller Unit (SCU): i.MX 8QuadMax and its derivatives i.MX 8QuadPlus i.MX 8QuadXPlus and its derivatives i.MX 8DualXPlus and i.MX 8DualX  NOTE: For the i.MX 8M Family of DDR tools please refer to the :  i.MX 8M Family DDR Tool Release                            The purpose of the i.MX 8/8X DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.).  This process equips the user to then proceed with the bring-up of a boot loader and an OS.  Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface.     The  i.MX 8/8X DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test   For more details regarding these DDR tools and their usage, refer to the MX8X_DDR_Tools_quickstart_guide.pdf attached to this page.   i.MX 8/8X DDR Register Programming Aid (RPA)   The i.MX 8/8X DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization in two formats (in separate Excel worksheet tabs):   DDR Stress Test script: This format is used specifically with the DDR stress test by first copying the contents in this worksheet tab and then pasting it to a text file, naming the document with the “.ds” file extension. The user will select this file when executing the DDR stress test. DCD CFG file: This format is the configuration file used specifically by the SCU Firmware (SCFW). In this scenario, the user copies the contents in this worksheet tab and pastes it to a text file, naming the document with the “.cfg” file extension and placing this file in the appropriate SCFW board file directory.   i.MX 8/8X DDR Register Programming Aid (RPA): Current Versions Note: In all cases, the RPA revision is aligned to a minimum SCFW version as shown in the table below. In some cases, the BSP alignment is provided as extra detail, however, the RPA tool is specifically aligned to a minimum SCFW version and later. To obtain the latest RPAs, please refer to the following links (note, existing RPAs have been removed from this main page and moved to the SoC specific links below): i.MX8QM: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX8QXP/QXP/DX: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302   Processor Mask Revisions Memory Supported Latest RPA Version * Notes i.MX 8QM B0 LPDDR4 Rev 23*** Rev 22** Rev 21** Rev 20** Rev 19** Rev 23: IMPORTANT: this is aligned to SCFWv1.7.0. When using SCFWv1.7.0, you must use this version or later RPA and cannot use earlier versions of the RPA. See note a end of table. Rev22: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 21: Fixed 1 DRC operation to comment out calls to VREF training to DRC1 and added DDRC_SCHED register programming to align with latest SCFW programming (refer to RPA revision history for more details). Rev 20: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 19: use with SCFW 1.3.1 and N XP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 LPDDR4 Rev 16*** Rev 15** Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0. When using SCFWv1.7.0, you must use this version or later RPA and cannot use earlier versions of the RPA. See note a end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0   later  (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and N XP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 DDR3L Rev 22*** Rev 21 Rev 20 Rev 22: IMPORTANT: this is aligned to SCFWv1.7.0. When using SCFWv1.7.0, you must use this version or later RPA and cannot use earlier versions of the RPA. See note a end of table. Rev 21: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW. -Compatible with SCFW 1.1.10 and later -Changes made to this revision do not affect the DCD CFG file output based on v19 -Issue discovered in the DDR stress test script, wherein certain commands were not being properly configured based on the ECC setting in the Register Configuration worksheet; this was resolved (cells A84, A87, A90, A93 ) -In addition, in both DCD CFG and DDR stress test script worksheets, all commands that depend on ECC config have been updated to include an "OR" with whether or not the data bus is configured for 16-bit (ECC is only supported for full 32-bit data bus width configurations) i.MX 8DualX C0, B0 LPDDR4 Rev 16*** Rev 15* Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0. When using SCFWv1.7.0, you must use this version or later RPA and cannot use earlier versions of the RPA. See note a end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0   later  (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and N XP BSP GA version L5.4.3_1_0_0 i.MX 8DualX C0, B0 DDR3L Rev 20*** Rev 19 Rev 18 Rev 20: IMPORTANT: this is aligned to SCFWv1.7.0. When using SCFWv1.7.0, you must use this version or later RPA and cannot use earlier versions of the RPA. See note a end of table. Rev 19: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  -Compatible with SCFW 1.1.10 and later * For a history of the previous versions of an RPA, refer to the Revision History tab of the respective RPA.  ** In general, it is recommended to use the latest RPA tool even with a pre-released BSP as it ensures you are testing with the latest fixes and features. Older versions of the RPA may be provided to support existing/released versions of the BSP.  This only applies to those RPA tools that are compatible with pre-release BSPs but may not be compatible with released versions of the BSP.   ***IMPORTANT: as stated in the table above, for the noted RPA version, it is aligned to SCFWv1.7.0.  Older versions of the RPA are not aligned to SCFWv1.7.0.  If trying to use an older version of an RPA with SCFWv1.7.0, it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QXP/DualX: DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ For MX8QM: DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QXP: [remove] ifndef SCFW_DCD [remove] /* For 1200MHz DDR, DRC 600MHz operation */ [remove] DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ [remove] #else <keep code as is> [remove] #endif   i.MX 8/8X DDR Stress Test    The i.MX 8/8X  DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational prior to building the SCFW for use with u-boot and OS bring-up. The DDR stress test uses the .ds DDR stress test script generated from the RPA tool along with a special build of the SCFW, built with option: DDR_CON=ddr_stress_test_parser Or in the case of i.MX 8QuadMax use of one DDR Controller: DDR_CON=ddr_stress_test_parser_DRC0_only The DDR stress test offers a Target option to dictate which SoC is under test. The following are Target options to select from: MX8QM – used to test i.MX 8QuadMax and its derivates i.MX 8QuadPlus MX8QX – used to test i.MX 8QuadXPlus and its derivates i.MX 8DualXPlus/DualX   To install the DDR Stress Test, save and extract the zip file  mx8_ddr_stress_test_ERxx_installation.zip    (where 'xx' is the current version number) and follow the on-screen installation instructions. Note, when extracting the DDR Stress Test tool .zip file, it is recommended to perform an "Extract here" operation.  Some systems do not allow for the extracted installation executable to run from another folder and will only work when being executed from the same location as the original, downloaded zip file.  For more details on the DDR stress test usage, refer to the MX8_DDR_Tool_User_Guide found in the DDR Stress Test tool delivery. NOTE:  Before using the DDR tools on a new custom board, the user should properly port the SCU Firmware (SCFW) to this new board. The DDR tools will not be able to run without a properly ported and working SCFW.            i.MX 8/8X DDR Stress Test   Requirements The tool requires access to the Windows registry, hence  users must run it in administrator mode . The tool cannot run on an OEM closed device that requires images signed by the customer When users design new i.MX 8/8X boards, please make sure to follow the rules outlined in the respective Hardware Developers Guide and the  MX8_DDR_Tool_User_Guide , which can help users bring up DDR devices on their respective i.MX 8/8X boards.   i.MX 8/8X DDR Stress Test  SECO Firmware It is generally not recommended to update the SECO (ahab) firmware that comes default with the DDR Stress Test. This is not recommended because the purpose of the DDR Stress Test is to test the DDR memory interface, not the entire SCFW to SECO firmware operation even though a newer version of the SCFW may complain that the SECO firmware version is not the latest. The SECO firmware version that comes with the DDR Stress Test has been tested and proven to work by the factory before the DDR Stress Test release; updating the SECO firmware to a different version may result in unintended consequences rendering the DDR stress test inoperable. In most cases, it is allowable to update only the SCFW without updating the SECO firmware. Should the user wish to update the SECO firmware version in the DDR Stress Test, then they will need to rename this firmware without the silicon version (for example, if updating the MX8QM SECO firmware, the user will need to rename mx8qmb0-ahab-container.img to mx8qm-ahab-container.img, basically remove the “b0”). The exception is for the MX8QXP, if updating the C0 silicon version SECO firmware, then the user should maintain the C0 nomenclature. If the user finds that the updated SECO firmware causes the DDR Stress Test to become inoperable, then it is recommended to revert to the default SECO firmware version that came with the DDR Stress Test release. i.MX 8/8X DDR Stress Test  User Guide The i.MX 8/8X DDR Stress Test tool includes the document: MX8_DDR_Tool_User_Guide.pdf NOTE: Please read the  MX8_DDR_Tool_User_Guide inside the package carefully before you use this tool.   DDR Stress Test Revision History   Rev Major Changes (Features) NXP BSP Software Version ER 14 Updated to support parsing of the VREF training command in the DDR Stress Test script This version is aligned with NXP BSP GA version L5.4.3_2_0_0 and later.    Related Resources Links: i.MX 8M Family DDR Tool Release  i.MX 6/7 DDR Stress test GUI Tool i.MX 8QM RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX 8QXP/DXP/DX RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302   FAQs: Q. When the DDR stress test is running, it indicates testing region 1 and then region 2. What is region 1 and region 2? A. There are two distinct DDR memory regions in the i.MX8X series which is due to the architecture of Cortex A core and the associated memory map of the i.MX8X. Region 1 is the 32-bit region, starting at 0x080000000 and ending at 0x0FFFFFFFF (2GB total) Region 2 is the 64-bit region (for the Cortex A core architecture), starting at 0x880000000 and ends at the remaining density: • For 4GB total on board density, 2GB for region 1 and 2GB for region 2, so region 2 will end at 0x8FFFFFFFF (0x900000000 minus 1) • For 6GB total (NXP board density), 2GB for region 1 and 4GB for region 2, so region 2 will end at 0x97FFFFFFF (0x980000000 minus 1) • For 8GB total, 2GB for region 1 and 6GB for region 2, so region 2 will end at 0x9FFFFFFFF (0xA00000000 minus 1) Hence there is a “hole” in the memory map between region 1 and region 2. As such, the DDR stress test first tests the lower region (region 1) until it is exhausted (up to 2GB), and if the DDR density exceeds 2GB, the test will test the remaining density in region 2. Q. Do the i.MX8X series SoCs support LPDDR4 memories with 17 row addresses (R[16:0])? A. The i.MX8QM, i.MX8QXP, and i.MX8DXP SoCs and their derivatives cannot support newer 17-row-address LPDDR4 memories. This means, in order to support the maximum 4GB (32Gb) LPDDR4 density, the configuration must be 16-row, 2 rank (as opposed to the unsupported 17-row, 1 rank). The upcoming i.MX8DXL is planned to support 17-row address LPDDR4 devices. Q. I can select a different i.MX8X AP UART port when running the DDR Stress Test? A. It is highly recommended to follow NXP board designs including selecting the same UART ports; this eases the user’s software porting efforts and minimizes issues with needless debugging. The DDR Stress Test requires the use of the USB OTG port and the AP UART port (and it is highly recommended to connect the SCFW UART port for SCFW debug messages). To date, the factory sees no reason why the user would need to select a different AP UART port than what is used on NXP boards. Selecting the same AP UART port ensures a faster bring up of the DDR stress test rather than needlessly debugging why a different UART port is not working. In any event, some wish to use a different UART port for whatever reason, as such, NXP has placed work arounds to allow the selection of a different UART port. To select a different UART port (0,1, or 2), the user simply needs to add the following line to the end of the DDR Stress Test DDR initialization (.ds) script: memory set  0x5C01042C 32   <UART port value> memory set  0x5C01042C 32   0x00000000   # UART0 port selection for AP UART (default) memory set  0x5C01042C 32   0x00000001   # UART1 port selection for AP UART memory set  0x5C01042C 32   0x00000002   # UART2 port selection for AP UART Note that UART ports 0, 1, and 2 have pad names that are default UART pins (IOMUX ALT0 config). To date, the DDR tools do not support other UART ports that are mux’d out on other non-default UART pins. However, there is an exception for i.MX8QXP/DXP and the upcoming i.MX8DXL where UART3 mux’d out on FLEXCAN2 can be used. To select this, add the following to the end of the .ds file: memory set  0x5C01042C 32   0x00000003   # UART3 port selection for AP UART (exception for i.MX8QXP/DXP and i.MX8DXL) Some RPAs do have support built in (via a pull down menu) to select the UART port. For those RPAs that do not have this feature, this is due to the fact that these RPA (NXP boards) were not tested with a different UART port as the board requires cutting traces and re-wiring the UART signals and some boards may not have these UART traces readily available. However, the user is still able to manually add this UART port selection. Refer to the following RPAs to see the UART port select option: MX8QXP DDR3 MX8DXP DDR3

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 i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/1121519   To reduce the number of attachments, older RPAs may be found in the attached zip file.   ***IMPORTANT: For SCFWv1.7.0, you must use the following RPA versions or later: MX8QXP_C0_B0_LPDDR4_RPA_1.2GHz_v16 MX8DualX_C0_B0_LPDDR4_RPA_1.2GHz_v16 MX8QuadXPlus_DualXPlus_C0_B0_DDR3L_RPA_v22 MX8DualX_C0_B0_DDR3L_RPA_v20 Older versions of the RPA are not aligned to SCFWv1.7.0.  If trying to use an older version of an RPA with SCFWv1.7.0, it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QXP/DualX: DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QXP: [remove] #ifndef SCFW_DCD [remove] -/* For 1200MHz DDR, DRC 600MHz operation */ [remove] DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ [remove] #else <keep code as is> [remove] #endif

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 i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/1121519   To reduce the number of attachments, older RPAs may be found in the attached zip file.   ***IMPORTANT: For SCFWv1.7.0, you must use the following RPA versions or later: MX8QM_B0_LPDDR4_RPA_1.6GHz_v23 Older versions of the RPA are not aligned to SCFWv1.7.0.  If trying to use an older version of an RPA with SCFWv1.7.0, it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QM: DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QM: [remove] #ifndef SCFW_DCD [remove] /* For 1600MHz DDR, DRC 800MHz operation */ [remove] DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ [remove] DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ [remove] #else <keep code as is> [remove] #endif  

    The meta layer is designed for those guys who want to use i.MX8M series SOC and Yocto system to develop AGV and Robot.    The platform includes some key components: 1, ROS1 (kinetic, melodic) and ROS2(dashing, eloquent, foxy) 2, Real-time Linux solution : Xenomai 3.1 with ipipe 5.4.47 patch 3, Industrial protocol : libmodbus, linuxptp, ros-canopen, EtherCAT(TBD) 4, Security: Enhanced OpenSSL, Enhanced GmSSL, Enhanced eCryptfs, secure key store, secure boot(TBD), SE-Linux(TBD),  Dm-verity(TBD) The first release bases on i.MX Yocto release L5.4.47 2.2.0 and You need download Linux 5.4.47_2.2.0 according to​​ https://www.nxp.com/docs/en/user-guide/IMX_YOCTO_PROJECT_USERS_GUIDE.pdf  firstly. And then you can follow the below guide to build and test ROS and Xenomai. A, use 7-zip to decompress attached file to get meta-robot-platform-v0.1-L5.4.47-2.2.0.tar.gz unzip meta-robot-platform-v0.1-L5.4.47-2.2.0.tar.7z.001.zip and meta-robot-platform-v0.1-L5.4.47-2.2.0.tar.7z.002.zip to get meta-robot-platform-v0.1-L5.4.47-2.2.0.tar.7z.001 and meta-robot-platform-v0.1-L5.4.47-2.2.0.tar.7z.002, and use 7-zip to merge and unzip meta-robot-platform-v0.1-L5.4.47-2.2.0.tar.7z.001 and meta-robot-platform-v0.1-L5.4.47-2.2.0.tar.7z.002 to get get meta-robot-platform-v0.1-L5.4.47-2.2.0.tar.gz. B, Adding the meta-robot-platform layer to your build 1, untar get meta-robot-platform-v0.1-L5.4.47-2.2.0.tar.gz and copy meta-robot-platform into <i.MX Yocto folder>/source 2, You should create a symbol link: setup-imx-robot.sh -> sources/meta-robot-platform/imx/meta-robot/tools/setup-imx-robot.sh C, How to build Robot image (example for i.MX8MQ EVK board) $ DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r kinetic -b imx8mqevk-robot-kinetic [or DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r melodic -b imx8mqevk-robot-melodic ] [or DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r dashing -b imx8mqevk-robot-dashing ] [or DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r eloquent -b imx8mqevk-robot-eloquent ] [or DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r foxy -b imx8mqevk-robot-foxy ] $ bitbake imx-robot-core [or bitbake imx-robot-system ] [or bitbake imx-robot-sdk ] And if you add XENOMAI_KERNEL_MODE = "cobalt" or XENOMAI_KERNEL_MODE = "mercury" in local.conf, you also can build real-time image with Xenomai by the below command: $ bitbake imx-robot-core-rt [or bitbake imx-robot-system-rt ] D, Robot image sanity testing //ROS1 Sanity Test #source /opt/ros/kinetic/setup.sh [or # source /opt/ros/melodic/setup.sh ] #echo $LD_LIBRARY_PATH #roscore & #rosnode list #rostopic list #only kinetic #rosmsg list #rosnode info /rosout //ROS2 Sanity Test #source ros_setup.sh #echo $LD_LIBRARY_PATH #ros2 topic list #ros2 msg list #only dashing #ros2 interface list #(sleep 5; ros2 topic pub /chatter std_msgs/String "data: Hello world") & #ros2 topic echo /chatter E, Xenomai sanity testing #/usr/xenomai/demo/cyclictest -p 50 -t 5 -m -n -i 1000 F, vSLAM demo You can find orb-slam2 demo under <i.MX Yocto folder>/sources/meta-robot-platform/imx/meta-robot/recipes-demo/orb-slam2. You should choose DISTRO=imx-robot-xwayland due to it depends on OpenCV with gtk+.   //////////////////////////////////////// update for Yocto L5.4.70 2.3.0  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v0.2-L5.4.70-2.3.0 for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP.  unzip meta-robot-platform-v0.2-L5.4.70-2.3.0.tar.7z.001.zip and meta-robot-platform-v0.2-L5.4.70-2.3.0.tar.7z.002.zip to get meta-robot-platform-v0.2-L5.4.70-2.3.0.tar.7z.001 and meta-robot-platform-v0.2-L5.4.70-2.3.0.tar.7z.002, and use 7-zip to merge and unzip meta-robot-platform-v0.2-L5.4.70-2.3.0.tar.7z.001 and meta-robot-platform-v0.2-L5.4.70-2.3.0.tar.7z.002 to get get meta-robot-platform-v0.2-L5.4.70-2.3.0.tar.gz. Updating: 1, Support i.MX8QM and i.MX8QXP 2, Add ROS driver of RPLIDAR and Orbbec 3D cameras in ROS1 3, Upgrade OpenCV to 3.4.13. 4, Add imx-robot-agv image with orb-slam2 demo 5, Fix the issue which failed to create image when adding orb-slam2 6, Fix the issue which failed to create imx-robot sdk image when add package ISP and ML Note: Currently, orb-slam2 demo don't run on i.MX8MM platform due to its GPU don't support OpenGL ES3.

GmSSL is an open source cryptographic toolbox that supports SM2 / SM3 / SM4 / SM9 and other national secret (national commercial password) algorithm, SM2 digital certificate and SM2 certificate based on SSL / TLS secure communication protocol to support the national security hardware password device , To provide in line with the national standard programming interface and command line tools, can be used to build PKI / CA, secure communication, data encryption and other standards in line with national security applications. For more information, please access GmSSL official website http://gmssl.org/english.html.   Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga cryptodev: 1.9 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/MM, i.MX8QM/QXP. The patches include the following features: 1, Support SM2/SM9   encryption/decryption/sign/verify/ key exchange ,   RSA  encryption/decryption, DSA/ECDSA sign/verify, DH/ECDH key agreement, ECC & DLC & RSA key generation and big number  operation and   e lliptic  c urve   m ath by CAAM hardware   accelerating . 2, run "git apply 0001-Enhance-cryptodev-and-its-engine-in-GmSSL-by-CAAM-s-.patch" under folder sources/poky, and "git apply 0001-Add-public-key-cryptography-operations-in-CAAM-drive.patch"   under folder   sources/meta-fsl-bsp-release for patch these codes. 3, GmSSL Build command: $ tar zxvf GmSSL-master-iMX.tgz $  cd  GmSSL-master-iMX (For i.MX8M/MM, i.MX8QM/QXP) $  source /opt/arm-arch64/environment-setup-aarch64-poky-linux  $  ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHW_ENDIAN_SWAP  --prefix= ~/install64   --openssldir=/etc/gmssl --libdir=/usr/lib no-saf no-sdf no-skf no-sof no-zuc -no-ssl3 shared linux-aarch64 $  make  $  make install                              /*image and config file will be installed to folder   ~ /install64   */   (For  i.MX6UL, i.MX7D/S ) $   source /opt/arm-arch32/environment-setup-cortexa7hf-neon-poky-linux-gnueabi $   ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS --prefix= ~ /install32   --openssldir=/etc/gmssl --libdir=/usr/lib no-saf no-sdf no-skf no-sof no-zuc -no-ssl3 shared linux-armv4 $  make  $  make install                             /*image and config file will be installed to folder   ~ /install32   */   4, How to use GmSSL: copy image gmssl to /usr/bin on i.MX board;  copy  gmssl libcrypto.so.1.1 and libssl.so.1.1 to /usr/lib  on i.MX board; copy folder etc/ gmssl to /etc/ on i.MX board. copy test examples (dhtest, dsatest, rsa_test, ecdhtest, ecdsatest, eciestest, sm3test, sms4test, sm2test, sm9test) under GmSSL-master-iMX/test  to U disk for running. You can run test examples by the following commands: #insmod /lib/modules/4.14.98-imx_4.14.98_2.0.0_ga+g5d6cbeafb80c/extra/cryptodev.ko #/run/media/sda1/dhtest #/run/media/sda1/dsatest #/run/media/sda1/rsa_test #/run/media/sda1/ecdhtest #/run/media/sda1/ecdsatest #/run/media/sda1/eciestest #/run/media/sda1/sm3test #/run/media/sda1/sms4test #/run/media/sda1/sm2test #/run/media/sda1/sm9test and speed test commands: #gmssl speed sm2 #gmssl genrsa -rand -f4 512 #gmssl speed dsa #gmssl genrsa -rand -f4 1024 #gmssl speed rsa #gmssl genrsa -rand -f4 2048 #gmssl speed ecdsa #gmssl genrsa -rand -f4 3072 #gmssl speed ecdh #gmssl genrsa -rand -f4 4096   ++++++++++++++++++++++++++++     updating at 2019-09-10    +++++++++++++++++++++++++++++++++++++++++++++ 0001-fix-the-bug-which-hash-and-cipher-key-don-t-use-DMA-.patch fix the issue which   dismatching on key buffer between crytodev and caam driver. Crytodev uses stack's buffer for key storage and caam driver use it to dma map which cause flush cache failure. The patch need to apply on cryptodev-module in Yocto build.   ++++++++++++++++++  updating at 2019-10-14 +++++++++++++++++++++++++++++++++++ This updating is for China C-V2X application. The package meta-cv2x_4.14.98_2.0.0_ga.tgz is Yocto layer which bases on GmSSL and Cryptodev. I add HW SM2 verification by dedicated CAAM job descriptor and enhanced SW  SM2 verification by precomputed multiples of generator and ARMv8 assembler language to accelerate point  operation.  Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga cryptodev: 1.9 HW platform: i.MX8M/MM/MN, i.MX8QM/QXP. How to build: 1, decompress  meta-cv2x_4.14.98_2.0.0_ga.tgz and copy meta-cv2x to folder (Yocto 4.14.98_2.0.0_ga dir)/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-cv2x and add BBLAYERS += " ${BSPDIR}/sources/meta-cv2x " into ( Yocto 4.14.98_2.0.0_ga dir ) /build-cv2x/conf/bblayers.conf and  IMAGE_INSTALL_append += " gmssl-bin "  into local.conf 3, Run bitbake fsl-image-validation-imx. 4, You can find  cv2x-verify.c under (build dir)/tmp/work/aarch64-poky-linux/cryptodev-tests/1.9-r0/git/tests. It is example for using CAAM cryptdev interface to do C-V2X verification (includes SM2 p256, NIST p256 and brainpoolP256r1).   cv2x_benchmark.c   under ( build dir )/tmp/work/aarch64-poky-linux/gmssl/1.0-r0/gmssl-1.0/test is the benchmark test program of C-V2X verifying. It includes HW, SW and HW+SW(one CPU) verifying for  SM2 p256, NIST p256 and brainpoolP256r1. 5, Run the below command on your i.MX8QXP MEK board. modprobe cryptodev ./cv2x_benchmark Note: the udpated GmSSL also support projective coordinates and affine coordinates (CAAM only support affine  coordinates ). Affine  coordinates is used  by default. You can call EC_GROUP_set_coordinates() and EC_GROUP_restore_coordinates() to change coordinates and restore default. When you hope to use some EC APIs under expected coordinates, you need to call EC_GROUP_set_coordinates() before EC APIs and  EC_GROUP_restore_coordinates()  after them. Like the below example: orig_coordinate = EC_GROUP_set_coordinates(EC_PROJECTIVE_COORDINATES); group = EC_GROUP_new_by_curve_name(NID_sm2p256v1); EC_GROUP_restore_coordinates(orig_coordinate);   ++++++++++++++++++++++++++++     updating at 2020-11-09   +++++++++++++++++++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.47_2.2.0​​. The package meta-gmcrypto_L5.4.47-2.2.0.tgz is Yocto layer which also support c-v2x feature in previous release .  Software environments as the belows: Linux kernel: imx_5.4.47_2.2.0 cryptodev: 1.10 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, decompress meta-gmcrypto_L5.4.47-2.2.0.tgz and copy meta-gmcrypto to folder (Yocto 5.4.47_2.2.0 dir)/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-gmcrypto " into ( Yocto 5.4.47_2.2.0 dir ) /build-imx8mmevk/conf/bblayers.conf and  IMAGE_INSTALL_append += " gmssl-bin "  into local.conf 3, Run bitbake fsl-image-validation-imx. 4, You can find  cv2x-verify.c under (build dir)/tmp/work/aarch64-poky-linux/cryptodev-tests/1.10caam-r0/git/tests. It is example for using CAAM cryptdev interface to do C-V2X verification (includes SM2 p256, NIST p256 and brainpoolP256r1).   cv2x_benchmark.c   under ( build dir )/tmp/work/aarch64-poky-linux/gmssl/1.0-r0/gmssl-1.0/test is the benchmark test program of C-V2X verifying. It includes HW, SW and HW+SW(one CPU) verifying for  SM2 p256, NIST p256 and brainpoolP256r1. 5, Run the below command on your i.MX8M Mini evk board. modprobe cryptodev ./cv2x_benchmark gmssl speed sm2 gmssl speed dsa gmssl speed rsa gmssl speed ecdsa gmssl speed ecdh gmssl genrsa -rand -f4 -engine cryptodev 4096 Note: 1, the udpated GmSSL also support projective coordinates and affine coordinates (CAAM only support affine  coordinates ). Affine  coordinates is used  by default. You can call EC_GROUP_set_coordinates() and EC_GROUP_restore_coordinates() to change coordinates and restore default. When you hope to use some EC APIs under expected coordinates, you need to call EC_GROUP_set_coordinates() before EC APIs and  EC_GROUP_restore_coordinates() after them. Like the below example: orig_coordinate = EC_GROUP_set_coordinates(EC_PROJECTIVE_COORDINATES); group = EC_GROUP_new_by_curve_name(NID_sm2p256v1); EC_GROUP_restore_coordinates(orig_coordinate); 2, Yocto Zeus integrates openssl 1.1.1g, so I change library name of gmssl from libcrypto to libgmcrypto and from libssl to libgmssl to avoid name confliction with openssl 1.1.1g (lib name are also libcrypto.so.1.1 and libssl.so.1.1). You should use -lgmcrypto and -lgmssl when you link gmssl library instead of -lcrypto and -lssl.   +++++++++++++++++++++++    updating at 2021-02-08  ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.70_2.3.0​​. The package meta-gmcrypto_L5.4.70-2.3.0.tgz is Yocto layer which also support c-v2x feature in previous release . 

    Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab       I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARM64 and test on i.MX8MQ EVK board. I did over night test( 5 real-time threads + GPU SDK test case) and stress test by tool stress-ng on  i.MX8MQ EVK board. It looks lile pretty good. Current version (20200730) also support i.MX8MM EVK.     You need attached file xenomai-4.19.35-1.1.0-arm64-20200818.tgz (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If  XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command ( /usr/xenomai/demo/cyclictest -p 99 -t 5 -m -n -i 1000  -l 100000 😞 //Over normal Linux kernel without GPU SDK test case T: 0 ( 4220) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 9 Max: 23 T: 1 ( 4221) P:99 I:1500 C: 66672 Min: 7 Act: 10 Avg: 10 Max: 20 T: 2 ( 4222) P:99 I:2000 C: 50001 Min: 7 Act: 12 Avg: 10 Max: 81 T: 3 ( 4223) P:99 I:2500 C: 39998 Min: 7 Act: 11 Avg: 10 Max: 29 T: 4 ( 4224) P:99 I:3000 C: 33330 Min: 7 Act: 13 Avg: 10 Max: 26 //Over normal Linux kernel with GPU SDK test case T: 0 ( 4177) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 11 Max: 51 T: 1 ( 4178) P:99 I:1500 C: 66673 Min: 7 Act: 12 Avg: 10 Max: 35 T: 2 ( 4179) P:99 I:2000 C: 50002 Min: 7 Act: 12 Avg: 11 Max: 38 T: 3 ( 4180) P:99 I:2500 C: 39999 Min: 7 Act: 12 Avg: 11 Max: 42 T: 4 ( 4181) P:99 I:3000 C: 33330 Min: 7 Act: 12 Avg: 11 Max: 36   //Cobalt with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --timeout 600s --metrics-brief T: 0 ( 4259) P:50 I:1000 C:3508590 Min:      0 Act:    0 Avg:    0 Max:      42 T: 1 ( 4260) P:50 I:1500 C:2338831 Min:      0 Act:    1 Avg:    0 Max:      36 T: 2 ( 4261) P:50 I:2000 C:1754123 Min:      0 Act:    1 Avg:    1 Max:      42 T: 3 ( 4262) P:50 I:2500 C:1403298 Min:      0 Act:    1 Avg:    1 Max:      45 T: 4 ( 4263) P:50 I:3000 C:1169415 Min:      0 Act:    1 Avg:    1 Max:      22   //Cobalt without GPU SDK test case T: 0 ( 4230) P:50 I:1000 C: 100000 Min: 0 Act: 0 Avg: 0 Max: 4 T: 1 ( 4231) P:50 I:1500 C:   66676 Min: 0 Act: 1 Avg: 0 Max: 4 T: 2 ( 4232) P:50 I:2000 C:   50007 Min: 0 Act: 1 Avg: 0 Max: 8 T: 3 ( 4233) P:50 I:2500 C:   40005 Min: 0 Act: 1 Avg: 0 Max: 3 T: 4 ( 4234) P:50 I:3000 C:   33338 Min: 0 Act: 1 Avg: 0 Max: 5 //Cobalt with GPU SDK  test case T: 0 ( 4184) P:99 I:1000 C:37722968 Min: 0 Act: 1 Avg: 0 Max: 24 T: 1 ( 4185) P:99 I:1500 C:25148645 Min: 0 Act: 1 Avg: 0 Max: 33 T: 2 ( 4186) P:99 I:2000 C:18861483 Min: 0 Act: 1 Avg: 0 Max: 22 T: 3 ( 4187) P:99 I:2500 C:15089187 Min: 0 Act: 1 Avg: 0 Max: 23 T: 4 ( 4188) P:99 I:3000 C:12574322 Min: 0 Act: 1 Avg: 0 Max: 29 //Mercury without GPU SDK  test case T: 0 ( 4287) P:99 I:1000 C:1000000 Min: 6 Act: 7 Avg: 7 Max: 20 T: 1 ( 4288) P:99 I:1500 C:  666667 Min: 6 Act: 9 Avg: 7 Max: 17 T: 2 ( 4289) P:99 I:2000 C:  499994 Min: 6 Act: 8 Avg: 7 Max: 24 T: 3 ( 4290) P:99 I:2500 C:  399991 Min: 6 Act: 9 Avg: 7 Max: 19 T: 4 ( 4291) P:99 I:3000 C:  333322 Min: 6 Act: 8 Avg: 7 Max: 21 //Mercury with GPU SDK  test case T: 0 ( 4222) P:99 I:1000 C:1236790 Min: 6 Act: 7 Avg: 7 Max: 55 T: 1 ( 4223) P:99 I:1500 C:  824518 Min: 6 Act: 7 Avg: 7 Max: 44 T: 2 ( 4224) P:99 I:2000 C:  618382 Min: 6 Act: 8 Avg: 8 Max: 88 T: 3 ( 4225) P:99 I:2500 C:  494701 Min: 6 Act: 7 Avg: 8 Max: 49 T: 4 ( 4226) P:99 I:3000 C:  412247 Min: 6 Act: 7 Avg: 8 Max: 53 //////////////////////////////////////// update for Yocto L5.4.47 2.2.0  /////////////////////////////////////////////////////////// New release package xenomai-5.4.47-2.2.0-arm64.tgz for Yocto release L5.4.47 2.2.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP). You need to add the following variable in conf/local.conf before build xenomai by command bitake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// update for Yocto L5.4.70 2.3.0  /////////////////////////////////////////////////////////// New release package xenomai-5.4.70-2.3.0-arm64.tgz for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP. Updating: 1, Support i.MX8QM and i.MX8QXP 2, Fix altency's the issue which uses legacy API to get time

    The document is about how to use WSL2 to compile yocto(android is the same process)  

This is a detailed programming aid for the registers associated with i.MX 8MNano (m815S) DDR initialization.  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467

Here is simple step to create a custom partition with AVB. Tested by i.MX8MN EVK and Android P9.0.0_2.3.1. Create image for xyz partition in 1024MB in Android build output folder # cd $OUT # mkdir xyz # echo "This is test txt file" > xyz/Readme.txt # make_ext4fs -l 1073672192 -s -a xyz xyz.ext4.img xyz   Apply the attached patch. uboot patch corrects the reading problem on avb footer.   Flash images by uuu # cd $OUT # sudo ./uuu_imx_android_flash.sh -f imx8mn   Check result.  Boot up and mount xyz partition # cd /data # mount /dev/block/mmcblk2p14 xyz # cat xyz/Readme.txt This is test txt file

      The i.MX6UL/LL/LZ processor supports 2 USB OTG interfaces, USB OTG1 and USB OTG2, and each USB interface can be configured as a device, host or dual role mode. On the EVK board of i.MX6UL/LL, USB OTG1 is designed as dual role mode, and USB OTG2 is designed as HOST mode. This is sufficient for most customers.       However, in actual applications, we may need 2 USB HOSTs, and at the same time, we don’t want to use MicroUSB to USB TYPE-AF cable for Host-Device mode conversion. Therefore, the design of the USB circuit needs to meet such requirements: 1. USB device mode We need a USB device to download the linux image to the flash or SD card on the board. 2. 2 USB HOSTs When the system is working normally, we need the board to support 2 USB HOST. i.MX6UL/LL/LZ has only 2 USB ports. How to design to meet this requirement without increasing the USB HUB? The following scheme is used as a reference, and I hope it will be helpful to customers with similar requirement:        The logic and application description of this Diagram: : Default—device mode In the process of debugging the software, we need to use the USB OTG interface to download the linux image, so it must work in device mode. What we need to do is: (1). Pull USB OTG ID up to 3.3V (2). The USB OTG D+/D- signal is switched to the MicroUSB connector. (3). The USB OTG VBUS is provided with 5V power from the external PC USB HOST. Usage:        -Use a jumper for Pin 1 and Pin2, USB OTG ID pin will be pulled up to High.        With the operation, SEL pin of USB Muxer is High, and USB signals are switched to port B, and USB differential signals are connected to MicroUSB connector. At the same time, MIC2026-1YM output is disabled. The USB OTG1 VBUS pin of CPU is supplied by VBUS of MicroUSB connector, that is to say, supplied by PC USB HOST.        In this mode, software engineer can use it to download images to flash on board. Normal Work—Host mode After the software debugging is completed, two HOSTs are needed on the board. At this time, we need to switch the USB OTG1 from device to HOST mode. What we need to do is: (1). Pull USB OTG1 ID down to LOW (2). The USB OTG D+/D- signal is switched to the USB Type-AF connector. (3). Board should supply 5V power for USB device connected USB Type-AF connector. Usage:        -Use a jumper for Pin 2 and Pin3, USB OTG ID pin will be pulled down to Low.        With the operation, USB OTG1 ID pin is pulled down to Low, SEL pin of USB Muxer is also LOW, USB signals are switched to Port A, and connected to USB type-AF connector. At the same time, MIC2026-1YM is enabled , OUTA will output 5V , which will supply USB device connected on USB type-AF connector.   [Note] Users need to pay attention to. When using the jumper with PIN1/2/3, the board needs to be powered off. In other words, when switching between device and host, you need to switch off the power, then power on, and restart the board. The solution can also be used for i.MX processors with USB 2.0 interface.   NXP CAS team Wedong Sun 01/15/2021

Recently, some customers are using i.MX processor, they want to add raid & LVM function support to the kernel, but they have encountered the problem that the compilation cannot pass. Tested it in L4.14.98, L4.19.35 & L5.4.x, Only L4.14.98 bsp exists the problem. Here are the experimental steps I have done, including the same problems I encountered with the customer, and how to modify the kernel to ensure that the compilation passes. 1. Exporting cross compilation tool chain from yocto BSP (1) Downloading Yocto BSP and compiling it. Following steps in i.MX_Yocto_Project_User's_Guide.pdf, download Yocto BSP and compile it successfully. (2) Exporting cross compilation tool chain Following methods described in i.MX_Linux_User's_Guide.pdf, export cross compilation tool chain from yocto BSP. See Chapter 4.5.12 of the document, please! Then cross compilation tool chain will be like below: (3) Copying linux BSP source code to a new directory # cd ~ # mkdir L4.14.98-2.0.0 # cd L4.14.98-2.0.0 # cp -r ~/imx-yocto-bsp/build-fb/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/4.14.98- r0/git ./ Then all linux source code has been copied to L4.14.98-2.0.0, which is the top directory of linux kernel source code, I will compile kernel image here. 2. Compiling linux kernel # cd ~/L4.14.98-2.0.0 # source /opt/fsl-imx-fb/4.14-sumo/environment-setup-cortexa9hf-neon-poky-linux-gnueabi # export ARCH=arm # make imx_v7_defconfig # make menuconfig Then we will add RAID and LVM modules to linux kernel. In order to reproduce errors, I added all related modules to kernel. See below, please! Device drivers---->Multiple devices driver support (RAID and LVM) After save and exit, began to compile kernel. # make (make –j4) The following errors will occur: ------------------------------------------------------------------------------------------- drivers/md/dm-rq.c: In function ‘dm_old_init_request_queue’: drivers/md/dm-rq.c:716:2: error: implicit declaration of function ‘elv_register_queue’; did you mean ‘blk_register_queue’? [-Werror=implicit-function-declaration] elv_register_queue(md->queue); ^~~~~~~~~~~~~~~~~~ blk_register_queue cc1: some warnings being treated as errors scripts/Makefile.build:326: recipe for target 'drivers/md/dm-rq.o' failed make[2]: *** [drivers/md/dm-rq.o] Error 1 scripts/Makefile.build:585: recipe for target 'drivers/md' failed make[1]: *** [drivers/md] Error 2 Makefile:1039: recipe for target 'drivers' failed make: *** [drivers] Error 2 ------------------------------------------------------------------------------------------- 3. Finding out root cause and solving it (1) elv_register_queue( ) function The function is loaded in dm-rq.c : int dm_old_init_request_queue(struct mapped_device *md, struct dm_table *t) { … … elv_register_queue(md->queue); … … } BUT compiler didn’t find it’s declaration and entity. Searching source code, and found it declared in linux_top/block/blk.h: … … int elv_register_queue(struct request_queue *q); … … It’s entity is in linux_top/block/elevator.c: int elv_register_queue(struct request_queue *q) { … … } (2) Adding declaration and exporting the function --- Declaration Add the line below to dm-rq.c: … … extern int elv_register_queue(struct request_queue *q); … … --- Exporting the function(elevator.c) Add EXPORT_SYMBOL(elv_register_queue); to the end of function, see below. int elv_register_queue(struct request_queue *q) { … … } EXPORT_SYMBOL(elv_register_queue); 4. Re-compiling Linux Kernel The above error will not occur and the compilation will complete successfully.   NXP CAS team Weidong Sun

Environment: openjdk-8 with L5.4.24-2.1.0 and GCC-9 1. Clone meta-java with dedicated branch name: git clone git://git.yoctoproject.org/meta-java -b zeus 2. Update .bb file for compile error in meta-java: diff --git a/recipes-core/icedtea/icedtea7-native.inc b/recipes-core/icedtea/icedtea7-native.inc index 8d0dc71..153a604 100644 --- a/recipes-core/icedtea/icedtea7-native.inc +++ b/recipes-core/icedtea/icedtea7-native.inc @@ -26,7 +26,7 @@ CXXFLAGS_append = " -fno-tree-dse" CXX_append = " -std=gnu++98" # WORKAROUND: ignore errors from new compilers -CFLAGS_append = " -Wno-error=stringop-overflow -Wno-error=return-type" +CFLAGS_append = " -Wno-error=stringop-overflow -Wno-error=return-type -Wno-error=format-overflow" inherit native java autotools pkgconfig inherit openjdk-build-helper 3. Add meta-java layer into bblayers.conf: BBLAYERS += "${BSPDIR}/sources/meta-java" 4. Edit the conf/local.conf to add openjdk variables # Possible provider: cacao-initial-native and jamvm-initial-native PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native" # Possible provider: cacao-native and jamvm-native PREFERRED_PROVIDER_virtual/java-native = "jamvm-native" # Optional since there is only one provider for now PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" PREFERRED_PROVIDER_java2-runtime = " openjdk-7-jre" IMAGE_INSTALL_append = " openjdk-7-jdk " diff --git a/recipes-core/openjdk/openjdk-8-common.inc b/recipes-core/openjdk/openjdk-8-common.inc index d8b30b8..ed03d60 100644 --- a/recipes-core/openjdk/openjdk-8-common.inc +++ b/recipes-core/openjdk/openjdk-8-common.inc @@ -181,5 +181,5 @@ FLAGS_GCC9 = "-fno-lifetime-dse -fno-delete-null-pointer-checks" BUILD_CFLAGS_append = " ${@openjdk_build_helper_get_build_cflags(d)}" BUILD_CXXFLAGS_append = " ${@openjdk_build_helper_get_build_cflags(d)}" # flags for -cross -TARGET_CFLAGS_append = " ${@openjdk_build_helper_get_target_cflags(d)}" +TARGET_CFLAGS_append = " ${@openjdk_build_helper_get_target_cflags(d)} -Wno-error=format-overflow" TARGET_CXXFLAGS_append = " ${@openjdk_build_helper_get_target_cflags(d)}" diff --git a/recipes-core/openjdk/openjdk-8-native.inc b/recipes-core/openjdk/openjdk-8-native.inc index 321a43d..97ff03f 100644 5. Switch the host GCC to gcc-8 and g++-8: sudo apt-get install gcc-8 g++-8 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8 --slave /usr/bin/g++ g++ /usr/bin/g++-8 --slave /usr/bin/gcov gcov /usr/bin/gcov-8 --slave /usr/bin/gcov-tool gcov-tool /usr/bin/gcov-tool-8 --slave /usr/bin/gcc-ar gcc-ar /usr/bin/gcc-ar-8 --slave /usr/bin/gcc-nm gcc-nm /usr/bin/gcc-nm-8 --slave /usr/bin/gcc-ranlib gcc-ranlib /usr/bin/gcc-ranlib-8 sudo update-alternatives --config gcc  6. And change the conf/local.conf from openjdk-7 -> openjdk-8: PREFERRED_PROVIDER_java2-runtime = " openjdk-8-jre" IMAGE_INSTALL_append = " openjdk-8 " 

i.MX_Android_FAQ i.MX Android FAQ 1 Sync project and Build 1.1 How can I download AOSP repo from mirror server? By default, all aosp repo in the Android project will be downloaded from google server directly. But some may have issues to access the google server, if you have server which has mirrored the aosp repo then you can redirct the aosp repo download link. In i.MX android project, all aosp repo will be included in the ${MY_ANDROID}/.repo/manifests/aosp*.xml, you can redirect the aosp repo remote by changing the "fetch" for remote "aosp", below is an example to redirect the remote link to <your-mirror-server-address>: @@ -2,7 +2,7 @@ <manifest> <remote name="aosp" - fetch="https://android.googlesource.com/" + fetch="<your-mirror-server-address>/" review="https://android-review.googlesource.com/" /> <default revision="refs/tags/android-10.0.0_r32" remote="aosp" 1.2 How do I configure the build information? BUILD_ID and BUILD_NUMBER are two makefile variables that can be used in Android core build system to specify build information if they are defined. In our release package, we define the BUILD_ID as the internal release build number, and define the BUILD_NUMBER as the internal release date. You can customize the value of these two variables in the file of ${MY_ANDROID}/device/fsl/{product}/build_id.mk. "${MY_ANDROID}" represents a the root directory of Android source code. "{product}" is related to specific chips and boards, for example, it can be "imx8m/evk_8mq". Below is an example to update the BUILD_ID for i.MX 8MQuad EVK diff --git a/imx8m/evk_8mq/build_id.mk b/imx8m/evk_8mq/build_id.mk index 257b500..b177202 100644 --- a/imx8m/evk_8mq/build_id.mk +++ b/imx8m/evk_8mq/build_id.mk @@ -18,5 +18,5 @@ # (like "CRB01"). It must be a single word, and is # capitalized by convention. -export BUILD_ID=1.0.0-ga-rc2 +export BUILD_ID=1.0.0-ga-rc3 export BUILD_NUMBER=20190114 1.3 How do I change boot command line in boot.img? After using boot.img, we stored the default kernel boot command line inside of this image. It will package together during android build. You can change this by changing BOARD_KERNEL_CMDLINE's definition in ${MY_ANDROID}/device/fsl/{product}/BoardConfig.mk file. NOTE: Replace {product} with your product, eg, imx8m/evk_8mq. 1.4 How to fix Python2 incompatible with latest git-repo? You might meet below exception when you execute "repo init" or "repo sync": haoran@pentakill:~/ssd/imx_5.4.y$ repo sync -c repo: warning: Python 2 is no longer supported; Please upgrade to Python 3.6+. Traceback (most recent call last): File "/home/ssd-1/haoran/imx_5.4.y/.repo/repo/main.py", line 56, in <module> from subcmds.version import Version File "/home/ssd-1/haoran/imx_5.4.y/.repo/repo/subcmds/__init__.py", line 38, in <module> ['%s' % name]) File "/home/ssd-1/haoran/imx_5.4.y/.repo/repo/subcmds/upload.py", line 27, in <module> from hooks import RepoHook File "/home/ssd-1/haoran/imx_5.4.y/.repo/repo/hooks.py", line 472 file=sys.stderr) ^ In Android repository, the "repo" tool which used to work actually is from ${MY_ANDROID}/.repo/repo/repo. This Python script is from Google's  https://gerrit.googlesource.com/git-repo  by default. Google pushed the change for this git-repo.git and removed the Python2 support of the repo tool after Dec 2020. So the Python2 cannot execute the repo sub command any more based on latest repo tools.  For older Android release, some build scripts of Android cannot support Python 3. So that it is not convenient to switch Python tool always between "repo sync" and images builts. A way to reslove this is that we can follow below instructions to fallback your git-repo version which work for Python 2 for older Android releases:   $cd ${MY_ANDROID}/.repo/repo $git checkout -b python2_repo 58ac1678e8438fd029a22365741fc57276eda404 $git branch python2_repo --set-upstream-to=origin/master 2 Connectivity 2.1 How do I setup a computer to support ADB? To setup a computer to support ADB, see   Android web site   for more details. There is one thing not clear in the page mentioned above about "setup the system to detect the device" on Ubuntu Linux, an udev rules file need to be created and well edited, please follow below steps:     1. Create the file of "/etc/udev/rules.d/51-android.rules" with root permission and add the vendors of the device to the file with below format SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev" the id value of "18d1" is USB PID for google, which is used in our USB HAL code.     2. now execute blow command on the host chmod a+r /etc/udev/rules.d/51-android.rules 2.2 How do I setup a computer to support ADB In Recovery mode? NXP i.MX 6/7 series support applying system update from ADB's. Linux OS supports this feature by default. For Windows OS, follow the steps below: Install the Google usb driver. Apply the patch below to the USB driver from Google. Connect the USB cable to the board and install the driver according to the instructions provided. --- android_winusb.inf 2013-06-04 13:39:40.344756457 +0800 +++ android_winusb.inf 2013-06-04 13:43:46.634756423 +0800 @@ -23,6 +23,8 @@ [Google.NTx86] +;adb sideload support +%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_D001 ;Google Nexus One %SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0D02 @@ -59,7 +61,8 @@ [Google.NTamd64] - +;adb sideload support +%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_D001 ;Google Nexus One %SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0D02 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_0D02&MI_01 2.3 How do I enable USB tethering? We support the USB tethering feature, and upstream device can be WIFI or Ethernet. USB tethering can be enabled in the Settings UI after your OTG USB cable is connected to PC: Settings -> Network & internet -> Hotspot & tethering -> USB tethering. On linux and Windows 7 PC, when USB tethering is enabled, you can easily get a usb network device with host driver installed automatically. The IP and DNS server is automatically configured. On Windows XP PC, when you have connected the board with the PC and you can see an unknown device named "Android" in the device manager, you have to manually install the tethering driver file of tetherxp.inf. After it is successfully installed, you can see "Android USB RNDIS device" in the device manager. By this time, you can use USB rndis network device to access the network. 2.4 How do I use MTP? The Media Transfer Protocol is a set of custom extensions to the   Picture Transfer Protocol   (PTP). Whereas PTP was designed for downloading photographs from digital cameras, Media Transfer Protocol supports the transfer of music files on digital audio players and media files on portable media players, as well as personal information on   personal digital assistants. Starting with version 4.0, Android supports MTP as default protocol transfer files with PC, instead of the USB Mass Storage. By default, as Google suggested, we disabled the UMS and enabled MTP. NOTE: Please make sure you disable the USB Tethering when using MTP. Under WinXP, you can not make MTP work with ADB enabled, but under Win7, MTP can work together with ADB in most of the cases. When connecting the board to PC by USB cable, a USB icon will be shown in the notification bar. Then you can click on the notification area, and select "Connected as a media device" to launch the USB computer connection option UI. There, MTP and PTP can be chosen as current transfer protocol. You can also launch the option UI by Settings -> Storage -> MENU -> USB computer connection. MTP on Windows XP Windows XP supports PTP protocol by default. In order to support MTP protocol, you must install Windows Media Player (Version >= 10). When connecting to the PC, you can see MTP devices in windows explorer. Since Windows XP only supports copy/paste files in the explorer, you cannot directly open the files in MTP device. MTP on Windows 7 Windows 7 supports MTP(PTP) protocol by default. When connecting to the PC, you can see MTP devices in windows explorer. You can do any operations just as you would on your hard disk. MTP on ubuntu Ubuntu supports PTP protocol by default. To support MTP protocol, you must install the following packages: libmtp, mtp-tools by $ sudo apt-get install mtp-tools If your default libmtp version is not 1.1.1 (current latest libmtp on ubuntu is 1.1.0), you must upgrade it manually by: $ sudo apt-get install libusb-dev $ wget http://downloads.sourceforge.net/project/libmtp/libmtp/1.1.1/libmtp-1.1.1.tar.gz $ tar -xvf libmtp-1.1.1.tar.gz $ cd libmtp-1.1.1 $ ./configure --prefix=/usr $ make -j4 $ sudo make install After you have done the steps outlined above, you can transfer the files between PC and Device by the following commands: mtp-detect: find current connected MTP device mtp-files: list all the files on MTP device 2.5 How do I set networking proxy for Wi-Fi? To configure the proxy settings for a Wi-Fi network, you have to: Tap and hold a network from the list of added Wi-Fi networks Now choose "Advanced options", and scroll down to "Proxy". Choose "Manually". Then enter the proxy settings provided by the network administrator. Finally tap on the button denoted as "CONNECT". 2.6 How to adapt the "wifi country code" for a specific country and/or region? In i.MX Android Software, "CN" is used as default code while it's mainly for mainland of China. Some other countries and/or regions are listed in below table for convenience. If the target country/region is not in below table,  Search on the internet with the keyword of "ISO 3166" for the result. Code Country/Region name CA Canada JP Japan DE Germany NL Netherlands IT Italy PT Portugal LU Luxembourg NO Norway FI Finland DK Denmark CH Switzerland CZ Czech Republic ES Spain GB United Kingdom KR Republic of Korea (South Korea) FR France SG Singapore BR Brazil IL Israel AT Austria AU Australia BE Belgium CY Cyprus EE Estonia GR Greece HU Hungary ID Indonesia IE Ireland ID India IS Iceland LT Lithuania LV Latvia MY Malaysia NZ New Zealand PH Philippines PL Poland SE Sweden SI Slovenia SK Slovak Republic TH Thailand US United States ZA South Africa   2.7 How to switch the Power role of USB Power Delivery through USB Type-C? Several i.MX 8 board support the USB Power Delivery(PD) through USB Type-C port.The board can be acted as Power Sink or Power Source. Check corresponding Android Release Notes to see whether board support USB Power Delivery(PD) or not. Below are the steps to switch the Power role: 1.Connect a reference device with i.MX board: Use a Type-C to Type-C cable to connect i.MX board with the reference device(support Usb Power Delivery). 2.Check i.MX board device's role If i.MX board connects as host , and the reference device is a device(has a usb Drop-down menu to choose transfer files, ptp), then do step 3 on the reference device. If i.MX board connects as device(has a usb Drop-down menu to choose transfer files, ptp), and the reference device is a host, then do step 3 on i.MX board. 3.Power role switch If i.MX board is host: To make i.MX board as Power Source to charge the reference device, choose "Charging this device" on the reference device's usb Drop-down menu. To make i.MX board as Power Sink to be charged by the reference device, choose "Supplying power" on the reference device's usb Drop-down menu. If i.MX board is device: To make i.MX board as Power Source to charge the reference device, choose "Supplying power" on i.MX board's usb Drop-down menu. To make i.MX board as Power Sink to be charged by the reference device,choose "Charging this device" on i.MX board's usb Drop-down menu. NOTE: 1.Below command can check current power role for the i.MX board cat /sys/class/typec/port0/power_role source [sink] : means this i.MX board is been charged by the reference device, [source] sink : means this i.MX board is charging the reference device, 2.The reference device should support the USB Power Delivery(PD). You can check whether the reference device support it or not by below command when it is connected with i.MX board's USB Type-C port: cat /sys/class/typec/port0/port0-partner/supports_usb_power_delivery, If this value is yes, then this reference device supports usb power delivery. Google pixel phone meets this requirement, but Google nexus 6 does not. 3 Core 3.1 How do I enter Android Recovery mode manually? When the system is running, press "VOLUME DOWN" and "Power" to enter Recovery mode if board has these keys. This check is in u-boot.git board support file, where you can change your preferred combo keys. Also, you can input this command in the console: reboot recovery # the board reset to recovery mode. to enter recovery mode. 3.2 How do I enter the text menu in recovery mode? NOTE: This function only works on boards with POWER / VOLUME UP / VOLUME DOWN keys. When the system completes booted up into recovery mode, you will see an Android Robot Logo Press the   POWER KEY(keep pressed),   and then   VOLUME UP KEY   going to the   text menu   like this: Move the menu item by   VOLUME UP   and   VOLUME DOWN   button. Select the menu item by   Power Key. Select the required option using the direction keys on the keypad or keyboard. reboot system now apply update from ADB, you may update the software from update.zip by adb sideload command. Only NXP i.MX 6/7 series support this feature. wipe data/factory reset. /data and /cache partitions are formatted. wipe cache partition. /cache partition is formatted. Reboot the system. 3.3 How do I upgrade system by ADB? NXP i.MX 6/7 series support applying system update from ADB. Before upgrade the system with ADB tool, please install adb driver first, see "2 Connectivity->2.2 How do I setup a computer to support ADB In Recovery mode?" section. After the installation and setup of the driver is complete, follow the steps below: Download the OTA update package to your computer, and connect the board to your PC with USB cable. Ensure that the system has entered recovery mode. See "3.1 How do I enter Android Recovery mode manually" section. Toggle the text Menu, move the cursor to "apply update from ADB", the UI is displayed as follows: On your computer, execute below command adb sideload $YOUR_UPDATE_PACKAGE.zip After the package is sent, the system starts updating the firmware with the update file. 3.4 How do I use android fastboot? Fastboot is an utility which can be used to download images from Windows/Linux PC to the target storage device. This utility is released by Google, which can be downloaded from Android official site. Android release implements part of the fastboot commands in the U-Boot, such as: flash, reboot, getvar. Before using the fastboot, Google usb driver should be installed on windows HOST and the target board should boot up to bootloader fastboot mode. NOTE: the size of images downloaded by fastboot must be less than the related partition size. Target side: Power on the board with USB OTG connected. Make sure board enter fastboot mode. There are several ways to enter fastboot mode. Option1: Input   reboot bootloader   in console after boot. Option2: Connect power to the board. You'll see the following output from the console. U-Boot ... ... Fastboot: Normal Hit any key to stop autoboot: 3 Hit   any key   before the countdown completes to access the bootloader prompt. Type fastboot usb and hit Enter: Fastboot: Normal Hit any key to stop autoboot: 0 => fastboot usb NOTE: 1.On HOST PC, it will prompt you that a new device was found and that you need to install the driver. Please install it. 2.After board enter U-Boot mode, type mmc part on target side to get detail partition name defined in partition table image. Some partitions are hardcoded in u-boot, it will not be listed here. Host side: Make sure fastboot is contained by the system environment variable of "PATH". Go to image folder. Below is an example to use fastboot to flash images for NXP imx8 series. Make sure your board is in unlock state before flashing images with fastboot. bootloader0/bootloader and gpt partitions is hardcoded in u-boot, it's not in partition table file. names and number of partitions defined in partition table file may change as time goes on and new features are enabled. $ fastboot flash gpt partition-table.img $ fastboot flash bootloader0 u-boot.imx $ fastboot flash dtbo dtbo.img $ fastboot flash boot boot.img $ fastboot flash system system.img $ fastboot flash vendor vendor.img $ fastboot flash vbmeta vbmeta.img $ fastboot reboot Below is an example to use fastboot to flash images for NXP i.MX 6/7 series. $ fastboot flash gpt partition-table.img $ fastboot flash bootloader u-boot.imx $ fastboot flash dtbo dtbo.img $ fastboot flash boot boot.img $ fastboot flash system system.img $ fastboot flash vendor vendor.img $ fastboot flash vbmeta vbmeta.img $ fastboot flash recovery recovery.img $ fastboot reboot 3.5 How to do incremental OTA update for imx6/7?      3.5.1 Check the definition of "IncrementalOTA_InstallEnd" function i.MX6/7 code released before Android10(not include Android10) does not support to build incremental OTA package. need to define a function named "IncrementalOTA_InstallEnd" in releasetools.py for a specific platform, this is a file under ${MY_ANDROID}/device/fsl. take i.MX 7ULP EVK as an example, this file is ${MY_ANDROID}/device/fsl/imx7ulp/releasetools.py. if the function is not defined, make below changes on the code. Other platforms have their own releasetools.py, modify the file based on you own requirement.                       diff --git a/imx7ulp/releasetools.py b/imx7ulp/releasetools.py index 8c40905d..d557b23e 100644 --- a/imx7ulp/releasetools.py +++ b/imx7ulp/releasetools.py @@ -38,3 +38,25 @@ def FullOTA_InstallEnd(info): # emit the script code to trigger the dtbo updater on the device info.script.WriteRawImage("/dtbo", "dtbo.img") + +def IncrementalOTA_InstallEnd(info): + # copy the vbmeta and dtbo into the package. + try: + vbmeta_img = common.GetBootableImage( + "vbmeta.img", "vbmeta.img", OPTIONS.input_tmp, "VBMETA") + dtbo_img = common.GetBootableImage( + "dtbo.img", "dtbo.img", OPTIONS.input_tmp, "DTBO") + except KeyError: + print "no vbmeta or dtbo images in target_files; skipping install" + return + # copy the vbmeta into the package. + common.ZipWriteStr(info.output_zip, "vbmeta.img", vbmeta_img.data) + + # emit the script code to trigger the vbmeta updater on the device + info.script.WriteRawImage("/vbmeta", "vbmeta.img") + + # copy the dtbo into the package. + common.ZipWriteStr(info.output_zip, "dtbo.img", dtbo_img.data) + + # emit the script code to trigger the dtbo updater on the device + info.script.WriteRawImage("/dtbo", "dtbo.img")                       The variable "BOARD_PREBUILT_DTBOIMAGE" in ${MY_ANDROID}/device/fsl  is used to specify the dtbo images to be built into the OTA package. modify the value of this variable based on your requirement. Take i.MX7ULP EVK as an example, you may need to made below change to make the OTA package suitable for boards with MIPI panel display                       diff --git a/imx7ulp/evk_7ulp/BoardConfig.mk b/imx7ulp/evk_7ulp/BoardConfig.mk index 0c023ecc..ec1c695f 100644 --- a/imx7ulp/evk_7ulp/BoardConfig.mk +++ b/imx7ulp/evk_7ulp/BoardConfig.mk @@ -103,7 +103,7 @@ TARGET_BOARD_DTS_CONFIG := imx7ulp:imx7ulp-evkb.dtb imx7ulp-evk:imx7ulp-evk.dtb TARGET_BOARD_DTS_CONFIG += imx7ulp-mipi:imx7ulp-evkb-rm68200-wxga.dtb imx7ulp-evk-mipi:imx7ulp-evk-mipi.dtb TARGET_KERNEL_DEFCONFIG := imx_v7_android_defconfig # TARGET_KERNEL_ADDITION_DEFCONF := imx_v7_android_addition_defconfig -BOARD_PREBUILT_DTBOIMAGE := out/target/product/evk_7ulp/dtbo-imx7ulp.img +BOARD_PREBUILT_DTBOIMAGE := out/target/product/evk_7ulp/dtbo-imx7ulp-mipi.img # u-boot target used by uuu for imx7ulp_evk TARGET_BOOTLOADER_CONFIG += imx7ulp-evk-uuu:mx7ulp_evk_defconfig                       3.5.2  Build target package file                You can use below command to generate target package file under android environment: $ cd ${MY_ANDROID} $ source build/envsetup.sh $ lunch evk_7ulp-userdebug $ make target-files-package -j4 After the build finish, you can find target package file in the following path: . ${MY_ANDROID}/out/target/product/evk_7ulp/obj/PACKAGING/target_files_intermediates/evk_7ulp-target_files-**.zip Copy the target file to ${MY_ANDROID} directory, let's rename it as evk_7ulp-target.a.zip. then execute below command to generate the full OTA package. $ ./build/tools/releasetools/ota_from_target_files evk_7ulp-target.a.zip evk_ota_full.zip Apply this OTA package evk_ota_full.zip to the board. for example, with adb, execute below commands on the host which is connected to the board via the USB cable: $ sudo adb root $ sudo adb reboot sideload # wait a while until the system reboot into sideload mode $ sudo adb sideload evk_ota_full.zip After preceding commands finished, the reboot the system. the images running on the board is the same as images in "evk_7ulp-target.a.zip"    3.5.3  Build incremental update package An incremental update contains a set of binary patches to be applied to the data already on the device. This can result in considerably smaller update packages. Incremental OTA package is also build from target package file, the difference with full OTA package is that two target package files are needed to generate on incremental OTA package. one target package has the images already running on the board, one has the image to be updated to. For example, we've update the i.MX 7ULP EVK board with images running on it the same as images in "evk_7ulp-target.a.zip". After this, some development work is done on the code. we can build the target package file again and generate full OTA package just as described in "3.5.2 Build target package file", We can also use this new generated target package file together with evk_7ulp-target.a.zip to generate a incremental OTA package. Assume that we've generated a target file, copied to ${MY_ANDROID} directory and rename it as evk_7ulp-target.b.zip. execute below command on the host to generate incremental OTA package: $ ./build/tools/releasetools/ota_from_target_files -i evk_7ulp-target.a.zip evk_7ulp-target.b.zip evk_7ulp_ota_diff.zip An incremental OTA package is generated with preceding command. it should be applied on device running the same images as in target file evk_7ulp-target.a.zip. This incremental OTA package can also be updated to the board with adb, just as described for full OTA package. After this OTA package is applied. next time if another incremental OTA is needed, a new generated target package file and the old evk_7ulp-target.b.zip is used to generate it. 4 A/V 4.1 How do I check frame drop statistic while video playback? Input below commands from console while video playback to get the real-time frame drop statistics. dumpsys media.player | grep "num" Then check the output,frame drop statistic will be showed like: numFramesTotal(1892), numFramesDropped(0), percentageDropped(0.00%) numFramesTotal: The total frames of the video file. numFramesDropped: The dropped frame count as AV synchronization. percentageDropped: The total dropped frame percentage. 5 Graphics 5.1 How to set GPU Minimal clock to balance performance and power consumption? Normally GPU works at full speed. When thermal driver report chip too hot, the GPU driver will adjust internal clock to reduce the power consumption to cool the chip down quickly. In theory we should set the GPU clock to 1/64 so that chip can be cool down more quickly, but you may see the black screen or flicker issue when GPU work at so slow clock especially in large resolution. There is below way to customize the threshold of GPU minimal clock based the chip and the resolution of their product. Customer can set the minimal GPU clock by change below line in ${MY_ANDROID}/device/fsl/{product}/init.rc file, the value can be set to any value from 1 to 64. write /sys/module/galcore/parameters/gpu3DMinClock 3 Current default value is 3. Customer should tune and set the suitable value based on their test. 5.2 How to disable GPU acceleration? There are three parts using GPU acceleration on android. Customer may need to disable some of them separately to narrow down issue. Below are the steps to do it. 1.Disable HWComposer: You can disable HWComposer in Setting apk, Settings->System-> {} Developer options ->Disable HW overlays 2.Disable OpenGL Renderer You can disable OpenGL Renderer and force use SKIA to draw by set "setprop sys.viewroot.hw false" and kill surfaceflinger thread. 3.Disable OpenGL 3D draw Disable OpenGL 3D draw can only be done after Disable OpenGL Renderer as this operation will totally disable all 3D OpenGL acceleration. You can do it by "mv /system/lib/egl/libGLES_android.so /system/lib/egl/libGLES.so" and kill surfaceflinger thread. NOTE: below example tell you how to kill surfaceflinger root@sabresd_6dq:/ # ps | grep surfaceflinger system 159 1 168148 7828 ffffffff b6f05834 S /system/bin/surfaceflinger root@sabresd_6dq:/ # kill 159 6 Boot 6.1 How to boot form different paritions of eMMC for boards with i.MX 8QuadXPlus b0 chips? i.MX 8QuadXPlus MEK with silicon revision b0 chips can boot from eMMC boot partition 32KB offset, but this is not a behaviour specified in the Reference Manual, it is not guaranteed to work fine on your boards. As the Reference manual shows that the first image container offset is 0 if the bootloader image is in eMMC boot partition or 32KB if the bootloader image is in eMMC User data area partition. If boot from eMMC boot partition 32KB offset does not work on your boards, some changes can be made to comply with the description in the Reference Manual: 1. bootloader image at eMMC boot partition with 0 offset with this scenario, eMMC fast boot mode should be used for i.MX 8QuadXPlus silicon revision b0 chips. eMMC fast boot mode is not enabled by default, and enabling it is irreversible. fastboot command "fuse prog -y 0 0x13 0x1" can be used to enable eMMC fastboot mode, this can be add to the uuu_imx_android_flash scripts. an example on uuu_imx_android_flash.sh: diff --git a/common/tools/uuu_imx_android_flash.sh b/common/tools/uuu_imx_android_flash.sh index da45518cb..49ee53555 100755 --- a/common/tools/uuu_imx_android_flash.sh +++ b/common/tools/uuu_imx_android_flash.sh @@ -145,6 +145,9 @@ function uuu_load_uboot if [[ ${target_dev} = "emmc" ]]; then echo FB: ucmd mmc partconf ${target_num} 1 1 1 >> /tmp/uuu.lst fi + if [[ ${soc_name} = "imx8qxp" ]] && [[ ${uboot_feature} != *"c0"* ]]; then + echo FB: ucmd fuse prog -y 0 0x13 0x1 >> /tmp/uuu.lst + fi if [[ ${intervene} -eq 1 ]]; then echo FB: done >> /tmp/uuu.lst Also, the "bootloader0" partition offset for i.MX 8QuadXPlus silicon revision b0 should change to 0 from 32K. diff --git a/drivers/fastboot/fb_fsl/fb_fsl_partitions.c b/drivers/fastboot/fb_fsl/fb_fsl_partitions.c index 92c978e6c8..7e3679b19a 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_partitions.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_partitions.c @@ -55,7 +55,7 @@ static ulong bootloader_mmc_offset(void) { if (is_imx8mq() || is_imx8mm() || ((is_imx8qm() || is_imx8qxp()) && is_soc_rev(CHIP_REV_A))) return 0x8400; - else if (is_imx8qm() || (is_imx8qxp() && !is_soc_rev(CHIP_REV_B))) { + else if (is_imx8qm() || is_imx8qxp()) { if (MEK_8QM_EMMC == fastboot_devinfo.dev_id) /* target device is eMMC boot0 partition, bootloader offset is 0x0 */ return 0x0; 2. bootloader image at eMMC User data area partition with 32KB offset. with this scenario, code in uboot should be modified to make the "bootloader0" partition in eMMC User data area partiton. Below patch can work for i.MX 8QuadXPlus MEK with b0 chips, but it obviously will impact other platforms, apply below path with caution. diff --git a/drivers/fastboot/fb_fsl/fb_fsl_dev.c b/drivers/fastboot/fb_fsl/fb_fsl_dev.c index f1c116bea2..c23f0a3e01 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_dev.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_dev.c @@ -124,7 +124,7 @@ static int get_fastboot_target_dev(char *mmc_dev, struct fastboot_ptentry *ptn) printf("Flash target is mmc%d\n", dev); if (target_mmc->part_config != MMCPART_NOAVAILABLE) sprintf(mmc_dev, "mmc dev %x %x", dev, /*slot no*/ - FASTBOOT_MMC_BOOT_PARTITION_ID/*part no*/); + FASTBOOT_MMC_USER_PARTITION_ID/*part no*/); else sprintf(mmc_dev, "mmc dev %x", dev); } @@ -559,4 +559,4 @@ void process_erase_mmc(const char *cmdbuf, char *response) sprintf(response, "OKAY"); return; -} \ No newline at end of file +} diff --git a/drivers/fastboot/fb_fsl/fb_fsl_partitions.c b/drivers/fastboot/fb_fsl/fb_fsl_partitions.c index 92c978e6c8..4629060402 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_partitions.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_partitions.c @@ -231,7 +231,7 @@ static int _fastboot_parts_load_from_ptable(void) bootloader_mmc_offset() / dev_desc->blksz; ptable[PTN_BOOTLOADER_INDEX].length = ANDROID_BOOTLOADER_SIZE / dev_desc->blksz; - ptable[PTN_BOOTLOADER_INDEX].partition_id = boot_partition; + ptable[PTN_BOOTLOADER_INDEX].partition_id = user_partition; ptable[PTN_BOOTLOADER_INDEX].flags = FASTBOOT_PTENTRY_FLAGS_UNERASEABLE; strcpy(ptable[PTN_BOOTLOADER_INDEX].fstype, "raw"); eMMC also need to be set to boot from User data area partition, set this in uuu_imx_android_flash scripts. An example on uuu_imx_android_flash.sh is as below, note that this will have impact on flashing other platforms, apply it with caution. diff --git a/common/tools/uuu_imx_android_flash.sh b/common/tools/uuu_imx_android_flash.sh index da45518cb..d98844d84 100755 --- a/common/tools/uuu_imx_android_flash.sh +++ b/common/tools/uuu_imx_android_flash.sh @@ -143,7 +143,7 @@ function uuu_load_uboot echo FB: ucmd mmc erase ${uboot_env_start} ${uboot_env_len} >> /tmp/uuu.lst if [[ ${target_dev} = "emmc" ]]; then - echo FB: ucmd mmc partconf ${target_num} 1 1 1 >> /tmp/uuu.lst + echo FB: ucmd mmc partconf ${target_num} 1 7 1 >> /tmp/uuu.lst fi if [[ ${intervene} -eq 1 ]]; then 7 Misc 7.1 How to enable Developer options on Android Jelly Bean and later version? Google has hidden the Developer options since the version Jelly Bean - here's how to get them back: Go to the Settings menu, and scroll down to "System". Tap it. Then Tap "About tablet" menu. Scroll down to the bottom again, where you see "Build number." Tap it seven times. After the third tap, you'll see a playful dialog that says you're four taps away from being a developer. Keep on tapping, until you've got the developer settings back. 7.2 How do I enable or disable bus frequency feature? The Bus Frequency driver is used to low down the DDR, AHB and AXI bus frequency in the SoC when the IPs who needs high bus frequency is not working. This saves the power consumption in Android earlysuspend mode significantly (playing audio with screen off). The bus frequency driver is   enabled   by default, if you want to enable or disable it, please do the following command in the console: Disable:    $ echo 0 > sys/bus/platform/drivers/imx_busfreq/busfreq/enable Enable:    $ echo 1 > sys/bus/platform/drivers/imx_busfreq/busfreq/enable Please note that if you're using ethernet, the up operation will enable the FEC clock and force bus frequency to be high. That means you can not go into low bus mode anymore, no matter the ethernet cable is plugged or unplugged. So if you want to system going to low bus mode, you must do 'netcfg eth0 down' to shutdown the FEC manually. If you want to use FEC again, please do 'netcfg eth0 up' manually, when FEC is shutdown with clock gated, the PHY can not detect your cable in/out events. 7.3 How do I use memtool?    7.3.1  build  memtool in Android environment git clone https://source.codeaurora.org/external/imx/imx-test/ -b imx_5.4.24_2.1.0 cp -r imx-test/test/memtool ${MY_ANDROID}/external  cd  ${MY_ANDROID} source build/envsetup.sh lunch evk_8mm-userdebug mmm external/memtool             The built binaries stores at ${MY_ANDROID}/out/target/product/evk_8mm/vendor/bin/memtool_32 and ${MY_ANDROID}/out/target/product/evk_8mm/vendor/bin/memtool_64    7.3.2  rebuild  boot image             Add below patch to enable CONFIG_DEVMEM, then rebuild boot.img and flash it on board: fastboot flash boot_a boot.img diff --git a/arch/arm64/configs/imx_v8_android_defconfig b/arch/arm64/configs/imx_v8_android_defconfig index ee40b9aa67e6..cdc9a1d56849 100644 --- a/arch/arm64/configs/imx_v8_android_defconfig +++ b/arch/arm64/configs/imx_v8_android_defconfig @@ -477,7 +477,6 @@ CONFIG_INPUT_ISL29023=y # CONFIG_SERIO_SERPORT is not set CONFIG_SERIO_AMBAKMI=y # CONFIG_LEGACY_PTYS is not set -# CONFIG_DEVMEM is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_EXTENDED=y    7.3.3   use memtool on board Push memtool to board's disk: adb push ${MY_ANDROID}/out/target/product/ evk_8 mm /vendor/bin/memtool_32 /data/local/tmp Run memtool_32 to get help info: evk_8mm:/ # /data/local/tmp/memtool_32 Usage: Read memory: memtool [-8 | -16 | -32] <phys addr> <count> Write memory: memtool [-8 | -16 | -32] <phys addr>=<value>   7.4 How do I use systrace? The systrace tool can be used to  analyze Android device performance. Please refer to below links about what is systrace and how to use it: https://source.android.com/devices/tech/debug/systrace  https://developer.android.com/topic/performance/tracing/command-line  The systrace tool will require the "CONFIG_DEBUG_FS" config to be enabled or you may have below error when generating the report: Starting tracing (stop with enter) Tracing completed. Collecting output... /system/bin/sh: <stdin>[2]: can't create /sys/kernel/debug/tracing/trace_marker: No such file or directory Outputting Systrace results... In some new Android releases, the "CONFIG_DEBUG_FS" config is disabled by default, you will need to enable it by yourself to enable the systrace function. For example: diff --git a/arch/arm64/configs/imx_v8_android_car2_defconfig b/arch/arm64/configs/imx_v8_android_car2_defconfig index 9e38bb17d640..bf35ce161d6d 100644 --- a/arch/arm64/configs/imx_v8_android_car2_defconfig +++ b/arch/arm64/configs/imx_v8_android_car2_defconfig @@ -509,3 +509,4 @@ CONFIG_PANIC_TIMEOUT=5 CONFIG_DEBUG_LIST=y CONFIG_ENABLE_DEFAULT_TRACERS=y # CONFIG_UPROBE_EVENTS is not set +CONFIG_DEBUG_FS=y

 

UUU is an evolution of MFGTools. The introduction of UUU detail you can see the uuu.pdf file.. Please download uuu.exe and follow the UUU introduction. Here are some running examples. If you are not familiar with uuu, you can refer to them firstly. Under Windows (should be as admin): • For SD card:  Linux:  .\uuu -b sd_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard • For EMMC:  Linux:  .\uuu -b emmc_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard  or  .\uuu.exe uuu.auto  Android:  .\uuu_imx_android_flash.bat -f imx8mm -u trusty Under Linux: • For EMMC  Linux:  sudo .\uuu uuu.auto If you download BSP release from nxp.com, you could find a file uuu.auto in the package. This is a preset script that can be executed directly (default for EMMC). You could change the script based on your requirement. Copy the uuu.exe under the release package, then execute the instructions. For UUU tool the prebuilt image and document are here: • https://github.com/NXPmicro/mfgtools/releases • UUU.pdf is snapshot of wiki   Environment PC: Window 10 64bit Board: i.MX8MMLPDDR4 EVK BSP: Q10.0.0_2.0.0 Demo images Screen: MX8-DSI-OLED1 Downloading android images to i.MX 8M Mini EVK LPDDR4 via UUU Tool 1\Hardware Preparations (1) Make the board enter serial download mode. For Rev. B boards, change the first two bits of board's sw1101 to 10 (from 1-2 bit) to enter serial download mode. For Rev. C boards, change the first four bits of board's sw1101 to 1010 (from 1-4 bit) to enter serial download mode. (2) Connecting J901to PC USB by a USB OTG cable. (3) Connecting J301(usb type c) to PC USB. (4) Plugging adapter into Power Jack (J302) (5) Power on i.MX 8M Mini EVK LPDDR4 board via SW101 Switch When first connect the board to PC, windows 10 64bit can’t automatically install FT2232D  driver from official website of manufacture, you need to Install the usb to uart driver manually： https://www.ftdichip.com/Drivers/D2XX.htm Download the setup executable and then install it. When installed success you can see the usb serial port can be used. 2\Downloading UUU Tool For the UUU binary file, download it from github: uuu release page on github . For the Q10.0.0_2.0.0 version use the UUU 1.3.124 version. For Linux OS, download the file named "uuu". For Windows OS, download the file named "uuu.exe". Here I use win10 system, so I download the uuu.exe file.   3\Download the Q10.0.0_2.0.0 Demo images for i.MX8MM   Now all the android os for i.MX products are here: Android OS for i.MX Applications Processors . Decompress release_package/android-10.0.0_2.0.0_image_8mmevk.tar.gz for LPDDR4 board. The package contains the image files and uuu_imx_android_flash tool. Copy uuu.exe to the directory of Q10.0.0_2.0.0 Demo images. 4\ Execute the uuu_imx_android_flash to flash image Power on the board. Open the serial port terminal and setting as following: Open a command line window. For the use and the Options for uuu_imx_android_flash tool details can see the Table 2 in the Android_Quick_Start_Guide. Here I use the OLED screen, to test MIPI panel output, need execute the tool with "-d mipi-panel". So here I use the .\uuu_imx_android_flash.bat -f imx8mm -e -d mipi-panel . When I use the download I meet the follow question: C:\Work\Products\Android BSP\New folder\Q10.0.0_2.0.0 Demo images\android-10.0.0_2.0.0_image_8mmevk>.\uuu_imx_android_flash.bat -f imx8mm -e -d mipi-panel This script is validated with uuu 1.3.124 version, it is recommended to align with this version. dtbo is supported dual slot is supported dynamic partition is supported You do not have sufficient privilege to perform this operation.   So here can change to use the Windows PowerShell, it works well and finished download.   Power off the board. 5\Boot up the board from emmc Set boot mode For Rev. C boards: Change sw1101 to 0110110010 and change sw1102 to 0001101000 if you want to boot from SD card. Change sw1101 to 0110110001 and change sw1102 to 0001010100 if you want to boot from eMMC. Set the U-Boot environment variables for t he MIPI panel display U-Boot > setenv bootargs console=ttymxc1,115200 earlycon=ec_imx6q,0x30890000,115200 init=/init androidboot.console=ttymxc1 androidboot.hardware=freescale cma=800M@0x400M-0xb80M androidboot.primary_display=imx-drm firmware_class.path=/vendor/firmware transparent_hugepage=never androidboot.wificountrycode=CN androidboot.lcd_density=240 U-Boot > saveenv Then use the boot to boot up and then display on OLED screen.   Hope this can do help for some users. Best Regards Rita

     

Hello everyone, In this document I'll explain on how to build the UUU (Universal Update Utility) using windows 10 PC. This may be useful in case of adding custom commands to run during the flash using built-in scripts, be it for debugging, fuse blowing, etc. First we need to download and install Visual Studio community, for this guide I'll use community 2019, version it is available here: https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=Community&rel=16 For workloads select Universal Windows Platform development.   When installing, make sure to select and install the Git for windows complement, at the top select Individual components, this will display a new list, scroll down to code tools and you will find Git for windows, check this box In case Visual Studio is already installed, you may open the installer again and chose modify, this will let you install the complement as well. After the installation is complete we may run the git commands on the power shell. Now open the windows power shell and type the following commands: git clone https://github.com/NXPmicro/mfgtools.git // clones the MFGTool (UUU) source code from the github cd mfgtools // enters the mfgtools folder we just cloned git submodule init // creates the local configuration file for the submodules git submodule update // set the submodules to the commit specified by the main repository. At this point we can edit the built in scripts to add our custom commands, for this guide I'll add the printenv uboot command at the end of the flashing process. For this I'll enter the folder mfgtools/uuu, and edit emmc_burn_all.lst with any text editor, i.e. Notepad ++, add the command FB: ucmd printenv.   Save and close the editor, it is possible to add most uboot commands like for example the fuse commands to burn eFuses. Then we can now build the tool, opening msvc/uuu-static-link.sln with Visual studio, select solution uuu-static-link.sln   And finally build the solution: The executable (uuu.exe) would be at the following path: mfgtools\msvc\x64\Debug   Finally we run the built in script we modified and check the results. Find attached both the powershell and uboot logs, I tested this using an i.MX8MN with L5.4.47_2.2.0, running the following command: ./uuu.exe -v -b emmc_all imx-boot-imx8mnevk-sd.bin-flash_evk imx-image-full-imx8mnevk.wic Hope this may found useful for anyone trying to achieve something similar.