i.MX Processors Knowledge Base

Discussions

Test environment i.MX8MP EVK LVDS0 LVDS-HDMI bridge(it6263) Uboot2022, Uboot2023 Background Some customers need show logo using LVDS panel. Current BSP doesn't support LVDS driver in Uboot. This patch provides i.MX8MPlus LVDS driver support in Uboot. If you want to connect it to LVDS panel , you need port your lvds panel driver like simple-panel.c Update [2022.9.19] Verify on L5.15.32_2.0.0 0001-L5.15.32-Add-i.MX8MP-LVDS-driver-in-uboot 'probe device is failed, ret -2, probe video device failed, ret -19' is caused by below code. It has been merged in attachment. // /* Only handle devices that have a valid ofnode */ // if (dev_has_ofnode(dev) && !(dev->driver->flags & DM_FLAG_IGNORE_DEFAULT_CLKS)) { // /* // * Process 'assigned-{clocks/clock-parents/clock-rates}' // * properties // */ // ret = clk_set_defaults(dev, CLK_DEFAULTS_PRE); // if (ret) // goto fail; // } [2023.3.14] Verify on L5.15.71 0001-L5.15.71-Add-i.MX8MP-LVDS-support-in-uboot [2023.9.12] For some panel with low DE, you need uncomment CTRL_INV_DE line and set this bit to 1. #include <linux/string.h> @@ -110,9 +111,8 @@ static void lcdifv3_set_mode(struct lcdifv3_priv *priv, writel(CTRL_INV_HS, (ulong)(priv->reg_base + LCDIFV3_CTRL_SET)); /* SEC MIPI DSI specific */ - writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - + //writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); + //writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); } [2024.5.15] If you are uing simple-panel.c, need use below patch to set display timing from panel to lcdif controller. diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c index f9281d5e83..692c96dcaa 100644 --- a/drivers/video/simple_panel.c +++ b/drivers/video/simple_panel.c @@ -18,12 +18,27 @@ struct simple_panel_priv { struct gpio_desc enable; }; +/* define your panel timing here and + * copy it in simple_panel_get_display_timing */ +static const struct display_timing boe_ev121wxm_n10_1850_timing = { + .pixelclock.typ = 71143000, + .hactive.typ = 1280, + .hfront_porch.typ = 32, + .hback_porch.typ = 80, + .hsync_len.typ = 48, + .vactive.typ = 800, + .vfront_porch.typ = 6, + .vback_porch.typ = 14, + .vsync_len.typ = 3, +}; + @@ -100,10 +121,18 @@ static int simple_panel_probe(struct udevice *dev) return 0; } +static int simple_panel_get_display_timing(struct udevice *dev, + struct display_timing *timings) +{ + memcpy(timings, &boe_ev121wxm_n10_1850_timing, sizeof(*timings)); + + return 0; +} static const struct panel_ops simple_panel_ops = { .enable_backlight = simple_panel_enable_backlight, .set_backlight = simple_panel_set_backlight, + .get_display_timing = simple_panel_get_display_timing, }; static const struct udevice_id simple_panel_ids[] = { @@ -115,6 +144,7 @@ static const struct udevice_id simple_panel_ids[] = { { .compatible = "lg,lb070wv8" }, { .compatible = "sharp,lq123p1jx31" }, { .compatible = "boe,nv101wxmn51" }, + { .compatible = "boe,ev121wxm-n10-1850" }, { } }; [2024.7.23] Update patch for L6.6.23(Uboot2023) [2025.10.24] If you are facing 'Enable clock-controller@30380000 failed' error, add clocks in ccm driver. diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c index 05a7d050be6..38497056344 100644 --- a/drivers/clk/imx/clk-imx8mp.c +++ b/drivers/clk/imx/clk-imx8mp.c @@ -181,6 +181,11 @@ static const char * imx8mp_media_mipi_phy1_ref_sels[] = {"clock-osc-24m", "sys_p static const char * imx8mp_media_disp_pix_sels[] = {"clock-osc-24m", "video_pll1_out", "audio_pll2_out", "audio_pll1_out", "sys_pll1_800m", "sys_pll2_1000m", "sys_pll3_out", "clk_ext4", }; + +static const char * imx8mp_media_ldb_sels[] = {"clock-osc-24m", "sys_pll2_333m", "sys_pll2_100m", + "sys_pll1_800m", "sys_pll2_1000m", + "clk_ext2", "audio_pll2_out", + "video_pll1_out", }; #endif static const char *imx8mp_dram_core_sels[] = {"dram_pll_out", "dram_alt_root", }; @@ -321,6 +326,8 @@ static int imx8mp_clk_probe(struct udevice *dev) #ifndef CONFIG_SPL_BUILD clk_dm(IMX8MP_CLK_MEDIA_MIPI_PHY1_REF, imx8m_clk_composite("media_mipi_phy1_ref", imx8mp_media_mipi_phy1_ref_sels, base + 0xbd80)); clk_dm(IMX8MP_CLK_MEDIA_DISP1_PIX, imx8m_clk_composite("media_disp1_pix", imx8mp_media_disp_pix_sels, base + 0xbe00)); + clk_dm(IMX8MP_CLK_MEDIA_DISP2_PIX, imx8m_clk_composite("media_disp2_pix", imx8mp_media_disp_pix_sels, base + 0x9300)); + clk_dm(IMX8MP_CLK_MEDIA_LDB, imx8m_clk_composite("media_ldb", imx8mp_media_ldb_sels, base + 0xbe00)); #endif clk_dm(IMX8MP_CLK_DRAM_ALT_ROOT, imx_clk_fixed_factor("dram_alt_root", "dram_alt", 1, 4)); clk_dm(IMX8MP_CLK_DRAM_CORE, imx_clk_mux2_flags("dram_core_clk", base + 0x9800, 24, 1, imx8mp_dram_core_sels, ARRAY_SIZE(imx8mp_dram_core_sels), CLK_IS_CRITICAL)); @@ -363,7 +370,9 @@ static int imx8mp_clk_probe(struct udevice *dev) clk_dm(IMX8MP_CLK_MEDIA_APB_ROOT, imx_clk_gate2_shared2("media_apb_root_clk", "media_apb", base + 0x45d0, 0, &share_count_media)); clk_dm(IMX8MP_CLK_MEDIA_AXI_ROOT, imx_clk_gate2_shared2("media_axi_root_clk", "media_axi", base + 0x45d0, 0, &share_count_media)); clk_dm(IMX8MP_CLK_MEDIA_DISP1_PIX_ROOT, imx_clk_gate2_shared2("media_disp1_pix_root_clk", "media_disp1_pix", base + 0x45d0, 0, &share_count_media)); + clk_dm(IMX8MP_CLK_MEDIA_DISP2_PIX_ROOT, imx_clk_gate2_shared2("media_disp2_pix_root_clk", "media_disp2_pix", base + 0x45d0, 0, &share_count_media)); clk_dm(IMX8MP_CLK_MEDIA_MIPI_PHY1_REF_ROOT, imx_clk_gate2_shared2("media_mipi_phy1_ref_root", "media_mipi_phy1_ref", base + 0x45d0, 0, &share_count_media)); + clk_dm(IMX8MP_CLK_MEDIA_LDB_ROOT, imx_clk_gate2_shared2("media_ldb_root_clk", "media_ldb", base + 0x45d0, 0, &share_count_media)); #endif clk_dm(IMX8MP_CLK_USDHC3_ROOT, imx_clk_gate4("usdhc3_root_clk", "usdhc3", base + 0x45e0, 0)); Update LVDS panel demo.

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 Validated part number Vendor Notes i.MX 8M Quad 24Gb/3GB MT53B768M32D4NQ-062 WT:B Micron 15 32Gb/4GB MT53D1024M32D4DT-046 AAT:D Micron 14 4Gb/512MB IS43LQ16256B-062BLI ISSI 5, 14 8Gb/1GB IS43LQ32256B-062BLI ISSI 5, 14 i.MX 8M Mini 16Gb/2GB MT53D512M32D2DS-053 WT:D Micron 15 16Gb/2GB M56Z16G32512A ESMT 5, 14 32Gb/4GB MT53E1G32D2FW-046 WT:A Micron 5, 14 64Gb/8GB MT53E2G32D4DT-046 AIT:A Micron 5, 14 32Gb/4GB B3221PM3BDGUI -U Kingston 5 i.MX 8M Nano 16Gb / 2GB C1612PC2WDGTKR-U Kingston 15 16Gb / 2GB D1611PM3BDGUI-U Kingston 5,14 32Gb / 4GB MT53E2G32D4DT-046 AIT:A Micron 5, 13, 15 16Gb / 2GB IMAG16L4KBB Intelligent Memory (IM) 5,14 4Gb / 512MB NT6AN256M16AV-J2 Nanya 5,14 4Gb / 512MB W66CP6RBQAHJ Winbond 5,14 8Gb / 1GB IS43LQ16512A-053BLI ISSI 5,14 8Gb / 1GB MT53D512M32D2DS-053 WT:D Micron 13, 15 i.MX 8M Plus 48Gb/6GB MT53E1536M32D4DT-046 WT:A Micron 15 64Gb/8GB MT53E2G32D4DE-046 AUT:C Micron 5, 14 32Gb/4GB K4FBE3D4HB-KHCL Samsung 5, 14 32Gb/4GB D1611PM3BDGUI-U Kingston 5, 14 64Gb/8GB Q6422PM3BDGVK-U Kingston 5, 14 8Gb/1GB W66DP2RQQAHJ Winbond 5, 14 32Gb/4GB IS46LQ32K01S2A-046BLA2 ISSI 5, 14 32Gb/4GB IS43LQ32K01S2A-046BLI ISSI 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 Part Number 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 Vendor Validated part number 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 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 part number (vendor) 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 Nov 2025 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 Package Maximum validated density Vendor Validated part number Notes i.MX 8QM/8QP 29x29 mm 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 21x21 mm 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 15x15 mm 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 Package Density Validated part number (vendor) Notes i.MX 8QXP/8DXP 21x21 mm 8Gb/1GB 2x MT41K256M16TW-093 IT:P (Micron) 12 i.MX 8XLite 15x15 mm 4Gb/512MB MT41K256M16TW-093 IT:P (Micron) 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));

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 root@192.168.100.105:/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 ------------

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:

