i.MX Processors Knowledge Base

Discussions

BSP: L5.15.5_1.0.0 Platform: i.MX8MPlus EVK Background The function lpddr4_mr_read in BSP always return zero and this casue the customer can't use it to read MR registers in DRAM. This is a simple demo for reading MR registers. Patch Code diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h b/arch/arm/include/asm/arch-imx8m/ddr.h index 0f1e832c03..fd68996a23 100644 --- a/arch/arm/include/asm/arch-imx8m/ddr.h +++ b/arch/arm/include/asm/arch-imx8m/ddr.h @@ -721,6 +721,8 @@ int wait_ddrphy_training_complete(void); void ddrphy_init_set_dfi_clk(unsigned int drate); void ddrphy_init_read_msg_block(enum fw_type type); +unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr); + void update_umctl2_rank_space_setting(unsigned int pstat_num); void get_trained_CDD(unsigned int fsp); diff --git a/board/freescale/imx8mp_evk/spl.c b/board/freescale/imx8mp_evk/spl.c index 33bbbc09ac..85e40ffbbe 100644 --- a/board/freescale/imx8mp_evk/spl.c +++ b/board/freescale/imx8mp_evk/spl.c @@ -150,6 +150,40 @@ int board_fit_config_name_match(const char *name) return 0; } #endif +void lpddr4_get_info() +{ + int i = 0, attempts = 5; + + unsigned int ddr_info = 0; + unsigned int regs[] = { 5, 6, 7, 8 }; + + for(i = 0; i < ARRAY_SIZE(regs); i++){ + unsigned int data = 0; + data = lpddr4_mr_read(0xF,regs[i]); + ddr_info <<= 8; + ddr_info += (data & 0xFF); + switch (i) + { + case 0: + printf("DRAM INFO : Manufacturer ID = 0x%x",ddr_info); + if(ddr_info & 0Xff) + printf(", Micron\n"); + break; + case 1: + printf("DRAM INFO : Revision ID1 = 0x%x\n",ddr_info); + break; + case 2: + printf("DRAM INFO : Revision ID2 = 0x%x\n",ddr_info); + break; + case 3: + printf("DRAM INFO : I/O Width and Density = 0x%x\n",ddr_info); + break; + default: + break; + } + } + +} void board_init_f(ulong dummy) { @@ -187,6 +221,8 @@ void board_init_f(ulong dummy) /* DDR initialization */ spl_dram_init(); + + lpddr4_get_info(); board_init_r(NULL, 0); } diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index 326b92d784..f45eeaf552 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -194,8 +194,15 @@ unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr) tmp = reg32_read(DRC_PERF_MON_MRR0_DAT(0)); } while ((tmp & 0x8) == 0); tmp = reg32_read(DRC_PERF_MON_MRR1_DAT(0)); - tmp = tmp & 0xff; reg32_write(DRC_PERF_MON_MRR0_DAT(0), 0x4); + + while (tmp) { //try to find a significant byte in the word + if (tmp & 0xff) { + tmp &= 0xff; + break; + } + tmp >>= 8; + } return tmp; } Test Result

This is simple known-how for how to implement "boot animation" with DRM under i.MX8/X + Linux: Code to refer to: ========================================================================= 1. kmscube: Either open source one or the customized on for i.MX will be OK: https://cgit.freedesktop.org/mesa/kmscube/ https://source.codeaurora.org/external/imx/kmscube-imx/ 2. Android display HAL: KmsDisplay.cpp Known-how: ========================================================================= 1. Only one application can grab the master role of the DRM device. If need to control DRM from two applicaiton simultanously, possible solution: A, Use "controlD" node instead of "card" node in /dev/dri/. This requires L4.14 or before. This device node was removed by two commits in L4.14.x: 8a357d10043c75e980e7fcdb60d2b913491564af 6449b088dd51dd5aa6b38455888bbf538d21f2fc Can be brought back by reverting these two commits in L4.14.98. B, Use framebuffer emulator to emulate a FB device (/dev/fb0). (not recommended due to lack of vsync). 2. Some kernel functions will re-config the DRM device during boot. This will cause display abnormal after user application has configured the DRM device. Better to disable these kernel features: CONFIG_DRM_FBDEV_EMULATION CONFIG_FRAMEBUFFER_CONSOLE 3. Use atomic mode of KMS API instead of legacy mode for any dynamically screen drawing application, such as video, game and etc. Atomic mode will have much better performance compare to legacy mode. The kmscube has sample code for both mode. 4. Better to do commit checking before doing any real commit, especially when doing display during boot. Sometimes some internal component in DRM is not fully ready after card device is present. DRM_MODE_ATOMIC_ALLOW_MODESET 5. If video playback will be used, some points to remind: a, Sample code for direct video decoding (in unit-test): imx-test/test/mxc_v4l2_vpu_test/ b, VPU in i.MX8/X only support tiled NV12 output and it has pixel alignment requirement (128). Need to use CPU or G2D to do un-tile, CSC and cropping. Sample code: <android>/vendor/nxp/fsl_imx_omx/OpenMAXIL/src/component/v4l2_common/G2dProcess.cpp If using G2D under Linux, it will support un-tile directly (through OpenCL internally).

This article is to show how to use CLK2 for PCIe ref clock for i.MX8MQ. Test Environment i.MX8MQ + BSP L5.10.52 Background In order to cost down, some customers used CLK2 as PCIe reference clock as below while no external OSC installed, which is different with i.MX8MQ EVK design, so no clock output for PCIe. Checked L4.14.98_2.3.0 and found it added internal PLL for PCIe clock support. Solution The attached patch based on 4.14.98 can’t be used directly on 5.10.52, the following is the main modification for PLLOUT of PCIe clock. PLLOUT Monitor Configuration Register contains bits to control the clock that will be generated on the CCM clock mapped to CLK2_P/N.

