[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-344779 

Flashing Kernel and Root File System using RedBoot Creating an image A kernel image and a root file system can be created using All Boards LTIB or compiling the kernel and setting the correct set of files. Create a root file system image from a set of files converting the files to a jffs2 file system. For this, install the package mtd-tools. In Ubuntu type apt-get install mtd-tools For making an root file system for flash, use the jffs2 file system like: mkfs.jffs2 -r rootfs/ -e 0x20000 -n -p -o rootfs.jffs2 Where rootfs/ is the original set of file for the file system and rootfs.jffs2 is the output image file. Flashing Some connections errors can be avoided by All Boards Configuring RedBoot. The process below uses TFTP to copy the files between host and target. See All Boards TFTP for detail in configurations. Copy the kernel image and the root file system image to the TFTP dir. For example, in  LTIB dir, type sudo cp ./rootfs/boot/zImage /tftpboot sudo cp rootfs.jffs2 /tftpboot/ Where /tftpboot is the dir configured for TFTP The next steps are performed in a Minicom session, and happens on the board. Formatting the flash: fis init Flashing kernel Load kernel image (zImage) using the command below. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/zImage -h 10.29.244.99 The address 0x100000 is used as a temporary location Create the kernel at the right address (0x200000, for IMX31PDK) fis create -f 0x200000 kernel Flashing root file system Load root file system image (rootfs.jffs2) to the temporary address. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/rootfs.jffs2 -h 10.29.244.99 Create the root file system in the right address (0x600000, for IMX31PDK. fis create -f 0x600000 root Testing You can now load your kernel in the flash by typing: fis load kernel To know if the root file system written in the flash was correctly saved, execute the NFS file system and mount the flash. For load the the root file system by NFS, type: exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.244.99:/tftpboot/rootfs init=/linuxrc ip=10.29.241.6:10.29.244.99" Wait the system go up, then mount the flash at /mnt. Reminde that the flash has a jffs2 file system. mount -t jffs2 /dev/mtdblock2 /mnt ls /mnt List the /mnt contents. The output must be the right file system. Modifying the initial script Reset the board and press CTRL-C. Type fc to modify the configurations and insert the initialization script. RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> fis load kernel >> exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 ip=none" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> Remember to save the configuration in the flash by typing y Reset the system. To certify that the board is loading the system from flash, remove the ethernet cable.

This is done with the 11.09 BSP for imx53 specifically. Attached is an amrnb.spec file, I put it in ltib/dist/lfs-5.1/amrnb. Then I extracted opencore-amr-0.1.3.tar.gz and put it in ltib/rpm/BUILD. I built with ltib ( ALl this could be added to the ltib menus as well 😞 ./ltib –m scbuild –p amrnb ./ltib –m scdeploy –p amrnb Then I applied the patch to .ltib for gst-plugins-ugly and built that with ltib. It will play a .3gp file with this pipeline: gst-launch filesrc location=/media/sd/test.3gp ! qtdemux name=demux demux.audio_00 ! queue ! amrnbdec ! alsasink demux.video_00 ! multiqueue ! mfw_vpudecoder ! mfw_isink Regards, Randy Krakora

Questions: 1.  Are there any hardware limitations (such as in the Host Controller IP block itself, how this IP block was implemented or in the DMA engine) to how many device endpoints the i.MX53 can handle on Host2 or Host3?  The Reference Manual notes that the OTG controller supports up to 8 endpoints but does not provide information on the Host Controller. 2.  Do any of the device validation tests for verifying the i.MX53 design (or USB cert tests) test compatibility/performance with multiple devices and multiple endpoints? 3.  What are the maximum number of endpoints Freescale has tested with? Problem Background: During extensive testing the customer observes 100% CPU utilization with only 6 endpoints (can be a combination of multi-endpoint devices or single-endpoint devices - see below for test configuration details) using our latest Linux reference BSP (2.6.35 Kernel).  They have tested with the Adeneo WEC7 BSP and the open source Linux kernel based on 3.11 for the QSB and have observed similar performance limitations. This has been tested with multiple packet sizes and device/endpoint configurations and no impact has been shown in varying these parameters. The customer did note that they are only receiving/processing a single interrupt at the 1ms boundary regardless of the number of devices/endpoints.  Processing this interrupt takes approximately 23us for one device and an additional 17us for each additional device endpoint after the first that is processed. The customer hardware configuration for their testing looks something like this: On the customer's board: [i.MX53 Host2/Host3] -> [SMSC 3315 USB High Speed ULPI PHY] -> [SMSC LAN9514 On-board 4-port USB 2.0 HS Hub] External: [SMSC LAN9514 Port #1] -> [SMSC USB2415 4-Port USB 2.0 HS Hub] -> Medical device w/ endpoints #1-4 [SMSC LAN9514 Port #2] -> [SMSC USB2415 4-Port USB 2.0 HS Hub] -> Medical device w/ endpoints #5-8 [SMSC LAN9514 Port #3] ->  Medical device w/ endpoint #9 [SMSC LAN9514 Port #4] ->  Medical device w/ endpoint #10 Answer: Hosts do not have endpoints. Only devices have endpoints. EHCI compliance hosts, like all i.MX devices, use a linked list of queues (for bulk/control transport). Each queue has a queuehead that represents a corresponding endpoint and has the endpoint's capabilities. On the queue are transfer descriptors that have the information of which data is to be moved to/from the endpoint of the device. All of this is in main memory and read/written under DMA.  There is no limit on how many devices/endpoints a host can service, other than the amount of available main memory (DRAM). The CPU has to build the linked lists, but this is  normally not taking much bandwidth. My guess at this time is that there may be a problem in the USB driver, or the application that is using the driver, or a problem with data alignment. For efficient operation, data must be aligned on 32-bit boundaries. Buffers are best aligned on 64-byte boundaries.

I have imx53 quick sort board i downloaded u-boot-mx53.bin and uImage to loade that into the board and dowloaded rootfs.ext2.gz in the L2.6.35_11.09.01_ERimages and i did partitions on 1GB memory card and loaded that u-boot-mx53.bin,uImage images on to the 500mb of NTFS filesystem and loaded and rootfs.ext2.gz on to the othe 500mb of ext4 file system the i inserted memorycard in to the board but u-boot logs are not comming what will be the solution

The i.MX21 Application Development System (MCIMX21ADSE) is a development tool which is designed to run software applications designed for the i.MX21 processor. Features   i.MX21 Processor   Two clock-source crystals, 32.768 KHz and 26 MHz   Power connector for +5.0-volts in from an external, regulated power supply, an in-line fuse, and a power on/off switch.   Voltage regulators that step down the 5.0-volt input to Vcc (3.0-volts), 2.5-volts, 1.8-volts, and 1.5-volts.   Multi-ICE debug support   Two 8M × 16-bit Burst Flash memory devices, configured as one 32MB, 32-bit device   Two 16M × 16-bit SDRAM devices, configured as one 64MB, 32-bit device   High speed expansion connectors for optional add on cards   Two-board system: modular CPU board plugs into Base board; Base board has connections for LCD display panel and keypad and TV encoder card   Memory mapped expansion I/O   Configuration and user definable DIP switches   SD/MMC memory card connector   Two RS232 transceivers and DB9 connectors (one configured for DCE and one for DTE operation) supporting on-chip UART ports   External UART with RS232 transceiver and DB9 connector   IrDA transceiver that conforms to Specification 1.4 of the Infra-red Data Association   USB OTG (On The Go) interface transceiver and USB mini AB connector   Separate LCD panel assembly with a ribbon cable that connects to the Base board and interfaces directly with the M9328MX21ADS   Touch panel controller for use with the LCD   Separate Keypad unit with 36 push button keys   Separate CMOS Image Sensor Card   Audio CODEC includes an 11.28MHz crystal oscillator, a 3.5mm audio input jack, a 3.5mm microphone jack, and a 3.5mm headphone jack   Cirrus Logic CS8900A Ethernet controller, with RJ-45 connector for connecting to a system hub   Two 32 × 3-pin DIN expansion connectors with most i.MX21 I/O signals   Variable resistor for emulation of a battery voltage level   NAND Flash card (Plugs into CPU)   LED indicators for power, external bus activity, Ethernet activity, and two LEDs for user defined status indiction   Universal power supply with 5.0-volt output @ 2.4A   USB cable   RS232 serial cable   Two RJ-45 Ethernet cables, network and crossover

1) nfs I burn the uboot to board by mfgtool, then starting the kernel by nfs, when the board boot up, I set a) ipaddr and b)serverip, then I set the c)"setenv nfsroot /home/usuario/fsl-release-bsp/buildimx6q/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui/1.0-r0/rootfs", this is sample, you need choose correct folder for yours, this is for imx6q, d) set the mdt file,then run the netboot. 2) program uboot to the qspi, then boot from SD card 3) change the mfgtool to program uboot, kernel to the qspi attched the ucl2.xml setenv bootcmd 'run bootargsset; sf probe; sf read ${loadaddr} 0xA00000 0x600000; sf read ${fdt_addr} 0x800000 0x10000; bootz ${loadaddr} - ${fdt_addr}'

