This document shows the necessary steps to configure the Eclipse IDE for development of Yocto applications. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release or Freescale Community BSP. For this example we'll use the Freescale BSP Release L3.14.28 but you may use the FSL Community BSP. - Freescale Community BSP FSL Community BSP - 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%20In… 3) Poky Meta Toolchain (Poky 1.7 / L3.14.28 for our example but you should use the 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. Task #7 - Create the toolchain 4) Eclipse Luna. We’ll use the Luna SR2 (4.4.2) version of the Eclipse IDE. You may find it on the following website: http://www.eclipse.org/downloads/packages/release/luna/sr2 Look for the “Eclipse IDE for C/C++ Developers”, which contains the Eclipse Platform, the Java Development Tools (JDT), and the Plug-in Development Environment. Once you have downloaded the tarball extract it. The following command unpacks and installs the downloaded Eclipse IDE tarball into a clean directory using the default name eclipse:      $ cd ~      $ tar -xzvf ~/Downloads/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz Configuring the Eclipse IDE Once with Eclipse Luna installed you may run the Eclipse IDE with the following command: $ cd eclipse $ ./eclipse Select a new workspace. Chose "Install New Software" from the "Help" pull-down menu. Select the "Luna - http://download.eclipse.org/releases/luna" Find and expand the Linux Tools option and select: Linux Tools LTTng Tracer Control Linux Tools LTTng Userspace Analysis LTTng Kernel Analysis If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Find and expand the Mobile and Device Development and select the following:   C/C++ Remote Launch (Requires RSE Remote System Explorer)   Remote System Explorer End-user Runtime   Remote System Explorer User Actions   Target Management Terminal (Core SDK)   TCF Remote System Explorer add-in   TCF Target Explorer If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Expand Programming Languages and select:   C/C++ Autotools Support   C/C++ Development Tools Chose Next and accept the necessary EULA Clck on the Finish button. The selected packages will be downloaded and installed. You will be asked to restart Eclipse IDE to finish the installation. Adding the Yocto Plug-in to the Eclipse IDE Next step is to install the Eclipse Yocto Plug-in into the Eclipse IDE. We'll show how to install the pre-built plug in. Start the Eclipse IDE In Eclipse, select "Install new Software" from the "Help" menu Click the "Add..." button to add a repository and enter: Name: Any name, we will use Yocto Fio Location: http://downloads.yoctoproject.org/releases/eclipse-plugin/1.8/luna Click "Ok" and then chose this new repository on the "Work with" drop-down menu and select the following plug-ins from the list:   Yocto Project ADT Plug-in   Yocto Project Bitbake Commander Plug-in   Yocto Project Documentation plug-in Install these plug-ins and click "OK" when prompted about installing software that contains unsigned content. You may be asked to restart the Eclipse IDE. Configuring the Eclipse Yocto Plug-in With all the necessary packages installed we'll now configure the Eclipse Yocto Plug-in. In this steps we will configure the Cross Compiler options and the Target options. These will then be used as default for your projects from within your working workspace. Select "Preferences" from the "Window" menu. Click on Yocto Project ADT from the left options and then under Cross Compiler Options select the Standalone pre-built toolchain radio button. We need to point to the Toolchain Root location of our installed toolchain. This is covered on the following community document: Task #7 - Create the toolchain In this case we'll be using poky 1.7 tollchain which has the following default location: /opt/poky/1.7 As fo the Sysroot Location this would correspond to your build directory sysroot folder, which is located on the following path: <YOCTO_BSP_DIR>/<BUILD_DIR>/tmp/sysroots/<MACHINE> In our case our Tartget architecture would be the Cortex-A9, which correspond to the i.MX6 and which is also the only option installed on the chosen directory. For Target Options we would be using the actual HW in order to test our application so keep the External HW option selected. Creating a Hello World Project We are now ready to create our project. Just to test our configuration we'll create a Hello World project.We can do so by selecting File->New->C Project or C++ Project We must then select a Project name and in project type we can chose either an Empty project or as in our case a Hello World Project, all this under the Yocto Project ADT Autotools Project folder. We will have the GNU Autotools Tolchain selected. The next screen will show some of the Basic Properties for our project, including the GNU license. Fill these as required. You may clock on Finish at this point. We should see that the HelloWorld project was created. We should right-click on the project folder and then chose Reconfigure Project in order to fill the necessary libraries. After this is completed we can build our project either by choosing the hammer icon or in the Build Project option inside the Project menu. We can look for correct competition or any errors or warning on the Console tab. Further Application Development After this basic setup you may work on more complex examples like a GPU and a Gstreamer Application examples on the following nicely written document: Yocto Application Development Using Eclipse IDE

