SW Environment Setup: 1. Prepare L5.10.35 Yocto and build Image  The prebuilt image also is available and useable. 2. Flash image to the SD card  Refer to the Yocto User Guide. 3. Compile flash.bin without M4 and flash it to sdcard (flash.bin as attachment)  make SOC=iMX8QM flash sudo dd if=flash.bin of=/dev/sde bs=1k seek=32 conv=fsync HW Environment Setup: Prepare the imx8qm MEK CPU board and base board and DB9 male cable, connect to CAN0 and CAN1 female connector on base board. (Pin to Pin connection) User Case: 1. Power on board and configure specify dtb file in uboot  setenv fdt_file imx8qm_mek.dtb 2. Boot up and config bitrate for can0 and can1 in kernel root@imx8qmmek:~# ip link set can0 up type can bitrate 500000 root@imx8qmmek:~# ip link set can1 up type can bitrate 500000 3. Check CAN0 and CAN1 devices root@imx8qmmek:~# ifconfig can0: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 85 can1: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 86 3. Run candump for CAN1 root@imx8qmmek:~# candump can1 & [1] 1215 [ 65.624580] can: controller area network core [ 65.630225] NET: Registered protocol family 29 [ 65.641158] can: raw protocol 4. Run cansend for CAN0 root@imx8qmmek:~# cansend can0 5A1#11.2233.44556677.88 can1 5A1 [8] 11 22 33 44 55 66 77 88   The above red is output result from CAN1.