The purpose of this document is to provide supportive information for selection of suitable LPDDR4, DDR4 and DDR3L devices that are supported by i.MX 8M family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products. It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs available on NXP.com Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket. LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB dual rank, dual-channel device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8M Mini 32-bit 64Gb/8GB dual rank, dual-channel device with 17-row addresses (R0-R16) 1, 2 i.MX 8M Nano 16-bit 32Gb/4GB dual rank, single-channel device with 17-row addresses (R0-R16) 1, 2, 3, 12 i.MX 8M Plus 32-bit 64Gb/8GB dual rank, dual-channel device with 17-row addresses (R0-R16) 1, 2 LPDDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 8M Quad 24Gb/3GB Micron MT53B768M32D4NQ-062 WT:B 15 32Gb/4GB Micron MT53D1024M32D4DT-046 AAT:D 14 4Gb/512MB ISSI IS43LQ16256B-062BLI 5, 14 8Gb/1GB ISSI IS43LQ32256B-062BLI 5, 14 i.MX 8M Mini 16Gb/2GB Micron MT53D512M32D2DS-053 WT:D 15 16Gb/2GB ESMT M56Z16G32512A-SMBIG 5, 14 32Gb/4GB Micron MT53E1G32D2FW-046 WT:A 5, 14 64Gb/8GB Micron MT53E2G32D4DT-046 AIT:A 5, 14 64Gb/8GB Micron MT53E2G32D4DE-046 AUT:C 5, 14 32Gb/4GB Intelligent Memory IMBG32L4KBB 5,14 32Gb/4GB Kingston B3221PM3BDGUI -U 5 16Gb/2GB Kingston D1621PM4CDGVIW-U 5 i.MX 8M Nano 16Gb / 2GB Kingston C1612PC2WDGTKR-U 15 16Gb / 2GB Kingston D1611PM3BDGUI-U 5,14 32Gb / 4GB Micron MT53E2G32D4DT-046 AIT:A 5, 13, 15 16Gb / 2GB Intelligent Memory IMAG16L4KBB 5,14 4Gb / 512MB Nanya NT6AN256M16AV-J2 5,14 4Gb / 512MB Winbond W66CP6RBQAHJ 5,14 8Gb / 1GB ISSI IS43LQ16512A-053BLI 5,14 8Gb / 1GB Micron MT53D512M32D2DS-053 WT:D 13, 15 i.MX 8M Plus 48Gb/6GB Micron MT53E1536M32D4DT-046 WT:A 15 64Gb/8GB Micron MT53E2G32D4DE-046 AUT:C 5, 14 32Gb/4GB Samsung K4FBE3D4HB-KHCL 5, 14 32Gb/4GB Kingston B3221PM3BDGVIW-U 5, 14 64Gb/8GB Kingston Q6422PM3BDGVK-U 5, 14 8Gb/1GB Winbond W66DP2RQQAHJ 5, 14 32Gb/4GB ISSI IS46LQ32K01S2A-046BLA2 5, 14 16Gb/2GB ISSI IS46LQ32512A-046BLA3 5 32Gb/4GB ISSI IS43LQ32K01S2A-046BLI 5, 14 32Gb/4GB IM IMBG32LK4BBG-046I 5, 14 32Gb/4GB Nanya NT6AN1024F32AV-J2 5, 14 LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table: Memory Vendor Memory Part# Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL K4UJE3D4AA-KU(H/F)CL 24Gb/3Gb 48Gb/6GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. The memory device only supports the LPDDR4X mode. DDR4 - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 6 i.MX 8M Mini 32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 i.MX 8M Nano 16-bit 64Gb/8GB x8, 16Gb device with 2 bank group addresses, 17-row addresses and 10 column addresses 1, 8 i.MX 8M Plus 32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 DDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 8M Quad 32Gb/4GB Micron 4x MT40A512M16JY-083EAAT 15 i.MX 8M Mini 16Gb/2GB Micron 2x MT40A512M16LY-075:E 15 i.MX 8M Nano 16Gb/2GB Micron 1x MT40A1G16RC-062E:B 15 8Gb/1GB Rayson 1x RS512M16Z2DD-62DT 14 8Gb/1GB UniIC SCB12Q8G160BF-06SI 14 i.MX 8M Plus 64Gb/8GB Micron 4x MT40A1G16RC-062E:B 15 16Gb/2GB Nanya NT5AD512M16C4-JRI 14 DDR3L - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB x16, 8Gb device with 16-row addresses and 10 column addresses 1, 9 i.MX 8M Mini 32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 10 i.MX 8M Nano 16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 11 i.MX 8M Plus i.MX 8M Plus does not support DDR3L DDR3L - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Vendor Validated Memory Part# Notes i.MX 8M Quad 16Gb/2GB Micron 4x MT41K256M16TW-107 AAT 14 i.MX 8M Mini 16Gb/2GB Micron 4x MT41K256M16TW-107 AAT 14 i.MX 8M Nano 8Gb/1GB Micron MT41K512M16VRN-107 15 Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standards JESD209-4/JESD209-4A (LPDDR4), JESD279-4/JESD279-4A (DDR4), and JESD79-3E/JESD79-3F/JESD79-3-1A (DDR3/DDR3L). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chips to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the DDR Controller Note 5: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 6: The density can be achieved by connecting 2 single-rank discrete devices with one 16Gb die each. Since the SoC supports x8 devices and also has connectivity for a second rank, usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Two x16 16Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (only two discrete devices used), and bandwidth aspects (full data bus width used). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 64Gb/8GB of address space dedicated for the DDR. Four x16 16Gb devices giving 64Gb/8GB in total is the optimal choice that balances the maximum density aspects, the signal integrity aspects (only four discrete devices used), and the bandwidth aspects (full data bus width used). Note 8: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Note 9: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Four x16 8Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (four discrete devices used), and bandwidth aspects (full data bus width used). Note 10: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that the first option significantly exceeds the number of devices used on the validation board (4 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis. Practically, it is not recommended to use more than 4 discrete DDR3L devices. This corresponds to the maximum density of 32Gb/4GB in the case of the single rank devices containing one 8Gb die or 64Gb/8GB in case of the dual-rank devices, each containing two 8Gb dies. Note 11: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note 12: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q1 2022). Note 13: Only one channel of the device (and hence, half of its density) was utilized due to the reduced data bus width (x16) of the SoC. Note 14: Part is active. Reviewed Jan 2026 Note 15: Part will either EoL or is not recommended for new designs by the respective vendor. Additional Links https://community.nxp.com/t5/iMX-and-Vybrid-Support/i-MX-8-8X-8XL-maximum-supported-LPDDR4-and-DDR3L-densities/ta-p/1152715