I²C is a communication protocol used to exchange information between cores. To see more about I²C, please follow this link Wikipedia:I²C. Enable I2C-tools in LTIB into Package List: Reboot your file system, there are three new I²C commands: i2cdetect, i2cdump and i2cset. All examples below were tested in a iMX27ADS, but this programs seems to have the same behavior to all platforms. Detecting busses This command lists all installed bus. mx27# i2cdetect -l i2c-0   unknown         MXC I2C Adapter                         Algorithm unavailable There is one installed bus with address 0. Installed Chips I2cdetect shows the installed chips too. mx27# i2cdetect 0     WARNING! This program can confuse your I2C bus, cause data loss and worse!     I will probe file /dev/i2c/0.     I will probe address range 0x03-0x77.         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 00:          XX XX XX XX XX XX XX XX XX XX XX XX XX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX 2d XX XX 30: UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 60: XX XX XX XX XX XX XX XX XX XX UU XX XX XX XX XX 70: XX XX XX XX XX XX XX XX There are several cores installed into bus i2c-0. If you received an error message like this: # i2cdetect 0 Error: Could not open file `/dev/i2c-0' or `/dev/i2c/0': No such file or directory You will need to create the special file /dev/i2c-0 : # mknod /dev/i2c-0 c 89 0 Chip Registers i2cdump shows a list of all registers for a core. For example, the command above shows registers for core with address 0x6a: mx27# i2cdump 0 0x6a No size specified (using byte-data access)     WARNING! This program can confuse your I2C bus, cause data loss and worse!     I will probe file /dev/i2c/0, address 0x6a, mode byte         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef 00: 00 00 28 00 00 03 15 03 00 00 00 00 00 00 03 01    ..(..???......?? 10: 04 01 00 00 04 01 00 00 17 41 1d 00 09 09 1f 03    ??..??..?A?.???? 20: 00 00 40 00 08 00 0c 00 0f 01 00 00 00 00 08 11    ..@.?.?.??....?? 30: 00 0f 05 fe 0b 00 00 00 82 00 0c 02 00 00 01 00    .????...?.??..?. 40: 21 f0 7c 1f 00 00 01 00 7a 40 80 38 00 01 47 00    !?|?..?.z@?8.?G. 50: 3c 00 17 21 1b 1b 24 9f 00 3e 0f 0f 60 05 cd 03    <.?!??$?.>??`??? 60: 89 04 89 01 02 00 0a 05 00 19 ff 03 24 0f 78 00    ?????.??.?.?$?x. 70: 00 b2 06 14 04 08 00 a3 c8 15 05 15 3c 00 00 20    .?????.?????<.. 80: 07 2f 07 00 00 00 00 00 00 00 00 ff 03 1a 1a 1a    ?/?.........???? 90: 1a 1a 40 03 00 00 00 00 00 00 00 00 00 00 e4 00    ??@?..........?. a0: 00 02 4d 00 96 00 1d 00 a0 00 db 00 7e 00 00 00    .?M.?.?.?.?.~... b0: 00 00 00 00 00 00 f0 00 00 00 00 00 00 00 00 00    ......?......... c0: 00 00 00 00 48 9c 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ....H??????????? d0: 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ???????????????? e0: 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ???????????????? f0: 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ???????????????? Setting a register To change some register value, use i2cset like in example below: mx27# i2cset 0 0x6a 01 0x0008 w     WARNING! This program can confuse your I2C bus, cause data loss and worse!     I will write to device file /dev/i2c/0, chip address 0x6a, data address     0x00, data 0x08, mode word. Value 0x8 written, readback matched Where: 0 is the bus address 0x6a is the slave address 01 is the register address 0x0008 is the new value for register w is the word mode for the setting

We are very proud to announce that Element14's SabreLite i.MX6Q board is now officially supported by Adeneo Embedded's i.MX6 WEC7 BSP. As a consequence, our customers are able to use the SabreLite board from Element14 as well as the one from Boundary Devices. Follow this link for Adeneo Embedded's i.MX6 WEC7 BSP Follow this link for Element 14's SabreLite board Ce document a été généré à partir de la discussion suivante : Element14's SabreLite board officially supported by Adeneo Embedded's i.MX6 WEC7 BSP

Here is a quick summary at booting Linux on the i.MX 6 sabre sd platform. This assumes you already have u-boot working on your platform as described here. This implies you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). Get Linux sources We will use git to fetch Linux sources:   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git This should create a linux directory with all the latest sources (after a while). Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l 'v*', and git checkout <the-desired-tag>. Compile Assuming your cross compiler is called e.g. arm-linux-gnueabihf-gcc, you can compile by doing:   $ cd linux   $ export ARCH=arm   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make imx_v6_v7_defconfig   $ make You then need to supply a LOADADDR (as joowonkim pointed out); do:   $ make uImage LOADADDR=0x10008000 This should create a number of files, including arch/arm/boot/uImage and arch/arm/boot/dts/imx6q-sabresd.dtb. Put on SD We need a proper FAT partition on the SD card, from which u-boot will be able to load the kernel and dtb. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout:   +-----+------+--------+-----+----------------   | MBR |  ... | u-boot | ... | FAT partition ...   +-----+------+--------+-----+----------------   0     512    1024           1M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk:   Device    Boot      Start         End      Blocks   Id  System   /dev/sdc1            2048     8054783     4026368    c  W95 FAT32 (LBA) (units: 512B sectors) You can format the FAT partition, mount, copy and unmount with:   $ mkfs.vfat /dev/<your-sd-card-first-partition>   $ mount /dev/<your-sd-card-first-partition> /mnt   $ cp arch/arm/boot/uImage arch/arm/boot/dts/imx6q-sabresd.dtb /mnt/   $ umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or /dev/mmcblk<X>p1. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. Also, be sure to have u-boot on the SD card as explained in this post. Boot! That's it; u-boot already knows how to deal with your kernel by default so you are good to go. Insert the SD card into the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. You should see u-boot messages:   U-Boot 2013.07-rc1-00014-g74771f4 (Jun 21 2013 - 16:27:39) u-boot should load the uImage and dtb from SD card and boot the kernel:   (...)   reading uImage   4215344 bytes read in 449 ms (9 MiB/s)   Booting from mmc ...   reading imx6q-sabresd.dtb   22818 bytes read in 22 ms (1012.7 KiB/s)   ## Booting kernel from Legacy Image at 12000000 ...      Image Name:   Linux-3.10.0-rc6      Image Type:   ARM Linux Kernel Image (uncompressed)      Data Size:    4215280 Bytes = 4 MiB      Load Address: 10008000      Entry Point:  10008000      Verifying Checksum ... OK   ## Flattened Device Tree blob at 11000000      Booting using the fdt blob at 0x11000000      Loading Kernel Image ... OK   OK      Using Device Tree in place at 11000000, end 11008921   Starting kernel ... The kernel should boot:   Booting Linux on physical CPU 0x0   Linux version 3.10.0-rc6 (vstehle@debian) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Fri Jun 21 18:09:26 CEST 2013 By default, the kernel will try to mount a root filesystem from the SD card second partition, as can be read in the default kernel command line:   (...)   Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw ...but we did not prepare a root filesystem partition, so after a number of boot messages the kernel will wait indefinitely:   (...)   mmc1: new SDHC card at address b368   (...)    mmcblk0: p1   (...)   Waiting for root device /dev/mmcblk1p2... We will see in another post how to prepare this root filesystem on the second SD card partition. Enjoy! See also... If you plan to compile Linux often, you might want to use a C compiler cache; see this post. Once you have Linux booting on your platform the next step is to give it a root filesystem. See this post for a Debian root filesystem, this post for a minimal busybox filesystem and this post for generating a root filesystem with buildroot.

