For more information about the i.MX 8QM/QP revision, please see the attached PDF slide deck at the bottom of this page. It includes frequently asked questions and is the official source of information regarding this revision. ------------------------------------------------------------------------------------------------------------------------------------- The i.MX 8QM and i.MX 8QP has been revised with lower clock speeds and higher core voltages to help improve instability issues found with the part. Old parts that have not been derated have an "FF" moniker in the part number, whereas new parts, releasing in June 2024, have an "FE" moniker. An example can be found below. SCFW (System Controller Firmware) 1.16.0, which will be released with the Q2 Linux Factory BSP (LF6.6.y_2.0.0), will make the necessary changes to increase core voltage for CPU and GPU cores in the 8QM/8QP, as well as reduce clock speeds. It may not be immediately apparent what changes must be made to derate these processors before the new parts and new SCFW version is released. To assist with these issues, we are providing the changes below as a workaround until SCFW 1.16.0 is released.     Recommended Changes until SCFW 1.16.0 is released 1. Increase voltages in pmic_init(). This function is found inside the respective board.c file within the SCFW porting kit. This is assuming that the customer has routed their VDD_A72 to PMIC_0 on SW3 and SW4, and routed their VDD_GPU0 and VDD_GPU1 to PMIC_1 on SW1 through SW4. +/* Set VDD_A72 to 1.1375V (1138mV) */ +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_0_ADDR, PF8100_SW3, 1138, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_0_ADDR, PF8100_SW4, 1138, REG_RUN_MODE)) +/* Set VDD_GPU0 and VDD_GPU1 to 1.03125V (1032mV) */ +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW1, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW2, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW3, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW4, 1032, REG_RUN_MODE))   2. Add +37.5mV offset for VDD_A72, +31.25mV offset for VDD_GPU0/VDD_GPU1. This is done in the function board_set_voltage, found in board.c of the respective processor in the SCFW porting kit. This ensures that voltages are set correctly if a frequency change occurs (like going from overdrive to nominal mode on GPU). /*--------------------------------------------------------------------------*/ /* Set the voltage for the given SS. */ /*--------------------------------------------------------------------------*/ sc_err_t board_set_voltage(sc_sub_t ss, uint32_t new_volt, uint32_t old_volt) { sc_err_t err = SC_ERR_NONE; pmic_id_t pmic_id[2] = {0U, 0U}; uint32_t pmic_reg[2] = {0U, 0U}; uint8_t num_regs = 0U; +// A72 cores are running on 1.1375V instead of 1.10V +if ((ss == SC_SUBSYS_A72) && (new_volt == 1100)) { +board_print(3, "Changing voltage from 1100 to 1138"); +new_volt = 1138; +} +// GPU is running on 1.03125V instead of 1.00V +if ((ss == SC_SUBSYS_GPU_0 || SC_SUBSYS_GPU_1) && (new_volt == 1000)) { +board_print(3, "Changing voltage from 1000 to 1032"); +new_volt = 1032; +} board_print(3, "board_set_voltage(%s, %u, %u)\n", snames[ss], new_volt, old_volt); board_get_pmic_info(ss, pmic_id, pmic_reg, &num_regs);   3. Remove 1.6GHz from Linux DTS OPP Table for A72 core. This is found in the device tree of the board. These are typically found in /arch/arm64/boot/dts/freescale/. /* opp-1596000000 { opp-hz = /bits/ 64 <1596000000>; opp-microvolt = <1100000>; clock-latency-ns = <150000>; opp-suspend; }; */ 4. Disable GPU overdrive mode - set to nominal mode using sysfs in Linux userland echo "nominal" > /sys/bus/platform/drivers/galcore/gpu_govern

  For some applications, we need to reduce the CPU Frequency, but if you are not familiar with our BSP or our devices probably you need some help to do some configurations.   In this post, I will share the configuration to set up lower frequencies (100MHz, 200MHz, 400Mhz, 600MHz, 800MHz, and 1000MHz) on iMX8MP, iMX8MN, and iMX8MM.   Note: Works on Kernel 6.1.xx (not tested on oldest BSP)   1- We have to modify the PLL driver to set the proper parameters to lower frequencies. The file to modify is "clk-pll14xx.c" adding the following lines:   https://github.com/nxp-imx/linux-imx/blob/770c5fe2c1d1529fae21b7043911cd50c6cf087e/drivers/clk/imx/clk-pll14xx.c#L57   static const struct imx_pll14xx_rate_table imx_pll1416x_tbl[] = { PLL_1416X_RATE(1800000000U, 225, 3, 0), PLL_1416X_RATE(1600000000U, 200, 3, 0), PLL_1416X_RATE(1500000000U, 375, 3, 1), PLL_1416X_RATE(1400000000U, 350, 3, 1), PLL_1416X_RATE(1200000000U, 300, 3, 1), PLL_1416X_RATE(1000000000U, 250, 3, 1), PLL_1416X_RATE(800000000U, 200, 3, 1), PLL_1416X_RATE(750000000U, 250, 2, 2), PLL_1416X_RATE(700000000U, 350, 3, 2), PLL_1416X_RATE(600000000U, 300, 3, 2), + PLL_1416X_RATE(400000000U, 200, 3, 2), + PLL_1416X_RATE(200000000U, 200, 3, 3), + PLL_1416X_RATE(100000000U, 200, 3, 4), };   2- Once the pll driver has been modified, only we have to add the values on the opp-table according to the device that you will use.   2.1- For iMX 8MP:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mp.dtsi         a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.2 For iMX8MM:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mm.dtsi     a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.3- For iMX8MN:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mn.dtsi   compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1200000000 { opp-hz = /bits/ 64 <1200000000>; opp-microvolt = <850000>;   After that, you should note the changes under Linux.   These commands return information about the system and the current settings.   • The kernel is pre-configured to support only certain frequencies. The list of frequencies currently supported can be obtained from: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies   • To get the available scaling governors: cat /sys/devices/system/cpu/*/cpufreq/scaling_available_governors   • To check the current CPU frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_cur_freq   The frequency is displayed depending on the governor set.   • To check the maximum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_max_freq   • To check the minimum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_min_freq   These commands set a constant CPU frequency:   • Use the maximum frequency: echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • Use the current frequency to be the constant frequency: echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • The following two commands set the scaling governor to a specified frequency, if that frequency is supported.   If the frequency is not supported, the closest supported frequency is used:   echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo <frequency> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed    

this is tested with MX93(A1) EVK running 6.1.55_2.2.0 pre-build image.   USB can output test patterns with either one of the setup below: 1. through device node: root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# cat role gadget root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo host > role [ 2672.864083] ci_hdrc ci_hdrc.0: EHCI Host Controller [ 2672.868996] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 [ 2672.893320] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 [ 2672.899314] hub 1-0:1.0: USB hub found [ 2672.909235] hub 1-0:1.0: 1 port detected root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# cat role host root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 4 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 3 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 2 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 1 > port_test   2. use memtool to program registers for i in $(find /sys -name control | grep usb);do echo on > $i;echo "echo on > $i";done; echo host > /sys/kernel/debug/usb/ci_hdrc.0/role #Offset:184h USB_OTG1 base address: 4C10_0000h base address USB_OTG2 base address: 4C20_0000h Register address Register address：base address+offset $ /unit_tests/memtool 0x4c100184 1 # Force to output Test Packet for Eye Diagram Test $ /unit_tests/memtool 0x4c100184=0x18041215 #Force to output J_STATE $ /unit_tests/memtool 0x4c100184=0x18011215 #Force to output K_STATE $ /unit_tests/memtool 0x4c100184=0x18021215 #Force to output SE0 (host) / NAK (device) $ /unit_tests/memtool 0x4c100184=0x18031215

Hello there. Here is a good way to use U-boot in an efficient way with custom scripts. The bootscript is an script that is automatically executed when the boot loader starts, and before the OS auto boot process. The bootscript allows the user to execute a set of predefined U-Boot commands automatically before proceeding with normal OS boot. This is especially useful for production environments and targets which don’t have an available serial port for showing the U-Boot monitor. This information can be find in U-Boot Reference Manual.   I will take the example load a binary file in CORTEX M4 of IMX8MM-EVK. In my case, I have the binary file in MMC 2:1 called gpio.bin and I will skip those steps because that is not the goal.   First, you need the u-boot-tools installed in your Linux machine: sudo apt install u-boot-tools   That package provide to us the tool mkimage to convert a text file (.src, .txt) file to a bootscript file for U-Boot.   Now, create your custom script, in this case a simple script for load binary file in Cortex M4: nano mycustomscript.scr  and write your U-Boot commands: fatload mmc 2:1 0x80000000 gpio.bin cp.b 0x80000000 0x7e0000 0x10000 bootaux 0x7e0000   Now we can convert the text file to bootscript with mkimage. Syntax: mkimage -T script -n "Bootscript" -C none -d <input_file> <output_file> mkimage -T script -n "Bootscript" -C none -d mycustomscript.scr LCM4-bootscript   This will create a file called LCM4-bootscript (Or as your called it).   A way to load this bootscript file to U-Boot is using the UUU tool, in U-Boot set the device in fastboot with command: u-boot=> fastboot 0 Then in linux with the board connected through USB to PC run the command: sudo uuu -b fat_write LCM4-bootscript mmc 2:1 LCM4-bootscript   Now we have our bootscript in U-Boot in MMC 2:1.   Finally, we can run the bootscript in U-Boot: u-boot=> load mmc 2:1 ${loadaddr} LCM4-bootscript 158 bytes read in 2 ms (77.1 KiB/s) u-boot=> source ${loadaddr} ## Executing script at 40400000 6656 bytes read in 5 ms (1.3 MiB/s) ## No elf image at address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD...   And the Cortex M4 booted successfully:    I hope this can helps to you.   Best regards.   Salas.  

Symptoms   Trying to initialize a repo, for example:  $repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml we have the below log: File "/home/username/bin/repo", line 51 def print(self, *args, **kwargs): ^ SyntaxError: invalid syntax   Workaround (1)   The first workaround consist in change the python alternatives (caused when you have installed two or more python versions). NOTE: in my case, the python version that i want to change as first priority is python3.8 $sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.8 1   Then we run: $sudo update-alternatives --config python    To verify if your python priority was changed successfully try: $python --version   You should see the version configured as priority number 1.     Workaround (2)   The workaround is very simple, only we need modify the repo file $ nano ~/bin/repo   and we will change the python interpreter in the first line (from python to python3): ORIGINAL FILE   EDITED FILE   After to do this change, repo will works fine again.     I hope this can helps to you!   Best regards.

  Platform & BSP :i.MX8MPlus, L6.1.36   The attachments enable the i.MX8MPlus pci function in uboot. lspci in Linux root@imx8mpevk:~# lspci -nn 00:00.0 PCI bridge [0604]: Synopsys, Inc. DWC_usb3 / PCIe bridge [16c3:abcd] (rev 01) 01:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. Device [1b4b:2b42] (rev 11) pci test results in uboot:  u-boot=> pci BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x16c3 0xabcd Bridge device 0x04 u-boot=> pci bar 00.00.00 ID Base Size Width Type ---------------------------------------------------------- 0 0x0000000018000000 0x0000000000100000 32 MEM u-boot=> pci regions 00 Buses 00-01 # Bus start Phys start Size Flags 0 0x0000000000000000 0x000000001ff80000 0x0000000000010000 io 1 0x0000000018000000 0x0000000018000000 0x0000000007f00000 mem 2 0x0000000040000000 0x0000000040000000 0x0000000016000000 mem sysmem 3 0x0000000058000000 0x0000000058000000 0x00000000a8000000 mem sysmem 4 0x0000000100000000 0x0000000100000000 0x00000000c0000000 mem sysmem u-boot=> pci header 00.00.00 vendor ID = 0x16c3 device ID = 0xabcd command register ID = 0x0007 status register = 0x0010 revision ID = 0x01 class code = 0x06 (Bridge device) sub class code = 0x04 programming interface = 0x00 cache line = 0x08 latency time = 0x00 header type = 0x01 BIST = 0x00 base address 0 = 0x18000000 base address 1 = 0x00000000 primary bus number = 0x00 secondary bus number = 0x01 subordinate bus number = 0x01 secondary latency timer = 0x00 IO base = 0x10 IO limit = 0x00 secondary status = 0x0000 memory base = 0x1820 memory limit = 0x1810 prefetch memory base = 0xfff0 prefetch memory limit = 0x0000 prefetch memory base upper = 0x00000000 prefetch memory limit upper = 0x00000000 IO base upper 16 bits = 0x0000 IO limit upper 16 bits = 0x0000 expansion ROM base address = 0x18100000 interrupt line = 0xff interrupt pin = 0x01 bridge control = 0x0000

Note: This guide is specifically for use with VS Code. For standalone with Segger software please refer to this guide. (How to Use Segger J-Link Plus with i.MX 8M Process... - NXP Community) In this guide we will describe the process to start using VS Code to debug an SDK application. The board used for this guide specifically is the i.MX 8M Nano EVK, but it also applies to all processors of the i.MX 8M Family. This guide covers the following topics: Hardware requirements Software requirements How to find, build, and download the i.MX SDK Debug Probe and i.MX 8M Nano EVK connection Create an SDK Application with MCUXpresso for VS Code Run and debug your SDK Application with MCUXpresso for VS Code Hardware requirements Evaluation Kit for the i.MX8M Nano Applications Processor (i.MX 8M Nano Evaluation Kit | NXP Semiconductors) Quick Start Guide for i.MX8M Nano (I.MX 8M Nano EVK Quick Start Guide (nxp.com)) J-Link Plus JTAG/SWD debug probe with USB interface (SEGGER J-Link PLUS) Features Download speed up to 1MB/s Unlimited breakpoints in flash memory Supports direct download into RAM and flash memory Supported NXP Devices Supported Devices - Search results "nxp" (segger.com) 9 Pin Cortex-M Adapter (9-Pin Cortex-M Adapter (segger.com)) Description Adapts from the 20-pin 0.1'' JTAG connector to a 9-pin 0.05'' Samtec FTSH connector as defined by Arm. Software requirements Windows 10 OS (host) J-Link Software and Documentation Pack for Windows (https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/) i.MX 8M Nano SDK (Welcome | MCUXpresso SDK Builder (nxp.com)) VS Code for Windows (Installation Guide: Running Visual Studio Code on Windows) MCUXpresso Extension for VS Code (Installation Guide: Training: Walkthrough of MCUXpresso for VS Code - NXP Community)   How to find, build, and download the i.MX 8M Nano SDK Enter Welcome | MCUXpresso SDK Builder (nxp.com) Click on "Select Development Board"  Select EVK-MIMX8MN (MIMX8MN6xxxJZ) from Boards -> i.MX -> EVK-MIMX8MN Click on the Build MCUXpresso SDK button Click on Download SDK, you'll be redirected to the MCUXpresso SDK Dashboard Look for the i.MX 8M Nano SDK and click on Download SDK Click on Download SDK archive and documentation, accept the Software Terms and Conditions and the .zip file for the SDK will be downloaded. Debug Probe and i.MX 8M Nano EVK connection Connect the debug cable (USB-UART) to the board and the other end to your PC. Connect the power cable to the second USB-C port and to a wall socket. Don't turn on the board yet. Connect the JLink Plus to your PC with the USB cable. Connect the JLink Plus to the JTAG of the i.MX 8M Nano EVK board In this part we will need to identify pin number 1 from the 9 Pin Cortex-M adapter and from the i.MX 8M Nano EVK board. For the first one identifies pin 7 identifiable by a "non-connect pin". For the i.MX 8M Nano, you can identify easily with a number 1 in one corner of the connectors.    The whole setup should look similar to this: Create an SDK Application with MCUXpresso for VS Code Before delving into the details of creating an SDK Application it is important to recognize the sections of VS Code User Interface. This will help us to describe accurately the buttons' position. Click on MCUXpresso for VS Code extension icon from the Activity Bar.  In the section “Quickstart Panel” located in the Side Bar click on “Import Repository.” On this window, go to “Local” and select your previously downloaded SDK folder location. Then, click on “Import.” Expand the section “Installed Repositories” from Side Bar and verify your selected SDK. Expand the section “Projects” from Side Bar and click on “Import Example from Repository” and complete the options: Choose a toolchain Choose a board Choose a template Name Location Finally, click on the "Create" button. Click on the gear icon located in the project folder to build the code. In “Projects” expand the “Settings” options and select “mcuxpresso-tools.json.” Here you will find a JSON file with different parameters. Defines the device that will be used to connect with the J-Link Plus. Code: “segger”: { “device”: “MIMX8MN6_M7” } Expand the section “Debug Probes” and verify that your J-Link Plus debug probe appears. Start SEGGER J-Link GDB Server. On section “Target Device” select MIMX8MN6_M7 and click “OK”. You will see the following window. Run and debug your SDK Application with MCUXpresso for VS Code Click on “Debug” located in the project folder, to start with the debugging session. In the Panel click on “Serial Monitor,” set it to the serial debug port with the lowest numbered port with the following settings: Baud rate: 115200 Line ending: None Click on "Start Monitoring" Use the debug controls to run the code. Verify your code output in the “Serial Monitor.”

Dynamic debug is designed to allow you to dynamically at runtime  enable/disable  kernel code to obtain additional kernel information. Currently, if ``CONFIG_DYNAMIC_DEBUG`` is set, then all ``pr_debug()``/``dev_dbg()`` and ``print_hex_dump_debug()``/``print_hex_dump_bytes()`` calls can be dynamically enabled per-callsite.    

Note: This guide is specifically for use with Segger software. For steps to use with the MCUXpresso extension for VSCode please refer to How to Use Segger J-Link Plus with i.MX 8M Process... - NXP Community This guide aims to be a technical reference to start using the SEGGER J-Link Plus debug probe on the i.MX 8M Family processors. The board used for this guide specifically is the i.MX 8M Nano EVK, but it also applies to all processors of the i.MX 8M Family. Here we will describe the process using the following structure: Hardware requirements Software requirements How to find, build, and download the i.MX SDK Host setup Build an example application Target setup Run an example application Hardware requirements Evaluation Kit for the i.MX8M Nano Applications Processor (i.MX 8M Nano Evaluation Kit | NXP Semiconductors) Quick Start Guide for i.MX8M Nano (I.MX 8M Nano EVK Quick Start Guide (nxp.com)) J-Link Plus JTAG/SWD debug probe with USB interface (SEGGER J-Link PLUS) Features Download speed up to 1MB/s Unlimited breakpoints in flash memory Supports direct download into RAM and flash memory Supported NXP Devices Supported Devices - Search results "nxp" (segger.com) 9 Pin Cortex-M Adapter (9-Pin Cortex-M Adapter (segger.com)) Description Adapts from the 20-pin 0.1'' JTAG connector to a 9-pin 0.05'' Samtec FTSH connector as defined by Arm. Software requirements Windows 10 OS (host) J-Link Software and Documentation Pack for Windows (https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/) i.MX 8M Nano SDK (Welcome | MCUXpresso SDK Builder (nxp.com)) MinGW CMake GNU ARM Embedded Toolchain Terminal Emulator for serial port connection (Tera Term, PuTTY, etc.)   How to find, build, and download the i.MX 8M Nano SDK Enter Welcome | MCUXpresso SDK Builder (nxp.com) Click on "Select Development Board"  Select EVK-MIMX8MN (MIMX8MN6xxxJZ) from Boards -> i.MX -> EVK-MIMX8MN Click on the Build MCUXpresso SDK button Click on Download SDK, you'll be redirected to the MCUXpresso SDK Dashboard Look for the i.MX 8M Nano SDK and click on Download SDK Click on Download SDK archive and documentation, accept the Software Terms and Conditions and the .zip file for the SDK will be downloaded.   Host Setup J-Link Software and Documentation Pack for Windows Download J-Link Software and Documentation Pack for Windows (https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/) Execute .exe file downloaded and then click on "Next" Follow the installation wizard with default parameters and click on "Finish".   MinGW Download the MinGW installer from MinGW - Minimalist GNU for Windows - Browse /Installer at SourceForge.net. Follow the installer instructions leaving all options in their default values. Click on Continue when the installer finishes. A MinGW Installation Manager window will pop up, select mingw32-base and msys-base from basic setup. Click on the Installation menu and select Apply Changes. On the next window, click on Apply and wait for the package to finish downloading. Add the appropriate item to the Windows operating system path environment variable. It can be found under Control Panel->System and Security->System->Advanced System Settings in the Environment Variables... section. The path is: \bin. Assuming the default installation path, "C:\MinGW". If the path is not set correctly, the toolchain does not work. Note: If you have C:\MinGW\msys\x.x\bin in your PATH variable (as required by KSDK 1.0.0), remove it to ensure that the new GCC build system works correctly.   CMake Download CMake Windows x64 Installer from  Download CMake. Scroll down to find the latest release for the installer: Run the installer and follow the instructions. Make sure to check the Add CMake to system PATH for all users option during the installation process. Restart your PC to apply changes. GNU ARM Embedded Toolchain Download the GNU ARM Embedded Toolchain installer from Downloads | GNU Arm Embedded Toolchain Downloads – Arm Developer, scroll down to find the latest release for the installer: Follow the installer instructions and check the Add to PATH option at the end of the process. Add a new system environment variable named ARMGCC_DIR with the GNU ARM embedded Toolchain installation path as its value ARMGCC_DIR=ARMGCC_DIR=C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10​   Build and example application Press the Windows Key and search for GCC Command Prompt and run it. Change the directory to the example application project directory (inside the armgcc folder), for example: C:\Users/<user>\Documents\8MNANO\boards\evkmimx8mn\demo_apps\hello_world\armgcc Type build_debug.bat on the command line or double click the build_debug.bat file (inside the armgcc folder of the application project) through Windows Explorer Wait for the building process to end and make sure no error messages are shown. Target Setup Connect the debug cable (USB-UART) to the board and the other end to your PC. Connect the power cable to the second USB-C port and to a wall socket. Don't turn on the board yet. Connect the JLink Plus to your PC with the USB cable. Connect the JLink Plus to the JTAG of the i.MX 8M Nano EVK board In this part we will need to identify pin number 1 from the 9 Pin Cortex-M adapter and from the i.MX 8M Nano EVK board. For the first one identify pin 7 identifiable by a "Non-connect pin". For the i.MX 8M Nano, you can identify easily with a number 1 in one corner of the connectors.    The whole setup should look similar to this: Run an example application Open a terminal application (TeraTerm, PuTTY, etc.) on your host PC and set it to the serial debug port with the lowest numbered port with the following settings: Speed: 115200 Data: 8-bit Parity: none Stop bits: 1 bit Flow Control: none Start SEGGER J-Link GDB Server. On section “Target Device” select MIMX8MN6_M7 and click “OK”. You will see the following window. Open a new instance of GCC Command Prompt. Change to the directory with the example previously compiled. Here is the path to folder that contains the files: <install_dir>/boards/<boad_name>/<example_type>/<application_name>/armgcc/debug​ Run the command: arm-none-eabi-gdb.exe <application_name>.elf.​ Example: At this point you are in the GDB Command Prompt, run the following commands: target remote localhost:2331 monitor reset monitor halt load monitor go The application will be now running and you can see the “hello world” on your terminal (PuTTY,Tera Term, etc.).  

Device: i.MX93 A1. ELE FW version: 0.0.10 Some new test scripts are added to secure enclave library, please refer to attached files. Please note: the scripts attached are for internal test/debug purpose only. The summary is from our test results and understanding, it's preliminary and may have changes later.    1. All current and all GA Sentinel FWs do not use lifecycle for key derivation of HSM keystore. Keystore created in OEM_OPEN lifecycle can be directly used in OEM_CLOSED lifecycle.  A-> Different from previous SECO devices 2. Key has lifecycle attribute. This attribute defines in which device lifecycle the key is usable. This attribute is set at key creation operation (generate key, import key, key exchange …). Before executing a key depending cryptographic or data storage (export option) operation the key lifecycle is compared with the current device lifecycle. Operation is executed only if the key lifecycle includes the current device lifecycle. When mentioned in the API command message description, the key lifecycle could be set to the current device lifecycle if the value is set to 0x0. Lifecycle values are encoded as bitfield. Multiple values could be set. The key could be used in several lifecycles.   Tested cases:   The key lifecycle attribute is verified during the key usage, not when the key is created. If the key operation doesn’t match device lifecycle, it will report 0xe29 - The key is not usable in the current lifecycle.  Please see attached hsm_generate_key.c / hsm_generate_key_signature.c  for reference.   3. SYNC operation and MC increase are separate flag. The previous STRICT operation is used to store persistent key, during which the monotonic counter will increase if the device is closed. For ELE device, two flags are used: SYNC flag and MC flag. The ELE SYNC pushes persistent key(s) in the NVM. Without executing this operation, even if the key attribute is set as persistent at the key creation the key will not be stored in the NVM. This operation is set through a flag in key management operations arguments. SYNC is applicable only for persistent key/permanent key. MC flag is new on ELE device. When used in conjunction with SYNC, the request is completed only when the monotonic counter has been updated. MC flag can be used both in OPEN and CLOSED lifecycle and increase the monotonic counter value. -> different from previous SECO device. Note: MC flag is not defined in 0.0.10 secure enclave library, but user can test it by directly setting the corresponding bit of the flag.   4. If the generated key store is deleted accidently and the monotonic counter is not 0, reprovisioning function is needed.  This is applied to both OPEN and CLOSED device. We cannot directly create a keystore again. Reprovisioning method is not supported yet.   5. One keystore can store 100 key groups at most. 100 groups are available per key store. It must be a value in the range [0; 99]. The key group ID should be 0~99, or it will report 0x429- MU sanity check failed / Invalid parameters. To push persistent keys in the NVM, a flag (SYNC) needs to be set during key management operations (generate, import, manage, …). Pushing a key to the NVM will also push all the key group data. When in use, a key group is loaded from the NVM to the internal secure RAM. The number of key group present is limited (depends on the device). A key group present in internal memory and not used, can be swapped out and replaced by a new key group containing the key to be used when there is no more free space. Note that only key 2 groups per key store can be stored in the internal secure RAM. Note that volatile keys cannot be in the same key group than persistent keys.   One assumption based on tests: It looks that each key group has its own SW counter, which may record update time of this key group. This is the test on i.MX93: If we delete the key group #2 file 0000abcd00020004 only from NVM manually, then we cannot create key of group #2 again, but we can create key of group #1. The process might be: Try to create key in group #2 -> checked the counter value is not 0 -> try to import the chunk from NVM -> fail because the chunk is deleted. Each key group has its own counter, so key group #1 is not affected.   6. Key size in one keystore One key group can store 16 ECC(p256) keys, or 1 RSA 2k key, or 1 RSA 4k key. Size of key group on i.MX93 = 8448 bits (size defined to allow 4k modulus+ 4k private exponent + header). Storage file in NVM will have additional overhead, the 8448 size is purely related to key data storage. For ECC keys, only private keys are stored (public key can be derived from private key), so P256 key only needs 256 bits of key storage + 256 bits header = 512 bits. 16 * 512 = 8192 => fits within 8448.    7. Delete key To delete the key from the NVM, an SYNC operation (in “Flags” field) must be done. To delete a key, user need to provide the key identifier which is generated when creating this key. There is also “MC” flag which should can be used for anti-rollback protection. Deleting key will not decrease the size of key group file directly, but the space in the key group will be covered by new key generated later.  Please see attached hsm_delete_key.c for reference.   8. Generic API Generic API is not supported on i.MX93 A0 due to a lack of RAM, it is supported on i.MX93 A1. In lf-6.1.22_2.0.0 ELE library, the generic feature is set as none supported, need to change the src/plat/ele/sab_msg.def file as below to test it on i.MX93 A1 chip. -MT_SAB_GC_AKEY_GEN := ${NOT_SUPPORTED} -MT_SAB_GC_ACRYPTO := ${NOT_SUPPORTED} +MT_SAB_GC_AKEY_GEN := ${FMW} +MT_SAB_GC_ACRYPTO := ${FMW} Generic cryptographic APIs can be used to perform cryptographic operation without using the FW key store. The key buffer, in plaintext, is an input parameter of the API. No need to open hsm keystore before using generic APIs. Because it will not save the key to key store, so NVM thread is also not necessary. Please see attached hsm_generic_api.c for reference. Asymmetric key generate: Only RSA is supported on S401 for now. It will return the address of output RSA key modulus /output RSA private exponent /input RSA public exponent Asymmetric crypto User can choose different operation mode for Encryption / Decryption / Signature generation / Signature verification.    9. How to get chip MC value? Command “Get device information” can be used to get generic information regarding the user, the chip and the EdgeLock Enclave FW. It can return Chip UUID/lifecycle/monotonic counter etc. User can run this API before and after some MC operation to check if the counter value is increased. Please see the attached hsm_get_info.c for reference.   Best Regards, Tia

What is a device tree? The device tree is a data structure that is passed to the Linux kernel to describe the physical devices in a system. Before device trees came into use, the bootloader (for example, U-Boot) had to tell the kernel what machine type it was booting. Moreover, it had to pass other information such as memory size and location, kernel command line, etc. Sometimes, the device tree is confused with the Linux Kernel configuration, but the device tree specifies what devices are available and how they are accessed, not whether the hardware is used. The device tree is a structure composed of nodes and properties: Nodes: The node name is a label used to identify the node. Properties: A node may contain multiple properties arranged with a name and a value. Phandle: Property in one node that contains a pointer to another node. Aliases: The aliases node is an index of other nodes. A device tree is defined in a human-readable device tree syntax text file such as .dts or .dtsi. The machine has one or several .dts files that correspond to different hardware configurations. With these .dts files we can compile them into a device tree binary (.dtb) blobs that can either be attached to the kernel binary (for legacy compatibility) or, as is more commonly done, passed to the kernel by a bootloader like U-Boot. What is Devshell? The Devshell is a terminal shell that runs in the same context as the BitBake task engine. It is possible to run Devshell directly or it may spawn automatically. The advantage of this tool is that is automatically included when you configure and build a platform project so, you can start using it by installing the packages and following the setup of i.MX Yocto Project User's Guide on section 3 “Host Setup”. Steps: Now, let’s see how to compile your device tree files of i.MX devices using Devshell. On host machine. Modify or make your device tree on the next path: - 64 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm64/boot/dts/freescale - 32 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm/boot/dts To compile, it is needed to prepare the environment as is mentioned on i.MX Yocto Project User's Guide on section 5.1 “Build Configurations”. $ cd ~/imx-yocto-bsp $ DISTRO=fsl-imx-xwayland MACHINE=<machine> source imx-setup-release.sh -b <build directory> $ bitbake -c devshell virtual/kernel (it will open a new window) On Devshell window. $ make dtbs (after finished, close the Devshell window) On host machine. $ bitbake -c compile -f virtual/kernel $ bitbake -c deploy -f virtual/kernel This process will compile all the device tree files linked to the machine declared on setup environment and your device tree files will be deployed on the next path: ~/imx-yocto-bsp/<build directory>/tmp/deploy/images/<machine> I hope this article will be helpful. Best regards. Jorge.

SoC: i.MX8MP LDP: Ubuntu22.04 and Ubuntu 20.04 Yocto: 6.1.22 mickledore   This doc includes two parts: 1)How to enable qt5 in LDP 2)How to enable qt5 in Yocto Linux 6.1.22     How to use qt5 in LDP(Linux Distribution Poc): The gcc and glibc is diffrent from Yocto Linux and Linux Distribution Poc. To cross compile the file between Linux and Ubuntu, we need to care about that.   To full enable the GPU usage of QT lib, please use "-gles" libs by apt-get command. Qt source code is not suggested, for it has not been tested. Building Qt5, for example: sudo apt-get update sudo apt-get -y install libqt5gui5-gles sudo apt-get -y install libqt5quick5-gles sudo apt-get -y install qtbase5-gles-dev   opengles test case glmark: sudo apt-get -y install glmark2-es2-wayland How to find the missing lib for apt-get: sudo apt-get install apt-file apt-file search xx   open wifi if needed NXP internal internet has limitation: sudo modprobe moal mod_para=nxp/wifi_mod_para.conf   and add "nameserver 8.8.8.8" in vi /etc/resolv.conf. You can also try:  echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf > /dev/null   some times system time is not automatically update, and that cause apt-get update fail User and choose manually configure it by: sudo date -s "2023-08-31 14:00:00"   For Chinese support for ubuntu, please use: sudo apt-get install ttf-wqy-microhei ttf-wqy-zenhei xfonts-wqy   possible env path you need to export: XDG_RUNTIME_DIR="/run/user/1000" export QT_QPA_PLATFORM=wayland   User can choose root login by command like: user@imx8mpevk:~$ sudo passwd New password: Retype new password:   please use qmake to build qt project: 1)qmake -o Makefile HelloWorld.pro 2)make   some other qt libs: sudo apt-get install -y qtwayland5 sudo apt-get install -y qml-module-qtquick-controls sudo apt-get install -y qml-module-qtquick-controls2 sudo apt-get install -y qml-module-qtcharts sudo apt-get install -y libqt5multimedia5 sudo apt-get install -y libqt5serialport5 sudo apt-get install -y libqt5script5 sudo apt-get install -y qml-module-qt-labs-settings sudo apt-get install -y qml-module-qt-labs-platform sudo apt-get install -y qml-module-qtmultimedia sudo apt-get install -y libqt5webengine5 sudo apt-get install -y qml-module-qtwebengine sudo apt-get install -y qml-module-qtquick-dialogs     How to enable qt5 in Yocto 6.1.22: 1.download meta-qt5 git clone https://github.com/meta-qt5/meta-qt5.git git checkout origin/mickledore   copy Yocto version 5.10.72_2.2.0 sources\meta-imx\meta-sdk\dynamic-layers\qt5-layer to the same path of Yocto 6.1.22   2.apply two patches qt5-1.patch: modify the path from qt6 to qt5 qt5-2.patch: modify the qt5 related in meta-imx, including: 1)Yocto grammer update，from "_" to ":";  2)NXP grammer，from mx8 to mx8-nxp-sdk;  3)remove gstreamer1.0-plugins-good-qt, for qt5 has been natively added into gst-plugin-good-1.22(which is not in 1.18)   3.after input command like "DISTRO=fsl-imx-xwayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b build-xwayland", comment the "meta-nxp-demo-experience"   # i.MX Yocto Project Release layers BBLAYERS += "${BSPDIR}/sources/meta-imx/meta-bsp" BBLAYERS += "${BSPDIR}/sources/meta-imx/meta-sdk" BBLAYERS += "${BSPDIR}/sources/meta-imx/meta-ml" BBLAYERS += "${BSPDIR}/sources/meta-imx/meta-v2x" #BBLAYERS += "${BSPDIR}/sources/meta-nxp-demo-experience"      