The purpose of this document is to provide supportive information for selection of suitable LPDDR4 and DDR3L devices that are supported by i.MX 8/8X/8XLite family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products. It is strongly recommended to consult with NXP and the respective memory vendor, the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the respective NXP i.MX 8 Hardware Developer's Guide available on NXP.com The i.MX8/8X/8XL Reference manuals declare that there are 16GB allocated for the DDR. Please note that this is only the address space, which is reserved for the DDR memory in the memory map. This specification does not guarantee that the entire region can be utilized as the maximum achievable densities listed below in the tables are restricted mainly by the addressing capabilities of the DDR controller, width of the data bus and other implementation-specific parameters as well as availability of supported devices on the market. Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket. LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QM/8QP 29x29 mm 32-bit (per controller) 32Gb/4GB (per controller) dual rank, dual-channel device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 21x21 mm 32-bit 32Gb/4GB dual rank, dual-channel device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 17x17 mm 16-bit 16Gb/2GB dual rank, single-channel device with 16-row addresses (R0-R15) 1, 2, 3, 4, 9 i.MX 8XLite 15x15 mm 16-bit 32Gb/4GB dual rank, single channel device with 17-row addresses (R0-R16) 1, 2, 3, 9 LPDDR4 - list of validated memories The validation process is an ongoing effort - updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 8QM/8QP 24Gb/3GB (per controller) Micron MT53B768M32D4NQ-062 AIT:B 12, 13 32Gb/4GB (per controller) Samsung K4FBE3D4HB-KHCL 10, 11 32Gb/4GB (per controller) Micron MT53E1G32D2FW-046 AUT:B (Z42M) 10, 11 32Gb/4GB (per controller) Micron MT53D1024M32D4DT-046 AAT:D 12 16Gb/2GB (per controller) Micron MT53D512M32D2DS-046 WT:D 10, 12 16Gb/2GB (per controller) Nanya NT6AN512T32AC-J1J 10, 11 16Gb/2GB (per controller) Nanya NT6AN512T32AC-J1H 10, 11 32Gb/4GB (per controller) Nanya NT6AN1024F32AC-J2J 10, 11 32Gb/4GB (per controller) Nanya NT6AN1024F32AC-J2H 10, 11 i.MX 8QXP/8DXP 24Gb/3GB Micron MT53B768M32D4NQ-062 AIT:B 12, 13 32Gb/4GB Nanya NT6AN1024F32AC-J2J 10, 11 32Gb/4GB Nanya NT6AN1024F32AC-J2H 10, 11 16Gb/2GB Nanya NT6AN512T32AC-J2J 10, 11 16Gb/2GB Nanya NT6AN512T32AC-J2H 10, 11 32Gb/4GB Micron MT53D1024M32D4DT-046 AAT:D 11 i.MX 8XLite 8Gb/1GB Micron MT53D512M16D1DS 046 AAT ES:D & Z9XGG 12 12Gb/1.5GB Micron MT53E768M16D1ZW-046 AAT:C 10, 11, 13 4Gb/0.5GB Samsung K4F4E164HD-THCL 10, 11 8Gb/1GB ISSI IS43LQ16512A-053BLI 10, 11 8Gb/1GB Nanya NT6AN512M16AV-J1I 10, 11 LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table: Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX8QM/8QP, i.MX8QXP/8DXP The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL 24Gb/3Gb i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4UJE3D4AA-KU(H/F)CL 48Gb/6GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. Samsung K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. The device only supports the LPDDR4X mode. DDR3L - maximum supported densities SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QXP/8DXP 21x21 mm 32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 6 i.MX 8QXP/8DXP 17x17 mm 16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 7 i.MX 8XLite 15x15 mm 16-bit 16Gb/2GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 8 DDR3L - list of validated memories The validation process is an ongoing effort - updates of the table are expected. SoC Density Memory Vendor Validated Mamory Part# Notes i.MX 8QXP/8DXP 8Gb/1GB Micron 2x MT41K256M16TW-093 IT:P 12 i.MX 8XLite 4Gb/512MB Micron MT41K256M16TW-093 IT:P 12 Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD209-4A. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chip to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the SoCs. Note 5: The numbers are based purely on the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD79-3E/JESD79-3F. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 6: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select, or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that this number of discrete devices significantly exceeds the number of devices used on the validation board (2 discrete devices, not taking into account the device used for ECC) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies (x16 8Gb devices with 16-row addresses and 10 column addresses assumed instead of x8 devices in such case). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note that the first option exceeds the number of devices used on the validation board (2 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis, hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies. Note 8: The density can be achieved by connecting 2 single rank discrete devices with one 8Gb die each to the i.MX. 8XLite supports only one chip select for DDR3L therefore, dual-rank systems are not supported. Note 9: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (2025). Note 10: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 11: Part is active. Reviewed Aug 2025 Note 12: Part is being End Of Life'd (EoL) by Vendor or obsolete. Note 13: Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. Additional Links i.MX 8M Quad/8M Mini/8M Nano/8M Plus - LPDDR4, DDR4 and DDR3L memory compatibility guide

