i.MX Processors Knowledge Base

Discussions

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

ro.hwui.disable_scissor_opt For Vivante GPU, the scissor should be enabled. The default value is enabled, So, keep the default value. ro.hwui.texture_cache_size ro.hwui.layer_cache_size ro.hwui.r_buffer_cache_size ro.hwui.path_cache_size ro.hwui.drop_shadow_cache_size These parameters depend on display resolution. The default value is calculated according to 720P resolution which near 1024x768 resolution on our platform. ro.hwui.text_small_cache_width ro.hwui.text_small_cache_height ro.hwui.text_large_cache_width ro.hwui.text_large_cache_height These variables depends on screen resolution, density(similar to ppi) and language used. On a larger resolution screen, there might be more characters painted on it. Better to have larger font cache size. On a larger density config, it tends to use larger fonts. If the language has more different characters (symbols), it may need larger texture size to cache the fonts. For example, English may only have 52 characters, but Chinese have more than 10K and each will occupy more memory cache than English character. If cache size is too small, performance may drop because the font renderer will flush existed cache and upload new ones. If cache size is too large, it just wastes memory. It's OK to flush existed cache sometimes. But it's better to have only one (or no) flush for rendering a single screen. The default value is optimum on out platform with 1024x768 display resolution. BTW, texture size limitation on current Vivante GPU are 8192 x 8192.

IMX6 S/DL for consumer has both PXP and IPU. Automotive and Industrial versions doesn't have PXP. As IMX6 also has IPU, the Linux framebuffer driver uses IPU and not PXP. Note : “pxp_v4l2_test.out” from unit_tests was made for processors (i.MX6 SL), that have only PXP and its framebuffer driver applies PXP to accelerate image processing. “pxp_v4l2_test.out” should not be used with i.MX6 S/DL. To test PXP device with i.MX6 S/DL users have to try “pxp_test.out”.

This is simple known-how for how to implement "boot animation" with DRM under i.MX8/X + Linux: Code to refer to: ========================================================================= 1. kmscube: Either open source one or the customized on for i.MX will be OK: https://cgit.freedesktop.org/mesa/kmscube/ https://source.codeaurora.org/external/imx/kmscube-imx/ 2. Android display HAL: KmsDisplay.cpp Known-how: ========================================================================= 1. Only one application can grab the master role of the DRM device. If need to control DRM from two applicaiton simultanously, possible solution: A, Use "controlD" node instead of "card" node in /dev/dri/. This requires L4.14 or before. This device node was removed by two commits in L4.14.x: 8a357d10043c75e980e7fcdb60d2b913491564af 6449b088dd51dd5aa6b38455888bbf538d21f2fc Can be brought back by reverting these two commits in L4.14.98. B, Use framebuffer emulator to emulate a FB device (/dev/fb0). (not recommended due to lack of vsync). 2. Some kernel functions will re-config the DRM device during boot. This will cause display abnormal after user application has configured the DRM device. Better to disable these kernel features: CONFIG_DRM_FBDEV_EMULATION CONFIG_FRAMEBUFFER_CONSOLE 3. Use atomic mode of KMS API instead of legacy mode for any dynamically screen drawing application, such as video, game and etc. Atomic mode will have much better performance compare to legacy mode. The kmscube has sample code for both mode. 4. Better to do commit checking before doing any real commit, especially when doing display during boot. Sometimes some internal component in DRM is not fully ready after card device is present. DRM_MODE_ATOMIC_ALLOW_MODESET 5. If video playback will be used, some points to remind: a, Sample code for direct video decoding (in unit-test): imx-test/test/mxc_v4l2_vpu_test/ b, VPU in i.MX8/X only support tiled NV12 output and it has pixel alignment requirement (128). Need to use CPU or G2D to do un-tile, CSC and cropping. Sample code: <android>/vendor/nxp/fsl_imx_omx/OpenMAXIL/src/component/v4l2_common/G2dProcess.cpp If using G2D under Linux, it will support un-tile directly (through OpenCL internally).

