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

The documentation is to provide steps for single secure boot for BSP Android 14.0.0_2.0.0. More details related to secure boot for Android BSP can be found from IMX ANDROID SECURE BOOT. However, the steps in this document facilitate some helps signing an Android boot image in the aspects of - First, the Android build process for signing the image, and second, the FDT signing process must be performed after the SPL/FIT of the signing process. The second one of which is crucial.   Best regards Harvey

    In i.MX93 EVK, it use RGMII in ethernet connection. Some customer use RMII connection. This article describe RMII HW design and SW config.  It listed four cases in attached.  

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.

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the IMX8MM-EVK board using the MCU-LINK Pro. You’ll install the necessary firmware, compile and flash a binary, and finally, initiate a debug session using MCUXpresso for VS Code. Requirements: IMX8MM-EVK Board MCU-LINK Pro Debug Probe PC Host with MCUXpresso for VS Code installed Install Segger Firmware on MCU-LINK Pro By default, the MCU-LINK Pro does not support i.MX processors. Installing the Segger firmware is essential for proper debugging. Follow the firmware update guide to update your MCU-LINK Pro.   Compile the Binary for the M Core Ensure MCUXpresso for VS Code is properly installed.   Import the iMX8MM-EVK SDK Chavira_0-1755698330924.png   Import "hello world" example Chavira_1-1755698515769.png Ensure that we are compiling a debug binary Chavira_0-1755709077404.png Build Project Chavira_2-1755698624814.png   Flash the Binary using UUU Tool Connect the IMX8MM-EVK Board to your Host PC via USB Chavira_0-1755701104573.jpeg   Enter Fastboot Mode in U-Boot Terminal => fastboot 0   On your Host PC, navigate to the binary location and flash it using the next commands: $ cd <project_location>/armgcc/debug/ $ uuu -b fat_write hello_world.bin mmc X:1 hello_world_debug.bin Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card Chavira_5-1755701729711.png Connect MCU-LINK Pro to the Target Chavira_1-1755701131673.jpeg     IMX8MM-EVK Debug connection: Chavira_2-1755701139996.jpeg   Launch the M Core from U-Boot Terminal Use the following commands in the U-Boot terminal: => fatload mmc X:1 0x48000000 hello_world_debug.bin; cp.b 0x48000000 0x7e0000 0x20000; => bootaux 0x7e0000 Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card Chavira_3-1755701674202.png     Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso: Chavira_0-1755701976656.png   Chavira_1-1755702026549.png    With the MCU-LINK Pro configured, the IMX8MM-EVK, and the binary successfully flashed and executed, you are now ready to debug applications on the M core using MCUXpresso and VS Code. This setup enables a reliable development workflow for i.MX8MM based projects.   References: AN14120.pdf 

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the IMX8MN-EVK board using the MCU-LINK Pro. You’ll install the necessary firmware, compile and flash a binary, and finally, initiate a debug session using MCUXpresso for VS Code. Requirements: IMX8MN-EVK Board MCU-LINK Pro Debug Probe PC Host with MCUXpresso for VS Code installed Install Segger Firmware on MCU-LINK Pro By default, the MCU-LINK Pro does not support i.MX processors. Installing the Segger firmware is essential for proper debugging. Follow the firmware update guide to update your MCU-LINK Pro.   Compile the Binary for the M Core Ensure MCUXpresso for VS Code is properly installed.   Import the iMX8MN-EVK SDK Chavira_0-1755698330924.png   Import "hello world" example Chavira_1-1755698515769.png Ensure that we are compiling a debug binary Chavira_0-1755709033328.png Build Project Chavira_0-1755708251783.png   Flash the Binary using UUU Tool Connect the IMX8MN-EVK Board to your Host PC via USB   Enter Fastboot Mode in U-Boot Terminal => fastboot 0   On your Host PC, navigate to the binary location and flash it using the next commands: $ cd <project_location>/armgcc/debug/ $ uuu -b fat_write hello_world.bin mmc X:1 hello_world_debug.bin Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card Chavira_5-1755701729711.png   Connect MCU-LINK Pro to the Target Chavira_0-1755708638687.jpeg   IMX8MN-EVK Debug connection: Chavira_1-1755708652859.jpeg   Launch the M Core from U-Boot Terminal Use the following commands in the U-Boot terminal: => fatload mmc X:1 0x48000000 hello_world_debug.bin; cp.b 0x48000000 0x7e0000 0x20000; => bootaux 0x7e0000 Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card Chavira_3-1755701674202.png   Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso: Chavira_0-1755708802524.png   Chavira_1-1755702026549.png    With the MCU-LINK Pro configured, the IMX8MN-EVK, and the binary successfully flashed and executed, you are now ready to debug applications on the M core using MCUXpresso and VS Code. This setup enables a reliable development workflow for i.MX8MN based projects.   References: AN14120.pdf 

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the IMX93-EVK board using the MCU-LINK Pro. You’ll install the necessary firmware, compile and flash a binary, and finally, initiate a debug session using MCUXpresso for VS Code. Requirements: IMX93-EVK Board MCU-LINK Pro Debug Probe PC Host with MCUXpresso for VS Code installed Install Segger Firmware on MCU-LINK Pro By default, the MCU-LINK Pro does not support i.MX processors. Installing the Segger firmware is essential for proper debugging. Follow the firmware update guide to update your MCU-LINK Pro.   Compile the Binary for the M Core Ensure MCUXpresso for VS Code is properly installed.   Import the iMX93-EVK SDK Chavira_0-1755621430498.jpeg     Import "hello world" example Chavira_1-1755621430541.jpeg   Ensure that we are compiling a debug binary Chavira_2-1755621430505.jpeg Build Project Chavira_3-1755621430500.jpeg   Flash the Binary using UUU Tool Connect the IMX93-EVK Board to your Host PC via USB Chavira_2-1755697061118.jpeg       Enter Fastboot Mode in U-Boot Terminal => fastboot 0   On your Host PC, navigate to the binary location and flash it using the next commands: $ cd <project_location>/armgcc/debug/ $ uuu -b fat_write sdk20-app.bin mmc X:1 hello_world.bin Note: replace the X with 0 if you are booting from eMMC or 1 if you are booting from SD Card Chavira_4-1755621484546.png     Connect MCU-LINK Pro to the Target   Chavira_8-1755621967816.jpeg   IMX93-EVK Debug connection:   Chavira_1-1755697045386.jpeg     Launch the M Core from U-Boot Terminal Use the following commands in the U-Boot terminal: => fatload mmc X:1 80000000 hello_world.bin; cp.b 0x80000000 0x201e0000 0x10000; => bootaux 0x1ffe0000 0 Note: replace the X with 0 if you are booting from eMMC or 1 if you are booting from SD Card Chavira_5-1755621576326.png     Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso: Chavira_6-1755621576151.png     Chavira_7-1755621576273.png    With the MCU-LINK Pro configured, the IMX93-EVK, and the binary successfully flashed and executed, you are now ready to debug applications on the M core using MCUXpresso and VS Code. This setup enables a reliable development workflow for i.MX93-based projects.   References: AN14120.pdf 