Customer can force PCIE to work at GEN1/GEN2 mode if PCB layout is not good. Pls refer to: linux/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt:40:- fsl,max-link-speed: Specify PCI gen for link capability. Must be '2' for i.MX8M: diff --git a/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi b/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi index f4dcf7ac3c98..262db6f93cb2 100755 --- a/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi @@ -1314,7 +1314,7 @@ <&clk IMX8MQ_CLK_PCIE1_AUX>, <&clk IMX8MQ_CLK_PCIE1_PHY>; clock-names = "pcie", "pcie_bus", "pcie_phy"; - fsl,max-link-speed = <2>; + fsl,max-link-speed = <1>; ctrl-id = <0>; power-domains = <&pcie0_pd>; status = "disabled"; @@ -1344,7 +1344,7 @@ <&clk IMX8MQ_CLK_PCIE2_AUX>, <&clk IMX8MQ_CLK_PCIE2_PHY>; clock-names = "pcie", "pcie_bus", "pcie_phy"; - fsl,max-link-speed = <2>; + fsl,max-link-speed = <1>; ctrl-id = <1>; power-domains = <&pcie1_pd>; status = "disabled"; diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c index 54459b52f526..a63de7e7bae0 100644 --- a/drivers/pci/dwc/pci-imx6.c +++ b/drivers/pci/dwc/pci-imx6.c @@ -1548,6 +1548,7 @@ static int imx_pcie_establish_link(struct imx_pcie *imx_pcie) u32 tmp; int ret; + dw_pcie_dbi_ro_wr_en(pci); /* * Force Gen1 operation when starting the link. In case the link is * started in Gen2 mode, there is a possibility the devices on the i.MX8/8x: fsl-imx8dx.dtsi pcieb: pcie@0x5f010000 { /* * pcieb phyx1 lane1 in default, adjust it refer to the * exact hw design. */ . . . . . power-domains = <&pd_pcie>; fsl,max-link-speed = <1>; /* 3=gen3, 1=gen1 */ hsio-cfg = <PCIEAX2PCIEBX1>; hsio = <&hsio>; ctrl-id = <1>; /* pcieb */ cpu-base-addr = <0x80000000>; status = "disabled"; }; pci-imx6.c @@ -1799,6 +1799,7 @@ static int imx_pcie_establish_link(struct imx6_pcie *imx6_pcie) u32 tmp; int ret; + dw_pcie_dbi_ro_wr_en(pci); /* * Force Gen1 operation when starting the link. In case the link is * started in Gen2 mode, there is a possibility the devices on the @@ -1870,11 +1871,13 @@ static int imx_pcie_establish_link(struct imx6_pcie *imx6_pcie) dev_info(dev, "Link: Gen2 disabled\n"); } + dw_pcie_dbi_ro_wr_dis(pci); tmp = dw_pcie_readl_dbi(pci, PCIE_RC_LCSR); dev_info(dev, "Link up, Gen%i\n", (tmp >> 16) & 0xf); return 0; err_reset_phy: + dw_pcie_dbi_ro_wr_dis(pci); dev_dbg(dev, "PHY DEBUG_R0=0x%08x DEBUG_R1=0x%08x\n", dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG0), dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG1));

The following steps allow you to toggle a pin on i.MX 8M Mini EVK, you can use the EVK as not gate, trigger a wake up signal, etc. With an script and modifying the device tree you can read an input and get as output the invert input. On the Host. Cloning the Linux kernel repository. Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/linux-imx cd linux-imx/ Patching the device tree. Open the imx8mm-evk.dtsi file: vim arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi For the purpose of this example, uart3 has to be "disabled" in order to avoid pins conflict, so change "okay" to "disabled": &uart3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart3>; assigned-clocks = <&clk IMX8MM_CLK_UART3>; assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>; fsl,uart-has-rtscts; status = "disabled"; }; Add the following lines in the iomuxc node: &iomuxc { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_hog>; pinctrl_hog: hoggrp { fsl,pins = < MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x19 MX8MM_IOMUXC_ECSPI1_MISO_GPIO5_IO8 0x19 >; }; Build the device tree. Setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8mm-evk.dtb Copy the .dtb file to the EVK, for example with scp: scp imx8mm-evk.dtb root@<EVK_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. On the EVK Board. Switching the device tree. To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8mm-evk.dtb Partition_1/ Reboot the board. reboot Create an script. Use vi: vi toggle.sh Add the following lines: #!/bin/bash echo 136 > /sys/class/gpio/export echo in > /sys/class/gpio/gpio136/direction echo 137 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio137/direction echo 0 > /sys/class/gpio/gpio137/value while : do if [[($(cat /sys/class/gpio/gpio136/value) == "0")]]; then echo 1 > /sys/class/gpio/gpio137/value else echo 0 > /sys/class/gpio/gpio137/value fi done Save the file: :wq Change file permissions: chmod +x toggle.sh Toggling a pin. In this example we are using the pin "UART3_CTS" like an input and "UART3_RTS" like an output. To toggle the pin, run the script: ./toggle.sh

Background Some customers connect their imx running Android to the cloud, so reboot-bootloader and the use of fastboot oem unlock is not acceptable. This way the system is disconnected and cannot be operated remotely using adb. This article therefore proposes to execute oem unlock before the bootloader is started when the system is first run, which can be unlocked directly. Patch diff --git a/drivers/fastboot/fb_fsl/fb_fsl_boot.c b/drivers/fastboot/fb_fsl/fb_fsl_boot.c index 86b919775a..d60cd248ee 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_boot.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_boot.c @@ -529,6 +529,42 @@ bool __weak is_power_key_pressed(void) { return false; } +static void wipe_all_userdata(void) +{ + char response[FASTBOOT_RESPONSE_LEN]; + + /* Erase all user data */ + printf("Start userdata wipe process....\n"); + /* Erase /data partition */ + fastboot_wipe_data_partition(); + +#if defined (CONFIG_ANDROID_SUPPORT) || defined (CONFIG_ANDROID_AUTO_SUPPORT) + /* Erase the misc partition. */ + process_erase_mmc(FASTBOOT_PARTITION_MISC, response); +#endif + +#ifndef CONFIG_ANDROID_AB_SUPPORT + /* Erase the cache partition for legacy imx6/7 */ + process_erase_mmc(FASTBOOT_PARTITION_CACHE, response); +#endif + +#if defined(AVB_RPMB) && !defined(CONFIG_IMX_TRUSTY_OS) + printf("Start stored_rollback_index wipe process....\n"); + rbkidx_erase(); + printf("Wipe stored_rollback_index completed.\n"); +#endif + process_erase_mmc(FASTBOOT_PARTITION_METADATA, response); + printf("Wipe userdata completed.\n"); +} +void do_unlock(void) +{ + int status; + wipe_all_userdata(); + status = fastboot_set_lock_stat(FASTBOOT_UNLOCK); + if (status < 0) + return FASTBOOT_LOCK_ERROR; + printf("Unlock device\n"); +} int do_boota(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]) { ulong addr = 0; @@ -563,6 +599,9 @@ int do_boota(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]) { fastboot_set_lock_stat(FASTBOOT_LOCK); lock_status = FASTBOOT_LOCK; } + if (lock_status == FASTBOOT_LOCK){ + do_unlock(); + } bool allow_fail = (lock_status == FASTBOOT_UNLOCK ? true : false); avb_metric = get_timer(0);