On imx8qm there are two DPUs(display process unit) and one ISI(image subsystem interface), ISI has 5 inputs and two of them are from DPU0 and DPU1. This document demonstrates on how to loopback DPU1 outputs to ISI. Note that only mipi dsi0 of dpu0 and lvds1 of dpu1 can be loopbacked to isi. Platform: imx8qm b0 mek OS: yocto 4.14.78 ga hardware connection: imx8qm lvds1 ====> it6263 cable =====> hdmi display. 1st: isi has 8 pipelines which can be assigned to any of the 5 inputs, this doc takes the 5th pipeline to sink the dpu1 input. So you will need to configure the isi_4( start from 0) source in the dts and write a simple v4l2 subdev for capture testing, the default isi_4 device will be /dev/video4. 2st: configure both framegen0 of dpu1 and lvds1's link to pixellink 3. 3st: write a v4l2 userspace program to capture from /dev/video4 device, take this vulkan-capture as an example. Note that Vulkan-capture is rendered by vulkan api, you can also take opengl es for rendering. See the atttachments for details. ======================================== 2019/11/12 update patches. ======================================== 2019/12/19 add patch. Support connect real display to DC1-LVDS1 Note: for ISI loopback, it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4] For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4]

In some cases, due to the limited resources allocated by imx pins, gpio has to be used as mdio/mdc. This article is a simple guide on how to use MDIO on GPIOs. The demo code is for network fec interface. 1. Add CONFIG_MDIO_GPIO=y and rebuild kernel 2. Modify fec device tree to use MDIO ON GPIO FEC test result: root@imx93evk:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 2 Transceiver: external MDI-X: Unknown Supports Wake-on: g Wake-on: d Link detected: yes root@imx93evk:~# ifconfig eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500 inet 10.192.246.129 netmask 255.255.255.0 broadcast 10.192.246.255 inet6 fe80::885a:aeff:fea3:7dcf prefixlen 64 scopeid 0x20<link> ether 8a:5a:ae:a3:7d:cf txqueuelen 1000 (Ethernet) RX packets 13 bytes 2294 (2.2 KiB) RX errors 0 dropped 3 overruns 0 frame 0 TX packets 25 bytes 4691 (4.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC> mtu 1500 ether a2:5e:45:17:72:79 txqueuelen 1000 eQOS test result imx93evk login: root root@imx93evk:~# ifconfig eth0: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC> mtu 1500 ether 00:04:9f:08:7f:d0 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500 inet 10.192.246.112 netmask 255.255.255.0 broadcast 10.192.246.255 inet6 fe80::204:9fff:fe08:7fcf prefixlen 64 scopeid 0x20<link> ether 00:04:9f:08:7f:cf txqueuelen 1000 (Ethernet) RX packets 12 bytes 3020 (2.9 KiB) RX errors 0 dropped 3 overruns 0 frame 0 TX packets 31 bytes 5355 (5.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 104 root@imx93evk:~# ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 1 Transceiver: external MDI-X: Unknown Supports Wake-on: ug Wake-on: d Current message level: 0x0000003f (63) drv probe l

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 Once done we can verify that the M33 firmware is running on DDR Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.

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!!🙂🙂🙂🙂

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

