Background: The i.MX95 introduces a system manager firmware, which is responsible for power, clock, resource isolation, security management, and system-level control between kernels, essentially acting as the "backend manager" for the entire SoC. Switching between different driver modes is necessary to change the VDD_SOC voltage of the i.MX 95. But, Unlike the i.MX 93, the i.MX 95 does not support DVFS and the i.MX 95 has only one fixed DDR frequency point., it is not possible to switch between OD, ND, and LD modes under userspace. This article will explain how to switch from OD to ND mode.   1. Test environment HW: i.MX95 EVK board SW: imx-oei, imx-sm 2. Voltage and frequency of i.MX 95 series processors in different modes The voltage VDD_SOC varies in different modes. pengyong_zhang_2-1787043053405.pngMaximum frequency of i.MX 95 series processor modules in different modes. pengyong_zhang_1-1787043037623.png 3. Code change(Switching to ND mode as an example) 3.1. imx-sm https://github.com/nxp-imx/imx-sm/blob/master/boards/mcimx95evk/sm/brd_sm.c#L107 index 077fa06..023a580 100755 --- a/boards/mcimx95evk/sm/brd_sm.c +++ b/boards/mcimx95evk/sm/brd_sm.c @@ -104,7 +104,7 @@      BRD_SM_REC_VLD_MASK)  /* Performance parameters */ -#define BOARD_PERF_LEVEL  DEV_SM_PERF_LVL_ODV  /* Target perf level */ +#define BOARD_PERF_LEVEL  DEV_SM_PERF_LVL_NOM  /* Target perf level */  #if BOARD_VOLT_SOC >= ES_ODV_UV_VDD_SOC  #define BOARD_BOOT_LEVEL  DEV_SM_PERF_LVL_ODV  /* Boot perf overdrive */  #elif BOARD_VOLT_SOC >= ES_NOM_UV_VDD_SOC diff --git a/configs/mx95evk.cfg b/configs/mx95evk.cfg index 8ac5392..5f19d42 100755 --- a/configs/mx95evk.cfg +++ b/configs/mx95evk.cfg @@ -459,7 +459,7 @@ PD_A55C2            stop=5  PD_A55C3            stop=4  PD_A55C4            stop=3  PD_A55C5            stop=2 -PERF_A55            start=3|3 +PERF_A55            start=3|2  CPU_A55C0           start=4  CPU_A55P            stop=1 @@ -473,7 +473,7 @@ PD_A55C2            msel=1, stop=5  PD_A55C3            msel=1, stop=4  PD_A55C4            msel=1, stop=3  PD_A55C5            msel=1, stop=2 -PERF_A55            msel=1, start=3|3 +PERF_A55            msel=1, start=3|2  CPU_A55C0           msel=1, start=4  CPU_A55P            msel=1, stop=1 @@ -487,7 +487,7 @@ PD_A55C2            msel=2, stop=5  PD_A55C3            msel=2, stop=4  PD_A55C4            msel=2, stop=3  PD_A55C5            msel=2, stop=2 -PERF_A55            msel=2, start=3|3 +PERF_A55            msel=2, start=3|2  CPU_A55C0           msel=2, start=4  CPU_A55P            msel=2, stop=1 diff --git a/configs/mx95evk/config_lmm.h b/configs/mx95evk/config_lmm.h index 3e3f508..999a4a1 100755 --- a/configs/mx95evk/config_lmm.h +++ b/configs/mx95evk/config_lmm.h @@ -152,11 +152,11 @@      {.lmId = 2U, .mSel = 1U, .ss = LMM_SS_PD, .rsrc=DEV_SM_PD_A55P}, \      {.lmId = 2U, .mSel = 2U, .ss = LMM_SS_PD, .rsrc=DEV_SM_PD_A55P}, \      {.lmId = 2U, .mSel = 0U, .ss = LMM_SS_PERF, .rsrc=DEV_SM_PERF_A55, \ -     .numArg = 1, .arg[0] = 3U, }, \ +     .numArg = 1, .arg[0] = 2U, }, \      {.lmId = 2U, .mSel = 1U, .ss = LMM_SS_PERF, .rsrc=DEV_SM_PERF_A55, \ -     .numArg = 1, .arg[0] = 3U, }, \ +     .numArg = 1, .arg[0] = 2U, }, \      {.lmId = 2U, .mSel = 2U, .ss = LMM_SS_PERF, .rsrc=DEV_SM_PERF_A55, \ -     .numArg = 1, .arg[0] = 3U, }, \ +     .numArg = 1, .arg[0] = 2U, }, \      {.lmId = 2U, .mSel = 0U, .ss = LMM_SS_CPU, .rsrc=DEV_SM_CPU_A55C0}, \      {.lmId = 2U, .mSel = 1U, .ss = LMM_SS_CPU, .rsrc=DEV_SM_CPU_A55C0}, \      {.lmId = 2U, .mSel = 2U, .ss = LMM_SS_CPU, .rsrc=DEV_SM_CPU_A55C0}, 3.2. imx-oei Add the timing.c file for different DRAM frequencies under different modes to the following file, and then recompile imx-oei: https://github.com/nxp-imx/imx-oei/tree/master/boards/mx952lp5-19/ddr pengyong_zhang_1-1787035595967.png 4. Boot log: The boot log shows that the CPU frequency had dropped to 1404MHz at this point. pengyong_zhang_3-1787035619561.png Note: Ensure that you are using the DRAM timing.c file corresponding to the specified mode and that the compilation is error-free. To guarantee a complete error-free compilation, it is recommended to create a new timing.c file in the directory corresponding to imx-oei, complete the configuration in the Makefile, and then compile. Do not completely overwrite the contents of the current timing.c file. For instructions on how to use Config Tool and how to update the timing.c file, please refer to the Config Tool User Guide.  

Attached slides introduce the i.MX95 Power management with following topics: SoC Power Architecture Power Management with BSP Power on/off & Reboot Suspend Implementation Low Power Run