The following steps allow you to add a pad Wakeup on i.MX 8QuadMax MEK CPU Board. On the Host. Cloning the Linux kernel repository. Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/linux-imx cd linux-imx/ Patching the device tree. Open the imx8qm-mek.dts file: vim arch/arm64/boot/dts/freescale/imx8qm-mek.dts Add the following lines: &lsio_gpio2{ pad-wakeup-num = <1>; pad-wakeup = <81 4 1>; }; In the line pad-wakeup-num = <1>; , the number "1" corresponds to the number of pads that you want to add. The line pad-wakeup = <81 4 1>; has three parameters: The first parameter corresponds to the "pin_id", you can find it in include/dt-bindings/pinctrl/pads-imx8qm.h , in this example we are using "IMX8QM_MIPI_CSI1_I2C0_SDA". The second parameter corresponds to the "'type'", you can find it in the i.MX 8QuadMax Applications Processor Reference Manual, in the page 802: For this example we are using "LOW". The third parameter corresponds to the "line", the number of bit in 32bit gpio group, you can find it in include/dt-bindings/pinctrl/pads-imx8qm.h In this example, "IMX8QM_MIPI_CSI1_I2C0_SDA" belongs to gpio group 2, line 1. Build the device tree. Setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8qm-mek.dtb Copy the .dtb file to the MEK CPU Board, for example with scp: scp imx8qm-mek.dtb root@<MEK_CPU_Board_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. On the MEK CPU Board. Switching the device tree. To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8qm-mek.dtb Partition_1/ Reboot the board. reboot How to wake up the i.MX 8QuadMax MEK CPU Board. In this example a wire was soldered on "R204": Run the following command on the MEK CPU Board: echo mem > /sys/power/state And you will see something like: [ 53.769266] PM: suspend entry (deep) [ 53.902130] Filesystems sync: 0.129 seconds [ 53.908068] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 53.917189] OOM killer disabled. [ 53.920420] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 53.929626] printk: Suspending console(s) (use no_console_suspend to debug) Connect the wire that was soldered on "R204" to ground, the MEK CPU Board will wake up and you will see something like: [ 54.687125] fec 5b040000.ethernet eth0: Link is Down [ 54.689876] PM: suspend devices took 0.756 seconds [ 54.709570] Disabling non-boot CPUs ... [ 54.710562] CPU1: shutdown [ 54.711582] psci: CPU1 killed (polled 0 ms) [ 54.714360] CPU2: shutdown [ 54.715376] psci: CPU2 killed (polled 0 ms) [ 54.717365] CPU3: shutdown [ 54.718382] psci: CPU3 killed (polled 0 ms) [ 54.719887] CPU4: shutdown [ 54.720884] psci: CPU4 killed (polled 4 ms) [ 54.722213] CPU5: shutdown [ 54.723229] psci: CPU5 killed (polled 0 ms) [ 54.724731] Enabling non-boot CPUs ... [ 54.725388] Detected VIPT I-cache on CPU1 [ 54.725423] GICv3: CPU1: found redistributor 1 region 0:0x0000000051b20000 [ 54.725486] CPU1: Booted secondary processor 0x0000000001 [0x410fd034] [ 54.726455] CPU1 is up [ 54.726930] Detected VIPT I-cache on CPU2 [ 54.726947] GICv3: CPU2: found redistributor 2 region 0:0x0000000051b40000 [ 54.726976] CPU2: Booted secondary processor 0x0000000002 [0x410fd034] [ 54.727478] CPU2 is up [ 54.727955] Detected VIPT I-cache on CPU3 [ 54.727971] GICv3: CPU3: found redistributor 3 region 0:0x0000000051b60000 [ 54.728001] CPU3: Booted secondary processor 0x0000000003 [0x410fd034] [ 54.728497] CPU3 is up [ 54.729806] Detected PIPT I-cache on CPU4 [ 54.729825] GICv3: CPU4: found redistributor 100 region 0:0x0000000051b80000 [ 54.729857] CPU4: Booted secondary processor 0x0000000100 [0x410fd082] [ 54.730490] CPU4 is up [ 54.730985] Detected PIPT I-cache on CPU5 [ 54.730999] GICv3: CPU5: found redistributor 101 region 0:0x0000000051ba0000 [ 54.731021] CPU5: Booted secondary processor 0x0000000101 [0x410fd082] [ 54.731679] CPU5 is up [ 54.756440] hdmi_rx_hd_core_clk: failed to set clock parent -16 [ 54.765828] gpio-mxc 5d0a0000.gpio: wakeup by pad, line 1 [ 54.844242] ahci-imx 5f020000.sata: external osc is used. [ 54.913582] caam 31400000.crypto: registering rng-caam [ 54.918358] PM: resume devices took 0.148 seconds [ 55.096663] OOM killer enabled. [ 55.099814] Restarting tasks ... done. [ 55.111833] PM: suspend exit