ERR005723 PCIe: PCIe does not support L2 Power Down Description: When PCIe works as Root Complex, it can exit L2 mode only through reset. Since PCIe doesn't have a dedicated reset control bit, it cannot exit L2 mode. Projected Impact: PCIe does not support L2 Power Down Workarounds: The PCIe can be put in PDDQ mode to save on PCIe PHY power and wakeup only by the OOB (Out of Band) wakeup signal (since wakeup by a beacon from link partner is not supported) driven from the link partner (End Point). This signal could be used as a GPIO interrupt to exit this mode. The limitation of this workaround is that the link partner cannot be put into L2. Proposed Solution: No fix scheduled Linux BSP Status: No software workaround available SW workaround used to fix ERR005723 in Linux BSP Why the original workarounds can’t be implemented in Linux BSP * PCIe controller doesn’t have the reset mechanism that can be used when re-insmod the PCIe driver without power down/up PCIe module. * During the PCie driver rmmod/insmod operations, the PCIe CLKs would be turned off/on. IC can’t guarantee that the PCIe PHY can work well and re-establish the PCIe link properly. One SIMPLE SW workaround for this errata imx: pcie: toggle bit18 of grp1 fix pcie can't exit L2 issue. Set bit18 of gpr1 before enter into supend, and clean it after resume, can fix the following errata. Errata ERR005723_PCIe PCIe does not support L2 Power Down. About the details, please refer to the attached patch. "0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch" The conception of the other SW workaround (System warm-reset) The procedures of the original suspend/resume. Suspend User suspend command echo mem > /sys/power/state All driver call suspend function SRPG, ARM save all state to memory Enter Stop mode and Power down ARM Resume: GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Recovery ARM status from memory Call all devices resume function. Because PCIe only reset by system reset, we need change above follow. Resume: GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Warm Reset system, memory context will be kept. But all peripheral status lost. ROM code running Jump to SRPG point again. Recovery ARM status from memory Call all devices resume function. Resume function call init to initialize it. And recover to the status saved before. Impact: Can’t support usb remote wake up, which required 4ms responsive Longer latency, warm reset need some ms. The recovery of the device status needs some more ms. Risk: Current BSP have not tested above follow Device driver have not supported this follow yet. Need additional work to enable \debug\test it. Modules enabled in this workaround now: * UART * ENET * PCIe Tests procedure. HW: one i.MX6Q SD boards, and one INTEL pciex1 1000M CT network card. SW(The images used by me are attached): * Apply the attached patches(kernel and uboot) to the kernel/uboot source codes, re-build, get the images. Kernel is based on imx_3.0.35_4.0 release, uboot , is based on imx_v2009.08 # build out SD/MMC and USB driver to make DRAM hibernate work # build pcie in. *procedure of the suspend/resume tests; # unload ep's driver --> suspend/resume --> reload ep's driver. NOTE: Please make sure that the command line contains “no_console_suspend” The command used to enable the console input wake up after login the consol: echo enabled > /sys/devices/platform/imx-uart.0/tty/ttymxc0/power/wakeup Log when the INTEL CT 1G network card is used: -------------------------------log-------------------------------------------- PM: Syncing filesystems ... done.  start suspend Freezing user space processes ... (elapsed 0.01 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. add wake up source irq 101 add wake up source irq 99 add wake up source irq 103 add wake up source irq 51 add wake up source irq 58 PM: suspend of devices complete after 15.482 msecs PM: late suspend of devices complete after 0.823 msecs Disabling non-boot CPUs ... CPU1: shutdown CPU2: shutdown CPU3: shutdown IMX PCIe imx_pcie_pltfm_suspend entering. IMX PCIe imx_pcie_pltfm_suspend exit.  suspended U-Boot 2009.08-00679-g6ec6783 (May 20 2013 - 14:50:20)  resume CPU: Freescale i.MX6 family TO1.2 at 792 MHz src 0x92eac8 resume 0x92eac8 jump to resume IMX PCIe imx_pcie_pltfm_resume entering. IMX PCIe imx_pcie_pltfm_resume pcie start re-link. IMX PCIe port imx_pcie_pltfm_resume: re-link up. Enabling non-boot CPUs ... CPU1: Booted secondary processor Calibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU1 is up CPU2: Booted secondary processor Calibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU2 is up CPU3: Booted secondary processor Calibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU3 is up PM: early resume of devices complete after 0.974 msecs remove wake up source irq 58 imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) imx-ipuv3 imx-ipuv3.1: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) remove wake up source irq 51 remove wake up source irq 103 remove wake up source irq 101 remove wake up source irq 99 PM: resume of devices complete after 54.174 msecs Restarting tasks ... done. PHY: 1:01 - Link is Up - 100/Full  resume is ok, reload ep’s driver num is 61 e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2 e1000e: Copyright(c) 1999 - 2011 Intel Corporation. e1000e 0000:01:00.0: Disabling ASPM L0s e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI-X interrupts. Falling back to MSI interrupts. e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI interrupts. Falling back to legacy interrupts. e1000e 0000:01:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b e1000e 0000:01:00.0: eth1: Intel(R) PRO/1000 Network Connection e1000e 0000:01:00.0: eth1: MAC: 3, PHY: 8, PBA No: E42641-005 e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: seq=0 ttl=64 time=3.126 ms 64 bytes from 192.168.0.1: seq=1 ttl=64 time=0.244 ms 64 bytes from 192.168.0.1: seq=2 ttl=64 time=0.232 ms 64 bytes from 192.168.0.1: seq=3 ttl=64 time=0.206 ms 64 bytes from 192.168.0.1: seq=4 ttl=64 time=0.222 ms 64 bytes from 192.168.0.1: seq=5 ttl=64 time=0.207 ms 64 bytes from 192.168.0.1: seq=6 ttl=64 time=0.250 ms 64 bytes from 192.168.0.1: seq=7 ttl=64 time=0.209 ms 64 bytes from 192.168.0.1: seq=8 ttl=64 time=0.154 ms 64 bytes from 192.168.0.1: seq=9 ttl=64 time=0.211 ms --- 192.168.0.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.154/0.506/3.126 ms PM: Syncing filesystems ... done.  ep’s functions are ok, re-do the suspend/resume tests Freezing user space processes ... (elapsed 0.01 seconds) done. -------------------------------end-------------------------------------------- Original Attachment has been moved to: 0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch.zip Original Attachment has been moved to: uboot_patch_image.zip Original Attachment has been moved to: kernel_patch_image.zip