Hello everyone! In this document you'll find an example on how to build your Cortex-M33 code where some parts of the code runs from DDR, for this changes on ATF where the M33 core can visit DRAM in early stage. For this we will take advantage of RPROC framework, RPROC (Remote Processor Framework) is a Linux kernel and U-Boot subsystem that manages secondary, embedded processors (like Cortex-M cores), where we will use the A55 to load the M33 firmware. This will require changes on Linux device tree, ATF and M33 linker file. Requirements: Ubuntu 20.04 or later host PC i.MX93 QSB UUU Tool ARM GNU Toolchain (arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu) SDK package (SDK_25_09_00_MCIMX93-QSB) Prebuild Linux Image (LF_v6.12.34-2.1.0_images_IMX93EVK) ### Clone imx-mkimage, it is better to download the same version of the sw we are working with ### $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.12.34-2.1.0 ### Decompress the GNU toolchain into a path in local disk, in this test 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.12.34-2.1.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 ELE firmware ### $ cd .. $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.3-286c884.bin $ chmod +x firmware-ele-imx-2.0.3-286c884.bin $ ./firmware-ele-imx-2.0.3-286c884.bin --auto-accept ### Optional if using i.MX FW ### $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.29-8741a3b.bin $ chmod +x firmware-imx-8.29-8741a3b.bin $ ./firmware-imx-8.29-8741a3b.bin --auto-accept ### Clone ATF ### $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.12.34-2.1.0 $ cd imx-atf ### Modify ATF for the M33 to be able to access DDR ###   --- a/plat/imx/imx93/trdc_config.h +++ b/plat/imx/imx93/trdc_config.h struct trdc_mrc_config trdc_n_mrc[] = { { 0, 0, 0, 0x80000000, 0x80000000, 0, false }, /* MRC0 DRAM for S400 DID0 */ { 0, 1, 0, 0x80000000, 0x80000000, 0, false }, /* MRC0 DRAM for MTR DID1 */ - { 0, 2, 0, 0x80000000, 0x80000000, 0, true }, /* MRC0 DRAM for M33 DID2 */ + { 0, 2, 0, 0x80000000, 0x80000000, 1, true }, /* MRC0 DRAM for M33 DID2 */ { 0, 3, 0, 0x80000000, 0x80000000, 1, false }, /* MRC0 DRAM for A55 DID3 */ { 0, 5, 0, 0x80000000, 0x80000000, 0, false }, /* MRC0 DRAM for USDHC1 DID5 */ { 0, 6, 0, 0x80000000, 0x80000000, 0, false }, /* MRC0 DRAM for USDHC2 DID6 */ ### Build modified 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- ### Modify linker file and build M33 code, in this example we are using hello world SDK example ### $ cd .. $ tar -xvzf SDK_25_09_00_MCIMX93-QSB.tar.gz $ cd SDK_25_09_00_MCIMX93-QSB/boards/mcimx93qsb/demo_apps/hello_world/armgcc --- a/boards/mcimx93autoevk/demo_apps/hello_world/armgcc/MIMX9352_cm33_ram.ld +++ b/boards/mcimx93autoevk/demo_apps/hello_world/armgcc/MIMX9352_cm33_ram.ld m_a55_suspend_ram (RW) : ORIGIN = 0x20002000, LENGTH = 0x00001000 m_data (RW) : ORIGIN = 0x20003000, LENGTH = 0x0001B000 m_rsc_tbl (RW) : ORIGIN = 0x2001E000, LENGTH = 0x00001000 + m_text_dram (RW) : ORIGIN = 0x8F000000, LENGTH = 0x00001000 + m_data_dram (RW) : ORIGIN = 0x8F001000, LENGTH = 0x00001000 } /* Define output sections */ . = ALIGN(4); } > m_text + .dram_text : + { + . = ALIGN(32); + *(.myDRAM) + . = ALIGN(32); + } > m_text_dram + .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) .ARM.attributes 0 : { *(.ARM.attributes) } ASSERT(__StackLimit >= __HeapLimit, "region m_data overflowed with stack and heap") + + .dram_data : + { + . = ALIGN(32); + *(.myDRAM_data) + . = ALIGN(32); + } > m_data_dram } a/boards/mcimx93autoevk/demo_apps/hello_world/hello_world.c +++ b/boards/mcimx93autoevk/demo_apps/hello_world/hello_world.c * Definitions ******************************************************************************/ +#define _RET_IP_ (unsigned long)__builtin_return_address(0) +#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; }) /******************************************************************************* * Prototypes /******************************************************************************* * Variables ******************************************************************************/ - +const char myString[] __attribute__((section(".myDRAM_data"))) = "Hello, World!"; /******************************************************************************* * Code ******************************************************************************/ +__attribute__ ((section(".myDRAM"))) +void Dram_test(void) { + PRINTF("Dram_test!!\r\n"); + + PRINTF("%s!!\r\n", myString); + + PRINTF("function %p\n",_THIS_IP_); +} + /*! * @brief Main function */ BOARD_BootClockRUN(); BOARD_InitDebugConsole(); - PRINTF("hello world.\r\n"); + PRINTF("hello world from DRAM.\r\n"); while (1) { ch = GETCHAR(); PUTCHAR(ch); + if(ch == 'a'){ + Dram_test(); + } } } $ 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 ### Copy i.MX firmware ### $ cd .. $ cp firmware-imx-8.29-8741a3b/firmware/ddr/synopsys/lpddr4_dmem_* ~/imx-mkimage/iMX93 $ cp firmware-imx-8.29-8741a3b/firmware/ddr/synopsys/lpddr4_imem_* ~/imx-mkimage/iMX93 $ cpfirmware-ele-imx-2.0.3-286c884/mx93a1-ahab-container.img ~/imx-mkimage/iMX93 ### Build the flash.bin using mkimage $ cd imx-mkimage $ make SOC=iMX93 flash_singleboot ### Clone, modify and build device tree for Linux to be able to use RPROC to load M33 Firmware ### $ git clone https://github.com/nxp-imx/linux-imx -b lf-6.12.34-2.1.0 --- a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts +++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts no-map; }; + dram: dram@20480000 { + reg = <0 0x8f000000 0 0x20000>; + no-map; + }; + rsc_table: rsc-table@2021e000 { reg = <0 0x2021e000 0 0x1000>; no-map; <&mu1 1 1>, <&mu1 3 1>; - memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, + memory-region = <&dram>, <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>; fsl,startup-delay-ms = <500>; status = "okay"; $ export ARCH=arm64 $ export CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- $ make imx_v8_defconfig $ make freescale/imx93-9x9-qsb.dtb Set SW for serial download on the QSB (0001), connect debug, download and power cables and turn on the QSB, for this test we will flash the demo image and just replace Linux device tree, flash.bin and M33 firmware into the QSB board. $ uuu -b sd_all flash.bin imx-image-full-imx93evk.wic Once it is done change SW to the respective bootmedia SD boot (0011) and boot the board and stop at uboot, to enter fastboot mode to load modified device tree and M33 firmware > fastboot 1 After this just run UUU tool on the host computer and fatload the files $ uuu -b fat_write imx93-9x9-qsb.dtb mmc 1:1 $ uuu -b fat_write hello_world.elf mmc 1:1 When the tool finish, stop fastboot mode by typing CTRL+C and then boot into Linux > boot Login with default password "root" and run the following commands to load M33 firmware $ root $ modprobe imx_rpmsg_tty $ cp /run/media/boot-mmcblk1p1/hello_world.elf /lib/firmware/ $ echo hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware $ echo start >/sys/class/remoteproc/remoteproc0/state M33_DDR.png   Once done we can verify that the M33 firmware is running on DDR hello_world.png Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.