MAX resolution 1024 x 768 Factory Details:      Long name:    Freescale: Hardware (VPU) Encoder      Class:            Codec/Encoder/Video      Description:    Encodes raw YUV 4:2:0 data to MPEG4 SP, H.264 BP or H.263 (Annex J, K (RS=0 and ASO=0) and T) elementary data;Enco des raw YUV 4:2:0, 4:2:2 horizontal, 4:2:2 vertical or 4:0:0 data into MJPEG elementary data;      Author(s):       Multimedia Team <[email protected]>      Rank:             primary (256) Plugin Details:      Name:                    mfw_vpuencoder      Description:            Encodes Raw YUV Data to MPEG4 SP, H.264 BP or H.263 data. For H.263 P0, the source frame rate must be 3000 0/1001 fps      Filename:               /usr/lib/gstreamer-0.10/libmfw_gst_vpu_enc.so      Version:                  2.0.2      License:                  unknown      Source module:        gst-fsl-plugin      Binary package:       Gstreamer Multimedia Plugins (Freescale)      Origin URL:              http://www.freescale.com GObject   +----GstObject         +----GstElement               +----MfwGstVPU_Enc Pad Templates:    SINK template: 'sink'       Availability: Always       Capabilities:          video/x-raw-yuv                   format: I420                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: YV12                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: NV12                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: Y42B                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: Y444                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]    SRC template: 'src'        Availability: Always        Capabilities:            video/mpeg                             width: [ 48, 1280 ]                           height: [ 32, 720 ]                   mpegversion: 4                 systemstream: false            video/x-h263                             width: [ 48, 1280 ]                            height: [ 32, 720 ]            video/x-h264                             width: [ 48, 1280 ]                            height: [ 32, 720 ]            image/jpeg                             width: [ 48, 8192 ]                            height: [ 32, 8192 ] Element Flags:    no flags set Element Implementation:    Has change_state() function: 0x2b01c98c    Has custom save_thyself() function: gst_element_save_thyself    Has custom restore_thyself() function: gst_element_restore_thyself Element has no clocking capabilities. Element has no indexing capabilities. Element has no URI handling capabilities. Pads:    SRC: 'src'      Implementation:      Pad Template: 'src'    SINK: 'sink'      Implementation:        Has chainfunc(): 0x2b01de28        Has custom eventfunc(): mfw_gst_vpuenc_sink_event        Has bufferallocfunc(): mfw_gst_vpuenc_buffer_alloc      Pad Template: 'sink' Element Properties:    name                : The name of the object                          flags: readable, writable                          String. Default: null Current: "mfwgstvpu_enc0"    codec-type          : selects the codec type for encoding                          flags: readable, writable                          Enum "MfwGstVpuEncCodecs" Default: 2, "std_avc" Current: 2, "std_avc"                             (0): std_mpeg4        - STD_MPEG4                             (1): std_h263           - STD_H263                             (2): std_avc             - STD_AVC                             (7): std_mjpg           - STD_MJPG    profile             : enable time profile of the vpu encoder plug-in                          flags: readable, writable                          Boolean. Default: false Current: false    width               : width of the frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 48 - 8192 Default: 48 Current: 0    height              : height of the frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 32 - 8192 Default: 32 Current: 0    bitrate             : target bitrate (in kbps) at which stream is to be encoded - 0 for VBR and others for CBR                          flags: readable, writable                          Unsigned Integer. Range: 0 - 32767 Default: 0 Current: 32768    gopsize             : gets the GOP size at which stream is to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 32767 Default: 30 Current: 30    qp                  : gets the quantization parameter - range is 0-51 - will be ignored for CBR (bitrate!=0)                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 15 Current: 4294967295    max-qp              : Maximum quantization parameter for CBR - range is 0-51 for H264 and 1-31 for MPEG4 - lower value brings be tter video quality but higher frame sizes                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 51 Current: 4294967295    min-qp              : Minimum quantization parameter for CBR - range is 0-51 for H264 and 1-31 for MPEG4 - lower value brings be tter video quality but higher frame sizes                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 0 Current: 4294967295    gamma               : gamma value for CBR - tells VPU the speed on changing qp - lower will cause better video quality                          flags: readable, writable                          Unsigned Integer. Range: 0 - 32768 Default: 24576 Current: 24576    intrarefresh        : 0 - Intra MB refresh is not used. Otherwise - At least N MB's in every P-frame will be encoded as intra MB 's.                          flags: readable, writable                          Unsigned Integer. Range: 0 - 3600 Default: 0 Current: 0    h263profile0        : enable encoding of H.263 profile 0 when codec-type is set to std_h263                          flags: readable, writable                          Boolean. Default: false Current: false    loopback            : disables parallelization for performance - turn off if pipeline with decoder                          flags: readable, writable                          Boolean. Default: true Current: true    intra-qp            : Quantization parameter for I frame. When this value is -1, the quantization parameter for I frames is auto matically determined by the VPU. In MPEG4/H.263 mode, the range is 1.C31; in H.264 mode, the range is from 0.C51. This is ignored for STD_MJPG                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 15 Current: 4294967295    crop-left           : The left crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    crop-top            : The top crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    crop-right          : The right crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    crop-bottom         : The bottom crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    rotation-angle      : Pre-rotation angle - should be 0, 90, 180 or 270                          flags: readable, writable                          Unsigned Integer. Range: 0 - 270 Default: 0 Current: 0    mirror-direction    : mirror direction from source image to encoded image                          flags: readable, writable                          Enum "MfwGstVpuEncMirDir" Default: 0, "none                " Current: 0, "none                "                             (0): none                     - MIRDIR_NONE                             (1): vertical mirroring     - MIRDIR_VER                             (2): horizontal mirroring - MIRDIR_HOR                             (3): both directions       - MIRDIR_HOR_VER    h264-byte-stream    : Generate H.264 byte stream format of NALU. Take effect for H.264 stream only.                          flags: readable, writable                          Boolean. Default: true Current: true

i.MX8M_DDR3L_register_programming_aid is created for DDR3L validation board.

This is a hack to support programming EEPROM I2C devices for MX28 boot. See post at: Re: mx28 boot issues with SSP (SD card) *** USE AT YOUR OWN RISK ***

Several customers met uuu failure because their board doesn't use same CC logic (ptn5110) of i.MX8MM EVK. For this problem it's able to disable CC logic and to force device mode of u-boot. Shared the patch based on 4.14.78 for reference.

Based on example code provided in AN4466 I've written a simple memory calibration script for ARM DS-5 that runs same steps and prints out results for DQS, read and write calibration. This script can be run on new boards in order to find optimum calibration settings for the memory controller. Prior to running this script it is necessary to run standard memory initialization script! When bringing up new board: obtain default memory initialization script for memory type you're using (for example from DDR stress tester package) and modify the memory controller settings according to memory device you are going to use. run DDR stress tester with the given configuration on target frequency you're going to use to make memory works with given settings (default values for calibration are  fine in most cases unless there's issues with PCB and/or routing). run memory init script and then the attached script to obtain calibrated values. Re-test Vladan