The following steps allow you to build a bootable image in two different ways and also how to enable and use SCFW debug monitor. There are four files needed to generate a bootable image: ├── bl31.bin ├── u-boot.bin ├── mx8qm-ahab-container.img └── scfw_tcm.bin There are some ways to get the four files, one way is with Yocto and other way is with stand alone build. Get the four files needed to generate a bootable image with Yocto. To get the four files needed with Yocto, you have to build an i.MX 8QuadMax image, maybe some steps are not necessary. 1.-Host packages. sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa \ libsdl1.2-dev pylint3 xterm rsync curl 2.-Setting up the Repo utility. mkdir ~/bin (this step may not be needed if the bin folder already exists) curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo export PATH=~/bin:$PATH 3.-Yocto Project Setup. git config --global user.name "Your Name" git config --global user.email "Your Email" git config --list mkdir imx-yocto-bsp cd imx-yocto-bsp repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-hardknott -m imx-5.10.72-2.2.0.xml repo sync 4.-Build configurations. DISTRO=fsl-imx-xwayland MACHINE=imx8qmmek source imx-setup-release.sh -b imx8qmmek 5.-Building an image. bitbake imx-image-full The four files needed to generate a bootable image are in: ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools Note: With Yocto you can not enable the SCFW debug monitor. For more information see the i.MX Yocto Project User's Guide. Get the four files needed to generate a bootable image with stand alone build. To build all required binaries from source you can use standard aarch64 Linux toolchain, on Ubuntu 20.04 LTS: sudo apt-get install gcc-aarch64-linux-gnu Get the bl31.bin file - Arm Trust Firmware. Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/imx-atf Build: cd imx-atf make clean PLAT=imx8qm CROSS_COMPILE=aarch64-linux-gnu- make PLAT=imx8qm CROSS_COMPILE=aarch64-linux-gnu- bl31 The compiled bl31.bin location: build/imx8qm/release/bl31.bin Get the u-boot.bin file - u-boot. Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/uboot-imx Build: cd uboot-imx make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx8qm_mek_defconfig make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- The compiled u-boot.bin location: ./u-boot.bin Get the mx8qmb0-ahab-container.img file - iMX Seco. wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-3.7.4.bin chmod +x imx-seco-3.7.4.bin ./imx-seco-3.7.4.bin --auto-accept The mx8qmb0-ahab-container.img file location: imx-seco-3.7.4/firmware/seco/mx8qmb0-ahab-container.img Get the scfw_tcm.bin file - SCFW. Download and Install a GNU Toolchain. Look at the packages/imx-scfw-porting-kit-1.7.4/doc/pdf/ , chapter Porting Guide, sub-chapter Tool Chain to check which GNU Toolchain version corresponds to the SCFW you are building. The imx-scfw-porting-kit-1.7.4 version uses the GNU Toolchain version gcc-arm-none-eabi-8-2018-q4-major . It is recommended to install toolchain in “opt” folder: cd /opt sudo wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 sudo tar xjf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 Download and Install a Arm GCC toolchain. It is recommended to install toolchain in “opt” folder: sudo wget https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz sudo tar -Jxvf gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz After installing the toolchain, set up the environment variable relevant for building. export ARCH=arm CROSS_COMPILE=/opt/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- export TOOLS=/opt Build the scfw_tcm.bin file. cd ~ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-scfw-porting-kit-1.7.4.bin chmod +x imx-scfw-porting-kit-1.7.4.bin ./imx-scfw-porting-kit-1.7.4.bin --auto-accept cd imx-scfw-porting-kit-1.7.4/src Extract the desired scfw porting kit: tar -xvf scfw_export_mx8qm_b0.tar.gz cd scfw_export_mx8qm_b0/ Build without debug monitor: make clean make qm B=mek R=B0 Build with debug monitor: make clean make qm B=mek D=1 M=1 R=B0 DDR_CON=imx8qm_dcd_1.6GHz The scfw_tcm.bin file location: build_mx8qm_b0/scfw_tcm.bin Generate the bootable image. Once you have the four files needed to generate a bootable image, use imx-mkimage tool. Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/imx-mkimage Copy the four binaries to iMX8QM folder. You have to rename some files. If you got the four binaries with Yocto. cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/bl31-imx8qm.bin ~/imx-mkimage/iMX8QM/bl31.bin cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/u-boot-imx8qmmek.bin-sd ~/imx-mkimage/iMX8QM/u-boot.bin cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/mx8qmb0-ahab-container.img ~/imx-mkimage/iMX8QM cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/mx8qm-mek-scfw-tcm.bin ~/imx-mkimage/iMX8QM/scfw_tcm.bin If you got the four binaries with stand alone build. cp ~/imx-atf/build/imx8qm/release/bl31.bin ~/imx-mkimage/iMX8QM cp ~/uboot-imx/u-boot.bin ~/imx-mkimage/iMX8QM cp ~/imx-seco-3.7.4/firmware/seco/mx8qmb0-ahab-container.img ~/imx-mkimage/iMX8QM cp ~/imx-scfw-porting-kit-1.7.4/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ~/imx-mkimage/iMX8QM Build the bootable image. cd ~/imx-mkimage make SOC=iMX8QM flash The compiled file is flash.bin and its location is: iMX8QM/flash.bin Flash the bootable image. To flash the bootable image follow the next steps: -Copy the flash.bin and uuu.exe in a folder. -Change SW2 on the base board to 000100 (from MSB to LSB, 1-ON and 0-OFF) to boot from the Serial Downloader. -Run the following command in Command Prompt: uuu.exe -b sd flash.bin -Power on the MEK CPU board. SCFW debug monitor. If the SCFW is compiled using the M=1 option (default is M=0) then it will include a debug monitor. This can be used to R/W memory or registers, R/W power state, and dump some resource manager state. Production SCFW should never have the monitor enabled (M=0, the default)! The debug monitor allows command-line interaction via the SCU UART. Inclusion of the debug monitor affects SCFW timing and therefore should never be deployed in a product! Note the terminal needs to be in a mode that sends CR or LF for a new line (not CR+LF). The following commands are supported: Command Description exit exit the debug monitor quit exit the debug monitor reset [mode] request reset with mode (default = board) reboot partition [type] request partition reboot with type (default = cold) md.b address [count] display count bytes at address md.w address [count] display count words at address md[.l] address [count] display count long-words at address mm.b address value modify byte at address mm.w address value modify word at address mm[.l] address value modify long-word at address ai.r ss sel addr read analog interface (AI) register ai.w ss sel addr data write analog interface (AI) register fuse.r word read OTP fuse word fuse.w word value write value to OTP fuse word dump rm dump all the resource manager (RM) info dump rm part [part] dump all partition info for part (default = all) dump rm rsrc [part] dump all resource info for part (default = all) dump rm mem [part] dump all memory info for part (default = all) dump rm pad [part] dump all pad info for part (default = all) power.r [resource] read/get power mode of resource (default = all) power.w resource mode write/set power mode of resource to mode (off, stby, lp, on) info display SCFW/SoC info like unique ID, etc. seco lifecycle change send SECO lifecycle update command (change) to SECO seco info display SECO info like Lifecycle, SNVS state, etc. seco debug dump SECO debug log seco events dump SECO event log seco commit commit SRK and/or SECO FW version update pmic.r id reg read pmic register pmic.w id reg val write pmic register pmic.l id list pmic info (rail voltages, etc) Resource and subsystem (ss) arguments are specified by name. All numeric arguments are decimal unless prefixed with 0x (for hex) or 0 (for octal). Testing SCFW debug monitor to display count long-words at address on Linux side and on SCU side. -Change SW2 on the base board to 001100 (from MSB to LSB, 1-ON and 0-OFF) to boot from the SD card. -Power on the MEK CPU board. -Open Tera Term and you will see: Hello from SCU (Build 5263, Commit 9b3d006e, Aug 20 2021 12:20:10) DDR frequency = 1596000000 ROM boot time = 262368 usec Boot time = 24583 usec Banner = 10 usec Init = 9038 usec Config = 3232 usec DDR = 2677 usec SConfig = 444 usec Prep = 5039 usec *** Debug Monitor *** >$ -Run the following commands: power.r power.w db on power.w dblogic on power.w mu_1a on -Example reading on Linux side: md.l 0x5d1c0000 10 -You will see: >$ md.l 0x5d1c0000 10 5d1c0000: 00000000 00000000 00000000 00000000 5d1c0010: 00010201 23c34600 d63fdb21 00000000 5d1c0020: 00f00200 18000000 -Example reading on SCU side: md.l 0x41cac080 10 -You will see: >$ md.l 0x41cac080 10 41cac080: 00000000 00000000 00000000 00000000 41cac090: 0d070201 ff0001f1 ffff8000 ffff00fb 41cac0a0: 00f00000 18000000 For more information see the System Controller Firmware Porting Guide.