Materials: i.MX8M Plus EVK Rev. A USB cable type-C USB cable type-B AC Adapter EA1045CR Micro SD (Optional) 88W8997-based wireless modules Software: Yocto Project Mobaxterm Personal Edition v20.2 Build 4296 This test was done on an i.MX8M Plus EVK with Linux 5.10. Hardknott. To achieve this, you need to identify your WI-FI module and look for the necessary drivers for that module, in my case I am using the 88W8997 module that comes with the i.MX8M Plus, but you can select any other WI-FI module you want. In my case I build a basic image on Yocto, following the Yocto users guide, I bitbake just the core boot image that allows me to boot the i.MX8M plus. Deploy your image on an SD or eMMC. These instructions apply to SD and MMC cards although for brevity, and usually, only the SD card is listed. For a Linux image to be able to run, four separate pieces are needed: Linux OS kernel image (zImage/Image) Device tree file (*.dtb) Bootloader image Root file system (i.e., EXT4) The Yocto Project build creates an SD card image that can be flashed directly. This is the simplest way to load everything needed onto the card with one command. A .wic image contains all four images properly configured for an SD card. The release contains a pre-built .wic image that is built specifically for the one board configuration. It runs the Wayland graphical backend. It does not run on other boards unless U-Boot, the device tree, and rootfs are changed. When more flexibility is desired, the individual components can be loaded separately, and those instructions are included here as well. An SD card can be loaded with the individual components one-by-one or the .wic image can be loaded and the individual parts can be overwritten with specific components. The rootfs on the default .wic image is limited to a bit less than 4 GB, but re-partitioning and re-loading the rootfs can increase that to the size of the card. The rootfs can also be changed to specify the graphical backend that is used. Carry out the following command to copy the SD card image to the SD/MMC card. Change sdx below to match the one used by the SD card. $ sudo dd if=<image name>.wic of=/dev/sdx bs=1M && sync The entire contents of the SD card are replaced. If the SD card is larger than 4 GB, the additional space is not accessible. As this build does not contain the driver integrated we need to add it manually on Linux user space. Follow these instructions to load the driver modules and bring up the 88W8987-based wireless module, more info can be found on the next link: https://www.nxp.com/products/wireless/wi-fi-plus-bluetooth/2-4-5-ghz-dual-band-2x2-wi-fi-5-802-11ac-plus-bluetooth-5-3-solution:88W8997?tab=Documentation_Tab Use the nano editor included in the pre-built image to edit and verify the module parameters in the wifi_mod_para.conf configuration file. Add the following lines to the configuration file: PCIE8997 = { cfg80211_wext=0xf wfd_name=p2p max_vir_bss=1 cal_data_cfg=none drv_mode=7 ps_mode=2 auto_ds=2 fw_name=nxp/pcieuart8997_combo_v4.bin } Load the modules in the kernel: Verify the kernel debug messages in the command output Verify that the module is now visible to the system: Now that the module is ready to work, we need to enable it, in my case the Wi-Fi is named mlan0, it could vary on other Linux systems. In the case you need to see which networks are available you can scan it and select the one you need. Identify your network and add it to the WPA supplicant file: Associate the Wi-Fi with config: Check if you have right SSID associated: Use DHPC to get the IP Ping any public site you know to check the network. In the case you have a Temporary failure in name resolution you will need to change the default DNS that was assigned by DHCP: Modify /etc/resolv.conf file and add the DNS of your preference, for my case I add the one that uses Google, as they have access to the most common web pages. And with that should work.