The patches are based on iMX53 L2.6.35_ER1109 BSP. In default linux BSP, the followed two pathes were supported in kernel driver mxc_v4l2_capture.c: CSI->IC->MEM CSI->MEM After appied these two patches, it can support the followed path: CSI->VDI->IC->MEM In this mode, the VDI de-interlace will be handled on the fly, so the whole system bandwidth will be reduced. Limitations: 1. Since the IC can only output resolution up to 1024*1024, so this is the limation on output. 2. Only VDI motion mode 2 was supported. mxc_v4l2_tvin_vdi_ic.zip: It is the test aplication, test command: "./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 2" "-i 2" means CSI->VDI->IC->MEM path.

Hi everybody, The attached document walks you through to build a Linux image for UDOO Quad board with QT5 support by using a Yocto Project build environment. The Kernel used in this process is 3.14.52. I hope you find it useful. Best regards, Carlos

Following docs(English or Chinese version) are also can be referred as a hand on guide. Freescale i.MX6 DRAM Port Application Guide-DDR3 飞思卡尔i.MX6平台DRAM接口高阶应用指导-DDR3篇 Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.Mx6DQSDL DDR3 Script Aid Please find i.MX6SX DDR3 Script Aid through below link. i.MX6SX DDR3 Script Aid Please find i.MX6UL DDR3 Script Aid through below link. I.MX6UL DDR3 Script Aid Please find i.MX6SL LPDDR2 Script Aid through below link.. i.Mx6SL LPDDR2 Script Aid History: 0.03 1. update ZQ_LP2_HW_ZQCS         2. add MMDC SW reset         3. add disable DQS gating and reset read FIFO Any questions are welcome!

Issue Description When WM8960 is working as master mode and target sample rate is 44100Hz or 48000Hz, it's found no sound can be heard on some i.MX boards. Impact Software Baseline: Linux 4.1.15_2.0.0 release or previous versions. Impact Hardware Platform: MCIMX6UL-EVKB, MCIMX6ULL-EVK and MX7SABRE boards which have WM8960 as Audio Codec. Root Cause When WM8960 is working as master mode, if input MCLK is 12.288MHz and configure "PLLPRESCALE =2 and SYSCLKDIV[1:0] =1", wrong BCLK and LRCLK output maybe got on some boards. And then it causes no sound output. Solutions After change the WM8960 PLL setting from “PLLPRESCALE =2 and SYSCLKDIV[1:0] =1” to “PLLPRESCALE =1 and SYSCLKDIV[1:0] =2”, the failure parts can work normally. See attached patch. The formal patch is also included into the releases starting from L4.1.15_2.0.1. See http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-bsp/recipes-kernel/linux/files?id=imx_4.1.15_2.0.1

This tutorial teaches how to flash bootloader using ATK. 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 S18 switch as below: Switch S18 -> 111100 3 - Run ATK by clicking Start -> Programs -> AdvancedToolKit -> AdvancedToolKit      Set the options:    Device memory -> DDR; Custom Initial File -> (keep it unmarked)    Communication Channel -> Serial Port (Usually COM1) 4 - Click Flash Tools to erase, program or dump the the flash memory and click GO 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 PackageSet Program, NOR Spansion, Bi Swap 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. 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

The i.MX 6 D/Q L3.035_1.0.3 patch release is now available on www.freescale.com ·         Files available # Name Description 1 L3.0.35_1.0.3_TEMP_PFD_PATCH This patch release is based on the i.MX 6Dual/6Quad Linux   12.09.01 release. The purpose of this patch release is update thermal sensor   calibration routine and correct the PFD workflow in U-Boot. More details in   the release notes.

We are pleased to announce that Pins Tool for i.MX Applications Processors v5 is now available.   The Pins Tool for i.MX Applications Processors is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations. Features Desktop application Muxing and pin configuration with consistency checking Multicore support Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE Supports English and Chinese (simplified) languages, based on locale settings. Please refer to user manual for details. ANSI-C initialization code Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Selection of Pins and Peripherals Package with IP blocks Routed pins with electrical characteristics Registers with configured and reset values Power Groups with assigned voltage levels Source code for C/C++ applications Documented and easy to understand source code CSV Report and Device Tree File     Downloads To download the installer for all platforms, please login to our download site via:  http://www.nxp.com/pinsimx Please refer to Pins Tool Documentation  for installation and quick start guides.   Overview of Changes - version 5 New Configuration Wizard allows to specify the default core for multi-core processors. Data Manager - allows overview of downloaded data, their versions, tool support information, update out dated, or manually download new data. Copy/Paste of pin(s) supported in Routed Pins view. Added in-tool tutorials - eclipse Cheat Sheets integration. Overview of Changes - version 4.1 Undo/Redo supported. Product based on Eclipse Oxygen release 3. Unified import wizard. A single import source is implemented. It allows you to import all supported types of C files. Community i.MX Processors 