Some customer enable AHAB function on i.MX8X board to realize security boot. So they have fused hab_closed bit on the board. While they want to change DDR type on this board so need to do DDR stress test. While If using NXP official released DDR stress test, it failed to run on such hab_closed board. This article describe how to run command line version DDR stress test on such hab_closed board. Thanks!

Useful information about push buttons. Physical level. When there is a change of voltage level on P0-P7 pins, PCA9555PW will generate interrupt on INT pin. The driver (running on SoC) can read the status of P0-P7 pins via I2C (SCL/SDA pins) and generate separate interrupts for each of P0-P7 pins. This is why this driver acts as interrupt controller. Consider next configuration: One push button changes level on P4 pin, tempting PCA9555PW to generate interrupt. Interrupt from PCA9555PW is connected to GPIO5 IP-core (inside of SoC), and it uses line #9 of that GPIO5 module to notify CPU about interrupt. So we can say that PCA9555PW is cascaded to GPIO5 controller. GPIO5 also acts as interrupt controller, and it's cascaded to GIC interrupt controller. Device tree properties. The meaning of properties is as follows: interrupt-controller property defines that device generates interrupts; it will be needed further to use this node as interrupt-parent in each push button node. #interrupt-cells defines format of interrupts property; in our case it's 2 : 1 cell for line number and 1 cell for interrupt type interrupt-parent and interrupts properties are describing interrupt line connection Interrupt handling. CPU now is in interrupt context in GIC interrupt handler. From gic_handle_irq() it calls handle_domain_irq() , which in turn calls generic_handle_irq() . See Documentation/gpio/driver.txt for details. Now we are in SoC's GPIO controller IRQ handler. SoC's GPIO driver also calls generic_handle_irq() to run handler, which is set for each particular pin. See for example how it's done in omap_gpio_irq_handler() . Now we are in PCA9555PW IRQ handler. PCA9555PW IRQ handler calls handle_nested_irq() . Finally, gpio_keys_gpio_isr() is called. The following steps allow you to enable rgb led's and push buttons on 8MIC-RPI-MX8 board with i.MX 8M Mini Applications Processor Evaluation Kit (EVKB). You have to use a led driver and change the device tree. On the Host. Cloning the Linux kernel repository. Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone https://source.codeaurora.org/external/imx/linux-imx This guide will use the following commit which corresponds to Kernel 5.10.35-2.0. cd linux-imx/ git checkout -b RGB ef3f2cfc6010 Patching the device tree. Download the "0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch" file attached to this post and copy it into linux-imx directory, then apply the patch. cp 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch ~/linux-imx/ cd ~/linux-imx/ patch < 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch When prompted, select the file to patch: File to patch: arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts patching file arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8mm-evk-8mic-revE.dtb Copy the .dtb file to the EVK, for example with scp: scp imx8mm-evk-8mic-revE.dtb root@<EVK_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. Compiling the Led driver. Obtain the leds-pca995x.h file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/include/linux/platform_data/leds-pca995x.h Copy it into the next path: cp leds-pca995x.h ~/linux-imx/include/linux Create a new directory. mkdir ~/linux-imx/PCA9955 Create a makefile. cd ~/linux-imx/PCA9955 vim Makefile KERNEL_ROOT?=~/linux-imx obj-m += leds-pca995x.o all: make -C $(KERNEL_ROOT) M=$(PWD) modules clean: make -C $(KERNEL_ROOT) M=$(PWD) clean Press the key "Esc" and then: :wq Obtain the leds-pca995x.c file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/drivers/leds/leds-pca995x.c Copy it into the next path: cp leds-pca995x.c ~/linux-imx/PCA9955 Obtain 0001-PCA9955BTW.patch file and copy it into the next path: cp 0001-PCA9955BTW.patch ~/linux-imx/PCA9955 Apply the patch. patch < 0001-PCA9955BTW.patch Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate .ko file. cd ~/linux-imx/PCA9955 make all Copy the .ko file to the EVK, for example with scp: scp leds-pca995x.ko [email protected]:/home/root NOTE: The linux version of .ko file must be the same as EVK. On the EVK. Switching the device tree. To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8mm-evk-8mic-revE.dtb Partition_1/ Reboot the board. reboot Stop on u-boot and modify the .dtb file to use the device tree for 8mic board. u-boot=> editenv fdtfile edit: imx8mm-evk-8mic-revE.dtb u-boot=> saveenv Saving Environment to MMC... Writing to MMC(1)... OK u-boot=> boot Installing a led driver. Execute the following command to load the led driver into the kernel. insmod leds-pca995x.ko And you will see something like: [ 249.359103] leds_pca995x: loading out-of-tree module taints kernel. [ 249.366864] ALL [ 249.368740] ALL 0 [ 249.370667] ALL 1 [ 249.372609] ALL 2 [ 249.374536] ALL 2 [ 249.376475] ALL 2 [ 249.378401] ALL 2 [ 249.380338] ALL 2 [ 249.382264] ALL 2 [ 249.384202] ALL 2 [ 249.386127] ALL 2 [ 249.388063] ALL 2 [ 249.389989] ALL 2 [ 249.391913] ALL 2 [ 249.393847] ALL 2 [ 249.395774] ALL 2 [ 249.397709] ALL 2 [ 249.399635] ALL 2 [ 249.401568] ALL 2 [ 249.403496] ALL 3 Turning on a Led. If you changed the device tree, you can turn on a led with the following command: echo 250 > /sys/class/leds/pca995x\:blue0/brightness To turn off a led: echo 0 > /sys/class/leds/pca995x\:blue0/brightness The red, blue and green leds can be turned on at different intensities provided. Testing the push buttons. If you changed the device tree, you can test the push buttons with the following command: evtest Select the correct number: No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: 30370000.snvs:snvs-powerkey /dev/input/event1: sw_keys /dev/input/event2: gpio_ir_recv Select the device event number [0-2]: 1 And you will see: Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sw_keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 67 (KEY_F9) Event code 113 (KEY_MUTE) Event code 114 (KEY_VOLUMEDOWN) Event code 115 (KEY_VOLUMEUP) Properties: Testing ... (interrupt to exit) Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------ Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------