i.MX95 Triple Display Patches for LF-6.6.52-2.2.0 BSP. iMX95 19x19 EVK. qiang_limpu_se_0-1739859470230.png     Patches files: 0001-iMX95-EVK-IT6263-LVDS-to-HDMI-bridge-chip-combine-it.patch Combine IT6263 with simple panel driver, no EDID is needed, 720P and 1080P display mode had been added as two examples.   0002-IT6263-Always-reported-connected-for-force-output.patch Let IT6263 always report cable connected to force output HDMI signals.   0003-iMX95-EVK-add-LVDS-clone-mode-based-on-IT6263.patch LVDS clone mode is supported on two LVDS ports, they output same content and same timing from one DPU display engine (1920*1080@60fps).   0004-iMX95-EVK-add-dual-LVDS-interleaver-mode-based-on-IT.patch LVDS interleave mode is supported on two LVDS ports, they output different content and same timing from one DPU display engine (3840*1080@60fps).   0005-iMX95-EVK-add-triple-display-support.patch Triple display is supported, 1 MIPI DSI + 2 LVDS.  imx95-19x19-evk-triple-display-lvds-clone.dtb: the two LVDS is in clone mode. imx95-19x19-evk-triple-display-lvds-interleaver.dtb: the two LVDS is in interleave mode.   For 1 MIPI DSI + 2 LVDS display clone mode: qiang_limpu_se_0-1739858854733.png For 1 MIPI DSI + 2 LVDS Interleave mode: qiang_limpu_se_2-1739859096402.png     Know issues:  Due to bridge numbers (3) and DPU engine/Pixel link/Pixel Interleaver number (2) is not aligned, during kernel boot up, there will be followed link error log, but there is no real function impact.   [    3.178741] imx95-ldb 4b0c0000.syscon:ldb@4: Failed to create device link (0x180) with 4b010000.syscon:bridge@8 ... [    4.209299] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller [    4.220355] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller ...     2025-8-19 update: Add the patch for L6.12.20_2.0.0 BSP. lf-6.12.20-2.0.0_triple_display_patches.zip  

vpuwraper can fulfill VPU decoder/encoder, if customer’s user case is simple, for example they just need to encode yuv stream to H264, or decode H264 stream to yuv, There is no need to use gstreamer or V4L2 complex framework, you can use vpuwraper. Platform: i.MX8MP + L5.4.70.2.3.0 Build Procedure: mkdir vpu cd vpu git clone https://github.com/nxp-imx/imx-vpuwrap   cd imx-vpuwrap/ git tag -l   git switch -c rel_imx_5.4.70_2.3.0   source ../../.././5.4.70.2.3.0/sdk/environment-setup-aarch64-poky-linux   make -f Makefile_8mp   Test on i.MX8MP EVK board Pls find attached test log for decode and encode If busChromaU in YUV file is null, you will failed to encode it, pls apply vpuwraper patch for L5.4.70.2.3.0.patch to fix it If YUV file is interleave format, you need to add interleave parameter : -interleave 1 ./test_enc_arm_elinux -i test.yuv -o aaa.h264 -f 2 -w 176 -h 96 -interleave 1   Thanks, Lambert