Why SWPDM? i.MX8MMINI, i.MX8MNANO and IMX8MPLUS  In order to process human voice, it is required to have the best audio resolution in the incoming data captured by the microphones. This mean, having a resolution of 16bits is not enough to capture all the information to properly process the voice. Voice processing requires a peripheral capable of capture data on a 32bits resolution within the range of the most common sample rates (16kHz, 44.1kHz, 48Khz, etc.). On the i.MX8M family there is a peripheral which fulfill those requirements and is called MICFIL. MICFIL is a peripheral which convert PDM (Pulse Density Modulation) data to PCM (Pulse-Code Modulation) data. The PDM format encode the analog signal in just one bit. Where 1 means the signal is increasing in amplitude while 0 means the opposite. In the other hand, the PCM format encode the data in 8, 16, or 32 bits. The advantage of PDM is that the creation of microphones is cheaper than having PCM microphones but then you will need a software or hardware which do the conversion for PDM to PCM since PDM cannot be processed. This is the reason of the MICFIL peripheral. However, not all the MICFIL's on the difference SOMs are the same. While the i.MX8MPLUS has a resolution of 32bits its smaller brothers do not. i.MX8MMINI and i.MX8MNANO have a MICFIL which only allows a resolution up to 16bits. For most of the cases it will be enough but not for voice processing. Nevertheless, not everything is lost; As mentioned previously, the PDM to PCM conversation can be done by hardware or by software. NXP also have the algorithm in software to do the conversation. Therefore, if a Mini or Nano is being used for voice processing it is fully recommended to use the ALSA SWPDM Plugin and avoid MICFIL peripheral.   Using the Plugin   In order to use the plugin, it is required to change the DTB to  imx8mm-evk-8mic-swpdm.dtb , when using the i.MX8MM or  imx8mn-evk-8mic-swpdm.dtb , when using the i.MX8MN. In order to do so follow the next steps: Please notice below example if for Mini. For Nano will be the same just changing the DTB name to imx8mn-evk-8mic-swpdm.dtb. # Stop at U-boot u-boot=> edit fdtfile edit: imx8mm-evk-8mic-swpmd.dtb u-boot=> saveenv u-boot=> boot   The change in the DTB is required to disable MICFIL so Linux can receive the raw data and sent it to the plugin. However, the plugin is not enabled by default, users need to explicit add the plugin to their ALSA pipeline. The way of doing so is by adding the following device to  /etc/asound.conf : pcm.cic { type cicFilter slave "hw:imxswpdmaudio,0" delay 100000 gain 0 OSR 48 }   Where: pcm.cic : Is an arbitrary name which allow ALSA to find the requested devices when setting the  -D  flag with  arecord  or  aplay . type cicFilter : This is the plugin type which is named with the algorithm name. slave: Name of the physical or virtual device which will be controlled by the cicFilter plugin. The recommendation is to always have the actual hardware connected to this plugin. delay : Amount of time in microsecond which the plugin won't write to the buffer, but it still does the conversion. The value could be between 100us to 1'000,000us. By removing the property from the structure, the delay will be set to 0. gain : A value between 0 and 100. OSR : Is related to the quality of the signal by increasing the PDM sample rate. With a higher valuer a best quality on the audio can be achieved. However, keep in mind than having a higher value will also require more memory to store all the new data due to the oversampling. The valid values for the OSR are: 48, 64, 96, 128, and 192. With all being said, the only thing left is to test the plugin by running the following command: $ arecord -D cic -c4 -r16000 -f s32_le --period-size=96 -d5 -v test.wav   Data Flow   When using PDM Microphones the default data flows is as shown in figure 1. Where the data is capture in the MICFIL peripheral and when it get to the Sound Drivers the data is already converted to PCM, so from the Kernel perspective the data is treaty as PCM values and the conversion from PDM to PCM is done under the hardware. However, with the changes we made earlier on the device tree and adding the plugin on /etc/asound.conf the data flows is as follow: Where the conversion from PDM to PCM is done just before giving the buffer to the application layer; Thus, conversion is made on User Space and the kernel is aware data have a PDM format. Another difference you can see is that MICFIL is disable and instead the datalines are controlled by SAI5. This is true for i.MX8MM, i.MX8MN, and i.MX8MP. Although for the application is a transparent change the truth is that the entire pipeline change, so please be aware of how the data is flowing to your application.   Integration With AFE   The next and final step is integrating the plugin with AFE and VoiceSeeker. The integration of SWPDM requires to apply a patch to the SWPDM repository. The patch changes the amount of period sizes allowed on the plugin. By default, the plugin only allows certain values which are:  48 Samples = 3ch x 4bytes format x 16samples = 192 bytes. 48 Samples = 2ch x 4bytes format x 48samples = 384 bytes. 48 Samples = 4ch x 4bytes format x 48samples = 768 bytes. 96 Samples = 4ch x 4bytes format x 96samples = 1,536 bytes. Although, AFE and VoiceSeeker are extremely configurable, 48 or 96 samples for the algorithm is too small. Meaning that the SWPDM should support a bigger period size, not all the way around. By applying the attached file, the plugin can have a period size from 64 bytes (1ch and 16 samples) up to 16,384 bytes (4ch and 1024 samples). However, the number of samples can vary depending on the OSR value and the number of channels. Once the patch has been applied in must be installed on: /usr/lib/alsa-lib (if the repository is being built on a standalone environment). AFE opens a device called mic  for capture the microphones' input. This device can have anything below it. By default, have the following definition on /etc/asound.conf  (after following the steps described on the TODO.md file). # mic represents the physical source (capture) pcm.mic { type plug slave.pcm "hw:micfilaudio,0" }   The devices opens the MICFIL driver, but on this case MICFIL is disable, which means the definition of the device must change. From above cic  device the definition can be copy and paste and then tweak one parameter. The delay must be set to 0 by removing the property or setting it explicitly on the structure. If this step if forgotten this might cause some underrun issues. The device definition will be: pcm.mic { type cicFilter slave "hw:imxswpdmaudio,0" delay 0 gain 0 OSR 48 }   The last thing to do will be running AFE with VoiceSeeker as usual. $ /unit_tests/nxp-afe/voice_ui_app & $ /unit_tests/nxp-afe/afe libvoiceseekerlight &   Considerations and Restrictions With all that said, there are few things left to mention, which are the considerations and restrictions on the plugin itself. These are good things to know before adding the plugin into any application. The plugin is supported from the Linux BSP 5.15.32. Currently the plugin only supports up to 4 channels. Plugin only outputs a S32_LE format (if required another format please use MICFIL). By applying above patch, the period size must be a multiple of 16, due to a limitation on the algorithm itself, rather than the plugin. The driver only allows to have one mic per data-line while MICFIL allows to have two microphones per data-line. The SWPDM Plugin is based on the External Plugin: I/O Plugin. This means it also have the restriction of this ALSA plugin, being the following restriction the most important one: "The I/O-type plugin is a PCM plugin to work as the input or output terminal point, i.e. as a user-space PCM driver". In other words, there can't be any device/plugin on top of it, not even a "plug" type. 

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

  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    

