OK-MX93 SPI2CAN/ADC Release Documentation Overview This document describes how to use the KV11Z SPI2CAN driver to implement IMX93 peripheral interface expansion. The driver connects to the KV11Z microcontroller via SPI interface, extending CAN bus and ADC acquisition capabilities for the IMX93 processor. Key Features: CAN Bus Extension: Provides 1Mbps CAN 2.0A/B communication capability ADC Acquisition Extension: Supports 8-channel 16-bit ADC with 1kHz sampling rate per channel Standard Interface: Fully compatible with Linux CAN Socket API and IIO subsystem High-Performance Transfer: Efficient data transfer architecture based on SPI+DMA+interrupt With this driver, developers can easily implement industrial-grade CAN communication and multi-channel analog signal acquisition on the IMX93 platform. System Architecture System Architecture Diagram Hardware Connection Description IMX93 and KV11Z are connected via standard SPI bus: MOSI: Master Output, Slave Input MISO: Master Input, Slave Output SCLK: SPI clock signal CS: Chip select signal (controlled by GPIO) IRQ: Interrupt signal (KV11Z to IMX93) Important Configuration Notes: Must use GPIO CS + DMA method, main controller CS method has known issues For device tree configuration, refer to the  OK-MX93-C.dts  file in the project SPI frequency recommended to be set at 7-12.5MHz, DMA configuration recommended to be enabled Data Flow Diagram Directory Structure . ├── adctest.c ├── build.sh ├── cantest.c └── OKMX93-linux-kernel-6.1.36 ├── arch │   └── arm64 │   └── boot │   └── dts │   └── freescale │   └── OK-MX93-C.dts └── drivers └── net └── can └── kv11z_spi2can.c Core Components 1. kv11z_spi2can.c - Core Driver Program Function: KV11Z SPI2CAN/ADC Linux kernel driver Implements CAN network device interface, supports standard Linux CAN Socket API Implements IIO ADC device interface, supports multi-channel ADC data acquisition Communicates with KV11Z microcontroller via SPI protocol Supports interrupt-driven high-performance data transfer Key Features: CAN Function: Supports standard and extended CAN frames, configurable baud rate and filters (under development) ADC Function: 8-channel ADC acquisition, supports triggered buffer mode and direct read mode High Performance: Multi-threaded architecture, supports concurrent CAN and ADC operations Configurable: Rich module parameters, supports runtime tuning Module Parameters: # CAN Configuration g_can_bitrate=1000000 # CAN baud rate (default 1Mbps) # ADC Configuration g_adc_mask=0xFF # ADC channel enable mask (default all channels) g_adc_sample_rate=1000 # ADC sampling rate (default 1kHz) # SPI Configuration spi_speed=7000000 # SPI bus speed (default 7MHz) transfer_time_us=30 # SPI transfer interval (default 30μs) # Debug Options debug=0 # Debug information switch (0=off, 1=on) 2. adctest.c - ADC Test Application Function: ADC data acquisition test tool Supports two ADC reading modes: direct mode and buffer mode Provides real-time data display and CSV file output Supports timestamps and performance statistics Hardware compatibility detection and channel validation Key Features: Dual Mode Support: Direct read mode (sysfs) and buffer mode (IIO buffer) Flexible Configuration: Configurable channel mask and sampling rate Data Export: Supports CSV format data export for subsequent analysis Real-time Display: Color terminal output and statistical information Usage Examples: # Compile gcc -O2 -o adctest adctest.c # Buffer mode, enable channels 0-3, with timestamps ./adctest -m 1 -c 0x0F -t # Direct mode, 500ms sampling interval ./adctest -m 0 -d 500000 # Save data to CSV file ./adctest -m 1 -f /tmp/adc_data # View help ./adctest -h 3. cantest.c - CAN Bus Test Tool Function: Comprehensive CAN bus testing and benchmarking tool Supports CAN frame generation, transmission and reception Provides MD5 verification to ensure data integrity Supports file transfer over CAN bus Real-time performance monitoring and statistical analysis Key Features: Performance Testing: Supports bulk transmission testing of large numbers of frames Data Integrity: MD5 verification ensures transmission data integrity File Transfer: Supports arbitrary file transfer over CAN bus Real-time Monitoring: Progress bar display, FPS statistics, error statistics, etc. Usage Examples: # Compile gcc -O2 -o cantest cantest.c # Transmitter: Send 1000 random CAN frames ./cantest -i can0 -t -n 1000 -d 1000 # Receiver: Receive CAN frames and verify ./cantest -i can0 -r # File transfer transmitter ./cantest -i can0 -t -f /path/to/file # File transfer receiver ./cantest -i can0 -r -f /path/to/output # View help ./cantest -h Quick Start 1. Environment Setup Ensure cross-compilation toolchain is installed: # Set cross-compilation environment source environment-setup-aarch64-toolchain 2. Build System # Complete build ./build.sh all # Or step-by-step build ./build.sh uboot ./build.sh kernel ./build.sh apps ./build.sh mkfs 3. Deploy Driver # Load driver module insmod kv11z_spi2can.ko # Configure CAN interface ip link set can0 type can bitrate 1000000 ip link set can0 up # Verify ADC device ls /sys/bus/iio/devices/ 4. Function Testing # Test ADC function ./adctest -m 1 -c 0xFF -t # Test CAN function ./cantest -i can0 -t -n 100 Technical Specifications Hardware Requirements Main Controller: OK-MX93 development board (IMX93 processor) Co-processor: KV11Z microcontroller Interface: SPI bus connection CAN: Supports CAN 2.0A/B protocol ADC: 8-channel 12-bit ADC Performance Metrics CAN Baud Rate: Up to 1Mbps ADC Sampling Rate: Up to 1kHz (per channel) SPI Speed: Up to 12.5MHz Latency: CAN frame transmission latency ≤1ms Throughput: Supports 7500 frames/second CAN transmission Software Compatibility Kernel Version: Linux 6.1.36 Architecture: ARM64 (aarch64) Compiler: GCC cross-compilation toolchain API: Standard Linux CAN Socket API, IIO subsystem API Troubleshooting Common Issues Compilation Failure Check if cross-compilation environment is correctly set Confirm all dependency packages are installed Driver Loading Failure Check if device tree configuration is correct Confirm SPI interface and GPIO configuration CAN Communication Abnormal Check CAN bus hardware connections Verify if baud rate configuration matches ADC Data Abnormal Check ADC channel mask configuration Verify if sampling rate setting is reasonable Debugging Methods # Enable driver debug information echo 1 > /sys/module/kv11z_spi2can/parameters/debug # View system logs dmesg | grep kv11z # Check device status cat /proc/interrupts | grep kv11z Technical Support For technical support, please contact the development team or refer to relevant technical documentation. Note: This software package is only applicable to OK-MX93 development board. Please ensure hardware configuration is correct before use.Other boards please porting by yourself. 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."