1. MediaPlayer Architecture 1.png   2.png   MediaPlayer is the server, MediaPlayerService and MediaPlayerService :: Client is the client. MediaPlayerService realize the IMediaPlayerService, the main function is to create the right player through the url sent by MediaPlayer::setDataSource MediaPlayerService :: Client realize the IMediaPlayer, the main function is to call the player created by MediaPlayerService to do those specific start, stop, resume, pause…      Entering NuplayerDriver means entering Android MultiMedia Framework.   2. NuPlayer   The playback video is mainly completed through Nuplayer. The figure below includes parser, decoder and render. 3.png   NuPlayer::Source is the parser module. Its interface looks like a combination of MediaExtractor and MediaSource NuPlayer::Decoder connects to CCodec for decoding. CCodec has a state pattern and pass MediaBuffers around with messages. NuPlayer::Render is responsible for rendering audio and also controls when to post video buffers back to NativeWindow for A/V sync. 3. Decoding Framework 3.1 Framework of i.MX8MP, i.MX8MQ and i.MX8MM   Decoding Process between the framework, vendor decoder component and kernel as follows on i.MX8MP, i.MX8MQ and i.MX8MM. 4.png   3.2 Framework of i.MX8QM   Decoding Process between the framework, vendor decoder component and kernel as follows on i.MX8QM. 5.png stream on: start to decode/encode stream off: stop decoding/encoding qbuf:  Queue the v4l2buffer filled in the decoder into the buffer queue created in the vpu driver so that the VPU can obtain it for decoding. dqbuf: When the VPU decoding is completed, the buffer will be dequeueed so that the decoder/codec can continue to be used. 4. Decode Video and Display Process 4.1 i.MX8MM and i.MX8MP   For i.MX8MP and i.MX8MM, G2D is used to composite layers, and the buffer transmission is completed between Decoder and SurfaceFlinger through the BufferQueue mechanism. The process as follows: 6.png  BufferQueue: As the producer of BufferQueue, decoder provides the decoded buffer, and SurfaceFlinger, as the consumer of BufferQueue, composite the decoded video layer.  Display: Use G2D to composite Android layer and video layer on i.MX8MP. SurfaceFlinger will hand over all layers to Display HAL, and then composite them into the framebuffer by G2D. 4.2 i.MX8MQ   For i.MX8MQ, GPU3D is used to composite Android UI, DCSS is used to composite overlay and android UI. And the buffer transmission is completed between Decoder and SurfaceFlinger through the BufferQueue mechanism. The processing is as follows: 7.png BufferQueue: Decoder provides the decoded buffer as producer. SurfaceFlinger as the cosumer of BufferQueue.  Display: Using GPU3D to composite Android UI layers. And video layer will be submitted to DCSS (Display Controller) through Display HAL. DCSS:  Responsible for combining video overlay and Android UI for display. GLESRenderEngine: SurfaceFlinger calls the opengl interface through GLESRenderEngine to complete rendering composite. 4.3 i.MX8QM For i.MX8QM, GPU3D or DPU are used to composite. And the buffer transmission is completed between Decoder Filter Component and SurfaceFlinger through the BufferQueue mechanism. The processing as follows: 8.png Decoder Filter:  Because GPU3D cannot directly composite TILED type layers, it needs to be converted into Linear through Decoder Filter first, and then handed over to SurfaceFlinger. BufferQueue:  Decoder Fillter will receive the outputbuffer from Decoder. And Filter will be as producer of BufferQueue to provide the buffer. SurfaceFlinger will be as consumer of BufferQueue to consume the buffers. GLESRenderEngine: SurfaceFlinger calls the opengl interface through GLESRenderEngine to complete rendering composite. Note:  On i.MX8QM,  Not all situations are composited using the GPU3D. Please refer to the table below.   9.png 4.4 DRM Widevine (Secure Decoder)   Now we have enabled DRM Widevine on i.MX8MP/i.MX8MQ/i.MX8QM so that secure video can be played.  For i.MX8MP, Use OEMCrypto trusted application to decrypt the encrypted stream. And Use RDC/CSU to protected hardware for secure pipeline. The framework is as follows: 10.png   For i.MX8MQ, Use OEMCrypto trusted application to decrypt the encrypted stream. And Use RDC/CSU to protected hardware for secure pipeline. The framework is as follows: 11.png   12.png   OEMCrypto: It is a library as tipc client to send the encrypted data to Trusty OS. OEMCrypto Trusted Application: Used to decrypt the protected data into secure memory and send it to Media Framewrok. Secure Framebuffer: It is allocated from secure heap through libdmabufheap. Secure heap: Used to allocate secure memory.  Resources in domain2 can read and write secure memory, but cannot write normal memory. Resources in domain0 can write to secure memory, but cannot read normal memory. When playing secure video, VPU, GPU2D, and lcdif will be in domain2. Or they are in domain0. Resource Domain Controller (RDC): It provides support for the isolation of destination memory mapped locations such as peripherals and memory to a single core, a bus master, or set of cores and bus masters.  CSU Central Security Unit (CSU) : 1. Peripheral Access Policy - the appropriate bus master privilege and identity are required to access each peripheral. 2. Masters Privilege Policy - the CSU overrides the bus master privilege signals (secure/non-secure).  Configure the VPU so that it can only be accessed by the secure world. For i.MX8QM, also use OEMCrypto trusted application to decrypt the encrypted stream. But related hardware and memory are protected through the secure partition created by SCU. The framework is as follows: 13.png OEMCrypto: It is a library as tipc client to send the encrypted data to Trusty OS. OEMCrypto Trusted Application: Used to decrypt the protected data into secure memory and send it to Media Framewrok. Secure Framebuffer: It is allocated from secure heap through libdmabufheap. Secure heap: Used to allocate secure memory.  Only Secure partition can access secure memory. Frimware Loader: It is a trusted application in Trusty OS, It is responsible for loading the encrypted firmware into the specified memory. Secure Partition: Secure partitions are created using SCU and all hardware that needs to be protected are moved to secure partitions to isolate it from non-secure partitions. 5. Encoding Process 5.1 Encoding Process on i.MX8MP 14.png BufferQueue:  MediaFramework will create Surface and create BufferQueue, SurfaceFlinger will serve as the producer to provide the composite layers, and the Encoder component will encode it as the consumer of the BufferQueue. MPEG4Writer:  Responsible for writing the VPU-encoded data to the output file. 5.2 Encoding Process on i.MX8QM and i.MX8MM 15.png   BufferQueue:  MediaFramework will create Surface and create BufferQueue, SurfaceFlinger will serve as the producer to provide the composite layer, and the Encoder Filter component will be as the consumer of the BufferQueue. MPEG4Writer:  Responsible for writing the VPU-encoded data to the output file. 6. Buffer transfer and management 6.1 Transfer and release process of Input Buffer 16.png Input Buffer allocation: It is allocated in CCodecBufferChannel, and it is used to allocate inputbuffer and recycled. InputManager: Before the queue buffer into the decoder, it will be registered with the InputManager. When the VPU is finished using it, the InputManager will be notified to release it. Use of InputBuffer:  After the buffer is queued into the decoder, the input buffer information will be copied to v4l2buffer so that the VPU can use it. Note: For DRM Secure decoder, the VPU will only use the paddr of inputbuffer. 6.2 Transfer and release process of Output Buffer   17.png   Output Buffer allocation:  When use Surface for output, It is allocated through BufferQueueAllocator that is created in CCodecBufferChannel. It is used to allocate outputBuffer.  Management: When use Surface, OutputBuffer is managed through the BufferQueue mechanism. When the VPU filled the outputBuffer with data that can be displayed, it will notify the Consumer to acquire the buffer. Use of OutputBuffer: In the decoder, the output buffer information will be copied to v4l2buffer so that the VPU can use it. Note:  For situations where OutputSurface is not used, GrallocAllocator is used by default instead of BufferQueueAllocator. 6.3 Buffer Management of Encoder   For screen recording situations, the Encoder's buffer transfer is also managed through the BufferQueue mechanism. After SurfaceFlinger is producer to fill the GraphicBuffer of BufferQueue, the encoder is as consumer to encode the composited data.  