Hello, this post describes how you can add Japanese Language to the Yocto BSP. There are just a few steps to achieve. It was tested on the i.MX93-FRDM board, i.MX93-EVK and i.MX8M (Family). And Linux kernel 6.6.36.   The first step before to start your board building according to the Yocto Project User's Guide, is adding the below lines to the local.conf file: GLIBC_GENERATE_LOCALES = "en_US.UTF-8 ja_JP.UTF-8" IMAGE_LINGUAS = "en-us ja-jp" IMAGE_INSTALL:append = " \ glibc-gconv-euc-jp \ glibc-gconv-sjis \ glibc-gconv-utf-16 \ glibc-utils \ fontconfig \ ttf-bitstream-vera \ ttf-dejavu-sans \ "   Where:  glibc-gconv-*: Adds Japanese encoding conversions.   After building, flash the Image to the board and boot it. You can check if the Japanese font was installed successfully with: root@imx93frdm:~# locale -a C POSIX en_US en_US.utf8 ja_JP ja_JP.utf8   We can see it was installed successfully: ja_JP ja_JP.utf8   Then, we can change the Language at Runtime with: root@imx93frdm:~# export LANG=ja_JP.UTF-8 root@imx93frdm:~# export LC_ALL=ja_JP.UTF-8   Finally, probe with a command that supports Japanese outputs like "date": root@imx93frdm:~# date 2024年 2月 27日 火曜日 17:29:11 UTC     I hope this information can helps to you.   Best regards, Salas.

Test environment: i.MX93FRDM LF6.6.36. With Yocto training.