i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
HW: i.MX7 SabreSD SW: Android N7.1.1_1.0.0   There is KPP module on i.MX7, but NXP reference board didn't have it. We reworked a "keypad" and has the demo. Signal: For testing, launch an app in Android that can accept text input. KPP also supports multiple input, the "A" is showed by pressing "shift" + "a".   As a side note, 1. The input device driver is drivers/input/keyboard/imx_keypad.c 2. The input event driver is drivers/tty/vt/keyboard.c Original Attachment has been moved to: 0001-Enable-KPP-on-i.MX7.patch.zip
View full article
It is based on L3.0.35_GA4.1.0 BSP.   In default Linux BSP, there are 3 kinds of de-interlace mode, motion =0,1,2 mode, motion mode 0 and 1 will use three fields for de-interlace, and motion mode 2 wil use one field for de-interlace, so the whole fps is 30. In this mode, for motion mode 0 and 1, field 1,2,3 was used for first VDI output frame of display; and field 3,4,5 was used for second VDI output frame of display; field 5,6,7 was used for third VDI output frame of display. One field data (such as 2,4,6) was used only once, so there is data lost.   After applied these patches, the VDI de-interlace output will be 60fps: for motion mode 0 and 1, field 0,1,2 was used for first VDI output frame of display; and field 1,2,3 was used for second VDI output frame of display; field 2,3,4 was used for third VDI output frame of display. So all field data will be used twice, there is no video data lost, the VDI quality was improved.   Kernel patches: 0001-Add-MEM-to-VDI-to-MEM-support-for-IPU.patch 0002-Add-IPU-IC-memcpy-support.patch 0003-IPU-VDI-support-switch-odd-and-even-field-in-motion-.patch 0004-IPU-VDI-correct-vdi-top-field-setting.patch   mxc_v4l2_tvin_imx6_vdi_60fps.zip: this is the test application sample code.   Test commands, parameter "-vd" means double fps VDI: ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 720 -oh 480 -m 0 -vd  
View full article
iMX8QXP/iMX8QM have hardware JPEG decoder: The JPEG-D-X core. This is the example code to use this hw decoder in M4 SDK to decode JPEG files. M4_JPEG_DECODER_SDK_2.5.1.7z The attached "rear_view_camera_jpegdec.tar.bz2" is the updated source code for "SDK\boards\mekmimx8qx\demo_apps\rear_view_camera". It is based on SDK 2.5.1 for iMX8QXP MEK. The "rear_view_camera_jpegdec.patch" is the modified code, it hasn't included the added "fsl_jpeg_dec.c" and "fsl_jpeg_dec.h".   The testing used two 256*256 JPEG files, they are RGB color space. We used followed commands to build them into flash.bin: ./mkimage_imx8 -soc QX -rev B0 -append ahab-container.img -c -scfw scfw_tcm.bin -m4 m4_rear_view_camera.bin 0 0x34FE0000 --data demo_rgb.jpg 0x84000000 --data demo_rgb2.jpg 0x84008000 -out flash.bin   If customer need change the JPEG resoluion, they can change them in file "fsl_jpeg_dec.h", APP_JPEG_SIZE_OF_KB is the JPEG file length in memory, aligned in KB.   #define APP_JPEG_WIDTH (256) #define APP_JPEG_HEIGHT (256) #define APP_JPEG_SIZE_OF_KB (32) #define APP_JPEG_FORMAT JPEG_RGB #define APP_JPEG_BUFFER (0x84000000)   To created RGB format JPEG file from RGB data, the customer can use linux unit test application "/unit_tests/JPEG/encoder_test.out". M4_JPEG_DECODER_WINDOW_MODE_SDK_2.5.1.7z Based on JEPG decoder, added DPU CSC support and render JEPG decoded video in overlay window. The architecture is followed: NXP logo is put in FetchLayer0 with RGB565 format, after LayerBlend0, it will be the prim layer for LayberBlend1 (FetchLayer0 can't be used as prim layer for LayerBlend), the JPEG decoder output is put to FetchDecoder0. RGB888 format, and it will be resize to 640*480, and put to x=100, y=100 of the display. (Only the sec layer of LayerBlend can be window mode). Some limitation for layer selection in LayerBlend:
View full article
Qt Creator can be a very good IDE in order to develop great QT applications. This IDE does not only helps with syntax highlighting, access to examples and tutorials, but also helps you to configure different toolchains Qt binary versions and target options. First download the binary installer from: For 32 bits: $ wget http://releases.qt-project.org/qtcreator/2.6.2/qt-creator-linux-x86-opensource-2.6.2.bin For 64 bits: $ wget http://releases.qt-project.org/qtcreator/2.6.2/qt-creator-linux-x86_64-opensource-2.6.2.bin execute the binary $ ./qt-creator-linux-x86_64-opensource-2.6.2.bin Follow the Installer GUI and choose a location. Default options should be OK. in my case the installation was done here: $ /home/b35153/qtcreator-2.6.2/bin Open Qt Creator (in my case from command line, use "&" to regain control of the terminal) $./qtcreator & Open Tools -> Options Choose Build & Run  on the menu of the left. and Select the Compilers Tab Here you can add the toolchain GCC compiler of your convenience. It will appear in the "Manual"  section. Now click on Qt Version Tab.  Here you can add the Qmake that you had created with your Qt installation; for example, the Qt5 installation described here: Building QT for i.MX6 It will appear in the Manual section. In my case I have Qmake for PC and Qmake for i.MX6. Now click on Kits Tab Here you can create combinations of Compilers and Qmake, and also specify where do you want the executables to go. In my case here I combined the i.MX6 toolchain and the Qmake for I.MX6 i had created. I did not set up device configuration since the sysroot is already shared to my device via NFS, but you can configure it so the files are sent via ssh to your device. And that's It! Next time you load a project you can choose which Kit you want to work on, and it will be compiled just as you need.
View full article
1. Follow all instructions from Freescale's github repo except the last bitbake command 2. Run hob under the build folder build$ hob & 3. On the GUI, select machine and image, then build 4. In case you need to flash an SD Card, hob does not produce an .sdcard image, so as a workaround, close hob and on the same console run build$ bitbake <image>     where image must be the same as the one you choose with hob 5. Flash your SD card build$ sudo dd if=tmp/deploy/images/fsl-image-gui-imx6qsabresd.sdcard of=/dev/sdX bs=4M NOTES: In case of building issues, please follow this link In case of booting issues, make sure: 1. board DIP switches are set correctly 2. you have chosen the correct machine before baking If issues persist, report it to the community
View full article
How to Test Yocto for i.MX6 i.MX Yocto Project: How Can I Collaborate on the Freescale Yocto Project? i.MX Yocto Project: How Can I Build the Freescale Yocto Images using bitbake? i.MX Yocto Project: How Can I Build the Freescale Yocto Images using hob? i.MX Yocto Project: What Can I Do if I Run Into a Compilation Error? i.MX Yocto Project: Are There Prebuilt Images Available? i.MX Yocto Project: How Can I Quicken the Compilation? i.MX Yocto Project: how can I conserve disk space during builds? i.MX Yocto Project: How do I add an existing package to an image? i.MX Yocto Project: Can I use a virtual machine to build? i.MX Yocto Project: How can I build an image with (latest) mainline kernel? i.MX Yocto Project: How can I (quickly) modify a package' source code and test it? i.MX Yocto Project: How can I find out the packages include on an image? i.MX Yocto Project: How can I compile the kernel manually? i.MX Yocto Project: How can I patch the kernel? i.MX Yocto Proyect: How can I create a new Layer? i.MX Yocto Project: How can I contribute to the community? i.MX Yocto Project: Where can I see current  BSP issues? i.MX Yocto Project: Where are the mainstream repositories hosted? Tutorials: Yocto Training - HOME http://www.slideshare.net/OtavioSalvador/yocto-training-in-english - Great tutorial created by the Community's maintainer (there is also a Portuguese version) i.MX Yocto Project: Freescale Yocto Project Tutorial - It covers some basic developing tasks Others: Useful bitbake commands i.MX Yocto Project: ltib versus bitbake
View full article
This documents describes the neceesary steps to set up Qt Creator with the Qt5 toolchain that is available as part of the 3.14.28 BSP Release. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release L3.14.28 or higher. For this example we'll use the Freescale BSP Release L3.14.28 but you may use future BSP releases that include the Qt toolchain. - Freescale BSP Release Documentation L3.14.28 (login required) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20Information&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=gz&WT_ASSET=Documentation&fileExt=.gz&Parent_nodeId=1337637154535695831062&Parent_pageType=product&Parent_nodeId=1337637154535695831062&Parent_pageType=product 3) Qt5 Meta Toolchain (Poky 1.7 qt5 / L3.14.28 for our example but you may use the qt toolchain that corresponds to the BSP that will be used) For information on how to extract and install the meta toolchain please follow the steps on the next document but with the following command: $ bitbake meta-toolchain-qt5 https://community.freescale.com/docs/DOC-95122 Task #7 - Create the toolchain Then run the script. fsl-release-bsp/<BUILD_DIR>/tmp/deploy/sdk/poky-glibc-x86_64-meta-toolchain-qt5-cortexa9hf-vfp-neon-toolchain-1.7.sh Installing Qt Creator We will use the Open Source version of Qt Creator. Please make sure that your application does comply with the requirements of Open Source Software before installing. You may download Qt Creator Open Source for Linux from the following link: http://www.qt.io/download-open-source/ Once you downloaded the installer you will need to make sure that the file has permission to be executed. You can add this with the following command: $ chmod +x qt-unified-linux-x64-2.0.2-2-online.run Then run the installer $ ./ qt-unified-linux-x64-2.0.2-2-online.run After the information from the repositories has been fetched you will be asked where to install Qt Creator. Then you will be asked which components to install. We will install Qt 5.4 which is the one supported on the 3.14.28 BSP release. You will need to accept the License Agreement and then the installer will fetch and install the necessary files. Configuring Qt Creator Once it’s finished downloading, launch Qt Creator. You can do this with the following command: cd <INSTALATION_DIR>/Tools/QtCreator/bin $./qtcreator.sh Under the Tools top bar menu, chose Options… On the Options window’s left menu chose Build & Run and then the Compilers tab and select Add GCC. On the next screen chose a name for this Compiler (i.e. i.MX Qt5) and then select the Compiler path, which may vary depending on where you have it installed but by default should be in: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ It should then be detected as arm-linux on the ABI section. Next select the Qt Versions tab and click on Add… Look for the qmake on the toolchain path, which is by default: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake Finally, on the Kits tab add a new kit and select the sysroots from the toolchain, which is by default located in: /opt/poky/<VERSION>/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi Qt Creator is now configured for building for the i.MX6.
View full article
The document will introduce all steps for poring WM8960 audio codec to freescale android4.2.2 BSP. Attachments include : (1)Document for porting (2)Codec driver : wm8960.c (3)Machine driver: imx-wm8960.c (4)wm8960 schematic for reference (5)Android Audio HAL: config_wm8960.h (6)schematic: MX6QDL-PIANO-CNFV1.DSN (7)i.MX6DL BSP files mx6dl_piano.c mx6dl_piano.h mx6dl_piano_pmic_pfuse100.c (8)i.MX6Q BSP files mx6q_piano.c mx6q_piano.h mx6q_piano_pmic_pfuse100.c   Freescale TICS Team Weidong.sun
View full article
1. Description     1) Support HDMI interlaced display mode, the followed format had been verified.         CEA format 5: 1920x1080i @60Hz         CEA format 6&7: 720(1440)x480i @60Hz         CEA format 20: 1920x1080i @50Hz         CEA format 21&22: 720(1440)x576i @50Hz     2) Support LCD interface for interlaced display mode, 1920x1080i @50Hz(CEA format 20)        had been verified. 2. File List -- 0001-IPUv3-support-interlaced-display-mode.patch    Patch to support interlaced display output for iMX6 ipuv3. -- 0002-iMX6-HDMI-support-interlaced-display-mode.patch    Patch to support interlaced display mode for iMX6 HDMI driver. -- 0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch    Patch to support interlaced display mode for iMX6 LCD interface driver.    -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - L3.0.35_4.1.0_GA_iMX6DQ kernel. 4. How to use -- Copy the patch files to kernel folder.     $ cd ~/ltib/rpm/BUILD/linux-3.0.35/     $ git apply ./0001-IPUv3-support-interlaced-display-mode.patch     $ git apply ./0002-iMX6-HDMI-support-interlaced-display-mode.patch     $ git apply ./0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch -- Build the new kernel image:     $ cd ~/ltib/rpm/BUILD/linux-3.0.35     $ export CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi-     $ export ARCH=arm     $ make imx6_defconfig     $ make uImage -- Uboot parameters for video mode    Output 1080i50 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1920x1080Mi@25,if=RGB24,bpp=32"    Output 1080i60 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1920x1080Mi@30,if=RGB24,bpp=32"    Output 576i50 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1440x576Mi@25,if=RGB24,bpp=32"    Output 480i60 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1440x480Mi@30,if=RGB24,bpp=32"    Output 1080i50 display mode on LCD interface:       "video=mxcfb0:dev=lcd,LCD-1080I50,if=RGB565,bpp=32"       -- Switch HDMI interlaced mode    $ echo S:1920x1080i-50 > /sys/class/graphics/fb0/mode    $ echo S:1920x1080i-60 > /sys/class/graphics/fb0/mode    $ echo S:1440x480i-50 > /sys/class/graphics/fb0/mode    $ echo S:1440x576i-60 > /sys/class/graphics/fb0/mode 5. Know issue     1) When the interlaced display and another display work on same IPU,        blank and unblank the interlaced display will get the followed IPU        warning, but the display still works due to IPU can revover from the error.     imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_5 = 0x00800000     imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00080000 2015-05-13 update: Replace the fourth patch to make interlace display mode follow CEA-861-specification The patch "0004-IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch" was fine tuned for CEA-861-D specification on interlaced mode display. Please use this patch to replace the old 0004 patch. 2016-05-20 Update: For 3.0.35 BSP, add patch 0005-IPU-update-interlaced-video-mode-parameters-to-align.patch      Align the interlaced video mode parameters to progressive mode. 0006-IPU-update-IDMAC-setting-for-interlaced-display-mode.patch      Udate the IDMAC setting for interlaced display mode, output odd field data from memory first, it aligns with IPU DI timing, odd field first. For 3.14.52 BSP, created the new patch L3.14.52_1.1.0_GA_HDMI_Interlaced_Mode_Patch_2016_05_20.zip.
View full article
The patches are based on iMX6 L3.10.53 and 3.14.52 GA 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 patches, it can support the followed path: CSI->VDI->IC->MEM CSI->VDI->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.zip: It is the test aplication, test command for CSI->VDI->IC->MEM ("-i 2" means CSI->VDI->IC->MEM path.): ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 2 -g2d"   test command for CSI->VDI->MEM ("-i 3" means CSI->VDI->MEM path.): ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 3 -g2d"  
View full article
Hardware connection: there are two board-to-board connectors on E-INK daughter card IMXEBOOKDC4, while there is only one on i.MX7D Sabre board, as the picture below. This might be a bit confusing to connect the two: Checked with internal, the original design was trying to wire both eLCDIF and EPDC bus out to one daughter card, add the flexibility to have different configurations on one display daughter card(LCD/EPD). On i.MX7D Sabre board, only one connector is available for EPDC bus. Here is how we connect i.MX7D Sabre and IMXEBOOKDC4: Software setup: here we use pre-build L3.14.38_6UL7D_Beta Linux as our boot-image, steps to setup/boot/test EPDC: 1. download and decompress BSP pre-build image package "L3.14.38_beta_images_MX6UL7D.tar.gz", you should be able to find the SD image in it -- "fsl-image-gui-x11-imx7dsabresd.sdcard" 2. program the SD image on your SD card(>800 MBytes) with command(I'm running this in Ubuntu): "dd if=fsl-image-gui-x11-imx7dsabresd.sdcard of=/dev/sdb;sync" 3. insert SD card to the slot(J6) on i.MX7D Sabre board, connect debug-UART and power-on the board 4. modify the u-boot environment variables as below:      a.) setenv fdt_file imx7d-sdb-epdc.dtb           (originally this is "fdt_file=imx7d-sdb.dtb")      b.) setenv mmcargs 'setenv bootargs console=${console},${baudrate} root=${mmcroot} epdc video=mxcepdcfb:E060SCM,bpp=16'           (originally this is "mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot}") 5. boot into Linux kernel, run unit-test: "/unit_tests/mxc_epdc_fb_test.out", should be able to have test patterns running on EPD.
View full article
The latest i.MX28 BSP provided by Freescale (10.12) is based on a 2.6.35 kernel. If you want to use the latest and greatest kernel version from kernel.org, follow the steps below. 1. Get the mainline kernel: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git(this is only done once) git checkout -b yourlocalbranch origin/master 2. Export the toolchain PATH=/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/:$PATH export PATH export CROSS_COMPILE=arm-none-linux-gnueabi- export ARCH=arm 3. Build the kernel make mxs_defconfig make uImage sudo cp arch/arm/boot/uImage /tftpboot (In this example /tftpboot is the directory used to send files via TFTP) 4. Kernel command line: On U-boot change the following parameter of the kernel command line: console=ttyAM0,115200 to console=ttyAMA0,115200 5. On LTIB You can still use LTIB to provide the root file system. ./ltib -c Target System Configuration Options ----> Unselect [] boot up with tty and login If this option is selected the serial port will fail to open as it still uses ttyAM0 instead of ttyAMA0. 6. Boot the kernel via TFTP and mount the rootfs via NFS.
View full article
On default i.MX6UL EVK board, it supports three boot device: SD Card boot in main board, micro-SD card boot in CPU board and QSPI-FLASH in CPU board. As we know, i.MX6UL supports NAND device boot and there are NAND device footprint in the EVK board. If customer wants to use NAND boot, there is something to rework in both hardware and software. Hardware Modification NAND device boot mode is conflict with micro-SD card and QSPI-FLASH device boot modes. 1. Remove U303 in CPU board and DO NOT insert micro-SD card into J301 2. Solder U302 NAND FLASH on EVK board Software Modification In Yocto-Linux BSP standard release, NAND device boot is not supported. We need add support in u-boot, linux DTB and MFGTool. 1. u-boot-imx modification and build Replace u-boot-imx/include/configs/mx6ul_14x14_evk.h with the same file in the attachment Copy mx6ul_14x14_evk_nand_defconfig in the attachment to u-boot-imx/configs/ Build the new u-boot.imx: make distclean; make mx6ul_14x14_evk_nand_defconfig;make Rename u-boot.imx to u-boot-imx6ulevk_nand.imx 2. Linux DTB modification and build Copy imx6ul-14x14-evk-gpmi-weim.dts in the attachment to kernel/arch/arm/boot/dts/ Build imx6ul-14x14-evk-gpmi-weim.dtb: make imx6ul-14x14-evk-gpmi-weim.dtb Rename imx6ul-14x14-evk-gpmi-weim.dtb to zImage-imx6ul-14x14-evk-gpmi-weim.dtb 3. MFGTOOL modification Copy mfgtool2-yocto-mx6ul-evk-nand.vbs in the attachment to MFGTOOL root direcory Copy u-boot-imx6ulevk_nand.imx and zImage-imx6ul-14x14-evk-gpmi-weim.dtb to MFGTOOL\Profiles\Linux\OS Firmware\firmware\ Copy u-boot-imx6ulevk_nand.imx and zImage-imx6ul-14x14-evk-gpmi-weim.dtb to MFGTOOL\Profiles\Linux\OS Firmware\files\ Congratulations!!!  You can burn NAND image to i.MX6UL-EVK board with mfgtool2-yocto-mx6ul-evk-nand.vbs script now!!
View full article
Several customers met problem on audio codec porting. In order to figure out cpu dai setting problem or codec dai problem. Create the dummy codec for test purpose.  What this dummy codec can do This dummy codec can play up to 8 channels and record up to 6 channels. Connect SAI1 TX data pin with SAI1 RX data pin for loopback test. Environment Verified with i.MX8MM EVK  Based on Linux BSP L4.14.78 Files Kernel patch 0001-multiple-channels-dummy-audio-codec 0002-Add-capture-for-multiple-channels User space setting /etc/asound.conf /usr/share/alsa/cards/aliases.con /usr/share/alsa/cards/DUMMY.conf Audio test content PCM_48_16_8_160000_1_29_jazzshort.wav The alsa command for loopback test with multiple channels  aplay -D surround51:CARD=dummyaudio PCM_48_16_8_160000_1_29_jazzshort.wav | arecord -D surround51:CARD=dummyaudio --disable-channels --disable-format --disable-resample -f S16_LE -r 48000 -c 6 -d 5 -v test.wav
View full article
This document shows how to run the multicore communication examples from MCUXpresso SDK while running the Android BSP on Cortex-A7 on i.MX 7ULP-EVK. Though this document is focused on the multicore demos, similar procedures can be applied to run any other demo in the SDK. 1. Source code This document is based on the following releases: Board Android BSP MCUXpresso SDK imx7ulp-evk Android O8.1.0 for i.MX 7ULP GA SDK2.4 for i.MX 7ULP GA Download releases at i.MX Software. 2. Building the Cortex-M4 SDK There are at least two multicore demos in the SDK package, rpmsg_lite_pingpong_rtos and rpmsg_lite_str_echo_rtos. They are located at: <SDK_2.4.0_EVK-MCIMX7ULP_dir>/boards/evkmcimx7ulp/multicore_examples/ Build the rpmsg_lite_str_echo_rtos demo according to the SDK Getting Started Guide. Remember to also follow the Chapter 6, Step 4 of the document to generate the ram bootable image (sdk20-app.img). 3. Building the Android BSP 3.1. RPMsg kernel module Before building the BSP, add the following line to the BoardConfig.mk file (<android_build_dir>/device/fsl/evk_7ulp/BoardConfig.mk): BOARD_VENDOR_KERNEL_MODULES += \    $(KERNEL_OUT)/drivers/net/wireless/qcacld-2.0/wlan.ko \ + $(KERNEL_OUT)/drivers/rpmsg/imx_rpmsg_tty.ko 3.2. Cortex-M4 image Copy the SDK image file (sdk20-app.img) to the following directory in the Android source code: $ cp <SDK_2.4.0_EVK-MCIMX7ULP_dir>/tools/imgutil/evkmcimx7ulp/sdk20-app.img \   <android_build_dir>/vendor/nxp/fsl-proprietary/mcu-sdk/7ulp/sdk20-app.img Change the BoardConfig.mk file accordingly: # Copy prebuilt M4 demo image: PRODUCT_COPY_FILES += \ - vendor/nxp/fsl-proprietary/mcu-sdk/7ulp/imx7ulp_m4_demo.img:imx7ulp_m4_demo.img + vendor/nxp/fsl-proprietary/mcu-sdk/7ulp/sdk20-app.img:imx7ulp_m4_demo.img After these changes, build and flash Android as described in the BSP User's Guide. 4. Enabling the multicore communication While booting, the SoC automatically loads the Cortex-M4 image. After complete booting, install the imx_rpmsg_tty.ko module to create the multicore communication channel: $ su $ insmod vendor/lib/modules/imx_rpmsg_tty.ko To send messages from Cortex-A7 to Cortex-M4, use the /dev/ttyRPMSG* channel: $ echo "MESSAGE" > /dev/ttyRPMSG* /dev/ttyRPMSG* refers to the RPMsg device created on the board, so change the number accordingly. Cortex-M4 will echo all messages received from Cortex-A7. This is a simple example on how to communicate different cores on i.MX using Android but it can be used as a starting point for Android multicore applications.
View full article
This is the procedure and patch to set up Ubuntu 14.04 64bit Linux Host PC and building i.MX6x L3.0.35_4.1.0. It has been tested to build GNOME profile and with FSL Standard MM Codec for i.MX6Q SDP with LVDS display. Add suggestion about compiling "gstreamer-plugins-good" when selecting "Min profile" rootfs.  Please refer to the Note session. A) Basic Requirement: Set up the Linux Host PC using ubuntu-14.04-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC      Needed packages: $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 $ sudo apt-get install libc6-dev-i386 $ sudo apt-get install u-boot-tools $ sudo apt-get install scrollkeeper $ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so   /usr/lib/librt.so      Useful tools: $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd      Note: this operation "$ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so /usr/lib/librt.so" is used to fix rpm-fs build issue; which is taking reference from: LTIB - Strange problem building IMX6 Linux BSP from fresh on Ubuntu 13.10 C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L3.0.35_4.1.0_130816_source. tar.gz $ ./L3.0.35_4.1.0_130816_source/install D) Apply the patch to make L3.0.35_4.1.0 could be installed and compiled on Ubuntu 14.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L3.0.35_4.1.0_compile_on_Ubuntu_14.04_64bit_OS What the patch is doing: a) The patch modifies the following files: bin/Ltibutils.pm dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/m4/m4.spec dist/lfs-5.1/ncurses/ncurses.spec dist/lfs-5.1/openssl/openssl.spec dist/lfs-5.1/xorg-server/xorg-server.spec b) Add the following files to the pkgs directory: pkgs/m4-1.4.16-1383761043.patch pkgs/m4-1.4.16-1383761043.patch.md5 pkgs/openssl-1.0.1c-1398677566.patch pkgs/openssl-1.0.1c-1398677566.patch.md5 pkgs/xorg-server-1.6.1-1398785267.patch pkgs/xorg-server-1.6.1-1398785267.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib F) about the patch: LTIB script warning when running with Perl v5.18.2 associated change: bin/Ltibutils.pm description: It prints out the following warning when doing package unpack, the patch is used to remove the warning. defined(@array) is deprecated at bin/Ltibutils.pm line 259         (Maybe you should just omit the defined()?) busybox compilation issue: associated change: dist/lfs-5.1/base_libs/base_libs.spec reference: Re: LTIB on Ubuntu 13.04 m4 compilation issue: associated change: dist/lfs-5.1/m4/m4.spec pkgs/m4-1.4.16-1383761043.patch pkgs/m4-1.4.16-1383761043.patch.md5 reference: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/m4/files/m4-1.4.16-no-gets.patch alsa-utils compilation issue: associated change: dist/lfs-5.1/ncurses/ncurses.spec reference: Re: Android and LTIB build error in ubuntu 12.04 x86_64 openssl compilation issue due to Perl v5.18.2: associated change: dist/lfs-5.1/openssl/openssl.spec pkgs/openssl-1.0.1c-1398677566.patch pkgs/openssl-1.0.1c-1398677566.patch.md5 description: the build fails in pod2man while trying to generate man pages from the pod files reference: https://forums.freebsd.org/viewtopic.php?&t=41478 https://gist.github.com/martensms/10107481 xorg-server configuration fail: associated change: dist/lfs-5.1/xorg-server/xorg-server.spec pkgs/xorg-server-1.6.1-1398785267.patch pkgs/xorg-server-1.6.1-1398785267.patch.md5 description: When doing configuration, it stops at saying tslib not found.  It could be fixed by adding -dl when doing tslib test in configuration stage. NOTE: A) During the LTIB setup and compilation, these warnings were pop up.  Just ignore them and it seems okay. B) the dist/lfs-5.1/gst-plugins-good.spec is used to configurate/compile/install the "gstreamer-plugins-good" package.  It set up the environment variables pointing to libcairo but disable it when doing configuration. Thus, libcairo is actually not being used.           In Gnome profile, cario has been selected by default.  Thus, it does not experience the problem when compiling "gstreamer-plugins-good". However, in Min profile, if you select gstreamer-plugins-good to compile and install to your rootfs but without selecting cario as well, you will experience the error described in this thread: Re: gst-fsl-plugins build failed Thus, you could follow the solution provide in the Re: gst-fsl-plugins build failed or simply select cairo in your package list.          
View full article
Multiple-Display means video playback on multiple screens. In case playback needs to be in a unique screen, the mfw_isink element must be used and some pipelines examples can be found on this link: GStreamer iMX6 Multi-Overlay. Number of Displays Display type Kernel parameters Pipelines # Set these shells variables before running the pipelines alias gl=gst-launch SINK_1="\"mfw_v4lsink device=/dev/video17\"" SINK_2="\"mfw_v4lsink device=/dev/video18\"" SINK_3="\"mfw_v4lsink device=/dev/video20\"" media1=file:///root/media1 media2=file:///root/media2 media3=file:///root/media3 2 hdmi + lvds video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 2 lvds + lvds video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 2 lcd + lvds video=mxcfb0:dev=lcd,800x480M@55,if=RGB565 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 3 hdmi + lvds + lvds video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB6 video=mxcfb2:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 playbin2 uri=$media3 video-sink=$SINK_3
View full article
Overview AVB/TSN Wikipedia: Audio Video Bridging (AVB) is a common name for the set of technical standards which provide improved synchronization, low-latency, and reliability for switched Ethernet networks. AVB was initially developed by the Institute of Electrical and Electronics Engineers (IEEE) Audio Video Bridging task group of the IEEE 802.1 standards committee. In November 2012, Audio Video Bridging task group was renamed to Time-Sensitive Networking (TSN) task group to reflect the expanded scope of its work, which is to "provide the specifications that will allow time-synchronized low latency streaming services through IEEE 802 networks". Further standardization efforts are ongoing in IEEE 802.1 TSN task group.   AVB and TSN technologies and standards: Standard Area of Definition Title of Standard AVB/TSN IEEE 802.1AS Timing and synchronization Timing and Synchronization for Time-Sensitive Applications (gPTP) AVB TSN IEEE 802.1Qav Forwarding and queuing Forwarding and Queuing for Time-Sensitive Streams (FQTSS) AVB IEEE 802.1Qat Path control and reservation Stream Reservation Protocol (SRP) AVB IEEE 802.1BA Bridging Audio Video Bridging (AVB) Systems AVB IEEE 1722 AVTP AV transport Layer 2 Transport Protocol for Time Sensitive Applications AVB IEEE 1722 AVDECC Device manage and control Device Discovery, Enumeration, Connection Management and Control Protocol AVB IEEE 802.1Qbu and IEEE 802.3br Forwarding and queuing Frame preemption TSN IEEE 802.1Qbv Forwarding and queuing Enhancements for scheduled traffic TSN IEEE 802.1Qca Path control and reservation Path control and reservation TSN IEEE 802.1Qcc Central configuration method Enhancements and performance improvements TSN IEEE 802.1Qci Time-based ingress policing Per-stream filtering and policing TSN IEEE 802.1CB Seamless redundancy Frame replication and elimination for reliability TSN   Since many of the standards are only for TSN switch/bridges and i.MX8MP is design to be a TSN/AVB endpoint, this demo does not implement a full stack or full standards. It only demonstrates the basic end-to-end point (talker to listener) A/V streaming without bridge or switch.   Below table shows what this demo supports: Standard Software Hardware IEEE 802.1AS Linuxptp ENET_QoS IP IEEE 802.1Qav/Qbu/Qbv TC qdisc (taprio, mqprio, etf, cbs) ENET_QoS IP (multi queue + EST, FPE, CBS) IEEE 1722 AVTP Libavtp N/A   Demo introduction Two i.MX8MP EVK boards are used for this demo, one act as a AVB talker to send A/V streams, the other one act as a AVB listener to receive A/V streams who can be playback to audio codec and sink video to screen. The two boards are connected by a RJ45 ethernet cable on each ENET2 port (only ENET2 port has TSN features). Three streams’ type and SR (Stream Reservation) class are defined as below to grantee time sensitive (sub-microsecond synchronization), low latency and bandwidth on the ethernet: Stream A: SR class A, AVTP Compressed Video Format, H.264 profile High, 1920x1080, 30 fps. Stream B: SR class B, AVTP Audio Format, PCM 16-bit sample, 48 kHz, stereo, 12 frames per AVTPDU. Other stream: Best-effort streams These three TSN streams would be allocated into different traffic control (TC) class for egress in Linux. Different TC class would be mapped to different hardware queues with dedicated DMA channel, thanks to the multi-queue support by ENET_QoS IP. Then the traffic control apply different scheduling policy on each queues for different types of streams egress, to make sure highest priority or critical packet can be sent in the correct time slot. The TSN streams are transmitted over Virtual LANs (VLANs). Bridges use the VLAN priority information (PCP) to identify Stream Reservation (SR) traffic classes which are handled according to the Forward and Queuing Enhancements for Time-Sensitive Streams (FQTSS) mechanisms described in Chapter 34 of the IEEE 802.1Q standard.   The demo is built up by following blocks: Linux TC (traffic control): streams egress control to meet AVB/TSN requirements, which take advantage of the i.MX8MP TSN ENET IP. Linux PTP: clock sync in network, which take advantage of the i.MX8MP TSN ENET IP. Libavtp: Time Sensitive Applications AV Transport protocol. ALSA: AVTP audio format plugin uses the libavtp to transmit and receive AVTP audio PCM streams. Gstreamer: avtp plugin uses the libavtp to transmit and receive AVTP audio/video streams (video should be encoded as H264, audio PCM). x264enc and libav is a software H.264 video encoder/decoder, which alternative to the on chip VPU acceleration plugin, due to the VPU plugin is not supported in the latest Gstreamer version (1.17.x).     Traffic control This demo can use two different traffic control qdisc settings: mqprio + cbs: use CBS features taprio + pfifo: use EST and FPE features (802.1Qbu/bv). The pfifo is the default traffic control class, which use FIFO schedule policy for egress packets. The CBS class is actually handled by hardware IP to select which queue for transmit in a certain time slot.   Credit Base Shaper (CBS) CBS parameters come straight from the IEEE 802.1Q-2018 specification. They are the following: idleSlope: rate credits are accumulated when queue isn’t transmitting; sendSlope: rate credits are spent when queue is transmitting; hiCredit: maximum amount of credits the queue is allowed to have; loCredit: minimum amount of credits the queue is allowed to have;     Enhancements to Scheduled Traffic (EST) The IEEE 802.1Qbv defines the schedule for each of the queues on every egress port which makes the implementation aware of traffic arrival schedule. This information can be used to block the lower priority traffic from transmission in this time window/slot. This ensures that scheduled traffic is forwarded from sender to receiver through all the network nodes with a deterministic delay. The i.MX8MP uses the gate control list with configurable time slot and frame preempt (IEEE 802.1Qbu) features to support EST. Other than the CBS, the gate control list control the egress transmission by a fixed open interval for that queue.   Build demo Build L5.4.24_2.1.0 $MACHINE=imx8mpevk DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b build-8mp $bitbake  fsl-image-validation-imx Prepare a SD card and burn it with the built out images. To add tc/tcpdump command in iproute2 package, please add package into IMAGE_INSTALL_append variable into conf/local.conf: IMAGE_INSTALL_append = " iproute2 iproute2-tc tcpdump Rebuild kernel Rebuild the kernel after applying the 0001-qenet-add-queue-avoid-panic.patch (attached), and overwrite the Image and imx8mp-evk.dtb on the boot partition of the SD card.   Install the toolchain $bitbake -f fsl-image-validation-imx -c populate_sdk $sh tmp/deploy/sdk/fsl-imx-xwayland-glibc-x86_64-fsl-image-validation-imx-aarch64-imx8mpevk-toolchain-5.4-zeus.sh The toolchain would be installed into /opt/fsl-imx-xwayland/5.4-zeus/   Create a install folder $mkdir <your install folder> Create a folder to install all of the shared libraries, binaries and configure files which built out manually in this doc. After built done, you should copy all of the contents in this folder to target board root.   Build libavtp $source /opt/fsl-imx-xwayland/5.4-zeus/environment-setup-aarch64-poky-linux $git clone https://github.com/Avnu/libavtp.git $cd libavtp $meson build $ninja -C build Copy the built out .so and .pc into the toolchain rootfs: $sudo cp build/libavtp.so* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/lib/ $sudo cp build/meson-private/*.pc /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/lib/pkgconfig/ To make sure you have avtp package installed correctly: $pkg-config --list-all | grep avtp Copy the .so into the install folder: $cp build/libavtp.so* <install folder>/usr/lib/ Copy header files: $cp libavtp/include/* files <toolchain_path>/sysroots/aarch64-poky-linux/usr/lib Build ALSA aaf plugin The AAF (ALSA AVTP Audio Format) plugin is a PCM plugin that uses Audio Video Transport Protocol (AVTP) to transmit/receive audio samples through a Time-Sensitive Network (TSN) capable network. The plugin enables media applications to easily implement AVTP Talker and Listener functionalities.   $cd <yocto build>/tmp/work/aarch64-mx8mp-poky-linux/alsa-plugins/1.1.9-r0/alsa-plugins-1.1.9 $./configure --build=x86_64-linux --host=aarch64-poky-linux --target=aarch64-poky-linux --prefix=<your install folder>/usr --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/opt/samba/nxa23059/jailhouse/yocto-5.x/build-8mp/tmp/work/aarch64-mx8mp-poky-linux/alsa-plugins/1.1.9-r0/recipe-sysroot  --disable-static  --enable-aaf --disable-jack --disable-libav --disable-maemo-plugin --disable-maemo-resource-manager --enable-pulseaudio --enable-samplerate --with-speex=lib $make $make install   Build Gstreamer AVTP plugins Build Gstreamer 1.17.x (commit e4f7cdb0df7b) $git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git $cd gstreamer $patch -p1 < gstreamer-1.0-pass-build.patch $meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install After Gstreamer is installed into <your install folder>, please fix the “prefix” path in the .pc files by, and copy to the toolchain folders: $cd <your install folder> $grep -lR <your install folder> ./lib/pkgconfig/ | xargs sed -i 's/<your install folder>/\/usr/g' NOTE: Make sure you use the ‘\’ for ‘/’ convert in your path. $cp -rf ./usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/   Build gst-plugins-base (commit 22827e8f) $git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-base.git $cd gst-plugins-base $patch -p1 < gst-plugins-base-pass-build.patch $meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install   Build gst-plugins-bad (commit ed14e0d5a) $git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad.git $cd gst-plugins-bad $meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install If you met gdbus-codegen issue, please remove the “--c-generate-autocleanup” and “--output-directory” parameters in the build/build.ninja If you met issue of include file like: “…/gst/gl/gstglapi.h:24:10: fatal error: gst/gl/gstglconfig.h: No such file or directory.” Please modify the build/build.ninja to correct the -I header file parameter of the build. After gst-plugins-base and gst-plugins-bad installed into <your install folder>, please fix the “prefix” path in the .pc files and copy them into the toolchain folders: $cd <your install folder> $grep -lR <your install folder> ./lib/pkgconfig/ | xargs sed -i 's/<your install folder>/\/usr/g' NOTE: Make sure you use the ‘\’ for ‘/’ convert in your path. $cp -rf ./usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/   Build H.264 SW plugins AVTPDU uses H.264 as payload for streaming, this requires H.264 encoder/decoder plugins, either software or hardware accelerations. Since we upgrade the Gstreamer and its plugins to a new version, the VPU plugins cannot be used anymore. So software H.264 plugins are required: x264 for encoder, libav for decoder.   Build x264 As the yocto actually has the x264 recipes, but not included in our bblayers, we need to copy the x264 source into our bblayers path under <yocto>/source to build: $cp -rf ./poky/meta/recipes-multimedia/x264 ./meta-openembedded/meta-multimedia/recipes-multimedia/ $vi ./meta-openembedded/meta-multimedia/recipes-multimedia/x264_git.bb Remove the LICENSE_FLAGS line $bitbake -f x264 -c do_install $sudo cp -rf tmp/work/aarch64-poky-linux/x264/r2917+gitAUTOINC+72db437770-r0/image/usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/ Build gst-plugins-ugly (commit 995a135d) $git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly.git $cd gst-plugins-ugly$meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install If you met build issue, please remove "if have_cxx" from meson.build Build libav As the yocto actually has the libav recipes, but not included in our bblayers, we need to copy the its source into our bblayers path under <yocto>/source: $cp -rf ./poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav ./meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer $vi ./meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.16.1.bb Remove the LICENSE_FLAGS line $bitbake -f gstreamer1.0-libav -c do_install $cp tmp/work/aarch64-mx8mp-poky-linux/gstreamer1.0-libav/1.14.0-r0/image/usr/lib/gstreamer-1.0/libgstlibav.so <your install folder>/usr/lib/gstreamer-1.0 Now you have all of the Gstreamer plugins which required for AVB/TSN audio/video demo: avtpsrc, avtpsink, avtpaafpay, avtpaafdepay, avtpcvfpay, avtpcvfdepay x264_enc (encoder), avdec_h264 (decoder)   Install binaries Final step is to copy all of your built out files from <your install folder> into your board / root, and boot up the board. Verify the Gstreamer plugins install correctly or not: $export GST_PLUGIN_PATH= /usr/lib/gstreamer-1.0/ $gst-inspect-1.0 Check if the above Gstreamer plugins we built out can be found by gst-instpect.   System Setup VLAN The ENTE_QoS is assigned to eth1 instance. So create eth1.5 for vlan id 5: $ip link add link eth1 name eth1.5 type vlan id 5 \         egress-qos-map 2:2 3:3 $ip link set eth1.5 up Qdiscs The TSN control plane is implemented through the Linux Traffic Control (TC) System. The transmission algorithms specified in the Forwarding and Queuing for Time-Sensitive Streams (FQTSS) chapter of IEEE 802.1Q-2018 are supported via TC Queuing Disciplines (qdiscs). Linux currently provides the following qdiscs relating to TSN: Multiply queue qdiscs (These two qdiscs are mutually exclusive, select one for your demo): MQPRIO: Mapping the TC class into different hardware queue in IP. TAPRIO: Implements the Enhancements for Scheduled Traffic introduced by IEEE 1Qbv/Qbu. This is supported by i.MX8MP ENET_QoS IP through EST features: Qbv – Time aware shaper Qbu - frame preemption. CBS qdisc: Implements the Credit-Based Shaper introduced by the IEEE 802.1Qav This is supported by i.MX8MP ENET_QoS IP through EST (Enhancements to Scheduled Traffic) features. It works with mqprio qdisc together. ETF qdisc: While not an FQTSS feature, Linux also provides the Earliest TxTime First (ETF) qdisc which enables the LaunchTime Since the i.MX8MP ENET_QoS IP does not support LaunchTime feature, this qdisc configurations would be ignored.   MQPRIO qdisc $tc qdisc add dev eth1 parent root handle 100 mqprio \         num_tc 3 \         map 0 0 2 1 0 0 0 0 0 0 0 0 0 0 0 0 \         queues 1@0 1@1 1@2 \         hw 1 NOTE, since ENET_QoS Q0 does not support hardware CBS, we have to avoid using Q0 for AVB streaming. Here’s the mapping: socket SO_PRIORITY 2 -> TC CLASS 2 -> Q2 socket SO_PRIORITY 3 -> TC CLASS 1 -> Q1 Other socket priority -> TC CLASS 0 -> Q0   TAPRIO qdisc Create a root qdisc handle to map the different CLASS streams to hardware queues w/ GCL (gate control list). This root handle maps the CLASS A stream to queue Q1, CLASS B stream to Q2, and others to Q0 by the “map” and “queues” parameters, same as mqprio above. The Q1/Q2(CLASS1/2) gates are open in the first 300us interval, then only Q1(CLASS1) gate is open in the next 300us with all other CLASS gated. The last sched-entry defines in after Q1 is open after 300us, all of the CLASS gates are open for next 200us. Then loopback to the first sched-entry for gate control. Please note in this demo, we only enable features to support the 802.1Qbv, the Qbu (Frame preempt) requires patches for iproute2. $tc qdisc add dev eth1 parent root handle 100 taprio \         num_tc 3 \         map 0 0 2 1 0 0 0 0 0 0 0 0 0 0 0 0 \         queues 1@0 1@1 1@2 \         base-time 1000000000 \         sched-entry S 0x6 300000 \         sched-entry S 0x2 300000 \         sched-entry S 0x7 200000 \         flags 0x2   CBS qdisc Q1 CBS for video, Q2 CBS for audio: $tc qdisc replace dev eth1 parent 100:2 handle 777 cbs \         idleslope 98688 sendslope -901312 hicredit 153 locredit -1389 \         offload 1 $tc qdisc replace dev eth1 parent 100:3 handle 888 cbs \         idleslope 3648 sendslope -996352 hicredit 12 locredit -113 \        offload 1 NOTE: By default, the Q0 will be allocated for pfifo qdisc class if we do not define them.   ETF qdisc As ENET_QOS does not support hardware launch time in IP, the ETF qdisc would not be used here.   TimeSync Run the ptp4l and phc2sys in background, and use check_clocks to check the ptp sync works. $ptp4l -i eth1 -f ./gPTP.cfg --step_threshold=1 & $pmc -u -b 0 -t 1 "SET GRANDMASTER_SETTINGS_NP clockClass 248 \         clockAccuracy 0xfe offsetScaledLogVariance 0xffff \         currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 1 \         ptpTimescale 1 timeTraceable 1 frequencyTraceable 0 \         timeSource 0xa0" $phc2sys -s eth1 -c CLOCK_REALTIME --step_threshold=1 \         --transportSpecific=1 -w &  $./check_clocks -d eth1 The PTP Hardware Clock (PHC)  synced between PTP master/slave means the RMS offset between PHC and GM (master clock) is < 100ns. PHC and system clock (CLOCK_REALTIME) synced means the clock offset < 100ns   NOTE: The check_clocks source code can be downloaded from here. cfg is described below, if you want to identify which is master and which is slave, use “masterOnly 1” or “slaveOnly 1” in this configuration file. #                                                                 # 802.1AS example configuration containing those attributes which # differ from the defaults.  See the file, default.cfg, for the   # complete list of available options.                              #                                                                 [global]                                                          gmCapable               1                                         priority1               248                                        priority2               248                                       logAnnounceInterval     0                                         logSyncInterval         -3                                        syncReceiptTimeout      3                                          neighborPropDelayThresh 800                                       min_neighbor_prop_delay -20000000                                 assume_two_step         1                                         path_trace_enabled      1                                         follow_up_info          1                                         transportSpecific       0x1                                        ptp_dst_mac             01:80:C2:00:00:0E                         network_transport       L2                                        delay_mechanism         P2P                                        Run demo ALSA AAF audio To run the alsa AAF demo, please add aaf0 and converter0 plugin device into /etc/asound.conf: pcm.aaf0 {         type aaf         ifname eth1.5         addr 01:AA:AA:AA:AA:AA         prio 2         streamid AA:BB:CC:DD:EE:FF:000B         mtt 50000         time_uncertainty 1000         frames_per_pdu 12         ptime_tolerance 100 }    pcm.converter0 {         type linear         slave {                 pcm "hw:2,0"                 format S16_LE         } }   The “aaf0” plugin device defines the ethernet interface which AAF runs on, the socket priority which mapping to Traffic Class in kernel TC, the stream-id for the aaf streaming. The “converter0” plugin device is used for convert the S16_BE format to S16_LE for the wm8960 PCM audio.   Select one device as AVB talker, and run: $speaker-test -p 25000 -F S16_BE -c 2 -r 48000 -D aaf0 Select one device as AVB talker, and run: $arecord -F 25000 -t raw -f S16_BE -c 2 -r 48000 -D aaf0 | aplay -F 25000 -t raw -f S16_BE -c 2 -r 48000 -D converter0 You can hear the sound on the listener device. You can also check which qdisc queue is used for AAF by: $tc -s qdisc   Gstreamer AAF audio Select one device as AVB talker, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     audiotestsrc samplesperbuffer=12 is-live=true ! \     audio/x-raw,format=S16BE,channels=2,rate=48000 ! \     avtpaafpay mtt=50000000 tu=1000000 streamid=0xAABBCCDDEEFF000B processing-deadline=0 ! \     avtpsink ifname=eth1.5 address=01:AA:AA:AA:AA:AA priority=2 processing-deadline=0 \)   Select one device as AVB listener, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     avtpsrc ifname=eth1.5 ! avtpaafdepay streamid=0xAABBCCDDEEFF000B ! \     queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! \     audioconvert ! audioresample !  alsasink device="hw:2,0" \)   Gstreamer CVF video Select one device as AVB talker, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     videotestsrc is-live=true ! video/x-raw,width=480,height=320,framerate=15/1 ! \     clockoverlay ! x264enc bframes=0  key-int-max=1 speed-preset=1 tune=4 ! h264parse config-interval=-1 ! \     avtpcvfpay processing-deadline=20000000 mtu=1400 mtt=2000000 tu=125000 streamid=0xAABBCCDDEEFF000A ! \     avtpsink ifname=eth1.5 priority=3 processing-deadline=20000000 \) NOTE: To eliminate the h.264 software encoding/decoding overhead with acceptable latency for this demo, we use several parameters for x264enc element: bframes: x264enc and avdec_h264 together was found to have issues, remove bframes in the stream would help. key-int-max: decoder can only decode the frame when a keyframe is present on stream to make sure decoder can work as faster as it can, the distance between two keyframes must be set to closest. speed-preset: to low down the CPU loading for encoding, we use the option to make encoding as faster as we can. (=1 means ultrafast) tune: 4 means zero latency ‘mtu=1400’ parameters for avtpcvfpay element is very important, if using the default mtu=1500, the listener cannot get the AVTPDUs package correctly from VLAN. The reason is unknown yet.   Select one device as AVB listener, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     avtpsrc ifname=eth1.5 ! avtpcvfdepay streamid=0xAABBCCDDEEFF000A ! \     queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! \     avdec_h264 ! videoconvert ! clockoverlay halignment=right ! waylandsink \)   The demo screenshot below: there are two clocks show on the videotestsrc stream: left one is the timestamp recorded before x264enc encoding on the AVB talker side, right one is the timestamp recorded after avdec_h265 decoding and do video convert to YUV frames on AVB listener side. You can see the timestamp is sync in seconds.     Deep dive Packet sniffer Use tcpdump on board to dump the L2 ethernet packet: ./tcpdump -i eth1 ether proto 0x22f0 -w dump.pcap The AVTP ether protocol code is 0x22f0 embedded inside the ether frame, or you can use "vlan 5" VLAN id for tcpdump parameters to dump. Then open this dump.pcap in the windows/Linux PC by the wireshark tool, it will automatically show the protocol inside the package, it can also parser the IEEE1722 (AVTP) CVF/AFF package header as below:   Precise latency measurement The clockoverlay plugin used in the above talker/listener is actually seconds level precision, which can not reflect the latency from talker videotestsrc -> listener avdec_h264 decoding finish. Here need a little hack to the clockoverlay element in the gst-plugins-base to get the millisecond precision. The patch is attached (gst-plugins-base-clockoverlay-us.patch), please apply and rebuild the gst-plugins-base, then replace the libgstpango.so on the board /usr/lib/gstreamer-1.0/. When doing CVF demo, you can take a picture of the screen, and check the two clock's diff. During my test, the latency is about 50ms, which include all the cost of encoding, AVTP packaging, streaming, ethernet transmit, ethernet receive, AVTP unpack and frame decoding. To measure the package latency from transmit port (talker) to receive port (listener), you can use the tcpdump on both end-points. And compare the Epoch Time the packet dumped: "Epoch Time: 1596252905.688243000 seconds". The delta of the epoch time of the same packet is around 100us~500us. This latency actually includes the AF_PACKET clone cost in kernel netfilter, also the tcpdump application schedule latency.   References Getting started with AVB on Linux: https://tsn.readthedocs.io/avb.html TSN vs AVB: https://dornerworks.com/blog/avb-vs-tsn-choose-the-best-deterministic-ethernet-solution-for-your-networked-devices/ ALSA aaf: https://fossies.org/linux/alsa-plugins/doc/aaf.txt Gstreamer avtp: https://gstreamer.freedesktop.org/documentation/avtp/index.html AVTP: https://avnu.org/wp-content/uploads/2014/05/AVnu-AAA2C_Audio-Video-Transport-Protocol-AVTP_Dave-Olsen.pdf MX8MP RM
View full article
One of the most important features of Yocto is its ability to handle sublayers. To understand the sublayers please Yocto Project Development Manual Start creating meta-custom folder, then create the other folders. For example: meta-daiane/ ├── conf │   └── layer.conf ├── README ├── recipes-core │   └── helloworld │       ├── helloworld │       │   └── hello_world.c │       └── helloworld_0.0.bb └── recipes-daiane     └── images         └── dai-image-hello.bb It´s possible to create recipes-kernel and place there your defconfig, or create a bbappend to apply your patches to kernel, or even create a recipes-multimedia and place there custom application for gstreamer, for example. Here, the custom application example is a helloworld application. One important tip: Yocto see recipes name as PACKAGENAME_VERSION.bb, It means, yocto uses "_" (underline) to separate the package name from package version on a recipe file name. So, if you call your helloworld application as hello_world_1.0.bb Yocto will think your application is called "hello" and the version is something around "world_1.0" Please, be careful. LAYER.CONF This is the file that gives new layer live. Find the content of mine layer.conf below: # We have a conf and classes directory, add to BBPATH BBPATH .= ":${LAYERDIR}" # We have a packages directory, add to BBFILES BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \             ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "daiane" BBFILE_PATTERN_daiane := "^${LAYERDIR}/" BBFILE_PRIORITY_daiane = "4" As soon as the new custom layer is created, it MUST include it to  conf/bblayers.conf file. Please see the example: LCONF_VERSION = "6" BBPATH = "${TOPDIR}" BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}" BBFILES ?= "" BBLAYERS = " \   ${BSPDIR}/sources/poky/meta \   ${BSPDIR}/sources/poky/meta-yocto \   \   ${BSPDIR}/sources/meta-openembedded/meta-oe \   \   ${BSPDIR}/sources/meta-fsl-arm \   ${BSPDIR}/sources/meta-fsl-arm-extra \   ${BSPDIR}/sources/meta-fsl-demos \   \   ${BSPDIR}/sources/meta-daiane \ " Please, find the tarball with sample meta layer attached to this document. It includes one image that will install the Hello World application: $ bitbake dai-image-hello When the content of image tar ball is extracted, hello_world was installed and it was for ARM: $ find -name hello* ./usr/bin/hello_world $ file ./usr/bin/hello_world ./usr/bin/hello_world: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped Go to Yocto Training - HOME Go to Task #9 - How to add bad/ugly
View full article
Sometimes it is helpful/faster to build a i.MX8MM boot binary outside of the Yocto environment. There are instructions on how to accomplish this on different places, this document tries to provide an example for the i.MX8M Mini LPDDR4 EVK, whenever possible pointing how to build for other boards. For the 8MM SoC a boot image is generated by imx-mkimage tool and requires: - u-boot - ARM trusted firmware image - ddr training firmware 1. Download and Build u-boot: mkdir imx-boot-bin cdimx-boot-bin git clone https://source.codeaurora.org/external/imx/uboot-imx.git cd uboot-imx/ git checkout -b imx_v2019.04_4.19.35_1.1.0 origin/imx_v2019.04_4.19.35_1.1.0 (Optional) Here you can "git log -1" to check that the commit matches SRCREV on the recipe. Next, use the BSP SDK script to setup the cross compilation environment, instructions on how to build it are here. source /opt/fsl-imx-wayland/4.19-warrior/environment-setup-aarch64-poky-linux export ARCH=arm Build make clean Supported boards have configuration files on "configs". Using the LPDDR4 EVK here: make imx8mm_evk_defconfig make 2.   Download and build the ARM Trusted Firmware cd .. git clone https://source.codeaurora.org/external/imx/imx-atf.git cd imx-atf/ git checkout -b imx_4.19.35_1.1.0 origin/imx_4.19.35_1.1.0 (Optional) Again, you can "git log -1" to check that the commit matches SRCREV on the recipe. https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imx/meta-bsp/recipes-bsp/imx-atf/imx-atf_2.0.bb?h=warrior-4.19.35-1.1.0 Build: make PLAT=imx8mm bl31 If you run into this error: aarch64-poky-linux-ld.bfd: unrecognized option '-Wl,-O1' aarch64-poky-linux-ld.bfd: use the --help option for usage information make: *** [Makefile:712: build/imx8mm/release/bl31/bl31.elf] Error 1 try:  unset LDFLAGS make PLAT=imx8mm bl31 3. Download the LPDDR4 training binaries It is on firmware-imx, recipe is here: https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imx/meta-bsp/recipes-bsp/firmware-imx?h=warrior-4.19.35-1.1.0 cd .. mkdir firmware-imx cd firmware-imx wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.5.bin chmod a+x firmware-imx-8.5.bin ./firmware-imx-8.5.bin 4. Download imx-mkimage and build the boot image cd .. git clone https://source.codeaurora.org/external/imx/imx-mkimage.git cd imx-mkimage/ git checkout -b imx_4.19.35_1.1.0 origin/imx_4.19.35_1.1.0 (Optional) "git log -1" matches SRCREV on: https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imx/meta-bsp/recipes-bsp/imx-mkimage/imx-mkimage_git.inc?h=warrior-4.19.35-1.1.0 Now, you can check the build targets and required binaries at iMX8M/soc.mak For the flash_evk for the imx8mm we will need binaries: u-boot: u-boot-spl.bin, u-boot-nodtb.bin, fsl-imx8mm-evk.dtb  ARM trusted firmware: bl31.bin LPDDR4 files: lpddr4_pmu_train_1d_imem.bin lpddr4_pmu_train_1d_dmem.bin lpddr4_pmu_train_2d_imem.bin lpddr4_pmu_train_2d_dmem.bin mkimage for mkimage_uboot Copy all these to imx-mkimage/iMX8M/ cp ../uboot-imx/spl/u-boot-spl.bin iMX8M/ cp ../uboot-imx/u-boot-nodtb.bin iMX8M/ cp ../uboot-imx/arch/arm/dts/fsl-imx8mm-evk.dtb iMX8M/ cp ../imx-atf/build/imx8mm/release/bl31.bin iMX8M/ cp ../firmware-imx/firmware-imx-8.5/firmware/ddr/synopsys/lpddr4_pmu_train_* iMX8M/ cp ../uboot-imx/tools/mkimage iMX8M/mkimage_uboot Build: make SOC=iMX8MM flash_evk Output binary is on ./iMX8M/flash.bin 5. Program on the SD Card: sudo dd if=iMX8M/flash.bin of=/dev/<path to your sd> bs=1024 seek=33
View full article