1.overwrite the sources/meta-freescale/recipes-security/optee-imx with optee-imx.zip 2.add below code to conf/local.conf DISTRO_FEATURES_append += " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "systemd-compat-units" MACHINE_FEATURES_append += "optee" DISTRO_FEATURES_append += "optee" IMAGE_INSTALL_append += "optee-test optee-os optee-client optee-examples" 3.bitbake optee-examples or bitbake imx-image-xxx You can directly install optee-examples_3.11.0-r0_arm64.deb in your device.

Symptoms When configure a gpio pin for a driver in the dts/dtsi file like below example, e.g. a-switch { compatible = "a-switch-driver"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_switch>; gpios = <&lsio_gpio1 1 GPIO_ACTIVE_HIGH>; status = "okay"; }; pinctrl_switch: switch_gpio { fsl,pins = < IMX8QXP_SPI2_SDO_LSIO_GPIO1_IO01 0x21 >; }; then you may get the error when request the gpio in the driver during the kernel boot up. Error message like this: a-switch: failed to request gpio a-switch: probe of a-switch failed with error -22 Linux version: L5.4.x Diagnosis Because the gpio_mxc_init function run before the function imx_scu_driver_init. The pm_domains for gpio is not ready before running mxc_gpio_probe, so gpio request will be failed. Solution There are two ways to resolve this issue 1. Build the driver as a module. i.e. select the driver in kernel’s menuconfig as “M”. Then , run “insmod” to load the driver after the kernel boot up. OR 2. Apply below patch, let gpio driver init after scu driver. diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c index 1dfe513f8fcf..52b5799040b3 100644 --- a/drivers/gpio/gpio-mxc.c +++ b/drivers/gpio/gpio-mxc.c @@ -892,7 +892,7 @@ static int __init gpio_mxc_init(void) return platform_driver_register(&mxc_gpio_driver); } -subsys_initcall(gpio_mxc_init); +device_initcall(gpio_mxc_init);