Copy Redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND or MMC flash media for Redboot. In this case, NAND is beeing used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate Copy redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND, or MMC flash media for Redboot. In this case, NAND is being used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate

Random Number Generator - RNGA Download rng-tools: http://downloads.sourceforge.net/sourceforge/gkernel/rng-tools-2.tar.gz This tool tests the link between a random number generator hardware and the kernel's PRNG (pseudo-random number generator). ./ltib -m shell LTIB> cd rpm/BUILD/ LTIB> cp ~/hwrandom/rng-tools-2.tar.gz . LTIB> tar zxvf rng-tools-2.tar.gz LTIB> cd rng-tools-2 LTIB> ./configure --host=arm-linux LTIB> make LTIB> sudo cp rngtest /tftpboot/ltib/home/ Restart your board and execute this command in the board's console: $ cat /dev/hwrng | /home/rngtest -c 1000

  Test Environment i.MX8MP EVK L6.6.52   Backgroud The default BSP will assign SAI3 and I2C3 to M7 when we use imx8mp-evk-rpmsg.dtb. If customer want to assign SAI3 and I2C3 to A53 and test audio in Linux while running M7 sdk with remoterpoc.   Test steps   1. Delete all of audio related code in SDK in below function. BOARD_BootClockRUN  BOARD_RdcInit 2. Modify Uboot   arch/arm/dts/imx8mp-evk-u-boot.dtsi   The RDC will assign SAI3, sdma3 and i2c3 to M7 when M7 start. So we need to delete these lines.      3. Add RDC config in ATF plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c  Assign SAI3, sdma3 and i2c3 to A53.    4.Modify imx8mp-evk-rpmsg.dts Delete rpmsg audio and i2c3. diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts index e43c4dafdb88..4edc0cb71b1c 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts @@ -4,8 +4,3 @@ */ #include "imx8mp-evk-rpmsg.dts" - -&rpmsg_audio { - /delete-property/ fsl,enable-lpa; - /delete-property/ fsl,rpmsg-in; -}; diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts index ddf5f76adc3b..75c9234d84b2 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts @@ -8,11 +8,6 @@ #include "imx8mp-evk.dts" / { - aliases { - i2c0 = &i2c1; - i2c1 = &i2c2; - i2c2 = &i2c_rpbus_3; - }; reserved-memory { #address-cells = <2>; @@ -45,70 +40,6 @@ rsc_table: rsc-table@550ff000 { no-map; }; - audio_reserved: audio@81000000 { - compatible = "shared-dma-pool"; - no-map; - reg = <0 0x81000000 0 0x10000000>; - }; - - micfil_reserved: mic_rpmsg@91000000 { - compatible = "shared-dma-pool"; - no-map; - reg = <0 0x91000000 0 0x100000>; - }; - }; - - sound-wm8960 { - status = "disabled"; - }; - - sound-micfil { - status = "disabled"; - }; - - rpmsg_audio: rpmsg_audio { - compatible = "fsl,imx8mp-rpmsg-audio"; - model = "wm8960-audio"; - fsl,rpmsg-channel-name = "rpmsg-audio-channel"; - fsl,enable-lpa; - fsl,rpmsg-out; - fsl,rpmsg-in; - assigned-clocks = <&clk IMX8MP_CLK_SAI3>; - assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; - assigned-clock-rates = <12288000>; - clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_IPG>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SDMA3_ROOT>, - <&clk IMX8MP_AUDIO_PLL1_OUT>, - <&clk IMX8MP_AUDIO_PLL2_OUT>; - clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k"; - audio-codec = <&codec>; - memory-region = <&audio_reserved>; - power-domains = <&audiomix_pd>; - audio-routing = - "LINPUT1", "MICB", - "LINPUT3", "MICB"; - status = "okay"; - }; - - rpmsg_micfil: rpmsg_micfil { - compatible = "fsl,imx8mp-rpmsg-audio"; - model = "micfil-audio"; - fsl,rpmsg-channel-name = "rpmsg-micfil-channel"; - fsl,enable-lpa; - fsl,rpmsg-in; - assigned-clocks = <&clk IMX8MP_CLK_PDM>; - assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; - assigned-clock-rates = <196608000>; - clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_PDM_IPG>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_PDM_ROOT>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SDMA3_ROOT>, - <&clk IMX8MP_AUDIO_PLL1_OUT>, - <&clk IMX8MP_AUDIO_PLL2_OUT>; - clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k"; - memory-region = <&micfil_reserved>; - power-domains = <&audiomix_pd>; - status = "okay"; }; imx8mp-cm7 { @@ -144,72 +75,10 @@ &flexspi { status = "disabled"; }; -/delete-node/ &i2c3; - -&i2c_rpbus_3 { - compatible = "fsl,i2c-rpbus"; - #address-cells = <1>; - #size-cells = <0>; - status = "okay"; - - pca6416: gpio@20 { - compatible = "ti,tca6416"; - reg = <0x20>; - gpio-controller; - #gpio-cells = <2>; - }; - - ov5640_1: ov5640_mipi@3c { - compatible = "ovti,ov5640"; - reg = <0x3c>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_csi0_pwn>, <&pinctrl_csi0_rst>; - clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; - clock-names = "xclk"; - assigned-clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; - assigned-clock-parents = <&clk IMX8MP_CLK_24M>; - assigned-clock-rates = <24000000>; - csi_id = <0>; - powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; - mclk = <24000000>; - mclk_source = <0>; - mipi_csi; - status = "disabled"; - - port { - ov5640_mipi_1_ep: endpoint { - remote-endpoint = <&mipi_csi1_ep>; - data-lanes = <1 2>; - clock-lanes = <0>; - }; - }; - }; - - codec: wm8960@1a { - compatible = "wlf,wm8960,lpa"; - reg = <0x1a>; - wlf,shared-lrclk; - SPKVDD1-supply = <&reg_audio_pwr>; - }; -}; - &pwm4{ status = "disabled"; }; -&sai3 { - status = "disabled"; -}; - -&micfil { - status = "disabled"; -}; - -&sdma3{ - status = "disabled"; -}; - &uart3 { status = "disabled"; };   Result We can play audio on wm8960 after we load M7 firmware.

