Attached is a chunk of the Filesystem needed to construct the Linux Image https://community.freescale.com/docs/DOC-93887

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

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

  This article is an example for users to change the DDR clock on i.MX6ULL board Environment: Hardware : i.MX6ULL EVK board Concept of MMDC controller clock source on i.MX6ull Consult Chapter 18 Clock Controller Module(CCM) in the I.MX 6ull reference manual. The MMDC clock source is shown in Figure 23.3.3.1:   Figure 23.3.3.1 MMDC Clock Source Figure 23.3.3.1 shows the clock source path diagram of MMDC, which is mainly divided into three parts. 1. CBCMR[PRE_PERIPH2_CLK_SEL] : The pre_periph2 clock selector, which is the pre-selector of periph2_clkd, is controlled by the PRE_PERIPH2_CLK_SEL bit (bit22:21) of the CBCMR register. 2. CBCDR[PERIPH2_CLK_SEL] : periph2_clk clock selector, controlled by the PERIPH2_CLK_SEL bit (bit26) of the CBCDR register,When it is 0, pll2_main_clk is selected as the clock source of periph2_clk. When it is 1, periph2_clk2_clk is selected as the clock source of periph2_clk. 3. CBCDR[FABRIC_MMDC_PODF] : It is a frequency divider. The frequency division value is set by the FABRIC_MMDC_PODF bit (bit5:3) of the CBCDR register. It can be set to 0~7, corresponding to 1~8 frequency divisions respectively. To configure the clock source of the MMDC to 396MHz, it must be set to 1 here, so FABRIC_MMDC_PODF=0. The above is the clock source setting of MMDC. Implementation Step 1 : git clone the uboot code from NXP github web $ git clone https://github.com/nxp-imx/uboot-imx.git Step 2 : Modify the different frequencies of DDR by modifying the following files : uboot-imx/board/freescale/mx6ullevk/imximage.cfg As default BSP code, our DDR run frequency is 400MHz (Actually, it's 396MHz), If you want DDR to boot at 132MHz, we need to configurate the CCM_CBCDR[FABRIC_MMDC_PODF] bit,  from this bit content, we need to set it to 010. The frequency division value is 3 based on 396MHz   Change code as following: DATA 4 0x020c4014 0x00018910, Add this code in imximage.cfg file. Step 3 : Re-compile the uboot and flash the uboot to the board. Result Now, We can see that DDR is running at successfully at 132MHz. Before modification:   After modification:      

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

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        

We are pleased to announce that Config Tools for i.MX v25.06 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) • DDR – Support for i.MX 91 is added. – Synchronized with BSP Q2 release – Support for the i.MX 91 FRDM board is added. – Support for the i.MX 93 FRDM board is added. – Spectrum support for i.MX 95 and i.MX 943 is spread. – The Address mirroring option in the UI for all mscale devices with DDR3L and DDR4 is exposed. – DDR3L support for i.MX 8M and i.MX 8MM is added. – Linux support for code generation (beta) is added. • SerDes tool – i.MX 943 support (Beta) is added. • Clocks – Support for read-only element settings is added. – Filtering all settings of Initialization modules in the Details view is supported. • Peripherals – A wizard to export the Registers view data in the CSV format is supported. – Performance of the tool is improved. • An ability to export/import Expansion Boards and Expansion Headers is added.

The documentation is about to present a detailed build steps to implement the verification of the integrity of the rootfs for i.MX8ULP.

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 

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.

  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    

  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.

based on customer's issue when use PTF pins of imx8ulp as GPIO or gpio hog