Hello, here Jorge. On this post I will explain how to enable MQS1 on i.MX8ULP. As background about how to setup the environment to build the image using Yocto, please take a look on our i.MX Yocto Project User's Guide: Requirements: i.MX 8ULP EVK. Serial console emulator (Tera Term, Putty, etc.). USB Type-C cable. Micro USB cable. Headphones/speakers. Linux PC. Build done in Linux 6.6.23_2.0.0. i.MX8ULP audio subsystem. i.MX 8ULP extends audio capabilities on i.MX 7ULP by adding dedicated DSP cores for voice trigger and audio processing, enabling lower latency and power efficiency to support variety of audio applications. Some of hardware blocks implemented on 8ULP to support audio use cases are the next: Cadence Fusion F1 DSP processor. Cadence HiFi4 DSP processor. PowerQuad hardware accelerator with fixed and floating + FFT. Digital Microphone interface with support of up-to 8 PDM channels. Up-to 8 independent SAI instances. Up-to 2 Medium Quality Sound (MQS). Sony/Philips Digital interface (SPDIF). JorgeCas_0-1721323039487.png JorgeCas_1-1721323112167.png As is described before, MQS0 and MQS1 are part of real time domain and application domain respectively. I’m going to focus this post on how to enable MQS1 on application domain. Medium Quality Sound (MQS)  This module is basically generates a PWM from PCM audio data. For the major part of typical audio applications will require an external CODEC to deliver the audio quality but, sometimes where the application does not demand this quality, MQS can provide a medium quality audio via GPIO pin that can directly drive the audio output to a speaker or headphone via inexpensive external amplifier/buffer instead of CODEC. The design of the MQS can be described as follows: Input the PCM audio data (from SAI) into a 16-bit register. Up-sample data to match PWM switching frequency. Perform a simple 2nd order Sigma-Delta smooth on the current data versus previous data. Convert the PCM register into a 6-bit PWM width register and output through a GPIO pin. JorgeCas_2-1721323174391.png   How to enable it? By default, our BSP does not enable clock for MQS1. This clock is controlled on CGC1 (AD), specifically on MQS1CLK (Multiplexer to select the audio clock connected to the MQS clock input). So, it is needed to modify imx8ulp-clock.h and clk-imx8ulp.c. Please take a look on patch attached at the end of this post to see the modification in drivers easily. These drivers have the definition/configuration for MQS1_SEL in CGC1 and needs to be added as follows: MQS1_SEL definition needs to be added in imx8ulp-clock.h: #define IMX8ULP_CLK_MQS1_SEL 56 #define IMX8ULP_CLK_CGC1_END 57 MQS1_SEL configuration needs to be added in imx8ulp_clk_cgc1_init of clk-imx8ulp.c: clks[IMX8ULP_CLK_MQS1_SEL] = imx_clk_hw_mux2("mqs1_sel", base + 0x90c, 0, 2, sai45_sels, ARRAY_SIZE(sai45_sels)); Also, it is necessary to configure MQS1 on device tree of i.MX8ULP. Add this in soc: soc@0 of imx8ulp.dtsi: mqs1: mqs@0x29290064 { reg = <0x29290064 0x4>; compatible = "fsl,imx8qm-mqs"; assigned-clocks = <&cgc1 IMX8ULP_CLK_MQS1_SEL>; assigned-clock-parents = <&cgc1 IMX8ULP_CLK_SPLL3_PFD1_DIV1>; clocks = <&cgc1 IMX8ULP_CLK_MQS1_SEL>, <&cgc1 IMX8ULP_CLK_MQS1_SEL>; clock-names = "core", "mclk"; status = "disabled"; }; And create a new device tree, in this case is going to be named imx8ulp-evk-mqs.dts and is as follows: #include "imx8ulp-evk.dts" / { sound-simple-mqs { compatible = "simple-audio-card"; simple-audio-card,name = "imx-simple-mqs"; simple-audio-card,frame-master = <&sndcpu>; simple-audio-card,bitclock-master = <&sndcpu>; simple-audio-card,dai-link@0 { format = "left_j"; sndcpu: cpu { sound-dai = <&sai4>; }; codec { sound-dai = <&mqs1>; }; }; }; }; &cgc1 { assigned-clock-rates = <24576000>; }; &iomuxc1 { pinctrl_mqs1: mqs1grp { fsl,pins = < MX8ULP_PAD_PTF7__MQS1_LEFT 0x43 >; }; }; &mqs1 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_mqs1>; status = "okay"; }; &sai4 { #sound-dai-cells = <0>; assigned-clocks = <&cgc1 IMX8ULP_CLK_SAI4_SEL>; assigned-clock-parents = <&cgc1 IMX8ULP_CLK_SPLL3_PFD1_DIV1>; status = "okay"; }; Let’s apply these changes on our BSP, in my case I’m going to create a new layer in Yocto to add these modifications with a patch that can be found at the end on this post, here the steps: Install essential Yocto Project host packages: $ 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 Install the “repo” utility: $ mkdir ~/bin $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH Set up Git: $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config –list Download the i.MX Yocto Project Community BSP recipe layers and create build folder: $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.23-2.0.0.xml $ repo sync $ DISTRO=fsl-imx-wayland MACHINE=imx8ulp-lpddr4-evk source imx-setup-release.sh -b 8ulp_build Create the new layer: $ cd ~/imx-yocto-bsp/sources $ bibake-layers create-layer meta-mqs $ cd meta-mqs conf/layer.conf should be as follows: BBPATH .= ":${LAYERDIR}" BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "meta-mqs" BBFILE_PATTERN_meta-mqs = "^${LAYERDIR}/" BBFILE_PRIORITY_meta-mqs = "6" LAYERSERIES_COMPAT_meta-mqs = "nanbield" Let’s change the recipe: $ sudo rm -r recipes-example $ mkdir -p recipes-kernel/linux/files 0001-8ULP-MQS-Enable.patch should be copied to ~/imx-yocto-bsp/sources/meta-mqs/recipes-kernel/linux/files Add an append (on this case is called “linux-imx_%.bbappend”)to change the recipe with next content: FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "file:// 0001-8ULP-MQS-Enable.patch " addtask copy_dts after do_unpack before do_prepare_recipe_sysroot do_copy_dts () { if [ -n "${DTS_FILE}" ]; then if [ -f ${DTS_FILE} ]; then echo "do_copy_dts: copying ${DTS_FILE} in ${S}/arch/arm64/boot/dts/freescale" cp ${DTS_FILE} ${S}/arch/arm64/boot/dts/freescale/ fi fi } The next step is add the layer and build the image: $ cd ~/imx-yocto-bsp/8ulp_build $ bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-mqs Confirm that the layer has been added: $ bitbake-layers show-layers Build the image: $ bitbake imx-image-multimedia i.MX8ULP EVK limitations The i.MX8ULP has the next MQS1 pins available: JorgeCas_0-1721922354052.png But, in the EVK board, the mayor part of these pins are used for other functions such as: - Push button: JorgeCas_1-1721922389927.png - MIPI DSI: JorgeCas_3-1721922691116.png  - Etc… So, take the output signal of MQS1 pins of EVK board is difficult, in this article, I’m going to configure PTF7 only (MQS1_left) for practicality. If you are working with this board and you need to use these pins for MQS function you will need to manipulate the traces and take the required signals. If you are designing a custom board, planning is essential to avoid this issue. Flash the board. One the build has been finished, we will have the necessary files to flash the board and test it. If you are not too familiarized with this process I suggest you take a look on this post. First, put the board in serial download mode changing the boot configuration switches on the board: JorgeCas_1-1721930524754.png   JorgeCas_5-1721923817851.png The next step is connecting the power cable, micro-USB cable on the debug port and USB-C type cable to USB0 connector on the board. Then, turn-on the board and run the next command in terminal of build directory: uuu -b emmc_all imx-boot-imx8ulpevk-sd.bin-flash_singleboot_m33 imx-image-multimedia-imx8ulpevk.wic Now, power-off the board, change the boot mode to single boot-eMMC and power it on to test it. Test MQS1 in i.MX8ULP. To test MQS1 it is needed to change the device tree we created, we can do it with the next commands in U-boot: u-boot=> setenv fdtfile imx8ulp-evk-mqs.dtb u-boot=> saveenv u-boot=> boot Now we can test MQS1 on i.MX8ULP EVK, let's confirm that the clock is active in MQS module with the next command: $ cat /sys/kernel/debug/clk/clk_summary -n As you can see mqs1_sel is active and running at 24576000 Hz: JorgeCas_1-1722445068647.png And the card appears if we run the next command: $ aplay -l JorgeCas_2-1722445127837.png To play audio through MQS we can do it as any sound card: $ speaker-test -D sysdefault:CARD=imxsimplemqs -c 2 -f 48000 -F S16_LE -t pink -P 3 JorgeCas_3-1722445194269.png The signal should look like this in the pin output: JorgeCas_1-1722458657552.bmp And like this after a filter, for example the filter used in i.MX93 EVK. JorgeCas_0-1722532245862.png   JorgeCas_2-1722458681492.bmp With this post we have been able check the general operation of MQS, configure and compile the image with the required changes to enable MQS1 on EVK board and measure the output on the board. There is a considerable limitation on EVK board since we cannot test left and right outputs without intervene the base board, but this can be helpful as a reference to who would like to use this audio output on i.MX8ULP processor. Best regards. References. Yocto Project customization guide - NXP Community How to add a new layer and a new recipe in Yocto - NXP Community Flashing Linux BSP using UUU - NXP.  i.MX8ULP reference manual. Embedded Linux Projects Using Yocto Project Cookbook.