1 - Introduction: The Ultra Secured Digital Host Controller (uSDHC) provides the interface between the host processor and the SD/SDIO/MMC cards. Most recent versions provides the ability to automatically select a quantized delay (in fractions of the clock period) regardless of on-chip variations such as process, voltage, and temperature (PVT). The auto tuning is performed during runtime at hardware level, no software enablement is needed to drive this feature. 2 - Failure description: SDIO cards can implement an optional feature that uses DATA[1] to signal the card's interrupt to the i.MX device, this feature can be enabled by the SDIO card device and does not depends on i.MX uSDHC driver configuration. NXP Linux BSP is enabling the auto tuning for high SDIO frequencies (SDR104 and SDR50). Out of reset uSDHC_VEND_SPEC2 register is configured to use DATA[3:0] for calibration, this setup can conflict with the SDIO interrupt as DATA[1] signal can be asserted asynchronously. SDIO failures can be observed when running SDIO applications that requires high usage of the SDIO interface (e.g Download of large files), SDIO controller cannot return an accurate DLL causing failures such as "CMD53 read error". Failure can be observed on i.MX8MM EVK and i.MX8MN EVK boards, both devices are running 88w8987 Wi-Fi chipset at 208Mhz (SDR104). Users can observe an SDIO crash followed by error message below at Linux Kernel level. [ 401.945627] cmd53 read error=-84 [ 401.974677] moal_read_data_sync: read registers failed 3 - Impacted devices: The following devices are impacted by this limitation. - i.MX6 Family: i.MX6SL, i.MX6SLL, i.MX6SX, i.MX6UL, i.MX6ULZ and i.MX6ULL. - All i.MX7 and i.MX7ULP family: i.MX7D, i.MX7S and i.MX7ULP. - All i.MX8M Family: i.MX8MQuad, i.MX8M Mini, i.MX8M Nano, i.MX8M Nano UL and i.MX8M Plus. - All i.MX8/8X Family: i.MX8DQXP, i.MX8DX and i.MX8QM. NXP Linux BSP is enabling the auto tuning for SDR104 and SDR50 modes. Other operation modes are not impacted by this limitation. Users can poll uSDHCx_CLK_TUNE_CTRL_STATUS register when running SDIO applications to confirm. TAP_SEL_PRE field is updated automatically during run time and constant variations can point to an incorrect delay cell calculated by the uSDHC controller. All NXP Wi-Fi chipsets are enabling SDIO interrupt during firmware load, failures can be observed with any Wi-Fi vendor enabling SDIO asynchronous interrupt. 4 - Software changes: Recommendation is to enable auto tuning for DATA[0] and CMD signals only, DATA[1] should not be used for auto calibration to avoid a possible conflict with SDIO interrupt. This setup can only be used if SDIO interface length are well matched. Software patches can be found at codeaurora.org. Fix is already included in L5.10.52-2.1.0 BSP, users can add fsl,sdio-interrupt-enabled property to uSDHC device tree node to enable SW workaround. https://github.com/nxp-imx/linux-imx/commit/3b3d6dec05277f7786d813592a31ea4a1ce60a74 https://github.com/nxp-imx/linux-imx/commit/b9b5a43df1d709809b2b654ad8f8181b00a4ee55 https://github.com/nxp-imx/linux-imx/commit/95a846af9f82dc6ea60064d9d12d5d2378e23941