What we need?  USB cable Windows Host PC MCU-LINK PRO What Do You Gain? With this firmware upgrade, you will be able to debug the M core of i.MX processors (such as i.MX8 and i.MX9). Also, the cost advantage due to the MCU-LINK PRO is currently the most affordable debugger available for i.MX processors.   Firmware Upgrade Steps   Install Required Tools Install the MCUXpresso IDE, or use the MCUXpresso Installer for VS Code to install the necessary software tools.     Download Firmware Get the latest firmware from the Segger web page   Save Firmware Save the downloaded firmware in the following directory: C:\nxp\LinkServer_1.6.133\MCU-LINK_installer\probe_firmware   Backup Old Firmware Rename the existing firmware file to keep a backup.   Example: Rename firmware.s19 to old_firmware.s19   Set Jumper and Connect Place a jumper on J4 and connect the MCU-LINK PRO to the host PC via USB.   Open LinkServer CLI Launch the LinkServer CLI. If it's not installed, download it from NXP web page.   Run the Update Script Execute the following commands in the terminal: $ cd MCU-LINK_installer $ scripts\program_JLINK.cmd   Start Firmware Flash Once the MCU-LINK PRO is detected, press any key to flash the Segger firmware.     Finalize Update After a successful update, remove the jumper from J4, disconnect and reconnect the MCU-LINK PRO   Verify Installation You can confirm that the debug probe is recognized using MCUXpresso IDE, or MCUXpresso for VS Code     References: MCU-Link installation   

  Platform & BSP : i.MX8MPlus EVK , L6.12.3， uboot lf_v2024.04   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 01.00.00 0x1b4b 0x2b42 Network controller 0x00 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 u-boot=> pci header 01.00.00 vendor ID = 0x1b4b device ID = 0x2b42 command register ID = 0x0006 status register = 0x0010 revision ID = 0x11 class code = 0x02 (Network controller) sub class code = 0x00 programming interface = 0x00 cache line = 0x08 latency time = 0x00 header type = 0x00 BIST = 0x00 base address 0 = 0x1810000c base address 1 = 0x00000000 base address 2 = 0x1820000c base address 3 = 0x00000000 base address 4 = 0x00000000 base address 5 = 0x00000000 cardBus CIS pointer = 0x00000000 sub system vendor ID = 0x0000 sub system ID = 0x0000 expansion ROM base address = 0x00000000 interrupt line = 0xff interrupt pin = 0x01 min Grant = 0x00 max Latency = 0x00