Note, the tools described in this page are deprecated and are no longer maintained.  For the latest maintained i.MX 6/7 series DDR tools, the user can find these here: i.MX 6/7 Series DDR Tool Release Hi All, DDR_Stress_Tester is a software application for fine tuning DDR parameters and verifying DDR performance on i.MX6 boards. It performs write leveling, DQS gating, read/write delay calibration on the target board to match the layout of the board and archive the best DDR performance. In addition, the stress test can help the user to verify the DDR performance on their boards.   The following are the features supported: • Support i.MX6Q, i.MX6D, i.MX6DL, iMX6S, i.MX6SL, and i.MX6SX DDR calibration. • Support DDR3 write leveling, DQS gating, Read/Write Delay auto-calibration. • Support LPDDR2 Read/Write Delay auto-calibration. • Support 16 bits, 32 bits, and 64 bits data bus. • Support fixed-mapping 2-channel LPDDR2. • Support DDR stress test between the frequency 135MHz and 672 MHz   If  USB OTG port is not available on customer board, please use the images in DDR_Stress_Tester_V1.0.3_UART1_for_SDboot&JTAG.zip. The bin files in the packages can be loaded by uboot and elf files are used by JTAG load.  Please note when the image is loaded by u-boot, the DDR is initialized by u-boot (reference flash_header.S).   To run ddr stress test from u-boot, CONFIG_SPLASH_SCREEN must be disabled in u-boot. Because when enter self refresh mode in ddr stress test, DRAM access will be blocked. If splash screen in u-boot is enabled, IPU will continuously access DRAM, so the system will hang up. If you have other DMA access in u-boot, it must be disabled.   If customer uses different RX/TX pin for UART, please contact FAE.   UART1 6DQ 6DL 6SL 6SX TX CSI0_DAT10/ALT3 CSI0_DAT10/ALT3 UART1_TXD/ALT0 GPIO1_IO04/ALT0 RX CSI0_DAT11/ALT3 CSI0_DAT11/ALT3 UART1_RXD/ALT0 GPIO1_IO05/ALT0   The commands to run ddr test in i.MX6Q uboot: U-Boot > fatload mmc 2:1 0x907000 ddr-stress-test-mx6dq.bin U-Boot > go 0x907000     For i.MX6Q/6D 4K interleaved LPDDR2, please use version v1.0.3.1. i.MX6 DDR Stress Test Tool V1.0.3.1 for LPDDR2 4K interleaved mode For i.MX6/i.MX7 DDR Stress Test Tool with GUI interface, please use version V2.x: i.MX6/7 DDR Stress Test Tool V2.10   History V1.0.3:  i.MX6SoloX is supported.