1. User Case: Demo Architecture: Demo Description: A, B, C and Speaker all are i.MX6DQ SabreSD board and running Ubuntu system. A is media server which send out broadcast 30Mbps h264 video and audio stream and running iperf to send out tcp packets via best efforts lane to PC. B and C are clients to get video data only and play in screen.  Speaker is a client to receive audio data only and play to speaker. PC which install ubuntu system is used to received best efforts data from A. Demo Goal: Use Gstreamer playback 30Mbps streaming  "H264_AVC_1080p_30fps_27Mbps_mp3.avi", while running iperf TCP streaming under the following two case: 1. Running the non-CBS kernel 2. Enable the FIQ kernel Validate the Qav (Queue and Forwarding Protocol) which is developed by SW. 2. Resource: FIQ Patch: 0001-GIC-FIQ-EPIT-implement.patch 0002-set-EPIT-priority-to-highest.patch 0003-GIC-support-SMP-4-cores-of-FIQ.patch CBS &Shaper Patch: 0004-Implement-credit-base-shaper-alogrithim-to-schdule-A.patch 0005-enet-avb-CBS-SIRQ-rum-mode-pass-performance-stress-t.patch Others Patch: 0006-Fix-the-61883-sub-type-protocol-check.patch 0007-Add-hrtimer-for-the-sirq.-Talker-transmit-packets-nu.patch 0008-1.-Fix-memory-map-size-issue.patch 0009-Increase-BD-entries-to-reduce-the-full-times.patch 0010-Add-sys-interface-to-log-out-the-video-packet-number.patch 0011-Add-AVB-timestamp-support.patch 0012-GIC-support-SMP-4-cores-of-FIQ.patch Gstreamer UDPAVB Plug-in Library and Source: Library: udp/output/libgstudp.so Source: udp/* 3. Setup the Patch:       - Low level:  kernel enet driver implement CBS and traffic shaper:              1. Apply all the patches in the patch_whole.tar.gz in the attachment               2. Rebuild kernel 3.0.35: Enable "CONFIG_ENET_IMX6_AVB" to support AVB.                        Enable "CONFIG_RUN_IN_FIQ"  in kernel:            let CBS run in FIQ mode.                3. make uImage.                You can also use the uImage-avb-fig in the attachment directly.  Flash to the SD card use dd command, the user gudie refer to the  i.MX_6Dual6Quad SABRE_SD_Linux_User_Guide.pdf.                Note: the uImage_org_nonavb in the attachment is the kernel image without QAV and FIQ. - High level: use Gstreamer as the media input/output interface, encapsulation with IEEE1722 format:         Before the below action, you should already have seutp the Ubuntu Rootfs,  copied all the Freescale *.deb files that come alone with the Release BSP demo image package and copied all the MM codec *.deb files (IMX_MMCODEC_3.0.7.tar) that from Freescale offical website, the user gudie refer to the  i.MX_6Dual6Quad SABRE_SD_Linux_User_Guide.pdf. 1. Add gstreamer setup version as following: - gstreamer core version: 0.10.35 - gst-plugins-good version: 0.10.30 - gst-plugins-bad version: 0.10.11 2. Setup: - tar xvzf udp.tar.gz - cd gst-plugins-good-0.10.30 - ./configure - make - make install - cp ~/udp/* gst/udp/ - cd gst/udp - make - cp  libgstudp.so /usr/lib/gstreamer-0.10/ - gst-inspect | grep avb         //Check whether the avb plugin is installed successfully. If the three avb plugin is printed out in the terminal, the avb plugins are proved to install properly. 4. Run the Demo:       1.  Start the iperf server in PC linux machine by inputting " iperf -s -i 1&".              2.  Power on the A board, ensure the board can get the DHCP IP address, Start the iperf client on the demo board which sends outgoing Audio-Video streaming in the background. Input "iperf -c <iperf server ip> - t 6000&". If the connection is  successful, the iperf log should be able to be seen in the linux machine terminal.              3.  Power on the B and C board, inputting the following command to receive video data:            Run "./startRxVideoAVB.sh"  to start gstreamer video receive process on video display board       4.  Power on the speaker board, inputting the following command to receive audio data:             Run "./startRxAudioAVB.sh" to start gstream audio receive process on audio  playback board 5.  Inputting the following command to send video/audio data to client at the A board terminal windowns:                              Run "./startTxAVB.sh" to start the 1722 streaming traffic                                      (note: H264_AVC_1080p_30fps_27Mbps_mp3.avi located at current directory)               6.  Change to the kernel with QAV and follow the steps 1~5 above 5. Result: Without FIQ Qav,  video play at client B and C serious freeze. It takes 3 minutes to play 1min 40s h264 stream.  iperf speed over 80Mbps. With FIQ Qav, video play at client B and  C is smooth and same as without iperf in background. Iperf show speed is less than 70Mbps.  FIQ Qav correctly reserve necessary bandwidth to AV stream 6. Know issues Failed to request the IP from DHCP         [Solution]  For FIQ, after kernel up, you must run the command: echo 1 > /sys/devices/platform/imx_wfi_issue.0/enable   2.   Kernel is halted or crashed [Solution] In bootloader parameter, add 'nosmp' in bootargs_mmc.

 This article uses i.MX Linux® User's Guide, Rev. L4.1.15_2.1.0-ga, 05/2017 as an example (it may be found as attachment), please refer to section 4.5.12 (How to build U-Boot and Kernel in standalone environment).   First, generate a development SDK, which includes the tools, toolchain, and small rootfs to compile against to put on the host machine.     • Generate an SDK from the Yocto Project build environment with the following command. To set up the Yocto Project build environment, follow the steps in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG). In the following command, set <Target-Machine> to the machine you are building for.   <Target-Machine> may be one of the following :   • imx6qpsabreauto • imx6qpsabresd • imx6ulevk • imx6ull14x14evk • imx6ull9x9evk • imx6dlsabreauto • imx6dlsabresd • imx6qsabreauto • imx6qsabresd • imx6slevk • imx6sllevk • imx6solosabreauto • imx6solosabresd • imx6sxsabresd • imx6sxsabreauto • imx7dsabresd  The «populate_sdk» generates an script file that sets up environment without Yocto Project. This SDK should be updated for each release to pick up the latest headers, toolchain, and tools from the current release.   $ DISTRO=fsl-imx-fb MACHINE=<Target-Machine> source fsl-setup-release.sh -b build-fb   $ DISTRO=fsl-imx-fb MACHINE=<Target-Machine> bitbake core-image-minimal -c populate_sdk   or   $ bitbake meta-toolchain       • From the build directory, the bitbake was run in, copy the sh file in tmp/deploy/sdk to the host machine to build on and execute the script to install the SDK. The default location is in /opt but can be placed anywhere on the host machine.     Note. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.    $ . /opt/fsl-imx-fb/4.1.15-2.0.0/environment-setup-cortexa9hf-neon-poky-linux-gnueabi   or    $ source /opt/fsl-imx-fb/4.1.15-2.0.0/environment-setup-cortexa9hf-neon-poky-linux-gnueabi   From  Yocto Project Mega-Manual  Note By default, this toolchain does not build static binaries. If you want to use the toolchain to build these types of libraries, you need to be sure your image has the appropriate static development libraries. Use the  IMAGE_INSTALL  variable inside your  local.conf  file to install the appropriate library packages. Following is an example using  glibc  static development libraries:      IMAGE_INSTALL_append = " glibc-staticdev"   On the host machine, these are the steps to build U-Boot and Kernel:  • On the host machine, set the environment with the following command before building.   $ export CROSS_COMPILE=/opt/fsl-imx-fb/4.1.15/environment-setup-cortexa9hf-vfp-neon-pokylinux-gnueabi   $ export ARCH=arm • To build U-Boot, find the configuration for the target boot. In the following example, i.MX 6ULL is the target.     Download source by cloning with   $ git clone http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git -b imx_v2016.03_4.1.15_2.0.0_ga   $ cd uboot-imx $ make clean $ make mx6ull_14x14_evk_defconfig $ make u-boot.imx   • To build the kernel, execute the following commands:   Download source by cloning with   $ git clone http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git -b imx_4.1.15_2.0.0_ga   $ cd linux-imx $ make defconfig $ make   • To build an application (Hello World) as test.c:   $ source /opt/fsl-imx-fb/4.1.15-2.0.0/environment-setup-cortexa9hf-neon-poky-linux-gnueabi $ cd ~/test/ $ arm-poky-linux-gnueabi-gcc --sysroot=/opt/fsl-imx-fb/4.1.15-2.0.0/sysroots/cortexa9hf-neon-poky-linux-gnueabi -mfloat-abi=hard test.c To check if the the compiled code (a.out) is ARM executable   $ file ./a.out   ./a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=0e5c22dcf021748ead2c0bd51a4553cb7d38f6f2, not stripped   Copy file a.out to target Linux filesystem and before run it check again :   root@imx6ul7d:/unit_tests/1# file a.out   a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=0e5c22dcf021748ead2c0bd51a4553cb7d38f6f2, not stripped   To define what Linux libs are needed to run our application :   root@imx6ul7d:/unit_tests/1# ldd a.out     linux-vdso.so.1 (0x7ee93000)   libc.so.6 => /lib/libc.so.6 (0x76e64000)   /lib/ld-linux-armhf.so.3 (0x76f9d000)   If some libs are not located in the filesystem you can observe the following message :   -sh: root@imx6ul7d:/unit_tests/1#./a.out: No such file or directory   Finally - run a.out:   root@imx6ul7d:/unit_tests/1# ./a.out Hello World root@imx6ul7d:/unit_tests/1#

To disable the Android dm-verity in the new devices you should have the below. A Window/Linux computer The Android SDK platform-packages tools. Download the Android Packages tool. To use the Android kernel or give root access to your Android device, it is needed to have some tools from the Android SDK like ADB or fastboot. To download those tools just go to below web-page: https://developer.android.com/studio#downloads Go to the “command line tools only” part and download the sdk-tools-windows-4333796.zip package. Note: Is recommended to store the content of the zip file in path that you could find without any problem since the Android SDK tools can only be run by the terminal console.   Unlock your Android device. On the Android GUI go to Settings -> systems -> About Phone At the bottom, you should see the build number of your Android device. Tap it multiple times until appears on the screen that you are a developer now. Go to the developer options and search for the OEM unlock option. You need to activate that option. Open the power-shell terminal and go to the path where you stored the zip file.   Example for Windows: cd C:\users\diego\Documents\platform-tools‍ Then you will use the ADB tool (Adroid Debug Bridge). To use it you need to run adb.exe in your power-shell terminal. To run an executable in the Windows terminal is just with ".\". Connect the serial download cable to the host computer (the Type C for the i.MX8M and i.MX8MM. The OTG for the i.M6 SabreSD boards). Open the adb server. .\adb.exe start-server‍ See your connected devices. .\adb.exe devices‍ You should see your device and the serial number that is assigned to the device. Then, enter into Bootloader mode. .\adb.exe reboot bootloader‍       Note to see if your board successfully entered to Bootloader mode. In your serial terminal, you should see that you are in Bootloader mode. Once inside the Bootloader mode, using fastboot you can unlock your phone. First, see if your computer recognizes your board once inside the Bootloader mode. .\fastboot.exe devices‍ If you do not see any device, go to Appendix A of the document. Finally, Unlock and reboot the board. .\fastboot.exe oem-unlock .\fastboot.exe reboot‍‍         Unlock the dm-verity option. After the board rebooted. Start again the adb server .\adb.exe start-server .\adb.exe devices‍‍ Then root the board .\adb.exe root ‍ After rooting the board, disable the dm-verity option .\adb.exe disable-verity‍ After disabling the verity option, it will request you to reboot your board. Just reboot your board. .\adb.exe reboot ‍ With that, you should have successfully disabled the verity option on your board.   Appendix A Update the USB driver (For Windows only) If your computer does not recognize once you are inside the bootloader mode. What you need to do is update the USB driver. To update the driver, follow the below steps. First, open your device manager and locate the Universal Serial Bus devices -> USB download gadget. Then press the right-click and select the Update driver option. Select the “Browse my computer for driver software” option. Select the “Let me pick from a list of available drivers on my computer” option.     Select the ADB Device Model.   And accept to install the driver. After that, your computer should recognize the board being into Bootloader mode.   Appendix B connects your Android device to a Linux computer through ADB.   You could face some adb problems if you want to connect your Android device to a Linux computer. If you want to use adb, the Android image does not allow you due to a permission problem. To make it work, you need to create a new rule for a plug device. To make the new rule, create a document inside the /etc/udev/rules.d named 51-android.rules. Inside the document write the following:   SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="d002", MODE="0660",  GROUP="plugdev", SYMLINK+="android%n"‍‍   Where the ATTR{idVendor} and ATTR{idProduct} is the USB id for the board. To know that information. Write lsusb and your Android device is the one named Google Inc. Then reboot your computer. With this new rule, ADB should work as usual. Hope this document could be useful to someone. Best regards, Diego.

The Linux Kernel is just another recipe for Yocto, so learning to patch it you learn to patch any other package. In the other hand, Yocto **should not** be used for package development, but in those rare cases follow the below steps. It is assumed that you have already build the package you want to patch. 1. Create the patch or patches. In this example we are patching the Linux kernel for [wandboard-dual](http://www.wandboard.org/) machine; in other words, the value of MACHINE on the `build/conf/local.conf` is `MACHINE ??= 'wandboard-dual'`. In case you already have the patches, make sure these can be nicely applied with the commands `git apply --check <PATCH_NAME>`, and jump this step build $ cd tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git build $ # Edit any files you want to change build $ git add <modified file 1> <modified file 2> .. # Select the files you want to commit build $ git commit -s -m '<your commit's title>' # Create the commit build $ git format-patch -1 # Create the patch 2. Create a new layer (see document i.MX Yocto Proyect: How can I create a new Layer?) 3. On the new layer (e.g `meta-fsl-custom`) , create the corresponding subfolders and the `.bbfile` sources $ mkdir -p meta-fsl-custom/recipes-kernel/linux/linux-wandboard-3.0.35/ sources $ cat > meta-fsl-custom/recipes-kernel/linux/linux-wandboard_3.0.35.bbappend FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" SRC_URI += "file://0001-calibrate-Add-printk-example.patch" PRINC := "${@int(PRINC) + 1}" # SEE NOTE BELLOW ^d (The PRINC variable is not needed starting at Yocto 1.6 ([RFC] base.bbclass: Deprecate the PRINC logic - Patchwork)) 4. Move the patch to the new layer sources $ cp \ ../build/tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git/0001-calibrate-Add-printk-example.patch \ meta-fsl-custom/recipes-kernel/linux/linux-wandboard-3.0.35 5. Setup the enviroment and clean previous package's build data (sstate) fsl-community-bsp $ . setup-environment build build $ bitbake -c cleansstate linux-wandboard 6. Compile and Deploy build $ bitbake -f -c compile linux-wandboard build $ bitbake -c deploy linux-wandboard 7. Insert the SD into your Host and copy the `uImage` into the first partition. Do not forget to unmount the partition before removing the card! build $ sudo cp tmp/deploy/images/uImage /media/Boot\ wandbo/ 8. Insert the SD into your board and test your change.

How to change Linux Kernel configuration file in Yocto Project metalayer Preparing the requirements Download the metalayer Git clone the Linux Kernel source code Customize the configuration Copy the configuration to the metalayer Install the patch in the Linux Kernel recipe Build the new image with the different Linux Kernel configuration How to change Linux Kernel configuration file in Yocto Project metalayer It is common that the metalayer providing a Linux Kernel recipe includes a default configuration file for the Linux Kernel source code (the defconfig file). There are several approaches to customize the Linux Kernel source code and defconfig file. This article presents the option to patch the defconfig from the Linux Kernel source code and is a good approach to be used with meta-fsl-bsp-release or meta-imx . Preparing the requirements The list of requirements: the target metalayer (in this example, it's meta-imx:imx-5.4.3-2.0.0 ) the same Linux Kernel source code, but git cloned Download the metalayer For example, take BSP release imx-5.4.3-2.0.0 for meta-imx $ mkdir <BSP_DIR> $ cd <BSP_DIR> $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.3-2.0.0.xml $ repo sync $ MACHINE=imx8mnevk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Git clone the Linux Kernel source code Use the very same Linux Kernel source code from the metalayer. In this example, open the file sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb to get the git repository, and git commit. $ cd ~ $ git clone git://source.codeaurora.org/external/imx/linux-imx.git $ cd linux-imx $ git checkout fd263a3edd95dfe812397fabf1059b5f99bba2ab -b change_defconfig‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Customize the configuration Using the default defconfig as a base, configure the Linux Kernel, and then use make menuconfig to change the configuration as desired. After the customization, generate a new defconfig file and replace the default one. The step by step with all the commands can be see in next snippet: $ export ARCH=arm64 $ export CROSS_COMPILE=aarch64-linux-gnu- $ make defconfig $ make menuconfig $ make savedefconfig $ cp defconfig arch/arm64/configs/defconfig‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The customization can be highlighted by git, in this example the result is show in next log: $ git status On branch change_defconfig Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: arch/arm64/configs/defconfig Untracked files: (use "git add <file>..." to include in what will be committed) defconfig no changes added to commit (use "git add" and/or "git commit -a")‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Review the change and create a commit, with that commit, create a patch. TIP: The defconfig file can also be directly changed. The make menuconfig can be skipped in that case. $ git add arch/arm64/configs/defconfig $ git commit -s -m "defconfig: Customize defconfig" $ git format-patch -1 0001-defconfig-Customize-defconfig.patch‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Copy the configuration to the metalayer Now that the Linux Kernel configuration is customized, and a patch to the kernel is created, copy over that patch to the metalayer, and install it to the Linux Kernel recipe file. $ mkdir <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx/ $ cp 0001-defconfig-Customize-defconfig.patch <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx/‍‍ Install the patch in the Linux Kernel recipe The Linux Kernel recipe for this example is linux-imx_5.4.bb . Edit the file to install the patch. $ gedit <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb‍ Add the following line: SRC_URI += "file://0001-defconfig-Customize-defconfig.patch "‍ The resultant change is show above: $ cd <BSP_DIR>/sources/meta-imx/ $ git diff diff --git a/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb b/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb index 214647abb..3f926314c 100644 --- a/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb +++ b/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb @@ -16,6 +16,7 @@ KERNEL_BRANCH ?= "imx_5.4.3_2.0.0" LOCALVERSION = "-2.0.0" KERNEL_SRC ?= "git://source.codeaurora.org/external/imx/linux-imx.git;protocol=https" SRC_URI = "${KERNEL_SRC};branch=${KERNEL_BRANCH}" +SRC_URI += "file://0001-defconfig-Customize-defconfig.patch " SRCREV = "fd263a3edd95dfe812397fabf1059b5f99bba2ab"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Build the new image with the different Linux Kernel configuration Remember to change the current directory to the metalayer. Build the image again. The new image binary reflects the changes in Linux Kernel, and in case the change removes some kernel module, the rootfs also reflects the change. $ cd <BSP_DIR>/bld-xwayland $ bitbake‍ <image-name>‍‍‍‍‍‍‍‍‍‍

                                                                                         Watch the Freescale i.MX team boot up Android 5.0 Lollipop in i.mx6 application processors—在线播放—优酷网，视频高清在线观看 The Freescale i.MX Android team has booted up Android 5.0 Lollipop in the SABRE platform for i.mx6 series. Google pushed all of the latest source for its Android release to AOSP on Nov. 5, and the Freescale Android Team started their work. With the previous 6 days to boot Android Lollipop up, the Freescale i.MX Android team enabled the basic features like connectivity, audio/video playback, sensors, inputs and display on day 7! You can see the some changes in the demo video at the beginning of the post. The Freescale i.MX Android team has closely followed almost every version of Android since it is released by AOSP and has good experience on it. Below are some snapshots and pictures for the Android Lollipop.

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

1.  Software change for Certification Test Compared to standard Linux/Android release, you may need to do below software changes to implement the certification tests, it is applicable from imx_3.10.31_1.1.0 Linux BSP GA release, for the release before that, user may need to apply the related patches before doing below things, and some examples may be different for former releases, the user needs to change accordingly. See the detailed information in this document “How to do USB Compliance Test for 3.10.y kernel”. And there is also a link describes the patch for USB Certification Test: Patch to make i.MX6DQ USB to support test modes for certification test 2. I.MX6 series USB Certification Guide http://cache.freescale.com/files/microcontrollers/doc/user_guide/IMXUSBCGUG.pdf Include the descriptions of all the Certification Test requirements, equipment, procedures for I.MX6 series. For example, Host/Device High Speed Eye Diagram Test(眼图测试).   3. Description of USBCertification related Registers AN4589 Configuring USB on i.MX 6 Series Processors http://cache.freescale.com/files/32bit/doc/app_note/AN4589.pdf   4. I.MX6Q/I.MX6DL/I.MX6SL/ I.MX6SX Certification Reports, see attachments   5. Checklist and TPL, see attachments. Original Attachment has been moved to: I.MX6SX-Checklist-and-TPL.zip

The edit-compile-test loop is the quickest way so can test your changes. 1. Go to the package's source code folder and edit your files. 2. Compile that particular package, e.g. bitbake linux-imx -c compile -f 3. Deploy, e.g. bitbake linux-imx -c deploy 4. Insert the SD card into your host, and copy the Linux kernel into the the first partition sudo cp tmp/deploy/images/uImage /media/Boot 5. Insert the SD card into your board, boot and test your changes 6. In case you are satisfied with the results, you need to create a patch and add into the package's recipe. Check this document to execute this step.

This is the prototype solution to enable second display showing different things on JB4.2.2 SabreSD. Make use of Class Presentation provided by android to be embedded into Status bar. When unlock the screen, the Presentation will show on second display. Now, the solution requires one .mp4 video placed in root sdcard. Of course, you may change it to show anything. The attached Files are a layout xml file, a patch and a recorded video. The layout file should be put into android/frameworks/base/packages/SystemUI/res/layout/ folder. The patch should be applied to frameworks/base.git. The recorded video shows the dual display demo as a reference.

Pre-requisites: An TFTP server U-boot with TFTP capabilities If you need to run a script (for example, running multiple setenv's commands) in U-boot for many boards, you can instead create a U-boot script (called script image), place it into your tftp folder, then ask U-boot to fetch it and run it. For example, you want to run the following setenv instructions setenv loadaddr 0x10800000 setenv bootargs_base 'setenv bootargs console=ttymxc0,115200' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666' setenv bootcmd_mmc 'run bootargs_base bootargs_mmc;mmc dev 3;mmc read ${loadaddr} 0x800 0x2000;bootm' run bootcmd_mmc save it into a file, I choose the name 'myscript'; under your <U-boot folder>/tools, execute $ mkimage -T script -C none -n 'My Script' -d myscript myscript.img and copy myscript.img file into your TFTP folder. On the target, set the following two variables (serverip and bootcmd) # Set the Server IP, where the TFTP server is running setenv serverip <the server IP> # In case the server IP is static, you can place this line into the U-boot script setenv scriptaddr 0x10700000 setenv scriptname myscript.img # You can use either TFTP or DHCP setenv tftpcmd tftp # or 'dhcp'  in case you want to use dhcp U-boot command # Not needed for dhcp setenv ipaddr <the target IP> # needed in case the command tftp is used setenv gatewayip <the Gateway IP> # needed in case the command tftp is used setenv bootcmd '${tftpcmd} ${scriptaddr} ${scriptname}; source ${scriptaddr}' saveenv reset That is all you need to do. Enjoy U-booting!

Multiple-Overlay (or Multi-Overlay) means several video playbacks on a single screen. In case multiple screens are needed, check the dual-display case GStreamer i.MX6 Multi-Display $ export VSALPHA=1 $ SAMPLE1=sample1.avi; SAMPLE2=sample2.avi; SAMPLE3=sample3.avi; SAMPLE4=sample4.avi; $ WIDTH=320; HEIGHT=240; SEP=20 Four displays (2x2) $gst-launch \ playbin2 uri=file://`pwd`/$SAMPLE1 video-sink="mfw_isink axis-top=0 axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT" \ playbin2 uri=file://`pwd`/$SAMPLE2 video-sink="mfw_isink axis-top=0 axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT" \ playbin2 uri=file://`pwd`/$SAMPLE3 video-sink="mfw_isink axis-top=`expr $HEIGHT + $SEP` axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT" \ playbin2 uri=file://`pwd`/$SAMPLE4 video-sink="mfw_isink axis-top=`expr $HEIGHT + $SEP` axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT" Basic rotation, (2 x 1, normal and inverted) gst-launch \ playbin2 uri=file://`pwd`/$SAMPLE1 video-sink="mfw_isink axis-top=0 axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT rotation=0" \ playbin2 uri=file://`pwd`/$SAMPLE2 video-sink="mfw_isink axis-top=`expr $HEIGHT + $SEP` axis-left=0 disp-width=$WIDTH disp-height=$HEIGHT rotation=3"

In some cases it is desired to directly have progressive content available from a TV-IN interface through the V4L2 capture device. In the BSP, HW accelerated de-interlacing is only supported in the V4L2 output stream. Below is a patch created against a rather old BSP version that adds support for de-interlaced V4L2 capture. The patch might need to be adapted to newer BSPs, However, the logic and functionality is there and should shorten the development time. This patch adds another input device to the V4L2 framework that can be selected to perform the deinterlacing on the way to memory. The selection is done by passing the index “2” as an argument to the VIDIOC_S_INPUT  V4L2 ioctl. Attached is also a modified the tvin unit test to give an example of how to use the new driver. An example sequence for running the test is as follows: modprobe mxc_v4l2_capture ./mxc_v4l2_tvin_vdi.out -ow 720 -oh 480 -ol 10 -ot 20 -f YU12 Some key things to note: This driver does not support resize or color space conversion on the way to memory. The requested format and size should match what can be provided directly by the sensor. The driver was tested on a Sabre AI Rev A board running Linux 12.02. This code is not an official delivery and as such no guarantee of support for this code is provided by Freescale.

Boundary Devices has a tool to load directly a U-boot binary file, all using the USB OTG port. Assuming that you have connected your i.MX board to your Linux Host through an USB cable, board is power-on  with dip switches configure to 'Serial Download Mode' (this configuration depends on the board you are booting),  clone the imx_usb_loader repo, generate the tool then boot as indicate below: $ git clone https://github.com/boundarydevices/imx_usb_loader.git $ cd imx_usb_loader $ make $ ./ imx_usb   ../ tmp/deploy/images/ u-boot.imx On the console terminal, you should see the booting kernel logs and at the end reaching the login prompt. Useful Links: [1] Unbricking a Nitrogen6X or Sabre Lite i.MX6 board [2] Boundary Devices Repos [3] Boundary Devices Main page

    Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab       I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARM64 and test on i.MX8MQ EVK board. I did over night test( 5 real-time threads + GPU SDK test case) and stress test by tool stress-ng on i.MX8MQ EVK board. It looks lile pretty good. Current version (20200730) also support i.MX8MM EVK.     You need git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-4.19.35-1.1.0-20200818 (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitbake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command (/usr/xenomai/demo/cyclictest -p 99 -t 5 -m -n -i 1000  -l 100000😞 //Over normal Linux kernel without GPU SDK test case T: 0 ( 4220) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 9 Max: 23 T: 1 ( 4221) P:99 I:1500 C: 66672 Min: 7 Act: 10 Avg: 10 Max: 20 T: 2 ( 4222) P:99 I:2000 C: 50001 Min: 7 Act: 12 Avg: 10 Max: 81 T: 3 ( 4223) P:99 I:2500 C: 39998 Min: 7 Act: 11 Avg: 10 Max: 29 T: 4 ( 4224) P:99 I:3000 C: 33330 Min: 7 Act: 13 Avg: 10 Max: 26 //Over normal Linux kernel with GPU SDK test case T: 0 ( 4177) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 11 Max: 51 T: 1 ( 4178) P:99 I:1500 C: 66673 Min: 7 Act: 12 Avg: 10 Max: 35 T: 2 ( 4179) P:99 I:2000 C: 50002 Min: 7 Act: 12 Avg: 11 Max: 38 T: 3 ( 4180) P:99 I:2500 C: 39999 Min: 7 Act: 12 Avg: 11 Max: 42 T: 4 ( 4181) P:99 I:3000 C: 33330 Min: 7 Act: 12 Avg: 11 Max: 36   //Cobalt with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --timeout 600s --metrics-brief T: 0 ( 4259) P:50 I:1000 C:3508590 Min:      0 Act:    0 Avg:    0 Max:      42 T: 1 ( 4260) P:50 I:1500 C:2338831 Min:      0 Act:    1 Avg:    0 Max:      36 T: 2 ( 4261) P:50 I:2000 C:1754123 Min:      0 Act:    1 Avg:    1 Max:      42 T: 3 ( 4262) P:50 I:2500 C:1403298 Min:      0 Act:    1 Avg:    1 Max:      45 T: 4 ( 4263) P:50 I:3000 C:1169415 Min:      0 Act:    1 Avg:    1 Max:      22   //Cobalt without GPU SDK test case T: 0 ( 4230) P:50 I:1000 C: 100000 Min: 0 Act: 0 Avg: 0 Max: 4 T: 1 ( 4231) P:50 I:1500 C:   66676 Min: 0 Act: 1 Avg: 0 Max: 4 T: 2 ( 4232) P:50 I:2000 C:   50007 Min: 0 Act: 1 Avg: 0 Max: 8 T: 3 ( 4233) P:50 I:2500 C:   40005 Min: 0 Act: 1 Avg: 0 Max: 3 T: 4 ( 4234) P:50 I:3000 C:   33338 Min: 0 Act: 1 Avg: 0 Max: 5 //Cobalt with GPU SDK test case T: 0 ( 4184) P:99 I:1000 C:37722968 Min: 0 Act: 1 Avg: 0 Max: 24 T: 1 ( 4185) P:99 I:1500 C:25148645 Min: 0 Act: 1 Avg: 0 Max: 33 T: 2 ( 4186) P:99 I:2000 C:18861483 Min: 0 Act: 1 Avg: 0 Max: 22 T: 3 ( 4187) P:99 I:2500 C:15089187 Min: 0 Act: 1 Avg: 0 Max: 23 T: 4 ( 4188) P:99 I:3000 C:12574322 Min: 0 Act: 1 Avg: 0 Max: 29 //Mercury without GPU SDK test case T: 0 ( 4287) P:99 I:1000 C:1000000 Min: 6 Act: 7 Avg: 7 Max: 20 T: 1 ( 4288) P:99 I:1500 C:  666667 Min: 6 Act: 9 Avg: 7 Max: 17 T: 2 ( 4289) P:99 I:2000 C:  499994 Min: 6 Act: 8 Avg: 7 Max: 24 T: 3 ( 4290) P:99 I:2500 C:  399991 Min: 6 Act: 9 Avg: 7 Max: 19 T: 4 ( 4291) P:99 I:3000 C:  333322 Min: 6 Act: 8 Avg: 7 Max: 21 //Mercury with GPU SDK test case T: 0 ( 4222) P:99 I:1000 C:1236790 Min: 6 Act: 7 Avg: 7 Max: 55 T: 1 ( 4223) P:99 I:1500 C:  824518 Min: 6 Act: 7 Avg: 7 Max: 44 T: 2 ( 4224) P:99 I:2000 C:  618382 Min: 6 Act: 8 Avg: 8 Max: 88 T: 3 ( 4225) P:99 I:2500 C:  494701 Min: 6 Act: 7 Avg: 8 Max: 49 T: 4 ( 4226) P:99 I:3000 C:  412247 Min: 6 Act: 7 Avg: 8 Max: 53 //////////////////////////////////////// Update for Yocto L5.4.47 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.47 2.2.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP). You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git,  and git checkout xenomai-5.4.47-2.2.0. You need to add the following variable in conf/local.conf before build xenomai by command bitbake imx-image-multimedia.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.4.70 2.3.0  /////////////////////////////////////////////////////////// New release  for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.0. Updating: 1, Support i.MX8QM and i.MX8QXP 2, Fix altency's the issue which uses legacy API to get time   //////////////////////////////////////// update for Yocto L5.4.70 2.3.2  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-5.4.70-2.3.2. Updating: 1, Enable Xenomai RTDM driver in Linux Kernel 2, Currently CAN, UART, GPIO,  SPI and Ethernet (in debug for RTNet)  are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf to enable relative device in Xenomai domain, for example rt-imx8mp-flexcan.   //////////////////////////////////////// Update for Yocto L5.4.70 2.3.4  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.4. You need to git clone  https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.4. Updating: 1, Enable RTNet FEC driver 2, Currently CAN, UART, GPIO,  SPI and Ethernet ( FEC Controller)  are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf and KERNEL_DEVICETREE += " freescale/imx8mm-rt-ddr4-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mmddr4evk.conf to enable rt_fec device in Xenomai domain. Verifying the network connection by RTnet Ping Between i.MX8M Mini EVK and i.MX8M Plus EVK a, Setup test environment 1, Connect ENET1 of  i.MX8M Plus EVK (used as a master) and  ENET of i.MX8M Mini EVK (used as a slave) of  to a switch or hub 2, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Plus EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.101" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -65,7 +65,7 @@ TDMA_MODE="master" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 3, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Mini EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.102" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -59,13 +59,13 @@ STAGE_2_CMDS="" # TDMA mode of the station ("master" or "slave") # Start backup masters in slave mode, it will then be switched to master # mode automatically during startup. -TDMA_MODE="master" +TDMA_MODE="slave" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 4, rename imx8mm-rt-ddr4-evk.dtb to imx8mm-ddr4-evk.dtb in /run/media/mmcblk1p1,  rename imx8mp-rt-evk.dtb to imx8mp-evk.dtb in /run/media/mmcblk1p1, and reboot board. 5, Run the below command on i.MX8M Mini EVK board. cd /usr/xenomai/sbin/ ./rtnet start & 5, Run the below command on i.MX8M Plus EVK board. cd /usr/xenomai/sbin/ ./rtnet start & When you see the log (rt_fec_main 30be0000.ethernet (unnamed net_device) (uninitialized): Link is Up - 100Mbps/Full - flow control rx/tx) and you can run command "./rtroute" to check route table if the slave IP (192.168.100.102) is in route.. b, Verify the network connection using the command below: ./rtping -s 1024 192.168.100.102 //////////////////////////////////////// Update for Yocto L5.10.52 2.1.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.52 2.1.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.52-2.1.0. Updating: 1, Upgrade Xenomai to v3.2 2, Enable Dovetail instead of ipipe. Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch.  Latency testing of Xenomai3.2+Dovetail with isolating CPU 2,3 ( Xenomai 3.2 on 8MM DDR4 EVK with GPU test case (GLES2/S08_EnvironmentMappingRefraction_Wayland) + iperf3 + 2 ping 65000 size + stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief )😞 The following is test result by the command (/usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000) root@imx8mmddr4evk:~# /usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 5.96 6.04 6.03 7/155 1349 T: 0 ( 615) P:50 I:1000 C:63448632 Min: 0 Act: 0 Avg: 0 Max: 55 T: 1 ( 616) P:50 I:1500 C:42299087 Min: 0 Act: 0 Avg: 1 Max: 43 T: 2 ( 617) P:50 I:2000 C:31724315 Min: 0 Act: 0 Avg: 1 Max: 51 T: 3 ( 618) P:50 I:2500 C:25379452 Min: 0 Act: 0 Avg: 1 Max: 53 T: 4 ( 619) P:50 I:3000 C:21149543 Min: 0 Act: 0 Avg: 1 Max: 47 //////////////////////////////////////// Update for Yocto L5.10.72 2.2.2  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.72 2.2.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.72-2.2.2. Updating: 1, Upgrade Xenomai to v3.2.1 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.15.71 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.15.71 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.15.71-2.2.0. Updating: 1, Upgrade Xenomai to v3.2.2 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai"   //////////////////////////////////////// Update for Yocto L6.1.55 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L6.1.55 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git recipes-rtlinux-xenomai -b Linux-6.1.x Updating: 1, Upgrade Xenomai to v3.2.4 and support i.MX93 2, Enable EVL (aka Xenomai 4) for i.MX93 and legacy i.MX(6/7D/8X/8M) Copy recipes-rtlinux-xenomai to <Yocto folder>/sources/meta-imx/meta-bsp/, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "evl" IMAGE_INSTALL:append += " libevl"   //////////////////////////////////////// Update for Yocto L6.6.52 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L6.6.52 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git recipes-rtlinux-xenomai -b Linux-6.6.52 Updating: 1, Upgrade Xenomai to v3.3 and support i.MX91/93/95 2, Upgrade EVL (aka Xenomai 4),  libevl to r50 and support i.MX91/93/95 Copy recipes-rtlinux-xenomai to <Yocto folder>/sources/meta-imx/meta-bsp/, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "evl" IMAGE_INSTALL:append += " libevl"    

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