In some cases, i.MX board connect to different module. It has very tiny changes, such as just one gpio different driver strength. We can build an entire new software to handle this requirement. Here we introduce another way, using u-boot to modify the device tree(dtb) at runtime. Here is u-boot fdt command for How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709 run loadfdt fdt addr ${fdt_addr_r} fdt print /soc/bus/pinctrl/uart3grp fdt rm /soc/bus/pinctrl/uart3grp fdt print serial2 fdt set serial2 status disabled fdt print serial2 fdt print gpio4 fdt resize fdt mknode gpio4 gpio_hog_demo fdt set gpio4/gpio_hog_demo gpio-hog fdt set gpio4/gpio_hog_demo gpios <7 0> fdt set gpio4/gpio_hog_demo output-high fdt print gpio4 run mmcargs run loadimage booti ${loadaddr} - ${fdt_addr_r} root@imx8mmevk:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/30200000.gpio, 30200000.gpio: gpio-5 ( |PCIe DIS ) out hi gpio-13 ( |ir-receiver ) in hi IRQ ACTIVE LOW gpio-15 ( |cd ) in hi IRQ ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/30210000.gpio, 30210000.gpio: gpio-38 ( |? ) out hi gpio-42 ( |reset ) out lo ACTIVE LOW gpio-51 ( |regulator-usdhc2 ) out lo gpiochip2: GPIOs 64-95, parent: platform/30220000.gpio, 30220000.gpio: gpio-80 ( |status ) out hi gpiochip3: GPIOs 96-127, parent: platform/30230000.gpio, 30230000.gpio: gpio-117 ( |PCIe reset ) out hi gpiochip4: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: gpio-135 ( |gpio_hog_demo ) out hi gpio-141 ( |spi1 CS0 ) out hi ACTIVE LOW gpio-149 ( |wlf,mute ) out hi ACTIVE LOW root@imx8mmevk:~# [ 33.758914] VSD_3V3: disabling dtc_utils-v1.6.1-win-x86_64.zip by msys2

Application Note AN13872 Enabling SWUpdate on i.MX 6ULL, i.MX 8M Mini, and i.MX 93 is available on www.nxp.com SWUpdate: Embedded Systems become more and more complex. Software for Embedded Systems have new features and fixes can be updated in a reliable way. Most of time, we need OTA(Over-The-Air) to upgrade the system. Like Android has its own update system. Linux also need an update system. SWUpdate project is thought to help to update an embedded system from a storage media or from network. However, it should be mainly considered as a framework, where further protocols or installers (in SWUpdate they are called handlers) can be easily added to the application. Mongoose daemon mode: Mongoose is a daemon mode of SWUpdate that provides a web server, web interface and web application. Mongoose is running on the target board(i.MX8MM EVK/i.MX8QXP MEK).Using Web browser to access it. Suricatta daemon mode: Suricatta regularly polls a remote server for updates, downloads, and installs them. Thereafter, it reboots the system and reports the update status to the server. The screenshot is SWUpdate scuricatta working with hawkbit server.

