ヘルプ
英语（美国） | English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

i.MXプロセッサ ナレッジベース

キャンセル
提案をオンにする
自動提案では、入力時に可能な一致が提案されるので検索結果を素早く絞り込むことができます。
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX Processors Knowledge Base

ラベル

ディスカッション

ソート順:

i.mx8ulp gpio hog

based on customer's issue when use PTF pins of imx8ulp as GPIO or gpio hog
記事全体を表示
評価なし
昨日

Audio / Video Trough camera stream on i.MX Processor

  This document shows how to use the open source gstreamer1.0-rtsp-server package on i.MX6QDS and i.MX8x to stream video files and camera using RTP protocol.  The i.MX 6ULL and i.MX 7 doesn't have Video Processing Unit (VPU). Real time protocol (RTP) is a very common network protocol for delivering media over IP networks. On the board, you will need a GStreamer pipeline that encodes the raw video, adds the RTP payload, and sends over a network sink. A generic pipeline would look as follows: video source ! video encoder ! RTP payload ! network sink Video source: often it is a camera, but it can be a video from a file or a test pattern, for example. Video encoder: a video encoder as H.264, H.265, VP8, JPEG and others. RTP payload: an RTP payload that matches the video encoder. Network sink: a video sync that streams over the network, often via UDP. Pre-Requisites: MX6x o MX8x board with the L6.6.52 BSP installed. A host PC with either Gstreamer or VLC player installed.   Receiving h264 / h.265 Encoded RTP Video Stream on a Host Using GStreamer: GStreamer is a low-latency method for receiving RTP video. On your host machine, install Gstreamer and send the following command: $ gst-launch-1.0 -v udpsrc port=5000 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! decodebin ! videoconvert ! autovideosink sync=false   Using HOST PC: VLC Player Optionally, you can use VLC player to receive RTP video on a PC. First, in your PC, create a sdp file with the following content:  stream.sdpv=0m=video 5000 RTP/AVP 96c=IN IP4 127.0.0.1a=rtpmap:96 H264/90000 After this, with the GStreamer pipepline on the device running, open this .sdp file with VLC Player on the host PC.   Sending h.264 and h.265 Encoded RTP video stream GStreamer provides an h.264 encoding element by software named x264enc. Use this plugin if your board does not support h.264 encoding by hardware or if you want to use the same pipeline on different modules. Note that the video performance will be lower compared with the plugins with encoding accelerated by hardware. # gst-launch-1.0 videotestsrc ! videoconvert ! x264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 Note: Replace <host-machine-ip> by the IP of the host machine. In all examples you can replace videotestsrc by v4l2src element to collect a stream from a camera   i.MX8X # gst-launch-1.0 videotestsrc ! videoconvert ! v4l2h264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000   i.MX8M Mini Quad / 8M Plus # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 i.MX6X The i.MX6QDS does not support h.265 so the h.264 can work: # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 Using other video Encoders While examples of streaming video with other encoders are not provided, you may try it yourself. Use the gst-inspect tool to find available encoders and RTP payloaders on the board: # gst-inspect-1.0 | grep -e "encoder"# gst-inspect-1.0 | grep -e "rtp" -e " payloader" Then browse the results and replace the elements in the original pipelines. On the receiving end, you will have to use a corresponding payload. Inspect the payloader element to find the corresponding values. For example: # gst-inspect-1.0 rtph264pay   Install rtp in your yocto different form L6.6.52 BSP, to install gstreamer1.0-rtsp-server in any Yocto Project image, please follow the steps below: Enable meta-multimedia layer: Add the following on your build/conf/bblayers.conf: BBLAYERS += "$"${BSPDIR}/sources/meta-openembedded/meta-multimedia" Include gstreamer1.0-rtsp-server into the image: Add the following on your build/conf/local.conf: IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server" Run bitbake and mount your sdcard. Copy the binaries: Access the gstreamer1.0-rtsp-server examples folder: $ cd /build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0-rtsp-server/$version/build/examples/.libs Copy the test-uri and test-launch to the rootfs /usr/bin folder. $ sudo cp test-uri test-launch /media/USER/ROOTFS_PATH/usr/bin Be sure that the IPs are correctly set: SERVER: => ifconfig eth0 $SERVERIP CLIENT: => ifconfig eth0 $CLIENTIP Video file example SERVER: => test-uri file:///home/root/video_file.mp4 CLIENT: => gst-launch-1.0 playbin uri=rtsp://$SERVERIP:8554/test You can try to improve the framerate performance using manual pipelines in the CLIENT with the rtspsrc plugin instead of playbin. Follow an example: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test caps = 'application/x-rtp'  ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! queue max-size-buffers=0 ! imxv4l2sink sync=false   Camera example SERVER: => test-launch "( imxv4l2src device=/dev/video0 ! capsfilter caps='video/x-raw, width=1280, height=720, framerate=30/1, mapping=/test' ! vpuenc_h264 ! rtph264pay name=pay0 pt=96 )" CLIENT: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test ! decodebin ! autovideosink sync=false The rtspsrc has two properties very useful for RTSP streaming: Latency: Useful for low-latency RTSP stream playback (default 200 ms); Buffer-mode: Used to control buffer mode. The slave mode is recommended for low-latency communications. Using these properties, the example below gets 29 FPS without a sync=false property in the sink plugin. The key achievement here is the fact that there is no dropped frame: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test latency=100 buffer-mode=slave ! queue max-size-buffers=0 ! rtph264depay ! vpudec ! imxv4l2sink    