What is CMA   The Contiguous Memory Allocator (CMA) is a framework, which allows setting up a machine-specific configuration for physically-contiguous memory management. Memory for devices is then allocated according to that configuration. The main role of the framework is not to allocate memory, but to parse and manage memory configurations, as well as to act as an in-between between device drivers and pluggable allocators. It is thus not tied to any memory allocation method or strategy.  Various devices on embedded systems have no scatter-getter and/or IO map support and as such require contiguous blocks of memory to operate. They include devices such as cameras, hardware video decoders and encoders, etc. Such devices often require big memory buffers (a full HD frame is, for instance, more then 2 mega pixels large, i.e. more than 6 MB of memory), which makes mechanisms such as kmalloc() ineffective. Some embedded devices impose additional requirements on the buffers, e.g. they can operate only on buffers allocated in particular location/memory bank (if system has more than one memory bank) or buffers aligned to a particular memory boundary. Development of embedded devices have seen a big rise recently (especially in the V4L area) and many such drivers include their own memory allocation code. Most of them use bootmem-based methods. CMA framework is an attempt to unify contiguous memory allocation mechanisms and provide a simple API for device drivers, while staying as customisable and modular as possible.   Why use it in default release   Most of the i.MX SoC does not have IOMMU for specific IP who requires larger contiguous memory for operations, like VPU/GPU/ISI/CSI. Or they have IOMMU, but performance is not that good. In the default i.MX BSP, we still allocate physical contiguous memory for those IP drivers for DMA transfers. In arm64 kernel, the DMA allocation API would allocate memory in a various way which depends on the device configurations (in dts or gfp flags). The below table shows how the DMA allocation API (w/o IOMMU enabled device) works to find a proper way for pages (by order, coherent pool -> CMA -> Buddy -> SWIOTLB): Allocator (by order) Configurations (w/o IOMMU) Comments Mapping Coherent Pool device dma is not coherent GFP flag is not allow blocking By __alloc_from_pool() Already mapped on boot when coherent pool init in VMALLOC CMA device CMA or system CMA is present GFP flag is allow blocking: __GFP_DIRECT_RECLAIM set By cma_alloc() map_vm_area, mapped in VMALLOC Buddy No CMA (device or system) or GFP not allow blocking By __get_free_pages(), which can only allocate from the DMA/normal zone (lowmem), 32bits address spaces Already mapped in the lowmem area by kernel on boot SWIOTLB No contiguous pages from buddy or return buffer area region > device dma_mask By map_single() Already mapped on boot when SWIOTLB init   Also a diagram shows how it works (DMA allocation path):     By default, kernel uses CMA as a backend of DMA buffers allocation for most of the cases. That's why i.MX BSP use CMA in the default release for GPU/VPU/CSI/ISI or other buffers for DMA transfers.   CMA Pros & Cons   Pros Well designed for large contiguous memory allocation even under memory fragment condition. Pages in CMA can be shared by buddy system, not a reserved pool Can be device specific CMA area, only used by this device and share to system Easy to configure it's start addr and size on runtime w/o re-compile kernel Cons Allocation process slow when migration pages needed Easy to be corrupted by system memory allocation. Customer may meet cma_alloc failure when system is out of memory, which would cause bad user experiences when foreground application wants graphic buffers for rendering and RVC wants buffers for CAR reverse. Potential dead lock when cma_alloc() need to migrate some pages, which is still flushing to storage (Some customers already met deadlock when one page is under writeback path by FUSE file system, and cma_alloc wants to migrate it). This is the initial motivation to write this documentation.   Why get rid of CMA   Read cons statement above. The key point is to reserve memory for critical path of allocation like GPU graphic buffers and camera/VPU preview/recording buffers to keep a good user experience from allocation failure which would cause black screen, preview stuck, etc. Also avoid potential dead lock when CMA and FUSE work together.   How to get rid of CMA   To get rid of CMA, the basic idea is to cut off the CMA way in the DMA allocation, turn to coherent pool (atomic pool). Please not that coherent pool can only be used by DMA allocation API, it's not shared to system buddy.   1. Enable coherent pool Add “coherent_pool=<size>” in command line, Coherent pool is actually allocate from system default CMA, so CMA size > coherent_pool. There's no reference for this size, as it's various from system to system and use cases to use cases: The biggest consumer of DMA is GPU, it's usage can be monitored by gmem_info tool. Monitor the gmem_info under the typical use cases, and settle down the GPU required memory. Checking for 2nd consumer of DMA: ISI/Camera, depends on the V4l2 reqbuf size and numbers Checking VPU, depends on the multimedia frameworks Plus alsa snd, USB, fec usage The size must be verified by test to make sure system stable.   2. DMA allocation hack Hack to arch/arm64/mm/dma-mapping.c, remove the gfpflags_allow_blocking check in the __dma_alloc() function: diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index 7015d3e..ef30b46 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -147,7 +147,7 @@ static void *__dma_alloc(struct device *dev, size_t size, size = PAGE_ALIGN(size); - if (!coherent && !gfpflags_allow_blocking(flags)) { + if (!coherent) { // && !gfpflags_allow_blocking(flags)) { struct page *page = NULL; void *addr = __alloc_from_pool(size, &page, flags);   3. ION allocator In both Android and Yocto release, ION allocator (android staging driver) is used for VPU buffers. And it default goes into the ION CMA heap. This means ION request for contiguous memory is direct to CMA. To avoid CMA, we can use carveout heap instead of CMA heap in ION:   3.1 Android Enable CARVEOUT heap, disable CMA heap: CONFIG_ION=y CONFIG_ION_SYSTEM_HEAP=y -CONFIG_ION_CMA_HEAP=y +CONFIG_ION_CARVEOUT_HEAP=y +CONFIG_ION_CMA_HEAP=n Adjust the carveout reserved heap base address and size in the dts: / {  reserved-memory {  #address-cells = <2>;  #size-cells = <2>;  ranges;    carveout_region: imx_ion@0 {  compatible = "imx-ion-pool";  reg = <0x0 0xf8000000 0 0x8000000>;  };  }; };   3.2 Linux Kernel - refer to attached patch for i.MX8QM. Almost same as Linux, but ION carveout heap driver need to be patched. Gstreamer - apply below patch to make allocate from carveout: yocto/build-8qm/tmp/work/aarch64-mx8-poky-linux/gstreamer1.0-plugins-base/1.14.4.imx-r0/git: diff --git a/gst-libs/gst/allocators/gstionmemory.c b/gst-libs/gst/allocators/gstionmemory.c index 1218c4a..12e403d 100644 --- a/gst-libs/gst/allocators/gstionmemory.c +++ b/gst-libs/gst/allocators/gstionmemory.c @@ -227,7 +227,8 @@ gst_ion_alloc_alloc (GstAllocator * allocator, gsize size,    }    for (gint i=0; i<heapCnt; i++) { -       if (ihd[i].type == ION_HEAP_TYPE_DMA) { +       if (ihd[i].type == ION_HEAP_TYPE_DMA || +             ihd[i].type == ION_HEAP_TYPE_CARVEOUT) {                heap_mask |= 1 << ihd[i].heap_id;          }    }   References "Aarch64 Linux Kernel memory management" "CMA documentation"

     

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.  

In the IMX8MM SDK unfortunately we cannot find any example about of use a GPIO as an input with interrupt.  To use a GPIO as input with interrupt we need to keep in mind how the GPIO IRQs works in the ARM Cortex M4.   We can find in Table 7-2 (CM4 Interrupt Summary) of IMX8MMRM (IMX8MM Reference Manual) the GPIOs IRQs are divided by two parts:     Combined interrupt indication for GPIOn signal 0 throughout 15  Combined interrupt indication for GPIOn signal 16 throughout 31    This basically means, the pines of GPIOn from 0 to 15 are handled by Combined interrupt indication for GPIOn signal 0 throughout 15 and the pines from 16 to 31 are handled by Combined interrupt indication for GPIOn signal 16 throughout 31.  Alejandro_Salas_0-1706127701440.png   In SDK we can find these definitions in:  <SDK root>/devices/MIMX8MM6/MIMX8MM6_cm4.h (Remember this is for IM8MM SDK)  Alejandro_Salas_1-1706127740049.png   In this example I will use GPIO5_IO12 (ECSPI2_MISO) as Input with IRQ and GPIO5_IO11 (ECSPI_MOSI) as Output of IMX8MM-EVK. I will connect the Output to the Input and will see the behavior of the IRQ in Rising and Falling edge.  Alejandro_Salas_2-1706127787773.png Alejandro_Salas_3-1706127804093.png   For this example I will connect ECSPI2_MOSI (GPIO5_IO11) to ECSPI_MISO (GPIO5_IO12):   Alejandro_Salas_4-1706127830066.png See the below definitions: Alejandro_Salas_5-1706127847121.png   #define IN_GPIO   GPIO5  This define the GPIO base of the IN pin  #define IN_GPIO_PIN  12u  This define the pin number (for in)  #define IN_IRQ  GPIO5_Combined_0_15_IRQn  This define the IRQ number (72 in this case)  #define GPIO_IRQ_HANDLER  GPIO5_Combined_0_15_IRQHandler  This is a "pointer" to function that will handle the interrupt  #define IN_NAME  "IN GPIO5_IO12"  This is only a name or description for the pin    See below definitions:  Alejandro_Salas_6-1706128301737.png   #define OUT_GPIO  GPIO5  This is the GPIO base of OUT pin  #define OUT_GPIO_PIN  11u  This define the pin number (for out)  #define OUT_NAME  "OUT GPIO5_IO11"  This is only a name or description for the pin      Now the below section is the IRQ handler (which was defined before)😞 Alejandro_Salas_8-1706128362819.png   The GPIO_ClearPinsInterruptFlags(IN_GPIO, 1u << IN_GPIO_PIN); refers to GPIOx_ISR register:    Alejandro_Salas_9-1706128379494.png Alejandro_Salas_10-1706128389932.png   For this example, the IRQ Handler will print "IRQ detected ............" in each interrupt.    We will create two different GPIOs config, one for Output and other one for Input with IRQ Falling edge:  Alejandro_Salas_11-1706128421672.png   Then configure the GPIOs and IRQ:   Alejandro_Salas_12-1706128434880.png   EnableIRQ refers to enable the 72 IRQ.   GPIO_PortEnableInterrupts refers to GPIOx_IMR: Alejandro_Salas_13-1706128465396.png Finally, the example put the out GPIO5_IO11 in High state and then in low state many. First the IRQ is configured as Falling edge, then as Rising edge.  Alejandro_Salas_14-1706128482221.png    I will attach the complete source file.    To compile it you can use ARMGCC toolchain directly, but I like to use VSCode with MCUXpresso integration.  Once, when you have your .bin file (in my case igpio_led_output.bin) you can load to board with UUU tool: In your Linux machine: sudo uuu -b fat_write igpio_led_output.bin mmc 2:1 gpio.bin In U-boot board: u-boot=> fastboot 0   Then, when the .bin file was loaded, you can load to the CORTEX M4 in U-boot with: u-boot=> fatload mmc 2:1 ${loadaddr} gpio.bin 7076 bytes read in 14 ms (493.2 KiB/s) u-boot=> cp.b 0x80000000 0x7e0000 0x10000 u-boot=> bootaux 0x7e0000 ## No elf image ar address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD... u-boot=>   NOTE: You can load the binary to cortex m4 with Custom bootscripts for practicity.   Once the binary loaded in M4 core you should see in seria terminal this logs (Remember GPIO5_IO11 and GPIO5_IO12 must be connected to get the same logs):  Alejandro_Salas_15-1706128516905.png   And the logs when you disconnect the GPIO5_IO11 and GPIO5_IO12 in execution time:  Alejandro_Salas_16-1706128531282.png 🔴Disconnection (Red color) 🔵Reconnection (Blue color)   I hope this can helps.     Best regards!    Salas. 

Traditional non-matter devices cannot directly join the matter network. But Matter Bridge solves the problem. Matter bridge can join a Matter network as a Matter device and nonmatter devices need to be mapped to Matter network as a dynamic endpoint. In this way, other Matter devices can communicate with non-matter devices through dynamic endpoints. The Guide is a Matter Zigbee Bridge implement based on i.MX93 + K32W0. gnar_fang_0-1687775855158.png     Feature List • Matter over Ethernet • Matter over Wi-Fi • Register and Remove Zigbee Deivces • Connect Zigbee devices into Matter ecosystem seamlessly • Zigbee Devices • On/Off cluster • Temperature Sensor Cluster • Matter Actions • Start Zigbee Network • Zigbee Network Permit Join • Factory Reset • No limitation if migrating to other i.MX MPU like i.MX6ULL, i.MX8MP • OTBR and Zigbee bridge can be integrated into one single device

Hello! In this post, we’ll cross-compile a kernel module for Linux 6.12.    This can be done either using a standalone kernel or a Yocto-built kernel.    Requirements:  A compiled Linux kernel 6.12.  A board running the same kernel version (Linux 6.12 in this case).  A cross-compiler toolchain.    This process applies to any i.MX processor, including i.MX8, i.MX8M, i.MX8MM, i.MX8MN, i.MX8MP, i.MX93, i.MX91, i.MX95, as well as the i.MX6 and i.MX7 families.    Step 1: Compile the Linux Kernel and get the Toolchain    First, you need to compile the Linux kernel (6.12 in this case).    You can do this in a standalone environment or using Yocto.     If you are using a Standalone environment, please refer to the Chapter 4.5.12 How to build U-Boot and Kernel in standalone environment of i.MX Linux User's Guide.  Also, in that document section, you will see how to obtain the cross-compiler toolchain.    NOTE: To get the toolchain you need use Yocto at least once (for more information please refer to i.MX Yocto Project User's Guide😞  $ DISTRO=fsl-imx-xwayland MACHINE=Target-Machine bitbake core-image-minimal -c populate_sdk   At the end of the building, you can install your toolchain populated under:    yocto-bsp/build/tmp/deploy/sdk     There you will find a file called:    fsl-imx-wayland-glibc-x86_64-imx-image-core-armv8a-your-machine-name-toolchain-6.12-walnascar.sh    Execute with:  $ sudo ./fsl-imx-wayland-glibc-x86_64-imx-image-core-armv8a-your-machine-name-toolchain-6.12-walnascar.sh   If you use the default installation, you will have your toolchain under /opt in your host machine.      (If you will use the compiled kernel from Yocto, you can avoid below step)  Download Standalone Kernel source by cloning with:  $ git clone https://github.com/nxp-imx/linux-imx -b lf-6.12.y $ cd linux-imx   To build the kernel in the standalone environment for i.MX 6 and i.MX 7, execute the following commands:    $ make imx_v7_defconfig $ Make   To build the kernel in the standalone environment for i.MX 8 and i.MX 9, execute the following commands:  $ make imx_v8_defconfig $ make   The full kernel compilation is required to generate headers and symbol files required for external module compilation, even if you don't plan to boot this kernel directly.      Step 2: Write a simple Kernel Module to test    Now that your kernel is compiled, you can write a basic kernel module for testing.    Create a new directory. It will have our hello.c and Makefile.    We will create the file hello.c:  #include <linux/init.h> #include <linux/module.h> #include <linux/kernel.h> MODULE_LICENSE("GPL"); MODULE_AUTHOR("Salas"); MODULE_DESCRIPTION("A simple kernel module example for cross-compilation."); MODULE_VERSION("0.1"); static int __init hello_init(void) { printk(KERN_INFO "Hello from the kernel module!\n"); return 0; } static void __exit hello_exit(void) { printk(KERN_INFO "Goodbye from the kernel module!\n"); } module_init(hello_init); module_exit(hello_exit);   Then, create a basic Makefile to compile the modules:    # Module name obj-m += hello.o # Build flags ldflags-y += --strip-debug # Kernel source directory (provided by Yocto) KERNEL_SRC ?= /path/to/your/compiled/kernel # Build target all: $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules # Clean target clean: $(MAKE) -C $(KERNEL_SRC) M=$(PWD) clean # Install target modules_install: $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules_install   KERNEL_SRC should be your compiled kernel from your Yocto build:   yocto-bsp/build/tmp/work/your-machine-poky-linux/linux-imx/6.12.20+git/build   Or the Standalone : path/to/linux-imx/     Step 3: Set the toolchain and compile the kernel module    Finally, we can compile the kernel module.    First, set the toolchain (in my case):  $ source /opt/fsl-imx-wayland/6.12-walnascar/environment-setup-armv8a-poky-linux   Then, compile using the makefile:  $ make   f everything goes well, at final you will have the generated files:    hello.ko hello.mod hello.mod.c hello.mod.o hello.o Makefile modules.order Module.symvers   The one we need is the hello.ko (Kernel Object).    We can check if the file was created correctly using:    $ readelf -h hello.ko ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: AArch64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 33992 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 41 Section header string table index: 40   We can see the Machine is AArch64 and the Type is a Relocatable file.      Step 4: Running the Kernel Object/Module in the board    Transfer the generated hello.ko file from your host machine to your board.    Then, In your board you can run with:    root@imx93evk:~# ls hello.ko root@imx93evk:~# insmod hello.ko root@imx93evk:~# dmesg | tail [ 5140.547447] Hello world from kernel! root@imx93evk:~# rmmod hello.ko root@imx93evk:~# dmesg | tail [ 5140.547447] Hello world from kernel! [ 5153.415215] Goodbye world from kernel!   I hope this can helps to you.    Best regards,  Salas. 

  Background : Some customer want to test the LPDDR4/X ECC feature based on the i.MX93 chip, But, for now, Our DDR Config Tool do not release this test chosen. And our ECC guide only tell the ECC feature function, does not tell the customer how to test it. So in this article, Will show you more details about ECC feature and how to run the ECC test use uboot command. But I won't put the source code of the test here, You can download the binary run the test on the i.MX93 EVK board.   HW : i.MX93 EVK board with 2GB LPDDR4 SW : 6.1.1-1.0.0   ECC Introduce what is ECC?       ECC is the abbreviation of Error Correction Code. Its function is to automatically detect and repair some minor errors in the memory to prevent data errors. How does ECC work? We can think of it as an "automatic proofreader", and its workflow is roughly as follows:  When writing data: The memory controller generates a "check code" (similar to the fingerprint of the data) for each piece of data. This check code will be stored together with the data. When reading data: The memory controller will recalculate the "fingerprint". Then compare the previously stored check code to see if there is any difference. If a difference is found: If it is just a 1-bit error, ECC can automatically correct it. But, If there are multiple errors, ECC can at least detect them and issue a warning.   ECC test step: 1. Flash the attachment file to the imx93 board. 2. Enter the uboot, run the "ecc --help" command, you will see the below help output message   pengyong_zhang_2-1752117144449.png 3. For example : ecc 0x80000000 0x90000000, it will test the ecc feature with on bit error detect and correct , 2 bits errors detect with 256MB DRM size. pengyong_zhang_3-1752117148095.png   if you need this ECC_ test binary file, please contact me, i will share it to you        

Our default BSP code can support below resolution:       https://github.com/nxp-imx/linux-imx/blob/cbfe1a744dc4a794e79396c7079339a54f89c8f2/drivers/phy/freescale/phy-fsl-samsung-hdmi.c If customer want to add new pixel clock about their  panel, they can ask our support to generate the new parameters about it, and then add the result to below struct: const struct phy_config samsung_phy_pll_cfg[] = {}. After add the result to the struct, you need to re-compile the kernel and boot your board, then run the "modetest -c" command Check whether the changes are effective when you run the modetest -c command, the following code show as below, You can see all the resolutions currently supported by your monitor. pengyong_zhang_0-1752116836936.png   How to change the panel display resolution: 1) Run the below command at the uboot period: setenv mmcargs 'setenv bootargs console=${console} root=${mmcroot} video=HDMI-A-1:1920x1080-32@30' video=HDMI-A-1:3840x2160-32@30: Set video output parameters: HDMI-A-1: Specifies the use of the HDMI interface. 3840x2160: The resolution is 3840x2160 (4K). -32: The color depth is 32 bits. @30: The refresh rate is 30Hz. saveenv boot 2) Change the westom.ini file at the /etc/xdg/weston location, Change the resolution you want in [output] part. [output] #name=HDMI-A-1 #mode=640x480@60 #transform=rotate-90 3)Reboot the board, and run the "modetest -p" command see if your change is effective