Platform i.MX8MPlus EVK, Android 13 Background Customer find we have enabled all configs about pstore and ramoops, but they can't get ramoops log in /sys/fs/pstore node on Android 13. Solution The default reboot will reset all hardware including the DDR control, so this will result in the loss of the log stored in RAM. We have include such codes in ATF, the default code will use imx_wdog_restart(true) to reset all hardware. void __dead2 imx_system_reset(void) { #ifdef IMX_WDOG_B_RESET imx_wdog_restart(true); #else imx_wdog_restart(false); #endif }   To avoid DDR reset, we should comment  IMX_WDOG_B_RESET in vendor/nxp-opensource/arm-trusted-firmware/plat/imx/imx8m/imx8mp/include/platform_def.h   Result evk_8mp:/sys/fs/pstore # ls console-ramoops-0 dmesg-ramoops-0 pmsg-ramoops-0  

  Introduction   Prior to 6.1.22_2.0.0 BSP release, Bluetooth interface are based on the tty line discipline framework, so we need to use hciattach tool to enable it in the user space. From 6.1.22_2.0.0 BSP, the nxp bluetooth driver no longer needs the help of the userspace hciattach tool, and the tty port bound by bluetooth also won't be exported to the user space, so you cannot find the corresponding tty device anymore. So, you won't see the (/dev/ttymxcX), for the Bluetooth interface. All jobs has been done in the new NXP Bluetooth driver. New Method   The new NXP Bluetooth UART Driver is based on a server driver for the NXP BT serial protocol, which can enable the built-in Bluetooth device inside an NXP BT chip. This driver has a Power Save feature that will put the chip into a sleep state whenever there is no activity for 2000ms and will be woken up when any activity is to be initiated over UART.  Device Tree support The new BT framework requires adding a "bluetooth" sub node with a device compatibility string to the attached UART node in the dts file &uart1 { bluetooth { compatibility = "nxp,88w8987-bt"; fw-init-baudrate = <3000000>; #Optional. Default is considered 115200 if this parameter not defined. }; };   Note: The parameter ‘compatibility = “nxp,88w8987-bt”’ will use for 88W8987, IW416, 88Q9098, IW612 chipsets and need to change for 88W8997 with parameter ‘compatibility = “nxp,88w8997-bt”’.   Note: ’fw-init-baudrate’ parameter depends on the module vendor. The Murata and Azuere wifi modules support in BSP release uses the default value -- 115200. We strongly recommend looking at the module vendor-specific baud rate parameter. Note: For the old 88Q9098 Murata 1XL module that uses the 3Mbps by default, please add the fw-init-baudrate = <3000000> property in dts files to make it work. Enable Guide   Use wifi interface to load combo (wifi & bt) firmware and enable BT Need to load wifi driver first, then load the BT driver, otherwise, BT driver suspend/resume test will fail. This is a HW limitation, since NXP wifi and BT module use the same power control pin(W_DISABLE1#), if we don't load the wifi driver, SDIO bus will power down the wifi chip during suspend resume, which may cause the BT chip also been powered down and cannot work after resume back. So we need to load the wifi driver to make sure SDIO bus won't power down the BT chip to make sure BT functions can work during suspend resume. modprobe moal mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart or insmod mlan.ko insmod moal.ko mod_para=nxp/wifi_mod_para.conf insmod btnxpuart   Unload UART Driver modprobe moal Make sure run hciconfig hci0 up or hciconfig hci0 reset or bluetootctl power on before unload btnxpuart driver. If we don't open hci0 interface, the driver cannot send change to 115200 baud rate command to BT chip, which causes the host and BT chip baud rate mismatch, the host still uses 115200bps talk to the BT chip which now use 3Mbps, it cannot work anymore. So we need to make sure open the hci0 interface before unload btnxpuart driver.   mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart sleep 3 hciconfig hci0 up #Note: Need to up hci interface before unload the BT module hcitool -i hci0 cmd 3F 23 02 00 00 modprobe -r btnxpuart modprobe -r moal sleep 3​ For better reference: Please find the I.MX 8MQ Linux getting started user guide, UM11483, Chapter "7.1 Bring-up using NXP Bluetooth UART driver"  Bluetooth Deep Sleep Feature App Note AN13920, Chapter 6 Load NXP UART driver module NOTE: Please do not run the power save feature for Murata IW612 2EL Module Regards, Mario

GUI Guider version: 1.6.0 LVGL version: v8.3.5 Host software requirements: Ubuntu 20.04, Ubuntu 22.04 or Debian 12 Hardware requirements: Evaluation Kit for the i.MX 93 Applications Processor. (i.MX 93 Evaluation Kit | NXP Semiconductors) On this guide we will use the IMX-MIPI-HDMI accessory board to connect the iMX93 with a HDMI Monitor. (IMX-MIPI-HDMI Product Information|NXP) This board is usually provided with the iMX8M Mini and the iMX8M Nano.  Steps: 1. Copy your project from the folder GUI-Guider-Projects to your Linux PC.  2. Build an image for iMX93 using The Yocto Project.    a. Based on iMX Yocto Porject Users Guide set directories and download the repo $ mkdir imx-bsp-6.1.1-1.0.0 $ cd imx-bsp-6.1.1-1.0.0 $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-langdale -m imx-6.1.1-1.0.0.xml $ repo sync Use distro fsl-imx-xwayland and select machine imx93evk and use this commnad with a build folder name: $ MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh - b bld-imx93evk b. Use bitbake command to start the build process. Also, add the -c populate_sdk to get the toolchain. $ bitbake imx-image-multimedia -c populate_sdk  c. Install the Yocto toolchain located on <build-folder>/tmp/deploy/sdk/.  $ sudo sh ./fsl-imx-xwayland-glibc-x86_64-imx-image-multimedia-armv8a-imx93evk-toolchain-6.1-langdale.sh d. Install ninja utility on the build host $ sudo apt install ninja-build e. For Ubuntu 20.04 and Ubuntu 22.04, copy the lv_conf.h file from lvgl-simulator to lvgl $ cp lvgl-simulator/lv_conf.h lvgl/ f. Change the interpreter on build.sh from #!/bin/sh to #!/bin/bash. This is an important step! g. Then, enter to linux folder and use the following commands to make build.sh executable $ dos2unix build.sh $ chmod +x build.sh h. Execute the build.sh $ ./build.sh i. Copy the binary to the iMX93 using a USB or SCP.  2. On the target iMX93 follow these steps. a. On Uboot, use fatls interface device:partition fatls mmc 0:1 (Device 0 : Partition 1) With this command, we will be able to list device tree files. => fatls mmc 0:1 b. Select imx93-11x11-evk-rm67199.dtb and use the command editenv fdtfile  => editenv fdtfile Output example edit: imx93-11x11-evk-rm67199.dtb c. In edit command line put the selected device tree .dtb d. Use saveenv command to save environment and continue with the boot process. e. Finally, run the GUI Application $ ./gui_guider&   I hope this article will be helpful. Best regards, Brian.

Introduction ARM SoC+FPGA/CPLD is widely used in some application like industry control and data acquisition system, there were many customers adopted i.MX6 EIM (a memory parallel interface) to access FPGA/CPLD, and archived good data throughput, but EIM is removed from i.MX8M and i.MX9, some customers is asking for such a compatible solution for i.MX8/8M and coming i.MX9 family.  FlexSPI is designed for connecting storage devices like NOR Flash, integrated in most of i.MXRT/i.MX8/LS products and provides flexible configuration for 4-wire/8wire working mode, this article provides a low-cost and efficiency demo to show how  to support CPLD/FPGA  via FlexSPI, as a replacement of EIM for EP i.MX8/9/LS products. key features Implement a  new kernel driver for FlexSPI to support read/write access to FPGA/CPLD. Support two type connections: Support 4-wire(QSPI) and 8-wire(HypeBUS, OctalSPI) Deliverables A new kernel driver for FlexSPI to support read/write access to FPGA/CPLD by AHB command A kernel patch to disable the QSPI Flash in kernel A test program shows how to do read/write performance test. Hardware Hardware Prepare: i.MX8MM-LPDDR4-EVK Lattice LFE5U EVK Figure1 4-wire SPI HW Block diagram Figure2 8-wire OctalSPI   Hardware Rework on i.MX8MM-EVK     1 Need to remove the SPI-Flash(U5, MT25QU256ABA) on the i.MX8MM-EVK board, and wire below signals: QSPI_DATA0 QSPI_DATA1 QSPI_DATA2 QSPI_DATA3 QSPI_SCLK QSPI_nSS0 VDD_1V8 GND Figure3 QPSI signals for FPGA/CPLD Figure4 Hardware rework on i.MX8MM-EVK board Note that, i.MX8MM-EVK QSPI power rails is 1.8v, so be careful that the FPGA/CPLD side IO should be 1.8V. Software BSP version 1 Linux BSP version: L5.10.52 Software Change  Apply 0001-FlexSPI-FPGA-need-to-disable-flexspi-for-fpga-usage.patch in Linux kernel and generate the new dtb extract the flexspi-fpga driver compile the flexspi-fpga driver with the kernel$ $make -C $(YOUR_KDIR) M=$(FlexSPI_FPGAW_DIVER_DIR) modules ARCH=arm64 CROSS_COMPILE=$(CROSS_COMPILE) Deployment  upload new generated i.mx8mm-evk.dtb to the target board(the 1st partition) upload the flex-spi driver and fpga/cpld test program to the target board   Test Test1: Set the flexspi working at 40Mhz   $insmod imx_flexspi_fpga.ko pre_div=2 post_div=5 Read/write FPGA/CPLD test .$/flexspi_fpga_test -p 0x08000000 -s 768 Test2: Set the FlexSPI working at 100MHz   $ insmod imx_flexspi_fpga.ko pre_div=1 post_div=4 Read/write FPGA/CPLD test $./flexspi_fpga_test -p 0x08000000 -s 768   Limitation FPGA and Flash devices can’t work at the same time due to just one FlexSPI controller. Due to the IO assignment conflict in i.MX8M EVK design, this demo just tested 4-wire（QSPI) mode at 50MHz and got data throughput as expected. Disclaimer: − “Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.”

Hello everyone, this document will share an step by step guide of the configuration needed in a Linux PC to compile the SDK examples we provide, as well as how to download them in an easy way. Requirements: I.MX 8M Mini EVK SDK package (for i.MX8MM) UUU tool First step would be to get the SDK package, this include documentation and code, which is available at the MCUXpresso builder webpage: https://mcuxpresso.nxp.com/en/welcome Click on the select a development board and select the package for your development kit or the i.MX MPU   This guide is focused on Linux build so will select GCC package and Linux host PC as the environment. Click on build and wait for the SDK package to be ready for download. Note1: Click on select all if the whole middleware package is desired Note2: it is possible to select each middleware that are desired. On new window select download SDK Select on new pop-up window download both SDK and documentation Read and accept EULA so the download start Decompress the package using the following command: $ tar -xvzf ~/SDK_2_13_0_EVK-MIMX8MM.tar.gz -C ~/SDK_2_13_0_EVK-MIMX8MM Next will be to download the GCC from the ARM webpage, gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 https://developer.arm.com/downloads/-/gnu-rm Note that the GCC version used is based on the minimum version required, since this was tested and supported, this could be found within the SDK documentation (~/SDK_2_13_0_EVK-MIMX8MM/docs/MCUXpresso SDK Release Notes for EVK-MIMX8MM) Once downloaded we can decompress and configure the environment: $ tar -xf gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 $ export ARMGCC_DIR=~/gcc-arm-none-eabi-10.3-2021.10 $ export PATH=$PATH:~/gcc-arm-none-eabi-10.3-2021.10 $ sudo apt-get install cmake  Check the version >= 3.0.x $ cmake --version Once this is done we enter the path of the example of our choice and compile using the script, as necessary using debug, release or all. $ cd ~/SDK_2_13_0_EVK-MIMX8MM/boards/evkmimx8mm/demo_apps/hello_world/armgcc $./build_release.sh The binary (elf and bin) will be found inside the folder according to whether we use debug or release script. For this example we used release script: $ cd release Once builded we can move/download the binaries from the Linux host PC to the board by using the UUU tool with the command fat_write #### we put the board in fastboot mode by entering the command in the uboot terminal fastboot 0 #### From the Linux terminal introduce the UUU command to  download to the FAT partition of the eMMC of the baord: ## For rproc it is needed the .elf binary ## $ uuu -v -b fat_write hello_world.elf mmc 0:1 hello_world.elf ## For bootaux it is needed the .bin binary ## $  uuu -v -b fat_write hello_world.bin mmc 0:1 hello_world.bin Once with the binaries in the FAT partition of the SD/eMMC of our board we can make the necessary modifications (device tree/bootargs) to test the Cortex-M examples. For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.

1.Compile full aosp or only kernel Build full aosp: source build/envsetup.sh lunch evk_8mm-userdebug ./imx-make.sh -j8  Only build kernel: ./imx-make.sh kernel -j8 2.Build GKI locally Download GKI outside of android_build. mkdir gki && cd gki (Make sure folder gki is not inside of ${MY_ANDROID}) repo init -u https://android.googlesource.com/kernel/manifest -b commonandroid13-5.15 repo sync Build GKI locally. BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh 3. Export symbols After building GKI locally, you can copy linux-imx from /vendor/nxp-opensource/kernel_imx into common. cd common rm -r ./* cp ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/* ./ ln -s ${MY_ANDROID}/vendor/nxp-opensource/verisilicon_sw_isp_vvcam verisilicon_sw_isp_vvcam ln -s ${MY_ANDROID}/vendor/nxp-opensource/nxp-mwifiex nxp-mwifiex  Build GKI about i.MX: BUILD_FOR_GKI=yes BUILD_CONFIG=common/build.config.imx EXT_MODULES_MAKEFILE="verisilicon_sw_isp_vvcam/vvcam/v4l2/Kbuild" EXT_MODULES="nxp-mwifiex/mxm_wifiex/wlan_src" build/build_abi.sh --update-symbol-list -j8 Then the  common/android/abi_gki_aarch64_imx will be generated. cd gki cp common/android/abi_gki_aarch64_imx /tmp/abi_gki_aarch64_imx   Update GKI kernel rm -r common/* # delete imx kernel repo sync # recover aosp kernel cp /tmp/abi_gki_aarch64_imx android/abi_gki_aarch64_imx cd .. BUILD_CONFIG=common/build.config.gki.aarch64 build/build_abi.sh LTO=thin --update -j8  Then, common/android/abi_gki_aarch64.xml is updated.  

  Introduction   Platform: i.MX93 EVK Uboot: origin/lf_v2022.04(lf-6.1.1-1.0.0) The LVDS design and media block control in i.MX93 is very similiar with i.MX8MPlus.This article implements the LVDS driver in uboot. You need apply 0001-Add-fake-adp5585-pwm-driver.patch which implements the adp5585 pwm driver in uboot. This is a fake pwm driver only implement the pwm driver framework. You can't use pwm value to adjust brightness for the moment, but this is enough to enable the backlight. Then please apply 0002-Add-imx93-lvds-and-panel-driver.patch, you will see nxp logo with this panel: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/dy1212w-4856:DY1212W-4856   Porting suggestions   1. Modify panel timing in drivers/video/simple_panel.c /* 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, }; 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; }   2.Modify VIDEO_PLL The VIDEO_PLL = pixel clock * 7. For default panel, the pixel clock is 71.143MHz and VIDEO_PLL  is 498MHz. static struct imx_fracpll_rate_table imx9_fracpll_tbl[] = { FRAC_PLL_RATE(1000000000U, 1, 166, 4, 2, 3), /* 1000Mhz */ FRAC_PLL_RATE(933000000U, 1, 155, 4, 1, 2), /* 933Mhz */ FRAC_PLL_RATE(700000000U, 1, 145, 5, 5, 6), /* 700Mhz */ FRAC_PLL_RATE(498000000U, 1, 166, 8, 0, 1),/* rate, rdiv, mfi, odiv, mfn, mfd */ FRAC_PLL_RATE(484000000U, 1, 121, 6, 0, 1), FRAC_PLL_RATE(445333333U, 1, 167, 9, 0, 1), FRAC_PLL_RATE(466000000U, 1, 155, 8, 1, 3), /* 466Mhz */ FRAC_PLL_RATE(400000000U, 1, 200, 12, 0, 1), /* 400Mhz */ FRAC_PLL_RATE(300000000U, 1, 150, 12, 0, 1), }; 3. Modify lcdif node in dts <498000000>, <71142857>, <400000000>, <133333333>; <VIDEO PLL>,<PIX CLK>, <MEDIA_AXI>,<MEDIA_APB> &lcdif { status = "okay"; - assigned-clock-rates = <484000000>, <121000000>, <400000000>, <133333333>; + assigned-clock-rates = <498000000>, <71142857>, <400000000>, <133333333>; };  

The following setup is done on i.MX 93. For i.MX 8M the same steps are valid and can be followed. Prerequisites Prepare the Yocto environment. $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-langdale -m imx-6.1.1-1.0.0.xml $ repo sync  Set the build environment. $ DISTRO=fsl-imx-wayland MACHINE=imx93-11x11-lpddr4x-evk source imx-setup-release.sh -b build-imx93 Add the 32-bit support to the image For i.MX 8M / i.MX 93, building 32-bit applications on 64-bit OS can be supported using the multilib configuration. Multilib offers the ability to build libraries with different target optimizations or architecture formats and combine these together into one system image.  Building a 32-bit application requires the following statements in conf/local.conf. The configuration specifies a 64-bit machine as the main machine type and adds multilib:lib32, where those libraries are compiled with the armv7athf-neon tune, and then includes to the image the lib32 packages. # Define multilib target require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE:virtclass-multilib-lib32 = "armv7athf-neon" # Add the multilib packages to the image IMAGE_INSTALL:append = " lib32-glibc lib32-libgcc lib32-libstdc++" Multilib is not supported with the debian package management. It requires the RPM system. Check and comment out the two package management lines in conf/local.conf to go to the default RPM. PACKAGE_CLASSES = "package_deb" EXTRA_IMAGE_FEATURES += "package-management" Build the image. bitbake imx-image-core Cross-compile a 32-bit application This section shows how to use the Linux SDK to cross-compile a simple C application into a 32-bit binary. Generate the SDK, which includes the tools, toolchain, and small rootfs to compile against to put on host machine: DISTRO=fsl-imx-wayland MACHINE=imx93-11x11-lpddr4x-evk bitbake core-image-minimal -c populate_sdk Set the SDK environment with the following command before building: source /opt/fsl-imx-wayland/6.1-langdale/environment-setup-armv7at2hf-neon-pokymllib32-linux-gnueabi Implement a simple hello world application: cat hello_world_32.c #include <stdio.h> int main() { printf("Hello, World!"); return 0; } $CC hello_world_32.c -o hello_world_32 Check the file's type: $ file hello_world_32 hello_world_32: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=0a5042a0309858e0b10b12175a155cfbfb4c6a80, for GNU/Linux 3.2.0, with debug_info, not stripped Copy the binary to the Linux rootfs. Run the application on i.MX 93 Boot the board and run the application: root@imx93-11x11-lpddr4x-evk:~# ./hello_world_32 Hello, World!