記事全体を表示
評価なし
木曜日

Transcode and Stream videos on i.MX6DLQ

  This article shows how to use the i.MX6DL/Q to transcode and stream videos on 1080i/p @ 24fps and 720p @ 30fps. For this test, we used one i.MX6DL as server and an i.MX6DL and i.MX6Q as clients. The video is streamed by the server, playing the sound at the same time, while the clients show the video in the HDMI output, as the image below:     This test depends on some GStreamer plugins. To check that the right GStreamer plugins are installed type the following commands: $ gst-inspect-1.0 | grep h264 To return all the H.264 related plugins, or: $ gst-inspect-1.0 decodebin To check directly the command. To connect more than one board to the minicom, open it with the command: $ sudo minicom –s This way, you open the configuration menu. Enter in the “Serial port setup” option and press “A” to set or change the PORTNUMBER, in “ttyUSB$PORTNUMBER”. To set the HDMI output, run the commands below from the U-Boot prompt: => setenv mmcargs 'setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 consoleblank=0' => saveenv Be sure that the IPs are correctly setted: SERVER: => ifconfig eth0 $SERVERIP CLIENTS: => ifconfig eth0 $CLIENTSIP Streaming transcoded video only SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, payload=(int)96' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false Streaming transcoded video + audio SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin name=demux demux. ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 demux. ! alsasink CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, encoding-name=(string)H264' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false   You can check the results with the 1080p@24fps.
記事全体を表示
評価なし
木曜日

FlexIO 8080 8 bit mode display on i.MX943/i.MX93