OpenCV is a computer vision library originally developed by Intel. It is free for commercial and research use under the open source BSD license. The library is cross-platform. It focuses mainly on real-time image processing; as such, if it finds Intel's Integrated Performance Primitives on the system, it will use these commercial optimized routines to accelerate itself. Application OpenCV's application areas include: * 2D and 3D feature toolkits * Egomotion estimation * Face Recognition * Gesture Recognition * Human-Computer Interface (HCI) * Mobile robotics * Motion Understanding * Object Identification * Segmentation and Recognition * Stereopsis Stereo vision: depth perception from 2 cameras * Structure from motion (SFM) * Motion Tracking To support some of the above areas, OpenCV includes a statistical machine learning library that contains: * Boosting * Decision Trees * Expectation Maximization * k-nearest neighbor algorithm * Naive Bayes classifier * Artificial neural networks * Random forest * Support Vector Machine Installing OpenCV on i.MX 51 EVK Board running Ubuntu Linux Assuming that you already have the Ubuntu Linux running on your board, you can use this wiki page to guide you to get your USB camera running on your system in order to use real time image processing features of this library. In a brand new installation of Ubuntu some libraries is not installed by default, so you need to install them by your own hands (use synaptic to do that), here is the list of these libraries: libgtk2.0-dev libjpeg62-dev zlib1g-dev libpng12-dev libtiff4-dev libjasper-dev libgst-dev libgstreamer0.10-dev If you already have some of those libraries installed, make sure that is the DEV version. After installing those libraries you can download the stable OpenCV version here. Install it following the procedure below: 1 - untar the opencv package tar -xvzf opencv-1.1pre1.tar.gz 2 - change to OpenCV folder cd opencv-1.1.0 3 - configure the installation enabling gstreamer and letting to compile demo apps later ./configure --with-gstreamer --disable-apps You will get the following results: General configuration ================================================ Compiler: g++ CXXFLAGS: DEF_CXXFLAGS: -Wall -fno-rtti -pipe -O3 -fomit-frame-pointer PY_CXXFLAGS: -Wall -pipe -O3 -fomit-frame-pointer OCT_CXXFLAGS: -fno-strict-aliasing -Wall -Wno-uninitialized -pipe -O3 -fomit-frame-pointer Install path: /usr/local HighGUI configuration ================================================ Windowing system -------------- Use Carbon / Mac OS X: no Use gtk+ 2.x: yes Use gthread: yes Image I/O --------------------- Use ImageIO / Mac OS X: no Use libjpeg: yes Use zlib: yes Use libpng: yes Use libtiff: yes Use libjasper: yes Use libIlmImf: no Video I/O --------------------- Use QuickTime / Mac OS X: no Use xine: no Use gstreamer: yes Use ffmpeg: no Use dc1394 & raw1394: no Use v4l: yes Use v4l2: yes Use unicap: no Wrappers for other languages ========================================= SWIG Python no Octave no Additional build settings ============================================ Build demo apps no Now run make ... 4 - Build OpenCV ./make 5 - Install OpenCV ./sudo make install if all steps above were executed properly, now you can compile the sample applications: 1 - change to samples/c directory cd samples/c 2 - change the build_all script mode to +x chmod +x build_all.sh 3 - run the script ./build_all.sh Now you can test. The results below were taken from the Laplacian filter sample processing in real-time images grabbed from an USB camera: Laplacian filter with USB Camera capture device Also, you can see how is it performance on a 3 windowed application performing color conversion and canny edge detection at the same time: http://www.youtube.com/watch?v=w9yQgdABT7c EOF !