Apply this patch into the LTIB folder.

The i.MX27 PDK, with Smart Speed™ technology, is a completely integrated hardware and software solution designed to simplify product development so you can focus on the critical differentiation needed for market success. Reduce development time and design products that have power to spare, even when running multiple applications simultaneously. Receive stellar Ethernet and video performance in a system design that dramatically reduces power consumption. Features i.MX27 Applications Processor - ARM9™ 128 MB DDR SDRAM 256 MB NAND FLASH Power Management (PMIC MC13783) + Power Circuitry Audio HS USB PHY Touch Controller 10/100 Ethernet port Accelerometer MMA7450L (Freescale) User I/O Connectivity (FM, 802.11, Bluetooth, USB OTG, USB HS) Button 2.7" TFT Display 2MP Camera Module SD card, ATA HDD External Connectors (dock, headphones, TV out, GPS) Microphone Speaker Debug Ethernet Port Debug Serial Port JTAG Reset, Interrupt, Boot Switches Debug LEDs CodeTest Interface Power Source Current/Power Monitoring

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-344896 

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

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

On behalf of Gopise Yuan. This is a patch to fix USB plug/unplug event detection failure issue on ChipIdea IP under corner case.

Use case: iMX8QXP system can be a video input source to another system.   Hardware Pins： LCDIF_D00 ~ LCDIF_D07 LCDIF_CLK LCDIF_VSYNC LCDIF_HSYNC LCDIF_EN   Reference patch： It is based on L5.4.70_2.3.0 GA BSP.  File: L5.4.70_2.3.0-iMX8QXP-LCDIF-add-YUV422-8-bits-output.patch Customer can change the timing parameters in file "panel-lcdif-yuv422.c" as needed, the default timing is a 1280x720 P30 mode: static const struct display_timing yuv422_lcd_timing = {     .pixelclock = { 74250000, 74250000, 74250000 },     .hactive = { 1280, 1280, 1280 },     .hfront_porch = { 220, 220, 220 },     .hback_porch = { 110, 110, 110 },     .hsync_len = { 40, 40, 40 },     .vactive = { 720, 720, 720 },     .vfront_porch = { 20, 20, 20 },     .vback_porch = { 5, 5, 5 },     .vsync_len = { 5, 5, 5 },     .flags = DISPLAY_FLAGS_DE_HIGH, };   Test application: drm_test_yuv.zip: it can set framebuffer to UYVY mode, in this case, no CSC is needed, the data in framebuffer memory will be same as output on display data interface. drm_test_rgb.zip: it can set framebuffer to RGBA mode, in this case, RGB to YUV CSC is needed, application can draw RGB data into framebuffer as normal, the LCDIF will convert it to YUV422 format on the fly, then output the YUV data to display interface.    