Legacy Interrupts in PCI have become a thing of the past in the PCI world, now that we have more efficient MSI interrupts in PCI Express, being used extensively across applications. However they are still used primarily for backward compatibility and boot-up support. Legacy Interrupts[INTx] used to be physical signals in PCI, however PCIe devices do not have physical INTx pins. So to support these legacy interrupts, PCIe emulates them logically. Almost like a virtual INTx mechanism. We shall see how these interrupts are realized in PCI Express, in such a way that developers/enthusiasts can get a hands-on following this guide. This blog has the following agendas:- 1. Why do we need to care about Legacy INTx style interrupts in PCIe? 2. System Overview 3. How are INTx legacy interrupts realized in PCIe? 4. Enabling and testing INTx emulation on iMX8MM

This article describes how to enable the GPIO support in SPL for i.MX 93 and how to use the associated library. Available GPIO banks Bank Registers' Base Address GPIO1 0x47400000 GPIO2 0x43810000 GPIO3 0x43820000 GPIO4 0x43830000   Software Tests performed using the LF6.12.20-2.0.0 BSP, but should work similarly in other versions.   Enable the GPIO support in SPL Enable the CONFIG_SPL_GPIO through menuconfig. Configure the GPIO pin Make sure the chosen GPIO pin is not used by any other peripheral, by checking U-Boot's device tree (example: imx93-11x11-evk.dts and its included files). If used, disable the conflicting peripheral in the device tree. To identify the exact macro associated to the GPIO functionality, please check the arch/arm/dts/imx93-pinfunc.h file.  Example 1: Use an available GPIO pin (e.g. GPIO2_IO05) This pin is not used by other peripheral, so there is nothing to disable.  To use the pin with the GPIO functionality, the following pin muxing must be added in the iomux node of the imx93-11x11-evk.dts file (located in dts/upstream/src/arm64/freescale/😞 😞 pinctrl_hog: hoggrp { fsl,pins = < MX93_PAD_GPIO_IO05__GPIO2_IO05 0x51e >; }; Note: 0x51e represents the value you want in the PAD register (SW_PAD_CTL_PAD_GPIO_IO05). You may configure it as you want.  Example 2: Use the XSPI1_TXC pin as GPIO (GPIO1_IO12) In our BSP, by default, this pin is used by the SAI1 peripheral. To use this pin as GPIO, SAI1 must be disabled in device tree. &sai1 { status = "disabled"; }; To use the XSPI1_TXC pin with the GPIO functionality, the following pin muxing must be added in the iomux node of the imx93-11x11-evk.dts file (located in dts/upstream/src/arm64/freescale/😞😞 pinctrl_hog: hoggrp { fsl,pins = < MX93_PAD_SAI1_TXC__GPIO1_IO12 0x51e >; }; Include the correct header files In the file you want to use the GPIO, include the following headers: #include <asm/arch-mx7ulp/gpio.h> #include <asm-generic/gpio.h> Define the GPIO To define the GPIO's handle, use the IMX_GPIO_NR(bank, index) macro. index = The pin number within the bank. bank = The GPIO bank number, mapped as follows (due to the way they are placed in memory): GPIO Bank bank value for IMX_GPIO_NR GPIO1 4 GPIO2 1 GPIO3 2 GPIO4 3 Example 1: Compute the handle for GPIO2_IO05 #define TIMED_GPIO IMX_GPIO_NR(1, 5) Example 2: Compute the handle for XSPI1_TXC (GPIO1_IO12) #define TIMED_GPIO IMX_GPIO_NR(4, 12)   Read the GPIO pin gpio_request(TIMED_GPIO, "timed_gpio"); gpio_direction_input(TIMED_GPIO); int val = gpio_get_value(TIMED_GPIO); printf("GPIO value is %d\n", val);   Write the GPIO pin gpio_request(TIMED_GPIO, "timed_gpio"); // set the pin as output and make it high gpio_direction_output(TIMED_GPIO, 1);   The driver used is drivers/gpio/gpio-uclass.c.

This slides firstly introduce the xSPI NOR devices related industry standards:JESD251 and JESD216, and i.MX95 FlexSPI controller. Based on these background knowledge, how to configure the FlexSPI Configuration Block(FCB) for FlexSPI boot in i.MX95 is introduced as well. Finally, some examples in Uboot to deal with the FCB are list.

Running Zephyr on i.MX9 A55 core brings a high performance, real-time (short interrupt, scheduler latency, etc.) OS experiences as well as the fast boot, small memory footprint features. This article provide all the information on how to run the Zephyr v4.1 on Cortex-A55 cores to support below features: Supported Features FRDM-IMX93 FRDM-IMX91 Description Zephyr RTOS code base     Based on Zephyr v4.1 FRDM-IMX93 board configure Yes   Board configuration, build, device tree files FRDM-IMX91 board configure   Yes Board configuration, build, device tree files Hello world Yes Yes   Dual Ethernet Yes   TY8521 Ethernet PHY support Display Yes   LCDIF, MIPI DSI, Waveshare 1024x600 7inch DSI LCD(C) Camera Yes   MIPI-CSI, ISI, AP1302 sensor Audio Yes   I2S with eDMA (Driver only) uSDHC Yes   SD card only USB Yes   USB CDC device class   The code has been release on github: Zephyr samples/drivers: https://github.com/nxp-zephyr/zephyr Zephyr HAL: https://github.com/nxp-zephyr/hal_nxp Tag: FRDM-IMX93-v4.1 How to doc is attached.  

share the document for ov5640 support on imx93 evk with 6.12 bsp

Hello everyone, in this post we will control one (or more) WS2812 LEDs from a Linux UserSpace application, communicating with Cortex M33 through RPMSG.  Required materials: FRDM-IMX93 WS2812 LED/Strip Attached wsled.c (userspace application) Attached ws2812_m33_project (Source code of firmware for M33)   Environment: Linux Kernel 6.6 arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi SDK 24.12.00   This is the block diagram of the application:    Diagrama sin título.drawio.png     CORTEX M33 SIDE.  From WS2812  LED datasheet, we can see the timing must be precise, that is the reason we will use the Cortex M33 (Real time applications):  Manuel_Salas_3-1749596540788.png   As we can see, the timing just accept tolerance of 150ns, that is the reason is preferred to use the Cortex M33 instead of control with Linux that is in charge of other tasks.    The function that we will implement to send Zero and One is:  void WS2812B_send_bit(uint8_t bit) { if (bit) { // Send "1" RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 1); for (int i = 0; i < HIGH_ONE_CYCLES; i++) __asm__("NOP"); RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 0); for (int i = 0; i < LOW_ONE_CYCLES; i++) __asm__("NOP"); } else { // Send "0" RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 1); for (int i = 0; i < HIGH_ZERO_CYCLES; i++) __asm__("NOP"); RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 0); for (int i = 0; i < LOW_ZERO_CYCLES; i++) __asm__("NOP"); } }     Testing and measuring the toggle timing with the RGPIO driver of Cortex M33, we could find the best number of NOP instructions to adjust with the required timing according to datasheet, and the results with core running at 200MHz are:    Parameter  Number of NOP times  HIGH_ONE_CYCLES  22  (T1H: 700 ns)  LOW_ONE_CYCLES  12  (T1L: 600 ns)  LOW_ZERO_CYCLES  20  (T0L: 800 ns)  HIGH_ZERO_CYCLES  6    (T0H: 350 ns)      Zero: Manuel_Salas_4-1749596660278.png Manuel_Salas_5-1749596678175.png   One: Manuel_Salas_6-1749596709146.png Manuel_Salas_7-1749596723057.png   Taking in mind this information, we can start to develop our application. From Cortex M33, we created a little protocol, that will wait for instructions to do.    For example, the expected string to fill the RPMSG buffer is:    Index  Purpose  Example  app_buf[0]  Command ('c' or 't')  'c' = store color in buffer  't' = show colors on LEDs  app_buf[1]  Red component (0–255)  0xFF  app_buf[2]  Green component (0–255)  0x00  app_buf[3]  Blue component (0–255)  0x80  app_buf[4]  LED index (target LED position)  e.g. 0, 1, 2    Commands:    'c'  "Color store"  This command stores the RGB color value into a local buffer, targeting a specific LED (app_buf[4]).  It doesn't update the LED strip immediately, it just prepares the data.  Example of RPMSG received buffer from Cortex A (Linux):   app_buf = { 'c', 0xFF, 0x00, 0x00, 2 };  // Store red color for LED 2     't'  "Transfer"  This command sends the full color buffer to the WS2812 strip, updating the LED colors.  The RGB values in the buffer are ignored, it simply triggers an update based on previously stored data.  Example of RPMSG received buffer from Cortex A (Linux):  app_buf = { 't', 0, 0, 0, 0 };  // Transfer the buffered colors to the LED strip     You can modify the code to add your custom commands like change number of LEDs on the strip, or change the GPIO, etc. Currently, the number of WS2812 LEDs supported is defined in software by NUM_RGB_LEDS. As default is 8 LEDs.    I will attach the full code for Cortex M33 firmware, it was tested with arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi and SDK 2_15, SDK 2_16 and SDK 24.    In this example, the EXP_GPIO_IO24 of FRDM-IMX93 was used to control the LED Strip. Connection.png   CORTEX A55 SIDE.  For Cortex A55 (Linux side), we developed an userspace application, that will create the structure for the buffer to send to the Cortex M33 and send through RPMSG using the imx_rpmsg_tty included on the NXP BSP. You can find the userspace application attached.    As we know, the imx_rpmsg_tty creates the tty channel called ttyRPMSG31 under /dev. So, this userspace application communicates directly with the device /dev/ttyRPMSG31 to send the buffer with the required structure for Cortex M33.    EXAMPLE OF USAGE.    STEP 1. Compile firmware for Cortex M33 and store in FRDM-IMX93 under /lib/firmware to use with remoteproc:   STEP 2.  Compile or cross-compile the userspace application (attached.)  To compile on the platform:  root@imx93evk:~# gcc wsled.c -o wsled root@imx93evk:~# ls wsled wsled.c Also, we can copy the wsled under /bin to practicity. root@imx93evk:~# wsled Error: -c <red> <green> <blue> is required. WS2812 Usage: wsled -c <red> <green> <blue> [-n <led_position>] Load the color of exact LED to the buffer wsled -t Shows the colors to the LEDs   STEP 3. To run the entire example: boot the board and load the firmware for cortex M33 with remoteproc: root@imx93evk:~# cd /sys/class/remoteproc/remoteproc0 root@imx93evk:/sys/class/remoteproc/remoteproc0# echo ws2812_m33.elf > firmware root@imx93evk:/sys/class/remoteproc/remoteproc0# echo start > state  Then, we will receive this from Cortex M33 terminal: RPMSG String Communication Channel FreeRTOS RTOS M33 clock is at: 200000000 Hz Nameservice sent, ready for incoming messages from Cortex-A55! WSLED   Load the imx_rpmsg_tty module in Linux to initialize RPMSG: root@imx93evk:~# modprobe imx_rpmsg_tty   Then, we will have the hello world message from Cortex A (Linux side), but with our buffer format in Cortex M33 console: CMD: h [1]:0x65 [2]:0x6c [3]:0x6c [4]: 111 LEN = 12   Finally, we are ready change colors of the LEDs: Load the buffer (LED 1 = RED, LED 2 = Green, LED 3 = Blue). root@imx93evk:~# wsled -c 0x55 0x00 0x00 -n 1 root@imx93evk:~# wsled -c 0x00 0x55 0x00 -n 2 root@imx93evk:~# wsled -c 0x00 0x00 0x55 -n 3   Show colors on LEDs. root@imx93evk:~# wsled -t   Manuel_Salas_8-1749597921154.png  

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. Chavira_0-1747762120431.png   Chavira_1-1747762220719.png   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 Chavira_0-1747763129172.png   Set Jumper and Connect Place a jumper on J4 and connect the MCU-LINK PRO to the host PC via USB. Chavira_1-1747763160702.png   Open LinkServer CLI Launch the LinkServer CLI. If it's not installed, download it from NXP web page. Chavira_2-1747762424078.png   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.   Chavira_2-1747763399333.png   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 Chavira_0-1747764271147.png Chavira_1-1747764385447.png     References: MCU-Link installation   

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 gaurav_sharma_0-1744718613352.png   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'   gaurav_sharma_1-1744718678374.png   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   gaurav_sharma_5-1744718944949.png Select 'PowerView Instance' and click on 'Start'. A window like below will appear: -   gaurav_sharma_6-1744719062494.png 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: -  gaurav_sharma_8-1744719186783.png   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 gaurav_sharma_9-1744719239784.png -- Click on 'Do' button to execute the script till the end. gaurav_sharma_0-1744719677000.png -- Set a breakpoint at start_kernel b.s start_kernel /Onchip   [Optional]Check the breakpoint via 'b.l'   gaurav_sharma_1-1744719798475.png -- Hit 'go' at t32 to let the cores execute the instructions, you will see 'running' state   gaurav_sharma_2-1744719826022.png -- Enter 'reboot' at Linux prompt and stop at Uboot command line prompt you will see trace32 at 'system down' state: - gaurav_sharma_3-1744719897706.png -- 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' gaurav_sharma_4-1744720057810.png   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: -   gaurav_sharma_5-1744720161325.png   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 gaurav_sharma_6-1744720206901.png   -- Apply breakpoints at t32 window b imx_rpmsg_init b imx_drm_bind   [Optionally] you can verify the breakpoints via 'b.l' gaurav_sharma_0-1744781339510.png 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: - gaurav_sharma_1-1744781477140.png   gaurav_sharma_2-1744781531859.png   gaurav_sharma_7-1744720262647.png   Now, to reach the next breakpoint, execute 'go' on the t32 gaurav_sharma_8-1744720292331.png At this point linux kernel execution has reached the function imx_rpmsg_init   Again, to reach the next breakpoint, execute 'go' gaurav_sharma_0-1744720569015.png   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.   gaurav_sharma_1-1744720601236.png   gaurav_sharma_2-1744720619336.png   Feel free to drop in the comments section or DM if you have any queries. Happy debugging!!🙂🙂🙂🙂  

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.  

This guide provides step-by-step instructions for setting up and applying necessary patches to the Linux kernel for the FRDM-IMX93 development board. The process involves cloning the required repositories, applying patches, and preparing the kernel for customization and compilation.   Prerequisites Required Software: A Linux-based operating system (Ubuntu/Debian recommended). Git installed (sudo apt install git). Yocto dependencies: $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 python3-subunit zstd liblz4-tool file locales libacl1 ​   Hardware: FRDM-IMX93 Board Sufficient storage space   1. Downloading the Repository Start by downloading the necessary tools and repository. If the ~/bin folder does not already exist, create it: $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH   2. Compile the Yocto SDK: $: mkdir Yocto_SDK $: cd Yocto_SDK $: 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 $: MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland $: bitbake imx-image-full -c populate_sdk   Run the generated .sh file to install the SDK: sudo ./fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93evk-toolchain-6.6-scarthgap.sh   The final .sh file is located in: bld-xwayland/tmp/deploy/sdk/   3. Creating the Working Directory First, create a dedicated directory for the kernel setup and navigate into it: $ mkdir FRDM-IMX93-Kernel $ cd FRDM-IMX93-Kernel   4. Cloning the Kernel patches Retrieve the necessary kernel patches from the NXP repository: $ git clone https://github.com/nxp-imx-support/meta-imx-frdm.git -b lf-6.6.36-2.1.0   5. Cloning the Kernel Repository (linux-imx repository) Clone the kernel source of Yocto SDK that you built earlier: $ git clone https://github.com/nxp-imx/linux-imx.git -b lf-6.6.36-2.1.0 6. Applying Kernel Patches Apply the necessary patches to the kernel: $ cd linux-imx/ $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0001-gpio-pca953x-fix-pca953x_irq_bus_sync_unlock-race.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0002-arm64-dts-add-i.MX93-11x11-FRDM-basic-support.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0003-arm64-dts-add-imx93-11x11-frdm-mt9m114-dts.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0004-Add-DSI-Panel-for-imx93.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0005-Add-CTP-support-for-waveshare-panel.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0006-arm64-dts-add-imx93-11x11-frdm-tianma-wvga-panel-dts.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0007-arm64-dts-add-imx93-11x11-frdm-aud-hat-dts.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0008-arm64-dts-add-button-support.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0009-arm64-dts-add-imx93-11x11-frdm-ov5640-dts.patch $ cd linux-imx/ $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0010-arm64-dts-add-imx93-11x11-frdm-ld.dts-for-lpm.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0011-arm64-dts-add-pwm-function-of-the-LED.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0012-arm64-dts-add-imx93-11x11-frdm-8mic.dts.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0013-arm64-dts-add-imx93-11x11-frdm-lpuart.dts.patch   7. Customizing the Device Tree Device trees can be modified or created based on your hardware setup.   Device Tree Locations: arch/arm64/boot/dts/freescale/   If you create a new device tree, add it to the respective Makefile: arch/arm64/boot/dts/freescale/Makefile   8. Setting Up the Cross-Compilation Environment To prepare for kernel compilation, source the environment setup script. Assuming the Yocto SDK is installed in /opt, run:   EXAMPLE: $ source /opt/fsl-imx-xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux   9. Configuring the Kernel Make configuration adjustments as needed in the file: arch/arm64/configs/imx_v8_defconfig Use the appropriate configuration command: $: make imx_v8_defconfig   10. Compiling Device Trees Only To compile only the device tree files, run: $: make dtbs   11. Compiling the Kernel Finally, compile the kernel image using: $ make -j $(nproc)   The resulting kernel image will be located in: arch/arm64/boot/   References: IMX YOCTO PROJECT USERS GUIDE IMX LINUX USERS GUIDE  IMX REFERENCE MANUAL 

We are pleased to announce that Config Tools for i.MX v24.12 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...) • DDR tool – Support for the custom System Manager image import is added. – i.MX 95 advanced tests are enabled: Vref for DQ and Vref for CA optimization • SerDes tool – Additional parameters for TX configuration on GUI (swing, margin, equalization) for i.MX 95 are added. – PCIe Gen1/Gen2/Gen3 switch on pattern generation. • Clocks – Modular clocks initialization is supported. – Initialization mode is visible in the Clocks diagram and Details view. – New Modular Initialization view for configuration of the initialization mode and core selection of the module is created. • TEE – Configuration and overview of areas with the same address and different address space is supported. – Code generation can be toogled for global options groups. – The process for releasing ELE crypto before setting up TRDC is supported. • Pins – Miscellaneous tab for various Pins configuration options is added. – Filtering for routing dialogs is added.

Config Tool Introduction and Use From i.MX93 using the Config Tool for the DDR configure. The Config Tools for i.MX is a suite of evaluation and configuration tools that help users from initial evaluation to production software development. Config Tools for i.MX is an easy-to-use way to configure the pins and DDR of the i.MX processor devices. The software, in general, enables you to create, inspect, change, and modify any aspect of the pin configuration and muxing of the device. It also allows you to configure and validate DDR settings. 1 Download and install The link in website: https://www.nxp.com/design/design-center/software/i-mx-developer-resources:IMXSW_HOME Rita_Wang_0-1730443182963.png   The Config Tools for i.MX is installed as a desktop tool which then loads additional device information through a network connection, but does otherwise not need internet connection. It does not require a project setup, as all the settings are stored in text and generated source files, which then can be easily stored in a version control system or exchanged with other users. Config Tool function For the Config Tool have two function, one is the Pins tool another is the DDR tool functions. 1.1 Pins tool The Pins Tool makes pin configuration easier and faster with an intuitive and easy user interface, which then generates normal C code that can then be used in any C and C++ application. The Pins Tool configures pin signals from multiplexing (muxing) to the electrical properties of pins, and it also creates Device Tree Snippets Include (.dtsi) files and reports in CSV format. Pins Tool Configuration of pin routing/muxing Managing different functions used for routing initialization Configuration of pin functional/electrical properties Generation of code for routing and functional/electrical properties 1.2 DDR Tool   The DDR tool provides two main functionalities: configuration and validation. The DDR configuration provides a user-friendly graphical interface to configure the DDR controller and the DDR PHY. It can be used for tweaking some of the configuration parameters when you want to use different memory modules than the ones received with the board or when you want to optimize the configuration. DDR validation provides different scenarios to verify the DDR performance, by downloading a test image to the processor’s internal RAM through a USB connection. The result is sent to the DDR tool via the UART. DDR validation can help verify DDR stability on the board in a non-OS environment.   DDR Tool The DDR tool is designed for: Configuration of DDR controllers Validation of DDR configuration Support for i.MX 8M and i.MX93 families Configuration: Simplified UI for device configuration Advanced board configuration options Stressing: Stress tests with overnight option Optimization: Sweep ODT configuration and optimization of Vref for DQ and CA Virtual Timing Signal Analysis (vTSA) support: RX and TX data eye, CA BUS signals margin and CA Eye test for LPDDR4 DRAM Generation of C code for U-boot SPL driver The DDR tool allows you to view and configure basic DDR attributes, such as memory type, frequency, number of channels and others and test the DDR configuration by a variety of tests. After you have specified the connection type, you can choose scenarios, tests to run in these scenarios, and view the test results, logs, and summary.         2 Install Download Config_Tools_for_i.MX_v16_x64.exe Rita_Wang_1-1730443182973.png   Note: In our company PC we need to apply the Admin Manage: Rita_Wang_2-1730443182978.png   Config Tools for i.MX is available offline (local)  Minimum system requirements One of the following graphical operating systems: – Microsoft Windows 10 (64-bit) – Ubuntu 22.04 LTS Note: Linux-hosted variants of tools are distributed on Linux as 64-bit binaries, which may not work on 32-bit systems. – Supported desktop environments: GNOME – Mac OS X (12.x) 4 GB RAM Display with resolution 1024 x 768 Internet connection for dynamic download from processor database Note: If the MacOS is set to Traditional Chinese, Config Tools for i.MX starts in English and not Chinese. This is intended. 2 The use of the Config tool Configuration of DDR controllers 2.1 Creating a new configuration create a configuration from the Start development wizard or by selecting File > New from the Menubar. If you start creating your development for any NXP board or kit, we recommended you start with example to create a configuration for a board or a kit. Such configuration contains board-specific settings. If you select a processor, the configuration will be empty. 2.2 Run the Config tool Open the Config tool, choose the Creating a new standalone configuration for a processor, board, or kit Rita_Wang_3-1730443182999.png   Choose the Processor Rita_Wang_4-1730443183009.png   Choose the i.MX93 part number product Rita_Wang_5-1730443183037.png   Rita_Wang_6-1730443183081.png   Choose DDR Under the tool select the tools---->DDR Three sections need to mentioned: Make DDR configure right and make the DDR is enabled already. Rita_Wang_7-1730443183147.png   Two sections are very important the same as the tool we supply before in the old product: DDR paramaters configuration DDR stress test(Validation) Rita_Wang_8-1730443183169.png   DDR parameters configuration: Rita_Wang_9-1730443183211.png   This is the UART Port configure, for the i.MX93 EVK Board default use the UART1 for A55 core debug, if in customer’s design use others port can choose here and also need modify the register settings manually.   Rita_Wang_10-1730443183218.png   Rita_Wang_11-1730443183239.png   Advanced parameters config, it is very important: Rita_Wang_12-1730443183354.png   General advice The I2C connection between MX and PMIC should be consistent with the development board, using the same pad. If choose different , Need to modify I2C Rita_Wang_13-1730443183365.png     Validation of DDR configuration In the previous DDR stress test tool, only two functions were provided: DDR calibration and stress test. In the new Config tool, more testing items are provided for customers to debug DDR, totaling four items. Rita_Wang_14-1730443183388.png   When finished the DDR configuration then go to do the validation.     Test DDR initialization script, Perform basic read and write operations Rita_Wang_15-1730443183433.png   If pass the test, it will be OK. If failed, we need to fail shooting for it. According to the log output information, check boot mode/UART/USB, etc If the test fails, first check the boot mode configuration and UART/USB interface. The previous DDR stress test tool would output statements such as "Please set in serial download mode" or "Please connect UART port", which are obvious. The current Config tool outputs all log information of the code, with a lot of content and no erroneous conclusions. We need to carefully review the log output to identify where the problem lies. Test on the i.MX93 EVK Board, if the boot mode not right and the USB is not connected, when do the test there will be the ERROR Messages in the logs: Rita_Wang_16-1730443183461.png   Test on the i.MX93 EVK Board, if not with proper UART port, the ERROR Messages in the logs: Rita_Wang_17-1730443183487.png   Optimization test This requires detailed ODT, driver strength testing, and scanning of all DQ IO configuration options, Test whether each configuration is passed or failed. Finally, output the mapping between the read/write drive strength and ODT output. For the test result when reading, the impedance of DRAM driven strength and PHY ODT cannot be set too big, (Green - pass, Orange - fail) Rita_Wang_18-1730443183502.png   When determining the optimal ODT/driver strength value for the customer's board, this mapping diagram can be used as a reference, but it cannot be the sole basis for making this decision. If the customer fully references the NXP development board for design, they can first use the default configuration of the development board for testing. Then fine tune it.     VTSA (Virtual Timing Signal Analysis) Generate write and read data eye diagrams by running a series of write/read operations. (Different from using a high-speed oscilloscope for manual physical TSA (pTSA) measurement). Use the DDR controller itself to test margin by writing margin (Diag Write Margin)/diagnosing read margin (Diag Draw a virtual data eye diagram for each DQ channel during the Read Margin test. This tool differs from the actual eye diagram results and is for reference only.   Rita_Wang_19-1730443183529.png   DDR Stress Test The last step, stress test, customer can choose long time test: Rita_Wang_20-1730443183576.png     Code generate In the right side we can see the lpddr4_timing.c generate, using for the uboot. For this tool, the code can be automatically generated and automatically generated code when the registers change, and do not need to run the test on the board, this is difference with the old tool. Rita_Wang_21-1730443183661.png   3 i.MX93 UBOOT and Kernel DDR configuration 3.1 The DDR configuration in the Uboot (1) Copy the generated lpddr4x_timing.c to uboot path: board/freescale/imx93_evk/lpddr4x_timing.c   Rita_Wang_22-1730443183720.png     (2) DDR Size setting uboot-imx/include/configs/imx93_evk.h The default size is 2GB for the i.MX93 EVK board. Rita_Wang_23-1730443183757.png   For the i.MX93EVK uses 2GB LPDDR4X. If using 1GB/512MB LPDDR4, it is important to note that the size of the DDR is related to the memory map address. Rita_Wang_24-1730443183808.png   According to the Memory map, starting from 0xC000_0000 is 1GB of DRAM space, and starting from 0xA000_0000 is 512MB of DRAM space.               3.2 The DDR configuration align in the Kernel For the 1GB LDDR4/4X device tree modify For the i.MX93 the NPU is accessed through M-core, so a section of DRAM memory is reserved. Regardless of whether NPU is used or not, ethos must be changed here, otherwise starting the kernel may result in errors. Change the address space to within 1GB and appropriately reduce the memory allocation size. arch/arm64/boot/dts/freescale$ vi imx93-11x11-evk.dts Rita_Wang_25-1730443183837.png         Summary: Config tool is NXP's new DDR script generation/stress testing/OMUX allocation tool, which is required for i.MX93. Other i MX chips can also use this tool. The Config tool provides more DDR testing projects, including testing ODT/driver capabilities and outputting mapping maps, generating DDR virtual eye diagrams, etc., making it easy to test DDR conditions from multiple perspectives. It is recommended to use the Config tool to debug ODT/driver capabilities and other parameters, which is also applicable to all i MX chip, as a debugging tool for reference. The theoretical parameters of the actual board should refer to the simulation results of the board or the measured results of DDR signals. Any questions contact us freely.  

This document is about enable iMX93 PWM and PWM led HW:   iMX93 11x11 EVK SW:   lf-6.6.3-1.0.0 PWM: TPM3 CH0, CH2            TPM4 CH2 Note: The i.MX PWM and           PWM led are already            enabled in lf-6.6.3-1.0.0   20241021_170742.jpg

Overview This document explains how to use Pulse Width Modulation (PWM) on the iMX93 EVK Board. Attached to this post is a patch to enable this functionality, which can be integrated into either Yocto or a standalone kernel compilation.   This procedure was tested on iMX93 EVK A0 silicon version with BSP 6.1.22 version, this feature should work on A1 silicon version too but is not tested yet.   Kernel Configuration: To enable PWM support, modify the imx_v8_defconfig  file by adding the following line: CONFIG_PWM=y CONFIG_PWM_ADP5585=y CONFIG_PWM_CROS_EC=m CONFIG_PWM_FSL_FTM=m CONFIG_PWM_IMX27=y CONFIG_PWM_RPCHIP=y CONFIG_PWM_SL28CPLD=m + CONFIG_PWM_IMX_TPM=y​ # Add this line   Device Tree Modifications: You will need to add the following nodes to the device tree to configure the TPM (Timer/Pulse Width Modulation) controller:   + &tpm4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_tpm4>; + status = "okay"; + }; ... + pinctrl_tpm4: tpm4grp { + fsl,pins = < + MX93_PAD_GPIO_IO05__TPM4_CH0 0x19e //EXP_GPIO_IO05 J1001 29 + >; + };​   Compiling and Flashing: After making the above changes, compile the kernel and device tree. Once the compilation is complete, flash the new image and device tree to the iMX93 EVK Board.  PWM Configuration on the Board After flashing, you can configure the PWM settings on the board. Open a terminal and execute the following commands: $ cd /sys/class/pwm/pwmchip1/ $ echo 0 >> export $ echo echo 2000000 >> pwm0/period # Set period to 2,000,000 ns (2 ms) $ echo echo 1000000 >> pwm0/duty_cycle # Set duty cycle to 1,000,000 ns (1 ms) $ echo 1 >> pwm0/enable   Validation To validate the PWM output signal, check pin 29 of connector J1001 on the iMX93 EVK Board. Chavira_0-1729101922003.png Chavira_1-1729101928428.png   Conclusion Following these steps should enable PWM functionality on your iMX93 EVK Board. If you encounter any issues, please refer to the documentation or reach out for assistance. Best Regards! Chavira

The Gui-guilder doesn't provide remote debug function in IDE and we still need use Yocto to build project or copy binary to board rootfs. This knowledge base will provide a solution about how to use VSCode to remote debug LVGL project on i.MX93 EVK board.    Yocto toolchain: L6.6.x GUI GUILDER: v1.8.0   Need to open GUI GUILDER project in VSCode.   1.Scripts in VScode   1.1 build.sh Modify build.sh in <LVGL project>/ports/linux     #!/bin/sh toolchain=$1 if [ -z "$toolchain" ];then toolchain=/opt/fsl-imx-xwayland/6.1-mickledore/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake if [ ! -r $toolchain ];then toolchain=/opt/fsl-imx-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake fi fi toolchain_path=$(echo $toolchain |sed -E 's,^(.*)/sysroots/.*,\1,') toolchain_arch=armv8a-poky-linux if [ ! -r $toolchain -o ! -r "$toolchain_path/environment-setup-$toolchain_arch" ];then echo "ERROR: Yocto Toolchain not installed?" exit 1 fi if [ -n "$BASH_SOURCE" ]; then ROOTDIR="`readlink -f $BASH_SOURCE | xargs dirname`" elif [ -n "$ZSH_NAME" ]; then ROOTDIR="`readlink -f $0 | xargs dirname`" else ROOTDIR="`readlink -f $PWD | xargs dirname`" fi BUILDDIR=$ROOTDIR/../build rm -fr $BUILDDIR mkdir $BUILDDIR . "$toolchain_path/environment-setup-$toolchain_arch" echo "start build..." cd $ROOTDIR/linux/lv_drivers/wayland/ cmake . make cd $BUILDDIR toolchain_path=/opt/fsl-imx-wayland/6.6-scarthgap/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake cmake -G 'Ninja' .. -DCMAKE_TOOLCHAIN_FILE=$toolchain_path -Wno-dev -DLV_CONF_BUILD_DISABLE_EXAMPLES=1 -DLV_CONF_BUILD_DISABLE_DEMOS=1 -DCMAKE_CXX_FLAGS="-ggd3 -O0" -DCMAKE_BUILD_TYPE=Debug ninja if [ -e gui_guider ];then echo "Binary locates at $(readlink -f gui_guider)" ls -lh gui_guider fi # Copy binary to board scp $BUILDDIR/gui_guider [email protected]:/opt     1.2 tasks.json     { "version": "2.0.0", "tasks": [ { "label": "Build", "type": "shell", "command": "./build.sh /opt/fsl-imx-wayland/6.6-scarthgap", "options": { "cwd": "${workspaceFolder}/ports/linux" }, "problemMatcher": [ "$gcc" ], } ] }       1.3 launch.json   miDebuggerServerAddress is board ip address.     { "version": "0.2.0", "configurations": [ { "name": "(gdb) Launch", "preLaunchTask": "Build", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/gui_guider", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}/", "environment": [], "externalConsole": false, "MIMode": "gdb", "logging": { "engineLogging": true, "trace": true, "traceResponse": true }, "debugStdLib":true, "miDebuggerPath":"/usr/bin/gdb-multiarch", //DO NOT USE GDB IN SDK!!!! "miDebuggerServerAddress": "192.168.31.243:12345", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true, "text": "set remotetimeout 100", } ] }] }       2. Launch gdbserver on board     export SHELL=/opt/gui_guider gdbserver 192.168.31.243:12345 /opt/gui_guider       3. Debug in VSCode   Click (gdb)launch, the source code will be compiled. Zhiming_Liu_1-1726018299992.png Then you will see the breakpoint in program. Zhiming_Liu_0-1726018276012.png Enjoy your debug~    

Ftrace is powerful tracing utility embedded in Linux kernel. It provides a very good method for kernel developer to get insights of the kernel behavior. While official kernel doc for ftrace is somehow long and complex, this document provides a quicker and simpler way to get start with ftrace.