Symptoms Bridge mode on EQoS module will not work since Linux Kernel 5.10_2.2.0. Platforms impacted: i.MX8MP/i.MX8DXL/i.MX93 Diagnosis When eqos module(eth1) is added to the bridge using brctl, it will first set eth1 to promiscuous mode and then set the VLAN for this bridge with a filter VID value of 1. Before adding Intel's patch, there is no problem. c89f44ff10fd net: stmmac: Add support for VLAN promiscuous mode However, when Intel's patch sets up the filter, if it finds that the promiscuous mode is turned on, it will turn off the VLAN Tag function. And it adds a judgment on whether promiscuous mode has been turned on in the function of configuring VID. Returns an error if promiscuous mode is found. Because the patch has turned off the VLAN tag function when promiscuous mode is enabled, which conflicts with continuing to configure the VID. Workaround This patch is okay for aarch64 platform to solve this issue. diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c index c25bfecb4a2d..2dc548b54b1c 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c @@ -481,12 +481,6 @@ static int dwmac4_add_hw_vlan_rx_fltr(struct net_device *dev, if (vid > 4095) return -EINVAL; - if (hw->promisc) { - netdev_err(dev, - "Adding VLAN in promisc mode not supported\n"); - return -EPERM; - } - /* Single Rx VLAN Filter */ if (hw->num_vlan == 1) { /* For single VLAN filter, VID 0 means VLAN promiscuous */ @@ -536,12 +530,6 @@ static int dwmac4_del_hw_vlan_rx_fltr(struct net_device *dev, { int i, ret = 0; - if (hw->promisc) { - netdev_err(dev, - "Deleting VLAN in promisc mode not supported\n"); - return -EPERM; - } - /* Single Rx VLAN Filter */ if (hw->num_vlan == 1) { if ((hw->vlan_filter[0] & GMAC_VLAN_TAG_VID) == vid) {

Whenever possible is always better to avoid Virtual Machines when compiling Android as the building process might take several hours to even a day or two depending on the resources available to the Virtual Machine. Sometimes, however, a VM is the only option available and here are some useful considerations when using a VM as a host for Android builds. This document addresses some of the requirements for the Kit-Kat Freescale Android BSP although some may also apply to the general Android releases. It’s recommended to use Ubuntu 12.04 64-bits as Host OS. As for HDD space, which is often a limited resource when using VM, Google states that at least 30GB of disk space in order to build the Android Tree. In practice, however, it’s recommended to allocate at least 100GB to the VM HDD if possible, as additional packages and larger images can quickly deplete disk space. Installing Java (not VM specific) It’s recommended (albeit not mandatory) to uninstall any version of Java other than the recommended for the specific Android release for which we will build. In the case of Kit-Kat this is Java 6. Another option is to just switch the java alternatives to the ones we want to use for Android. There is a document with the exact instructions on how to install the required JKD on the following link. How to install Sun's JDK in Ubuntu for Android build Starting KitKat, however, it’s also necessary to install javap (Java Class File Dissasembler) so please also add these steps when following this document. $ sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk1.6.0_45/bin/javac 1 $ sudo update-alternatives --config javac Memory considerations when using a Virtual Machine Using a Virtual Machine slows down the image building considerably. Besides that memory system is often also an issue. Having insufficient RAM especially on the linking part of the image build may cause a number of issues that are difficult to troubleshoot. In these cases it’s good to take a look at the resource monitor to see if indeed the RAM was depleted. One way to make up for the limited RAM is using a bigger swap. Google recommends at least 16GB of RAM/swap so it’s not uncommon to create a 10GB swap when working in VM, to do this please use the following commands. $ sudo fallocate -l 10g /mnt/10GB.swap $ sudo chmod 600 /mnt/10GB.swap $ sudo mkswap /mnt/10GB.swap $ sudo swapon /mnt/10GB.swap This will helps with the memory requirements but won’t speed up the build process. Building time with VM, as previously stated, will take several hours or even a couple of days depending on computing power.

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

[OUTDATED] Workaround for de-rating i.MX 8QM/QP parts before SCFW 1.16.0 releases

UI performance tuning in hwui hardware render for Lollipop

i.MX 8MM EVK Display Selection Guide

如何在没有UUU的情况下更新eMMC上的Linux内核和dtb

IMX6 S/DL PXP module

Building imx-tests on ubuntu hardfloat rootfs for imx6d/q

Boot animation through DRM in Linux

i.MX8MM RMII TXC OUTPUT

i.MX8QM dpu loopback to isi.

MDIO on GPIOs

i.MX93 Cortex-M33 DDR example

Debug Linux running on i.MX93EVK with Lauterbach TRACE32

Test pstore/ramoops based on Android 13

Hardware Design Checklist for i.MX28

SW workaround used to fix ERR005723 in Linux BSP

i.MX51 EVK Board OpenCV

Workaround for issue: Bridge mode on EQoS module will not work

Android Virtual Machine Host Setup Recommendations

Debugging method of linux kernel

Docker On i.MX6UL With Ubuntu16.04