We will build a remote debug environmet of Qt Creator in this user guide. Contents 1 Change local.conf file in Yocto 2 2 Build and deploy Yocto SDK 2 2.1 Build full image SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Deploy SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Configure QT Kit 2 3.1 Setup device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2 Configure QT version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3 Configure gcc and g++ manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Configure gdb manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Configure Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6 Very important thing!! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Test result

In some cases, such as OTA, need a complete reset/reboot of the i.MX8/i.MX8X. Current BSP default design for i.MX8/i.MX8X is partition reset/reboot. So even using spl bootloader(flash.bin). The scfw is still running old version. Not the upgrade version as expected. Because the reset/reboot by the u-boot or Linux, Only reset/reboot the A Core partition. SCU is not reset. Need to change to the board reset, which will launch entire reset/reboot of the i.MX8/i.MX8X including SCU.

What is Automotive Grade Linux? Automotive Grade Linux is a collaborative, open source project that brings together automakers, suppliers, and technology companies for the purpose of building Linux-based, open source software platforms for automotive applications that can serve as de facto industry standards. AGL address all software in the vehicle: infotainment, instrument cluster, heads-up-display (HUD), telematics, connected car, advanced driver assistance systems (ADAS), functional safety, and autonomous driving. Architecture The Automotive Grade Linux Software Architecture diagram is below. The architecture consists of five layers. The App/HMI layer contains applications with their associated business logic and HMI. The Application Framework layer provides the APIs for creating both managing and running applications on an AGL system. The Services layer contains user space services that all applications can access. The Operating System (OS) layer provides the Linux kernel and device drivers along with standard OS utilities. For IVI (In Vehicle Infotainment) system a full fledged demo is available. Supported Boards The following table briefs about the various hardware platforms, supported by AGL : BOARD $MACHINE ARCHITECHTURE BeagleBone bbe arm32 beaglebone arm32 i.MX 6 cubox-i arm32 imx6qdlsabreauto arm32 nitrogen6x arm32 i.MX 8 imx8mqevk arm64 imx8mqevk-viv arm64 Snapdragon dragonboard-410c arm64 dragonboard-820c arm64 ARC HS hsdk ARC virtio virtio-aarch64 arm64 AGL Components AGL includes some major components showing as follow: agl-compositor waltham-receiver_waltham-transmitter rba drm-leasemanager appfw cynagora. pyagl pipewire_wireplumber agl-compositor When the AGL project was started, weston was chosen as the compositor, which is the reference implementation of a Wayland compositor, while for window management functionality it relied on ivi-shell (In-Vehicle Infotainment) together with an extension, called wayland-ivi-exension. Waltham protocol is a IPC library similar to Wayland, developed with networking in mind. It operates over TCP sockets, while the wayland protocol only works locally over a UNIX socket. It retains wayland-esque paradigm, making use of XMLs to describe the protocol, and it follows an object-oriented design with an asynchronous architecture. DRM Lease Manager The DRM Lease Manager is used in AGL to allocate display controller outputs to different processes. Each process has direct access to its allocated output via the kernel DRM interface, and is prevented from accessing any other outputs managed by the display controller. PyAGL PyAGL was written to be used as a testing framework replacing the Lua afb-test one, however the modules are written in a way that could be used as standalone utilities to query and evaluate apis and verbs from the App Framework Binder services in AGL. PipeWire / WirePlumber AGL uses the PipeWire daemon service to provide audio playback and capture capabilities. PipeWire is accompanied by a secondary service, WirePlumber (also referred to as the session manager), which provides policy management, device discovery, configuration and more. Applications can connect to the PipeWire service through its UNIX socket, by using either the libpipewire or libwireplumber libraries as a front-end to that socket. How to port AGL in i.MX8qm get agl source as follow: repo init -b koi -uhttps://git.automotivelinux.org/AGL/AGL-repo repo sync apply patches in attachment add file agl_imx8qmmek.inc to path 'meta-agl\meta-agl-bsp\conf\include'. add files 40_bblayers.conf.inc, 50_local.conf.inc and 50_setup.sh to path 'meta-agl\templates\machine\imx8qmmek'. build as follow: source meta-agl/scripts/aglsetup.sh -f -m imx8qmmek agl-demo bitbake agl-demo-platform Then the wic image can be flashed into i.mx8qm showing as below:

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

Demo code of lpddr4_mr_read for reading MR registers in DRAM

i.MX8 serials GPIO input and output setting tips

[i.MX8]Adding support for showing interrupt status in Sysrq

Boot animation through DRM in Linux

CLK2 used as PCIe REF CLK on i.MX8MQ + L5.10.52

i.MX 8M Quad/Mini/Nano/Plus - LPDDR4, DDR4 & DDR3L memory compatibility guide

i.MX 8/8X/8XLite - LPDDR4 and DDR3L memory compatibility guide

[i.MX8/8X/8M]Force PCIE to work at GEN1/2 mode

Toggle pin on i.MX 8M Mini Applications Processor Evaluation Kit (EVKB).

Unlock device while Android booting

How to add a i.MX 8QuadMax PAD Wakeup.

How to build I.MX Bootloader for i.MX 8QuadMax MEK CPU Board.

How to run DDR stress test on i.MX8X hab_closed board

Enable RGB LED's and push buttons on 8MIC-RPI-MX8 board.

Remote debug QT5 User Guide

i.MX8 i.MX8X Board Reset

regulator userspace-consumer

AGL architecture and How to port in i.MX8qm

How to use Bluetooth on i.MX8M boards

Porting MPU6050 on Android to realize auto rotation of screen