Overview The purpose of this document is to provide guidance for FlexIO 8080 display capability. Generally, the 8080 bus interface consists of one chip-select line (CS), one writing-latch line (WR), one reading-latch line (RD), one data/command-select line (RS, also called D/C), and 8 or 16 bidirectional data lines (Data Bus). Since The FlexIO instance of i.MX 943 support only 16 pins, the demo can only support 8 bit 8080 mode(two pin should be used as WR and RD signal. Below are pins used in the 8 bit 8080 display. Panel Setup The panel in the example is X-LCD-PAR-S035. To use 8 bit 8080 mode, need ser IM[2:0] to be 011. Connection and Software i.MX 943 Need pull down SPI8_SEL1 and SPI8_SEL3 of PCA6416 in SW to select Arduino for 8080 pins D[7:4]. Here is the patch for system manager. For quick verification, use flash_m70 when building bootloader. diff --git a/configs/mx94evk.cfg b/configs/mx94evk.cfg index 9d46976..90bf089 100755 --- a/configs/mx94evk.cfg +++ b/configs/mx94evk.cfg @@ -499,6 +499,9 @@ ENC_PLL OWNER ENDAT2_1 OWNER ENDAT2_2 OWNER ENDAT3_1 OWNER +GPIO2 OWNER +GPIO3 OWNER +FLEXIO1 OWNER FLEXIO3 OWNER FLEXIO4 OWNER FLEXPWM1 OWNER @@ -515,6 +518,7 @@ HIPERFACE_SAFE1_2 OWNER HIPERFACE_SAFE2_1 OWNER HIPERFACE_SAFE2_2 OWNER IRQSTEER_M7_0 OWNER +LPI2C6 OWNER LPIT1 OWNER LPTMR1 OWNER LPTMR2 OWNER @@ -557,6 +561,25 @@ XBAR_DSC3 OWNER PIN_GPIO_IO24 OWNER PIN_GPIO_IO25 OWNER +# 8080 +PIN_GPIO_IO00 OWNER +PIN_GPIO_IO01 OWNER +PIN_GPIO_IO02 OWNER +PIN_GPIO_IO03 OWNER +PIN_GPIO_IO08 OWNER +PIN_GPIO_IO09 OWNER +PIN_GPIO_IO10 OWNER +PIN_GPIO_IO11 OWNER +PIN_GPIO_IO12 OWNER +PIN_GPIO_IO13 OWNER +PIN_GPIO_IO14 OWNER +PIN_GPIO_IO15 OWNER +PIN_GPIO_IO38 OWNER + +# I2C6 +PIN_GPIO_IO28 OWNER   Attached imx943_flexio_8080_8bit.zip is patch for m70 demo based on SDK_25_06_00_MCIMX943-EVK.   i.MX 93 Need pull up EXP_SEL(pin4 R4) of ADP5585 in SW to route some pins. Attached imx93_flexio_8080_8bit.zip is patch for m33 demo based on SDK_25_06_00_MCIMX93-EVK. The running status is similar as i.MX943.
記事全体を表示
評価なし
水曜日

i.MX 93 Memory Compatibility Guide

The purpose of this document is to provide extended guidance for the selection of compatible LPDDR4/4X memory devices that are supported by the i.MX 93 series of processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs. The i.MX 93 series of processors supports different packages, and each have their own maximum supported LPDDR4/4x data rates. Please refer to the respective datasheets. NOTE: Some of the LPDDR4/4X devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low-speed operation is planned in the use case, please consult with the memory vendor about the configuration aspects and possible customization of the memory device so correct functionality is ensured. LPDDR4/4X - Maximum Supported Densities SoC Max Data bus width Maximum density Assumed memory organization Notes i.MX 93 (i.MX 93xx) 16-bit 16 Gb / (2 GB) single rank, single channel device with 17-row addresses (R0 - R16) 1, 2, 3   LPDDR4/4X - List of Validated Memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A  (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7   4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/ (512 MB) Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: D1611PM3BDGUI-U 4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U  7, 9 8 Gb/ (1 GB) ISSI LPDDR4: IS43LQ16512A-053BLI 4, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/ (512 MB) JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2Gb / (256 MB) Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8Gb / (1 GB) IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 4Gb / (512 MB) Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8 Gb / (1 GB) AM (Alliance Memory) LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 2Gb / (256 MB) ISSI LPDDR4: IS46LQ16128A-062BSLI 4, 6, 8   Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4B/JESD209-4-1 (LPDDR4/4X). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4/4X devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The SoC also supports dual rank single channel devices therefore, 16Gb/2GB density can be also achieved by using a dual rank single channel device with 16-row addresses (R0 - R15). Note 4: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 5: This is a dual channel x32 device. Since i.MX93 only supports 16-bit LPDDR4/X data bus, it can only interface with one of the channels and therefore, utilize only half of the device's density. As indicated in the table - the device has 32Gb/4GB density however, only 16Gb/2GB can be used. There is no functional problem with using only one channel of a dual channel device as the channels are independent in LPDDR4/4X.  Note 6: This is a new JEDEC 100 ball package, half the size of the standard 200 ball package. This 100 ball package has the same performance and functionality as the 200 ball package, and has the added advantage of being smaller and cheaper than the standard package. Note 7: This device has been EoLed by the manufacturer and has been updated by a new memory part number  Note 8: Part is active. Reviewed Aug 2025 Note 9: Part is obsolete. Note 10: This device will be EoLed in Q2 24 by the manufacturer and will not be updated by a new memory part number Note 11: DQ eye marginalities were identified during TSA analysis. vTSA and stability testing did not identify any issues.
記事全体を表示
100%が役に立ったと言っています (3/3)
月曜日

Getting Started with iMX8MP-EVK and MCU-LINK Pro for M Core Debugging

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the IMX8MP-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: IMX8MP-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 iMX8MP-EVK SDK   Import "hello world" example Ensure that we are compiling a debug binary Build Project Flash the Binary using UUU Tool Connect the IMX8MP-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   Connect MCU-LINK Pro to the Target   IMX8MP-EVK Debug connection:     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   Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:          With the MCU-LINK Pro configured, the IMX8MP-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.MX8MP based projects.   References: AN14120.pdf 
記事全体を表示
評価なし
月曜日

[8MP]Workaround for running UART with SDMA enabled on Cortex M7 in parallel of Linux on A53

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.       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    3.2 Clock changes   evkmimx8mp_iuart_sdma_transfer\clock_config.c In function BOARD_BootClockRUN     3.3 Application specific changes   evkmimx8mp_iuart_sdma_transfer\board.h      app.h   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.   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 ..... 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 We need to assign UART3 to domain 1 so Cortex M7 can access   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 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     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   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   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        
記事全体を表示
評価なし
1週間前

Steps for single secure boot for Android BSP

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
記事全体を表示
評価なし
1週間前

i.MX93 RMII debug tips

    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.  
記事全体を表示
評価なし
1週間前

Application of xSPI NOR Device in i.MX95 Boot

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.
記事全体を表示
評価なし
1週間前

i.MX 8M Quad/Mini/Nano/Plus - LPDDR4, DDR4 & DDR3L memory compatibility guide

The purpose of this document is to provide supportive information for selection of suitable LPDDR4, DDR4 and DDR3L devices that are supported by i.MX 8M family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products.  It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs available on NXP.com For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket.  LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8M Mini  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16) 1, 2 i.MX 8M Nano  16-bit 32Gb/4GB dual rank, single-channel  device with 17-row addresses (R0-R16) 1, 2, 3, 12 i.MX 8M Plus  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16)  1, 2   LPDDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Validated part number  Vendor Notes i.MX 8M Quad  24Gb/3GB MT53B768M32D4NQ-062 WT:B     Micron 15 32Gb/4GB MT53D1024M32D4DT-046 AAT:D  Micron 14 4Gb/512MB IS43LQ16256B-062BLI  ISSI 5, 14 8Gb/1GB IS43LQ32256B-062BLI  ISSI 5, 14 i.MX 8M Mini 16Gb/2GB MT53D512M32D2DS-053 WT:D  Micron 15 16Gb/2GB M56Z16G32512A     ESMT 5, 14 32Gb/4GB MT53E1G32D2FW-046 WT:A  Micron 5, 14 64Gb/8GB MT53E2G32D4DT-046 AIT:A  Micron 5, 14 32Gb/4GB B3221PM3BDGUI -U Kingston 5 i.MX 8M Nano  16Gb/2GB C1612PC2WDGTKR-U   Kingston 15 16Gb/2GB  D1611PM3BDGUI-U  Kingston 5,14 32Gb/4GB MT53E2G32D4DT-046 AIT:A  Micron 5, 13, 15 4Gb/512MB NT6AN256M16AV-J2 Nanya 5,14 4Gb/512MB W66CP6RBQAHJ  Winbond 5,14 8Gb/1GB MT53D512M32D2DS-053 WT:D  Micron 13, 15   i.MX 8M Plus 48Gb/6GB MT53E1536M32D4DT-046 WT:A   Micron 15 64Gb/8GB MT53E2G32D4DE-046 AUT:C   Micron 5, 14 32Gb/4GB K4FBE3D4HB-KHCL  Samsung 5, 14              8Gb/1GB  W66DP2RQQAHJ Winbond       5, 14 32Gb/4GB D1611PM3BDGUI-U  Kingston 5, 14 64Gb/8GB Q6422PM3BDGVK-U  Kingston 5, 14   LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table:   Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad  The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL K4UJE3D4AA-KU(H/F)CL 24Gb/3Gb 48Gb/6GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. The memory device only supports the LPDDR4X mode.    DDR4 - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 6 i.MX 8M Mini  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 i.MX 8M Nano  16-bit 64Gb/8GB x8, 16Gb device with 2 bank group addresses, 17-row addresses and 10 column addresses 1, 8 i.MX 8M Plus  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7   DDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required.   SoC Density Validated part number (vendor) Notes i.MX 8M Quad 32Gb/4GB 4x MT40A512M16JY-083EAAT (Micron) 15 i.MX 8M Mini  16Gb/2GB 2x MT40A512M16LY-075:E (Micron) 15 i.MX 8M Nano 16Gb/2GB 1x MT40A1G16RC-062E:B (Micron) 15 i.MX 8M Plus 64Gb/8GB 4x MT40A1G16RC-062E:B (Micron) 15 16Gb/2GB NT5AD512M16C4-JRI (Nanya) 14   DDR3L - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 8Gb device with 16-row addresses and 10 column addresses 1, 9 i.MX 8M Mini  32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 10 i.MX 8M Nano  16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 11 i.MX 8M Plus  i.MX 8M Plus does not support DDR3L   DDR3L - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Validated part number (vendor) Notes i.MX 8M Quad  16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14 i.MX 8M Mini  16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14   Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standards JESD209-4/JESD209-4A (LPDDR4), JESD279-4/JESD279-4A (DDR4), and JESD79-3E/JESD79-3F/JESD79-3-1A (DDR3/DDR3L). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chips to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the DDR Controller Note 5: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 6: The density can be achieved by connecting 2 single-rank discrete devices with one 16Gb die each. Since the SoC supports x8 devices and also has connectivity for a second rank, usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Two x16 16Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (only two discrete devices used), and bandwidth aspects (full data bus width used). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 64Gb/8GB of address space dedicated for the DDR. Four x16 16Gb devices giving 64Gb/8GB in total is the optimal choice that balances the maximum density aspects, the signal integrity aspects (only four discrete devices used), and the bandwidth aspects (full data bus width used). Note 8: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select.  Note 9: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Four x16 8Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (four discrete devices used), and bandwidth aspects (full data bus width used). Note 10: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that the first option significantly exceeds the number of devices used on the validation board (4 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis. Practically, it is not recommended to use more than 4 discrete DDR3L devices. This corresponds to the maximum density of 32Gb/4GB in the case of the single rank devices containing one 8Gb die or 64Gb/8GB in case of the dual-rank devices, each containing two 8Gb dies. Note 11: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note 12: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q1 2022). Note 13: Only one channel of the device (and hence, half of its density) was utilized due to the reduced data bus width (x16) of the SoC. Note 14: Part is active. Reviewed July 2025 Note 15: Part will either EoL or is not recommended for new designs by the respective vendor.   Additional Links https://community.nxp.com/t5/iMX-and-Vybrid-Support/i-MX-8-8X-8XL-maximum-supported-LPDDR4-and-DDR3L-densities/ta-p/1152715          
記事全体を表示
100%が役に立ったと言っています (5/5)
2 週間前

