i.MX Processors Knowledge Base

Discussions

When working with an evaluation kit you will be provided with a System Controller Firmware (SCFW) binary included in your BSP. This scfw binary has been tailored for that specific board and you might need to modify some board dependencies to fit your specific hardware. This document aims to provide an overview on the SCFW porting process, for detailed information please refer to the System Controller Porting guide (sc_fw_port.pdf). Setting up the system The SCFW is built on a Linux host. The steps to set-up your system are the following: Download the GNU ARM Embedded Toolchain: 6-2017-q2-update June 28, 2017 from the ARM website: Select a directory to untar the file unto, for instance: mkdir ~/gcc_toolchain cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ cd ~/gcc_toolchain/ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Set TOOLS environment variable to the directory containing the tool chain, "~/gcc_toolchain" on the example above, .bash_profile can also be modified to export this environment variable: export TOOLS=~/gcc_toolchain/ srec_cat is also necessary for the build, this is usually contained in the srecord package, on ubuntu you can do: sudo apt-get update sudo apt-get install srecord Now you can change to the porting kit directory (e.g. scfw_export_mx8qm) and build the scfw. System Controller Firmware Porting kit The SCFW porting kit contains source files and object files that will allow you to modify the SCFW to work with your board. You can get the latest System Controller Firmware Porting kit from the i.MX Software and development webpage: Once you obtain the porting kit untar it: tar xvzf imx-scfw-porting-kit-1.1.tar.gz‍ You will see the following file structure: The porting kit is contained under packages, the README contains the instructions to extract the porting kit, basically: cd packages/ chmod a+x imx-scfw-porting-kit-1.1.bin ./imx-scfw-porting-kit-1.1.bin‍‍‍ You will be prompted to accept an End User License Agreement: Once you accept the agreement the porting kit will be extracted in a new folder, the folder structure is as follows: All documentation regarding SCFW is under doc/pdf or in html format if preferred, it is recommended to go over sc_fw_port.pdf. The porting kits for different SoC variants (QM A0, QM B0 and QXP B0) are under src packaged as tar.gz, all other files are SCFW libraries for different software packages, such as Linux, QNX, FreeRTOS, U-boot, ARM Trusted Firmware, etc... If you will be working with several SoC variants (working with both QXP and QM) it is recommended to extract all porting kits into a single directory, that way you will be able to build for any variant from this directory, the command to do this is: cd imx-scfw-porting-kit-1.1/ cd src/ find scfw_export_mx8*.gz -exec tar --strip-components 1 --one-top-level=scfw_export_mx8 -xzvf {} \;‍‍‍ A scfw_export_mx8 folder will be created, from here you will be able to build SCFW for any supported variant. Or you can just extract the package for the variant you are interested on and use that. cd scfw_export_mx8/‍ All the build folders contain the results of building the SCFW and platform is where the source of the SCFW is stored. All the code that is specific to a board configuration is under "platform/board/mx8<derivative>_<board_name>" where derivative is the i.MX8 silicon family such as QXP or QM, and board name is the name of the board the SCFW package is for. The first step in porting the SCFW to your board is to create a folder for your i.MX8 derivative and board, you can take one of the available board examples and rename the folder, that will provide you a project to get started with, for instance: cp -r platform/board/mx8qm_val/ platform/board/mx8qm_myBoard/‍‍‍‍‍‍‍‍‍‍ The board in this example will be called "myBoard" and it is for an i.MX8QM B0 device. To build a SCFW for this board simply call: make qm R=B0 B=myBoard‍‍‍‍‍‍‍‍‍‍‍‍ If the target is an i.MX8QXP simply take a board based on this device and change the call to "make qx". Additional information such as build options and in detailed boot information can be found in the SCFW porting guide (sc_fw_port.pdf), chapter 2 of this document is a great introduction to the porting process. Overview and useful information Configuring the PMIC overview and board.c common modifications The main file that needs to be altered (if not the only) is the "board.c" file, it is located at "platform/board/mx8X_board/". The board.c file contains most of the board related information such as SCU UART ports, PMIC initialization routines, PMIC temperature alarms settings and you can also modify it to configure LDOs voltages and communicate with the PMIC in general. All functions in the board.c file are executed by the SCU itself and this gives you access to the I2C interface that is used to communicate with the PMIC. SoC resources that are powered by an external supply (PMIC LDO for instace) such as AP cores and GPUs are powered off/on by board_set_power_mode, the mapping of the resource to an specific PMIC supply happens in board_get_pmic_info, for instance in our i.MX8QM validation board using the A53 subsystem is powered by SW2 of the third PMIC (PMIC_2_ADDR addresses start at PMIC_0) on the PF100 PMIC card and by SW5 of the first PMIC (PMIC_0_ADDR) on the PF8100 PMIC card. case SC_SUBSYS_A53: pmic_init(); if (pmic_card == PF100) { pmic_id[0] = PMIC_2_ADDR; pmic_reg[0] = SW2; *num_regs = 1; } else {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1; } break; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The voltages of SoC resources that are powered by an external supply (AP cores, GPUs, etc...) are managed by board_set_voltage in the board.c file. The mapping of resource to power supply occurs in board_get_pmic_info as in the example above. Eight "board resources" (SC_R_BOARD_R0, ... SC_R_BOARD_R7) are available, these resources allow you to define components in your board that the SCU can manage, for instance a sensor on your board powered by one of the PMIC LDOs can be mapped to a board resource and the board.c file can be modified to power on/off the sensor as well as modifying its voltage. Modifying the voltage on a board resource can be either be done by modifying the voltage at board_trans_resource_power (see below) or if the voltage needs to change at run time the function board_set_control can be modified to change the voltage whenever a miscellaneous call (more details in the Miscellaneous Service 101) is made on that resource. For instance to change the voltage on SC_R_BOARD_R7 you would have the following case to board_set_control: case SC_R_BOARD_R7: if (ctrl == SC_C_VOLTAGE) { /* Example only PMIC_X_ADDR and PMIC_SUPPLY need to match an actual device */ pmic_interface.pmic_set_voltage(PMIC_X_ADDR, PMIC_SUPPLY, val, step); } else return SC_ERR_PARM; break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The case above will be executed by the SCU every time the application calls the function below: sc_misc_set_control( ipc, SC_R_BOARD_R7, SC_C_VOLTAGE, voltage_val);‍‍‍‍‍‍‍‍ Powering on/off a board resource happens at board_trans_resource_power in the board.c file. For instance in NXP's validation board the PTN5150 on the board is managed through a board resource 0, and the power on/off is managed as follows: case BRD_R_BOARD_R0 : /* PTN5150 (use SC_R_BOARD_R0) */ if (pmic_ver.device_id == PF100_DEV_ID) { if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_2_ADDR, VGEN6, 3300, SW_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_ON); } else { pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_OFF); } } else {/* PF8100_dual Card */ if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_1_ADDR, PF8100_LDO1, 3300, REG_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_EN_STBY_EN); } else { pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_OFF_STBY_OFF); } } break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Whenever the function below is called from the application side the SCU will execute the code above: sc_pm_set_resource_power_mode(ipc, SC_R_BOARD_R0, SC_PM_PW_MODE_ON/OFF);‍‍‍‍‍‍‍‍ board_config_sc is used to mark resources that the SCU needs, such as the I2C module and pads used to communicate with the PMIC, any resource needed by the board.c functions to work should be marked in this function as not movable, for instance to keep the SCU I2C module the following line is added: rm_set_resource_movable(pt_sc, SC_R_SC_I2C, SC_R_SC_I2C, false);‍‍‍‍‍‍‍‍‍ The following pads are part of the SCU and the application will not be able to access them: - SC_P_SCU_PMIC_MEMC_ON - SC_P_SCU_WDOG_OUT - SC_P_PMIC_EARLY_WARNING - SC_P_PMIC_INT_B - SC_P_SCU_BOOT_MODE0 through SC_P_SCU_BOOT_MODE5 board_system_config is where early resource management occurs, this function is only called when the alt_config flag is set in the image, and it can create partitions and allocate resources to it. More details are found in the resource management service 101. board_get_pcie_clk_src defines the clock that the PCIe uses, it can be either BOARD_PCIE_PLL_EXTERNAL or BOARD_PCIE_PLL_INTERNAL. board_print is very useful to debug your changes the syntax is as follows: board_print(3, "Debug printout %d\n", val);‍‍‍‍‍‍‍ Where the first parameter is the Debug Level and from there on it works as a standard printf. The output will only be visible on the SCU debug output whenever the SCU is built with the corresponding debug level, in the case above the SCFW needs to be built as follows in order to see the output: make qm B=myBoard‍‍‍‍ DL=3 or higher (debug level goes from 0 to 5)‍‍‍‍‍‍‍ Usage examples The following utility shows how to make System Controller Firmware requests and provides a way to make such requests through command line interface on both QNX and Linux System Controller Firmware Command Line Utility for Linux and QNX System Controller Firmware 101

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 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 8Gb/1GB W66DP2RQQAHJ Winbond 5, 14 32Gb/4GB D1611PM3BDGUI-U Kingston 5, 14 64Gb/8GB Q6422PM3BDGVK-U Kingston 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 Validated part number (vendor) Notes i.MX 8M Quad 32Gb/4GB 4x MT40A512M16JY-083EAAT (Micron) 15 i.MX 8M Mini 16Gb/2GB 2x MT40A512M16LY-075:E (Micron) 15 i.MX 8M Nano 16Gb/2GB 1x MT40A1G16RC-062E:B (Micron) 15 i.MX 8M Plus 64Gb/8GB 4x MT40A1G16RC-062E:B (Micron) 15 16Gb/2GB NT5AD512M16C4-JRI (Nanya) 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 Validated part number (vendor) Notes i.MX 8M Quad 16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14 i.MX 8M Mini 16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14 i.MX 8M Nano 8Gb/1GB MT41K512M16VRN-107 (Micron) 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 July 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