Hello everyone! In this document you'll find an example on how to build your own flash.bin for i.MX93 low power mode where only the Cortex-M33 rom is running after Power-On Reset, the following table provides the boot devices supported for LP boot: In LP boot, up to three containers (NXP and OEM containers) are expected to be handled by CM33 ROM code. • NXP container (optional): EdgeLock Enclave FW only (must-have in case NXP container present) • OEM container (mandatory), contains: — CM33 FW (must-have) — FCB Region Copy Image (optional) Requirements: Ubuntu 20.04 or later host PC i.MX93 EVK UUU Tool ARM GNU Toolchain (arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu) SDK package (SDK_2_16_000_MCIMX93-EVK) Build procedure: Clone imx-mkimage, it is better to use the same SW version for each source we are working with, please refer to i.MX Linux Release Notes document, table 3. BSP and multimedia standard packages for this information. $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.6.52-2.2.0 Decompress the GNU toolchain into a path in local disk, in this guide would be /opt $ sudo tar -xvJf arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt Clone and build Uboot $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.6.52-2.2.0 $ cd uboot-imx $ make -j $(nproc --all) clean $ make -j$(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- imx93_11x11_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- Download and extract i.MX firmware $ cd .. $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-1.3.0-17945fc.bin $ chmod +x firmware-ele-imx-1.3.0-17945fc.bin $ ./firmware-ele-imx-1.3.0-17945fc.bin --auto-accept Optional if using AHAB FW $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.26-d4c33ab.bin $ chmod +x firmware-imx-8.26-d4c33ab.bin $ ./firmware-imx-8.26-d4c33ab.bin --auto-accept Clone and build ATF $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.6.52-2.2.0 $ cd imx-atf $ make -j $(nproc --all) PLAT=imx93 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- Build M33 code, in this example we are using hello world from the i.MX SDK package. $ cd .. $ tar -xvzf SDK_2_16_000_MCIMX93-EVK.tar.gz $ cd SDK_2_16_000_MCIMX93-EVK/boards/mcimx93evk/demo_apps/hello_world/armgcc $ export ARMGCC_DIR=~/gcc-arm-none-eabi-10.3-2021.10 $ export PATH=$PATH:~/gcc-arm-none-eabi-10.3-2021.10 $ ./build_release.sh Copy the resulting binaries to imx-mkimage $ cp ~/imx-atf/build/imx93/release/bl31.bin ~/imx-mkimage/iMX93 $ cp ~/uboot-imx/u-boot.bin ~/imx-mkimage/iMX93 $ cp ~/uboot-imx/spl/u-boot-spl.bin ~/imx-mkimage/iMX93 $ cp release/sdk20-app.bin ~/imx-mkimage/iMX93/m33_image.bin Copy i.MX firmware to imx-mkimage $ cd .. $ cp firmware-imx-8.26-d4c33ab/firmware/ddr/synopsys/lpddr4_imem_1d_v202201.bin ~/imx-mkimage/iMX93 $ cp firmware-imx-8.26-d4c33ab/firmware/ddr/synopsys/lpddr4_dmem_1d_v202201.bin ~/imx-mkimage/iMX93 $ cp firmware-imx-8.26-d4c33ab/firmware/ddr/synopsys/lpddr4_dmem_2d_v202201.bin ~/imx-mkimage/iMX93 $ cp firmware-imx-8.26-d4c33ab/firmware/ddr/synopsys/lpddr4_imem_2d_v202201.bin ~/imx-mkimage/iMX93 $ cp firmware-ele-imx-1.3.0-17945fc/mx93a1-ahab-container.img ~/imx-mkimage/iMX93 Build the flash.bin using mkimage, we have different target memory options for lpboot $ cd imx-mkimage eMMC/SD $ make SOC=iMX9 REV=A1 flash_lpboot eMMC/SD no AHAB $ make SOC=iMX9 REV=A1 flash_lpboot_no_ahabfw Flexspi $ make SOC=iMX9 REV=A1 flash_lpboot_flexspi Flexspi no AHAB $ make SOC=iMX9 REV=A1 flash_lpboot_flexspi_no_ahabfw Flexspi XiP $ make SOC=iMX9 REV=A1 flash_lpboot_flexspi_xip Change the binary name so we can identify and it is easier when flashing $ mv flash.bin flash_m33_lpboot.bin Also, build singleboot flashbin so we can use it to run UUU and flash the lpboot binary $ make SOC=iMX9 REV=A1 flash_singleboot $ mv flash.bin flash_UUU.bin Set SW1301 for serial download on the EVK (0011), connect debug, download and power cables and turn on the EVK. Flash the resulting binary into the EVK for the respective target (SD/eMMC/FSPI) $ uuu -b sd flash_UUU.bin flash_m33_lpboot.bin $ uuu -b emmc flash_UUU.bin flash_m33_lpboot.bin $ uuu -b qspi flash_UUU.bin lash_m33_lpboot.bin Once it is done change SW1301 to the respective bootmedia SD Low power boot (1010) eMMC Low power boot (1000) FlexSPI NOR Low power boot* (1101) *Note M.2 QSPI card is required for FlexSPI Boot option, since QSPI memory is not populated into the EVK Power on the board, and the example should be running on the Cortex-M33 terminal only. Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.