Getting Started with iMX8MM-EVK and MCU-LINK Pro for M Core Debugging

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   Import "hello world" example Ensure that we are compiling a debug binary Build Project   Flash the Binary using UUU Tool Connect the IMX8MM-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 Connect MCU-LINK Pro to the Target     IMX8MM-EVK Debug connection:   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     Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:      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 
記事全体を表示
評価なし
2 週間前

Getting Started with iMX8MN-EVK and MCU-LINK Pro for M Core Debugging

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   Import "hello world" example Ensure that we are compiling a debug binary Build Project   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   Connect MCU-LINK Pro to the Target   IMX8MN-EVK Debug connection:   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   Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:      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 
記事全体を表示
評価なし
2 週間前

Getting Started with iMX93-EVK and MCU-LINK Pro for M Core Debugging

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     Import "hello world" example   Ensure that we are compiling a debug binary Build Project   Flash the Binary using UUU Tool Connect the IMX93-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 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     Connect MCU-LINK Pro to the Target     IMX93-EVK Debug connection:       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     Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:        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 
記事全体を表示
評価なし
2 週間前

[i.MX8MP/VPU] Tips for vpuwraper

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
記事全体を表示
評価なし
3 週間前

Android MultiMedia Framework

1. MediaPlayer Architecture     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.   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.   3.2 Framework of i.MX8QM   Decoding Process between the framework, vendor decoder component and kernel as follows on i.MX8QM. 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:  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: 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: 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.   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:   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:     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: 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 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   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 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     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.  
記事全体を表示
評価なし
3 週間前

MQS in i.MX8ULP

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). 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.   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: But, in the EVK board, the mayor part of these pins are used for other functions such as: - Push button: - MIPI DSI:  - 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:   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: And the card appears if we run the next command: $ aplay -l 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 The signal should look like this in the pin output: And like this after a filter, for example the filter used in i.MX93 EVK.   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.
記事全体を表示
評価なし
3 週間前

i.MX6 DDR Stress Test Tool V1.0.3

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.
記事全体を表示
評価なし
3 週間前

How to get rid of CMA

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"
記事全体を表示
評価なし
3 週間前