This post contains a guide of how to use SDMA1 on Cortex M7 in parallel of Linux on A53. For i.MX 8M Plus, SDMA1 is a general-purpose DMA engine which can be used by low speed peripherals including UART, SPI and other peripherals. But some customers found issues when they are using SDMA1 on M7 core in parallel of Linux on A53. For example, if you try to run the sdma_uart_transfer example on the i.MX8M Plus EVK, the example works correctly when interfacing through the JLink debugger. However, you will find that you can not run it from both the remoteproc interface and U-Boot. It exits without error from the UART_SendSDMA function, but the callback is never called and it seems to hang waiting for the information to be sent. On the i.MX 8MP EVK board, uart4 is used for Cortex-M7 core. This article tries to provide an example to establish communication using UART3 and SDMA1 on the i.MX 8MP EVK, while Linux is running on Core A53. This example is based on sdma_uart_transfer demo. The steps are verified with i.MX Linux 6.12.20_2.0.0 release and SDK_25.06.00. The software is compiled on an Ubuntu 22.04 host machine. This article is structured as follows: 1 Hardware requirements 2 Software Requirements 3 Modification in application 3.1 Pin changes 3.2 Clock changes 3.3 Application specific changes 3.4 Memory Region Control change 4 ATF changes 4.1 Download ATF source and change it 4.2 build ATF 5 U-BOOT change 5.1 build u-boot 5.2 make imx-boot image by using imx-mkimage 5.3 flash imx-boot image into i.MX 8MP EVK board 6 Running and Debugging 6.1 Debugging Cortex-M while Cortex-A is in U-BOOT 6.2 Debugging Cortex-M while Cortex-A is in Linux 7 Summary 1 Hardware requirements -PC Host with MCUXpresso for VS Code installed -i.MX 8M Plus EVK (i.MX 8M Plus Power Evaluation Kit | NXP Semiconductors) -12V power supply -Micro USB Cable -J-Link Debug Probe. -USB To TTL( serial ) Converter connect J21 (Pin6_GND Pin8_UART3-TXD Pin10_UART3-RXD) to Host PC via a USB to TTL converter. 2 Software Requirements SDK_25_06_00_EVK-MIMX8MP This package can be download from https://mcuxpresso.nxp.com/ Next I will describe the detailed steps. 3 Modification in application 3.1 Pin changes evkmimx8mp_iuart_sdma_transfer\pin_mux.c 3.2 Clock changes evkmimx8mp_iuart_sdma_transfer\clock_config.c In function BOARD_BootClockRUN 3.3 Application specific changes evkmimx8mp_iuart_sdma_transfer\board.h app.h Till now, we have completed all the changes for change uart4 to uart3. Compile , and debug with J-LINK, we can get the correct result. Board receives 8 characters then sends them out. However, if we try to load code on Cortex-M from U-Boot or Linux, we can not get the expected results. Below steps is a workaround to fix this issue. 3.4 Memory Region Control change hardware_init.c In function BOARD_InitHardware ..... Then compile the application, the output are iuart_sdma_transfer.bin and iuart_sdma_transfer_cm7.elf 4 ATF (ARM Trust Firmware)changes 4.1 Download ATF source and Change it The RDC configuration in default BSP assign UART2 to domain 0 for A53, and Domain 0 can read/write RDC, and Domain 1 (M7) only can read it. $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.12.3-1.0.0 GitHub - nxp-imx/imx-atf: i.MX ARM Trusted firmware plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c We need to assign UART3 to domain 1 so Cortex M7 can access 4.2 build ATF $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.12.3-1.0.0 $ cd imx-atf $ source /opt/fsl-imx-xwayland/6.12-walnascar/environment-setup-armv8a-poky-linux $ export ARCH=arm64 $ unset LDFLAGS $ make PLAT=imx8mp bl31 This builds the bl31.bin binary, the location is : build/imx8mp/release/bl31.bin 5 U-BOOT change 5.1 Download and build u-boot please refer to chapter 4.5.13 How to build imx-boot image by using imx-mkimage , $ git clone https://github.com/nxp-imx/uboot-imx -b lf_v2025.04 $ cd uboot-imx/ $ source /opt/fsl-imx-xwayland/6.12-walnascar/environment-setup-armv8a-poky-linux $ export ARCH=arm64 $ make distclean $ make imx8mp_evk_defconfig $ make The compiled u-boot.bin location uboot-imx/u-boot.bin 5.2 make imx-boot image by using imx-mkimage My work folder The following steps allow you to build the bootable image for i.MX 8M Plus EVK, there are 9 files needed to generate a bootable image: ├── u-boot-spl.bin ├── u-boot-nodtb.bin ├── imx8mp-evk.dtb ├── bl31.bin ├── signed_hdmi_imx8m.bin ├── lpddr4_pmu_train_1d_dmem_202006.bin ├── lpddr4_pmu_train_1d_imem_202006.bin ├── lpddr4_pmu_train_2d_dmem_202006.bin └── lpddr4_pmu_train_2d_imem_202006.bin Once you have the nine files , use imx-mkimage tool. 5.2.1 Download source : $ git clone https://github.com/nxp-imx/imx-mkimage.git -b lf-6.12.20-2.0.0 5.2.2 Copy and rename mkimage from u-boot/tools/mkimage to imx-mkimage/iMX8M/mkimage_uboot. $ cp uboot-imx/tools/mkimage imx-mkimage/iMX8M/mkimage_uboot 5.2.3 Copy u-boot-spl.bin from u-boot/spl/u-boot-spl.bin to imx-mkimage/iMX8M/ $ cp uboot-imx/spl/u-boot-spl.bin imx-mkimage/iMX8M/ 5.2.4 Copy u-boot-nodtb.bin from u-boot/u-boot-nodtb.bin to imx-mkimage/iMX8M/ $ cp uboot-imx/u-boot-nodtb.bin imx-mkimage/iMX8M/ 5.2.5 Copy imx8mp-evk.dtb from u-boot/arch/arm/dts/ to imx-mkimage/iMX8M/. $cp uboot-imx/u-boot.dtb imx-mkimage/iMX8M/imx8mp-evk.dtb 5.2.6 Copy bl31.bin from Arm Trusted Firmware (imx-atf) to imx-mkimage/iMX8M/ $ cp imx-atf/build/imx8mp/release/bl31.bin imx-mkimage/iMX8M/ 5.2.7 Copy the LPDDR4 Training Firmware Download LPDDR Training Firmware cd ~/work wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.16.bin chmod +x firmware-imx-8.16.bin ./firmware-imx-8.16.bin copy below files from firmware/ddr/synopsys of the firmware-imx package to imx-mkimage/iMX8M/ lpddr4_pmu_train_1d_dmem_202006.bin lpddr4_pmu_train_1d_imem_202006.bin lpddr4_pmu_train_2d_dmem_202006.bin lpddr4_pmu_train_2d_imem_202006.bin $ cp firmware-imx-8.16/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin imx-mkimage/iMX8M/ $ cp firmware-imx-8.16/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin imx-mkimage/iMX8M/ $ cp firmware-imx-8.16/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin imx-mkimage/iMX8M/ $ cp firmware-imx-8.16/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin imx-mkimage/iMX8M/ 5.2.8 Copy firmware/hdmi/cadence/signed_hdmi_imx8m.bin from the firmware-imx package to imx-mkimage/iMX8M/. $ cp firmware-imx-8.16/firmware/hdmi/cadence/signed_hdmi_imx8m.bin imx-mkimage/iMX8M/ The folder structure after copying all the necessary files 5.2.9 Build the bootable image run make SOC=iMX8MP flash_evk to generate imx-bootimage. $ cd imx-mkimage $ make SOC=iMX8MP flash_evk The compiled file is flash.bin and its location iMX8M/flash.bin 5.3 flash imx-boot image into i.MX 8MP EVK board In order to flash the imx-boot image, please follow the following steps -copy uuu.exe and flash.bin in a folder -change the board's SW4 (boot mode) to 0001 to enter serial download mode uuu.exe -b emmc flash.bin uuu.exe -b emmc flash.bin -power off the board, change SW4 to switch the board back to 0010 (eMMC boot mode). 6 Running and Debugging Download the application (iuart_sdma_transfer.bin and iuart_sdma_transfer_cm7.elf) to /run/media/boot-mmcblk1p1 6.1 Debugging Cortex-M while Cortex-A is in U-BOOT $ fatload mmc 2:1 0x48000000 iuart_sdma_transfer.bin $ cp.b 0x48000000 0x7e0000 30000; $ bootaux 0x7e0000 $ fatload mmc 2:1 0x48000000 iuart_sdma_transfer2.bin $ cp.b 0x48000000 0x7e0000 30000; $ bootaux 0x7e0000 From M7 console, we can see the output 6.2 Debugging Cortex-M while Cortex-A is in Linux u-boot=> setenv fdtfile 'imx8mp-evk-rpmsg.dtb' u-boot=>run prepare_mcore u-boot=>boot u-boot=> setenv fdtfile 'imx8mp-evk-rpmsg.dtb' u-boot=>run prepare_mcore u-boot=>boot Linux system boot up: echo /run/media/boot-mmcblk2p1/iuart_sdma_transfer_cm7.elf > /sys/class/remoteproc/remoteproc0/firmware echo start > /sys/class/remoteproc/remoteproc0/state Then we can see the output from M7 console. 7 Summary This is a workaround to run UART with SDMA1 enabled on Cortex-M7, and Linux running on Cortex-A53 in parallel. In order to do that, we need to modify the ATF, and U-BOOT, and application. With the above modifications, I can get the expected results. References: 1. UG10163: i.MX Linux User's Guide Rev LF6.12.20_2.0.0--26 June 2025

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

System Controller Firmware 101 - Getting started

Getting Started with RTSP and AP1302 using GStreamer

i.mx8ulp gpio hog usage

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

[8MP]Workaround for running UART with SDMA enabled on Cortex M7 in parallel of Linux on A53

SCALABLE EDGE COMPUTING FOR IOT: DEVICE MANAGEMENT & REAL-TIME TELEMETRY