ATK (Advanced Toolkit) ATK (Advanced Toolkit) is a Windows software for programming the flash memory of i.MX boards. Using ATK This section will describe the procedure to erase the flash memory and program the bootloader. 1 - Connect a serial cable between PC and i.MX board. 2 - Some hardware configurations (switches) must be done to flash the board.   Set SW2 switch as below: Switch SW2 -> 11111 3 - Run ATK going to Start -> Programs -> AdvancedToolKit -> AdvancedToolKit   Set the options:   Device memory -> DDR; Custom Initial File -> (keep it unmarked)   Communication Channel -> Serial Port (Usually COM1) 4 - Click on Flash Tools to erase, program or dump the the flash memory and click GO h4> Flash Programming The next step is to program the bootloader image into the board's Flash following the steps below. 1 - Select the parameters as shown in the figure below and press Program. The bootloader binary image file can be found into your Board Support Package Set Program, NOR Spansion 2 - Add it on Image File field and press Program. 3 - Close ATK, turn off the board and set switch back as shown in the picture below. Set SW2 switch as below: Switch SW2 -> 11010 Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe

i.MX 35 PDK board has 256 MB of RAM, due to a bug in Redboot bootloader compiled for the board effectively there is only 128 MB available. This procedure fixes this bug to be able to use 256 MB of RAM. Redboot supporting 256 MB of RAM 1. Download the attached Redboot256.bin file. 2. Flash the new redboot image instead of the old one using one of the methods: All Boards Updating RedBoot Through RedBoot