Purpose This is early communication to notify i.MX 8M Dual/8M QuadLite/8M Quad customers of a potential incorrect PCIe power supply configuration on certain NXP BSP Linux and Android versions. Description The PCIE_VPH power supply is selectable in software between 1.8V and 3.3V. When the PCIE_VPH supply is configured to operate at 3.3V, the 1.8V internal regulator (disabled by default) must be enabled to prevent overstress conditions on the PCIe PHY. If the 1.8V internal regulator is left disabled when the PCIE_VPH supply is configured to operate at 3.3V, it could potentially impact the product lifetime of the device. Impact •i.MX 8M Dual/8M QuadLite/8M Quad (other i.MX processors are not impacted) •Only Impacts Linux/Android kernel versions earlier than L5.4.70_2.3.2 or Linux 5.10.9_1.0.0 releases MITIGATION •When the PCIE_VPH supply is configured to operate at 3.3V users need to enable the internal regulator by setting the IOMUXC_GPR_GPR14 and IOMUXC_GPR_GPR16 registers - PCIE1_VREG_BYPASS and PCIE2_VREG_BYPASS bit to 0. •There are 3 software patches for each release. Software patch details in the Code Aurora Forum (CAF): •For L5.4.70_2.3.2 patch release, the git log references are: •MLK-25349-3 PCI: imx: clear vreg bypass when pcie vph voltage is 3v3 •MLK-25349-2 arm64: dts: imx8mq-evk: add one regulator used to power up pcie phy •MLK-25349-1 dt-bindings: imx6q-pcie: add one regulator used to power up pcie phy • •The L5.4.70_2.3.2, LF_5.10 Q2 and later BSP releases correctly configure and enable the internal regulator by setting the IOMUXC_GPR_GPR14 and IOMUXC_GPR_GPR16 registers The Patch MLK-25349 which correctly enables the internal regulator is already included in the L5.4.70_2.3.2 patch release and release versions after it. MITIGATION •The following branches of Linux/Android BSP releases contain the MLK-25349 patch. The patch is attached below for each respective release. •Other branches which are not listed should try to apply the nearest Patch version patch. If a user encounters any conflicts in applying, they should back porting from below nearest patch release version below. imx_4.9.51_ga, imx_4.9.y_android_imx8m_ga_v2 - Patch attached imx_4.9.88_ga, imx_4.9.y_android_2.0.0_ga - Patch attached imx_4.14.y and imx_4.14.98_2.3.0, imx_4.14.98_2.3.0_android - Patch attached imx_4.19.y and imx_4.19.35_1.1.0, imx_4.19.35_1.1.0_android - Patch attached imx_5.4.y, imx_5.4.3_2.0.0, imx_5.4.3_2.0.0_android - Patch attached Documentation Change Description – 1 of 3 for Datasheet Updated Datasheets and Reference Manual will be published to nxp.com. Updated Hardware Design guide and Schematics have already been published on nxp.com. Updated the descriptions of PCIE_VPH in the Datasheet Table 8, "Operating ranges" Documentation Change Description – 2 of 3 for Reference Manual (RM) Updated the description of field 12 "PCIE1_VREG_BYPASS" in 8.2.4.15 GPR14 General Purpose Register (IOMUXC_GPR_GPR14) Documentation Change Description – 3 of 3 for RM Updated the description of field 12 "PCIE2_VREG_BYPASS" in 8.2.4.17 GPR16 General Purpose Register (IOMUXC_GPR_GPR16) REFERENCES •i.MX 8M Dual / 8M QuadLite / 8M Quad Product Lifetime Usage •i.MX 8M Dual / 8M QuadLite / 8M Quad Applications Processors Data Sheet for Industrial Products •i.MX 8M Dual / 8M QuadLite / 8M Quad Applications Processors Data Sheet for Consumer Products •i.MX 8MDQLQ Hardware Developer’s Guide •i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

Add i.MX8MP LVDS driver in uboot

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

mx8_ddr_stress_test without UI

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

AGL architecture and How to port in i.MX8qm

Porting MPU6050 on Android to realize auto rotation of screen

How to connect to a Wi-Fi network on i.MX8MP

Enable SFTP on i.MX

Enable SSH on i.MX

Incorporating Out-of-Tree Modules in YOCTO

Build optee-examples in yocto(hardkott)

i.MX8M/8X GPIO probe failed

uSDHC auto tuning and possible SDIO failures

u-boot runtime modify Linux device tree(dtb)

Debugging method of linux kernel

How to use gpio-hog demo

SWUpdate OTA i.MX8MM EVK / i.MX8QXP MEK

i.MX 8M Dual/8M QuadLite/8M Quad Incorrect PCIE Supply Configuration