Platform: I.MX8MMEVK uboot version:  uboot-imx_lf_v2023.04 BSP: 6.1.x Add patch in uboot git clone https://github.com/nxp-imx/uboot-imx.git git checkout lf_v2023.04 git apply 0001-Enable-imx8mm-pcie-driver-v2023.04.patch   test log: u-boot=> pci enum pcie phy base: 0x32f00000, size 0x10000 pcie phy pll is locked after 0 us. Link up, Gen1 u-boot=> pci BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x16c3 0xabcd Bridge device 0x04 01.00.00 0x1131 0x3003 Network controller 0x00 01.00.01 0x1131 0x3004 Network controller 0x00  

give an example for bring up the imx8mq DP/eDP board based on nxp SW

Test environment: i.MX93FRDM LF6.6.36. With Yocto training.

We are pleased to announce that Config Tools for i.MX v25.03 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) • Output Paths Overrides for toolchain project is fixed. • "Filter source files" search bar with case-sensitive checkbox is removed. • TEE – Sort for Peripheral Configurations table is added. DDR tool (part of Config tools for i.MX 25.03😞 [MX91] Added 1Gb and 2Gb DRAM configurations in the GUI. [MX9x] Enhanced Diagnostic tests to display DBI lane when DBI is enabled. [MX95][FW2024.09] Optimized PLL settings. [MX95][FW2024.09] Included missing registers in the retention list. [Mscale] Added a temperature derating GUI option for devices with LP4. [8MP] Updated PMIC configuration to correctly set 1.2V for 8M-Plus. [8MN] Improved board bus configuration. Enabled maximum number of available frequencies setpoints for all supported devices. Added EVK default configuration for all supported devices.

Test environment: i.MX8ULP EVK, SDK2.16 Some customer want to use LPUART2 in DSP domain on M33 core. This patch is based on lpuart_edma example.   Hardware test point:   You will get such log from LPUART2 if we enter 3 on keyboard LPUART EDMA example Send back received data Echo every 8 characters 33333333   Modify M33 debug console from LPUART1 to LPUART2 is similiar.

Test environment: i.MX8ULP EVK, SDK2.16 Some customer want to use LPUART2 in DSP domain on M33. This patch is based on lpuart_polling.   Hardware test point: If you send data from uart2, you will get such log from M33 console: reg = d2000000, 94000000 LPUART_WriteBlocking get readbuf = 73 get readbuf = 73  

This article explains how to get started with JTAG debugging of the Linux kernel running on the A55 of iMX93EVK. We will be using Lauterbach Trace32 to debug iMX93EVK. Here is a list of pre-requisites that is expected from the readers:- 1. Basic knowledge to get started on Trace32 - Please refer Learning and Training | Lauterbach TRACE32 2. You should have Linux source code and steps to build the kernel. 3. Trace32 Software with a license to debug A55 COMPONENTS   Hardware required: -   iMX93EVK running 6.6.52 BSP Lauterbach Power Debug E40 with a Debug cable Software required: - Trace32 Linux kernel source code   Linux Kernel Modifications Step 1:- In arch/arm64/configs/imx_v8_defconfig, please make sure that:- CONFIG_DEBUG_INFO_REDUCED=n CONFIG_DEBUG_INFO = y CONFIG_KALLSYMS=y   Step-2 :- Enabling JTAG debugging in Linux On iMX93EVK LPUART5 is MUX'd with the JTAG pins   so if we want to debug the linux kernel via JTAG, we will have to disable it. Go to the device tree source file - arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts Change the status of the following node to 'disabled'     Step 2:- Build the kernel. vmlinux will be created as part of this. This has the Linux kernel along with the debug symbols required for Trace32 debugging. Step-3 At this point either you can copy the linux-imx folder to your local windows machine where Trace32 is installed, or you can simply map the linux machine as a network drive so that the same folder '/opt/samba/nxg05261/linux-imx' is accessible on windows. The motive of this exercise is to use 'vmlinux' and the linux source files present in this folder from trace32 cmm scripts that we will be executing.   Step-4 Replace the newly built kernel 'Image' - arch/arm64/boot/Image with the one present in the boot partition of imx93evk. You can simply copy this Image to iMX93EVK via scp and copy it to the folder - /run/media/boot-mmcblk0p1 Note:- Please make sure that the kernel version that is running on the box and the one you have built should be the same otherwise there will be debug symbols mismatch After copying the Image, reboot iMX93EVK. Debugging with Trace32 Step-1 Configuring Uboot bootargs Cpu idle state interferes with the JTAG debugging by impacting the clocks so we need to disable the cpu idle power management. We do this by appending "cpuidle.off=1" to the bootargs:- a. Stop at Uboot prompt. b. Execute command - setenv mmcargs "setenv bootargs ${jh_clock} ${mcore_clk} console=${console} root=${mmcroot}  cpuidle.off=1" [do not omit the inverted commas in the command] Step-2 Boot to Linux prompt   Step-3 Connect the USB cable of Lauterbach Power Debug probe to your windows machine and Open t32 - C:\T32\bin\windows64\t32start.exe   Select 'PowerView Instance' and click on 'Start'. A window like below will appear: -   Step- 4 Extract MMU translation info for the debugger For this either you can execute the below commands on the T32 in sequence: -   RESet SYStem.RESet SYStem.CPU IMX93-CA55 SYStem.JtagClock 10MHz SYStem.CONFIG.DEBUGPORTTYPE JTAG SYStem.Option EnReset OFF CORE.ASSIGN 1. 2. SYStem.Option MMUSPACES ON SYStem.Option IMASKASM ON SYStem.Mode Attach Data.LOAD.Elf <path_of_vmlinux> /NoCODE DO ~~/demo/arm/kernel/linux/board/generic-template/detect_translation.cmm OR simply edit the attached cmm script - detect_address_translation.cmm and modify the <path_of_vmlinux> as per your file location. Then execute it like this:- Do <file_path>/detect_address_translation.cmm In my case, this command was: - Do C:\Users\nxg05261\Documents\cmm_scripts\detect_address_translation.cmm Note:- <path_of_vmlinux> in my case was  C:\T32\demo\arm\bootloader\uboot\vmlinux. You can modify it as per the location where you have copied 'vmlinux' -- After executing the above commands, debugger address translation will be displayed: -    Now we will copy the above highlighted lines and paste it in the final cmm script that we will use for debugging. For readers' convenience this info has been collated into the final script - 'linux_attach_t32.cmm', attached with this blog.   Disclaimer:- The lines that are highlighted depends on the kernel version and customer design decisions, so it is strongly advised to take the output of detect_translation.cmm for your system and then paste it in the cmm script, instead of using the exact output that I have shown in the above picture. File -> Open File -> linux_attach_t32.cmm -- Click on 'Do' button to execute the script till the end. -- Set a breakpoint at start_kernel b.s start_kernel /Onchip   [Optional]Check the breakpoint via 'b.l'   -- Hit 'go' at t32 to let the cores execute the instructions, you will see 'running' state   -- Enter 'reboot' at Linux prompt and stop at Uboot command line prompt you will see trace32 at 'system down' state: - -- Execute 'system.mode.attach' at t32 to attach to the system, you will again see 'running' state -- Execute 'break' to stop the running state -- Check if the breakpoint 'start_kernel' still exist via command 'b.l' -- If you see the breakpoint is still set, Execute 'go' at t32 to take the cores to the running state. -- Then, at Uboot prompt, execute 'boot' so that it may load the linux kernel to the memory.   As soon as you do that you would see that Uboot will try to load kernel. The last print you will see on the serial console will be: - "Starting kernel …' the execution will stop and at t32 you will see that the breakpoint is hit, meaning the Program Counter is at the address of the function 'start_kernel'   Note- The Warning that you might observe[like in the above picture] means that trace32 is not able to find the source file 'main.c'. So you will not be able to see the 'C' source code at this point. To resolve this:- -- Right click on the 'List.auto' window where you see the assembly code. Click on 'Resolve Path' and navigate to the init/main.c in your kernel source code folder and click Open. You would see that the source path translation is now correct and you're able to view the disassembly as well as the source code: -     Now we will load kernel symbols and apply 2 breakpoints in the linux kernel to demonstrate kernel debugging:-   -- Load the kernel symbols Data.LOAD "C:\T32\demo\arm\bootloader\uboot\vmlinux"  H:0x0::0x0 /NoCODE /SOURCEPATH Z:\linux-imx   -- Apply breakpoints at t32 window b imx_rpmsg_init b imx_drm_bind   [Optionally] you can verify the breakpoints via 'b.l' These breakpoints are temporary as you can see in the above snapshot. That means after they are hit, they will be removed, so to make them permanent:- Right click the breakpoint -> Change -> Uncheck Temporary -> Click Ok like depicted in the following snapshots: -       Now, to reach the next breakpoint, execute 'go' on the t32 At this point linux kernel execution has reached the function imx_rpmsg_init   Again, to reach the next breakpoint, execute 'go'   So this is how you start debugging the linux kernel. Apart from this, there is a nice t32 feature called 'linux awareness' which allows you to easily debug the kernel loadable modules, user space applications amongst other things. To explore 'linux awareness', you can go about checking the 'Linux' drop down menu present at the top. Plenty of support documents are available on the web.       Feel free to drop in the comments section or DM if you have any queries. Happy debugging!!🙂🙂🙂🙂  

Overview   This document intends to provide one reference how to emulate i.MX8QM 1.3GHz part running on i.MX8QM MEK with 1.6GHz part based on i.MX Linux BSP release.   You can find i.MX8QM/QP processors datasheet on NXP web: i.MX 8QuadMax 1.3GHz Automotive and Infotainment Applications Processors; i.MX 8QuadPlus 1.3GHz Automotive and Infotainment Applications Processors; i.MX 8QuadPlus Industrial Applications Processors Data Sheet; i.MX 8QuadMax Industrial Applications Processors Data Sheet;   Key differences between 1.3GHz part and 1.6GHz part is as follows: Key Differences 1.6GHz part 1.3GHz part 8QM/8QP A72 core max frequency 1600MHz 1296MHz 8QM GPU max frequency core 800MHz  shader 1000MHz core 650MHz shader 700MHz 8QM VDD_GPU mode Overdrive mode Remove overdrive mode, only nominal 8QM VDD_GPU nominal operation range Min 0.95V Typ 1.0 V Max 1.1V Min 0.98V Typ 1.03125V Max 1.14V   Software Changes   Since Linux 6.6.23_2.0.0 BSP release, i.MX8QM/8QP 1.3GHz part is supported into i.MX Linux release by identifying the fuse of 1.3GHz part and configuring frequency and voltage automatically. If you have i.MX8QM MEK board with 1.6GHz part, before revision E, you can apply software changes to emulate 1.3GHz part configurations explicitly. The following software reference patches are built based on Linux 6.6.52-2.2.0 release: Component Patch Name Description Linux Kernel 0001-arm64-dts-imx8qm-remove-A72-core-1.6GHz-operating-po.patch Used to remove Cortex-A72 core 1.6GHz operating-points 0002-arm64-dts-imx8qm-set-GPU-operating-points-at-nominal.patch Used to remove GPU overdrive operating-points and set GPU core frequency as 650MHz, GPU shader frequency as 700MHz. SCFW 0001-Increase-VDD-of-GPU.patch Used to increase GPU voltage ATF 0001-plat-imx8-make-ATF-kick-off-A72-core-freq-at-1.3GHz.patch Used to kickoff A72 core and set its frequency as 1.3GHz in ATF   Validation Test Apply patch into Linux kernel, SCFW porting kit, ATF, follow 6.6.52_2.2.0 release document(www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX) to build and deploy image.     After Linux OS boot up,  run below command to check A72 and GPU frequency,  for example: #cat /sys/kernel/debug/gc/clk gpu0 mc clock: 647981058 HZ. gpu0 sh clock: 695997687 HZ. gpu1 mc clock: 647990370 HZ. gpu1 sh clock: 695987994 HZ   #cat /sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_max_freq 1296000   Measure VDD_GPU voltage from i.MX8QM MEK board TP53 and TP42

This tutorial outlines the steps required to set up and build a Yocto image for the FRDM-IMX93 board, including integrating the meta-imx-frdm recipes and applying a patch to enable UART3 support. Required Materials A computer running Linux (Ubuntu 22.04) FRDM-IMX93 board Network cable or WiFi configured on the board USB C cables   Installing the repo Utility $ mkdir ~/bin $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=${PATH}:~/bin Downloading i.MX Linux Yocto Release $ mkdir ${MY_YOCTO} # This directory will be the top-level directory $ cd ${MY_YOCTO} $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.36-2.1.0.xml $ repo sync If errors occur during repo init, remove the .repo directory and run repo init again.   Integrating meta-imx-frdm Recipes into Yocto $ cd ./sources $ git clone https://github.com/nxp-imx-support/meta-imx-frdm.git $ cd meta-imx-frdm $ git checkout imx-frdm-1.0   Applying the Patch $ mv /home/<user_name>/Downloads/FRDM-IMX93-LPUART3-SUPPORT.patch . $ git apply FRDM-IMX93-LPUART3-SUPPORT.patch Setting Up the Build Environment $ cd ../../ $ MACHINE=imx93frdm DISTRO=fsl-imx-xwayland source sources/meta-imx-frdm/tools/imx-frdm-setup.sh -b frdm-imx93 Compiling the Kernel $ bitbake -c deploy virtual/kernel Once the compilation is complete, the new device tree will be located at: tmp/deploy/images/imx93frdm/imx93-11x11-frdm.dtb Flashing the Modified Device Tree You can flash the modified device tree using the uuu tool with the method described in this community post   To flash the device tree using network method, boot the board and connect it to the network using a cable or WiFi. Then, use scp to transfer the file. #For eMMC Boot $ cd tmp/deploy/images/imx93frdm/ $ scp imx93-11x11-frdm.dtb root@<frdm_ip>:/run/media/boot-mmcblk0p1/ $ reboot #For SD Boot $ cd tmp/deploy/images/imx93frdm/ $ scp imx93-11x11-frdm.dtb root@<frdm_ip>:/run/media/boot-mmcblkp1/ $ reboot   Using UART3 After rebooting, UART3 will be available on GPIO14 and GPIO15 of the RPi connector on the board.     Results:  

Attached package includes BSP patch for AI Robot Platform Based on i.MX 8M Plus  Version 6.1.55 : Rel_imx_6.1.55-2.2.0_8mp_airobot.tar.gz

This guide provides a step-by-step approach for beginners looking to flash a custom Kernel Image or device tree on an NXP i.MX board. Sometimes, we need to customize the Kernel Image or modify the device tree for our board. Fortunately, NXP provides the UUU (Universal Update Utility) tool, which allows us to flash and use a custom Kernel Image or update the device tree on our board.   Requirements Before proceeding, ensure you have the following: - The latest version of the UUU Tool. - An i.MX EVK board (i.MX6, i.MX7, i.MX8, i.MX9). - The power supply for the board. - Two USB cables (USB-C or Micro USB, depending on your board).   Preliminary Steps To customize the Kernel Image or device tree, refer to the following community posts: - How to Fix FRDM-IMX93 Linux Kernel BSP - How to Compile Linux Kernel Image and Device Tree Using Yocto SDK   Once you have your customized Linux Kernel Image or device tree ready, follow the steps below to deploy it to your board.   Flashing the Kernel Image or Device Tree Connect and Prepare the Board 1. Connect the USB debug cable and the OTG cable from your board to your host computer. 2. Power on your board and stop the boot process at the U-Boot stage by pressing a key in the terminal. 3. Enter fastboot mode by running the following command in the U-Boot terminal: u-boot -> fastboot 0   Flash the Custom Kernel Image or Device Tree   4. Open a terminal on your host computer and navigate to the directory containing the new Kernel Image or device tree. 5. Flash the new files using the following command: $ uuu -b fat_write <file_name> mmc <device>:<partition> <file_name_in_board> Example: $ uuu -b fat_write imx93-11x11-evk.dtb mmc 0:1 imx93-11x11-evk-custom.dtb In this example, the file imx93-11x11-evk.dtb stored on the host machine is flashed to the board's eMMC device, saving it as imx93-11x11-evk-custom.dtb.   Note: If you are using Linux, run the command with sudo. - For eMMC and SD card, the command is the same; just ensure you use the correct device number. - On the i.MX93, device 0 corresponds to eMMC, and device 1 corresponds to the SD card.   Update U-Boot Environment Variables   6. Exit fastboot mode by pressing CTRL+C. This returns you to the U-Boot terminal. 7. Set up the environment variablesto use the new files: For the Kernel Image: u-boot -> setenv image <custom_image_name> u-boot -> saveenv u-boot -> reset For the Device Tree: u-boot -> setenv fdtfile <custom_device_tree_name> u-boot -> saveenv u-boot -> reset The board should now boot using your modified Kernel Image and device tree.  

Platform: i.MX8MP EVK L6.6.52 , SDK2.16 The rpmsg_lite_pingpong_rtos demo in SDK will complete 100 times ping-pong and then destory the rpmsg connection and related resources. For Linux kernel, there is no such rpmsg api to finish similiar thing,  which will case imx-rproc imx8mp-cm7: imx_rproc_kick: failed (0, err:-62) , this error indicates that the remoteproc is still try to kick up M7 after rpmsg_lite_pingpong_rtos destory the rpmsg resources.   Here is a simple workaround for this error. 1. drivers/rpmsg/imx_rpmsg_pingpong.c Destory ept when saying goodbye. 2.drivers/rpmsg/virtio_rpmsg_bus.c Disable virtuequeue callback(->imx_rproc_kick) in _rpmsg_destory_ept.   Result: No imx-rproc imx8mp-cm7: imx_rproc_kick: failed (0, err:-62) after 100 times ping-pong    

GUI Guider version:  1.9.x LVGL version: v8.x.x , v9.x.x Host software requirements: Ubuntu 20.04, Ubuntu 22.04 or Debian 12 Hardware requirements: FRDM i.MX 93 Development Board i.MX 93 Evaluation Kit   Steps: 1. Export 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.6 $ cd imx-bsp-6.6 $: repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.52-2.2.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-full -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-full-armv8a-imx93evk-toolchain-6.6-scarthgap.sh d. Install ninja utility on the build host $ sudo apt update $ sudo apt upgrade -y $ sudo apt install ninja-build e. Unzip the gui guider and lvgl sources $ cd meta-gui-guider/recipes-graphics/gui-guider/gui-guider/ $ unzip gui-guider.zip $ cd ../../lvgl/lvgl/ $ unzip lvgl.zip $ cd ../../gui-guider/gui-guider/ $ mv ../../lvgl/lvgl/ . $ cd ports/linux/ f. Change the interpreter on build.sh from #!/bin/sh to #!/bin/bash. $ nano build.sh -- #!/bin/sh ++ #!/bin/bash g. 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.    RESULTS:     I hope this article will be helpful

GUI Guider version: 1.6.x, 1.7.x, 1.8x LVGL version: v8.x.x 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.

Hardware:​  Soc: NXP i.MX 93 11x11 EVK FPGA:​ Lattice ECP5 Evaluation Board   Deploy the driver of FlexSPI and Test​​ Apply below patch into Linux kernel and compile. (6.1.55-2.2.0 is tested)​ git apply 0001-Added-flexspi-fpga-module-support-of-i.MX93.patch​ make imx_v8_defconfig​ make –j8​ Copy the generated imx93-11x11-evk-flexspi-m2-fpga.dtb to the boot partition​ Set the dtb in uboot​ setenv fdtfile imx93-11x11-evk-flexspi-m2-fpga.dtb ​ saveenv​ boot​ Copy the generated imx93_flexspi_fpga.ko and the test app source file flexspi_fpga_latency_test.c to home directory Run blow command to do the test​ gcc flexspi_fpga_latency_test.c​ ./a.out 128​ ​ About driver and test app​ ​The driver can be installed in test app automatically. Insmod command is called in test app as below.​ insmod imx93_flexspi_fpga.ko mux=1 div=30​ The parameter mux can be set to 0,1,2,3. Means 24MHz, 1000MHz, 800MHz, 625MHz root clock. And div is the divider. In default, 1000/30 = 33MHz is applied. More details of hardware connection: Since the adapter board is not on NXP website and it is just for test, there are two options. Use fly-wire to connect flexspi and lattice fpga instead of the adapter card. Use M.2 adapter card but need be produced by customer themselves.  If M.2 adapter is not used, fly-wire can be applied to connect i.MX93 to FPGA. The column of Pads is a pad list that can bring out signal lines from the bottom layer of i.MX93 EVK. i.MX 93 Pads of imx93 FPGA ECP5 SD3_CLK TP912 B10 SD3_CMD TP913 A9 SD3_DATA0 TP914 C6 SD3_DATA1 TP915 C7 SD3_DATA2 TP916 E8 SD3_DATA3 TP917 D8 GND   GND J1003-2 1V8   VCCIO0 Remove JP10 Jumper   It is also possible that the customer would choose M.2 adapter card solution. The adapter card is simple and cheap. It can be redesigned easily with attached schematic as reference. Make sure the board thickness is 0.8mm. And recommend to apply GND copper to improve signal quality. The schematic is attached. To get the information about the demo from Lattice perspective, please check the link below. Lattice QSPI to NXP MPU Reference Design | Lattice Reference Design  

This article describe i.M93 RGMII to PHY connection, delay adding tips. i.MX93 don't support delay in both FEC and QOS port in i.MX93 side. It also provide solution on i.MX93 how to connect MAC to MAC in HW & SW. Thanks!