Question: Is it true ture that MX6 VPU is capable of encoding dual H.264 streams that are 1024x600 at 60fps?  There are slides that claim three 720p30 streams or two 1080p30 streams simultaneously. There is little guidance as to what the VPU limits in resolution, frame rate and bit rate are for other resoluitons and frame rates. Is there any information that can be used to decide if  the VPU can encode an arbitrary video stream or multiple arbitrary video streams?  Since memory bandwidth will enter into this decision at some point has anyone quantified the memory bandwidth requirements verses video resolution and frame rate? Answer: Maximum supported trhoughput,  is 72,576,000 pixels /s @ VPU frecuency of 266 mhz 2 x  1024 x 600 x 60hz = 73,728,000 So this is not supported. If framerate is lower i.e.  30hz  then it will be supported.

 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#

  IMX6 UL boot process is described in Chapter 8 (System Boot) of the Reference Manual. Also you may look at the following Community regarding i.MX6 boot ROM activity. How to build bootable SD image (for i.MX6 SL as example)  U-boot is used as Linux bootloader and U-boot image should be located in SD area, used by i.MX6 boot ROM. The simplest way to get bootable SD card is just to copy system image in so called .sdcard format. Such image is prepared in Yocto by default and can be transfered to SD card with Linux dd command or Windows win32diskimager utility. Guide to the .sdcard format  Win32 Disk Imager download | SourceForge.net   The full SD image (.sdcard) should contain all parts, needed for Linux boot (U-boot, kernel, dtb, file system), maybe except U-boot environment. Carry out the following command to copy the SD card image to the SD/MMC card. Change sdx below to match the one used by the SD card. $ sudo dd if=<image name>.sdcard of=/dev/sdx bs=1M && sync   Note, U-boot environment (described below) should be set (and saved) in U-boot after the first start.   In any case it makes sense to understand general structure and implementation details of bootable SD card. Instructions are provided in section 4.3 (Preparing an SD/MMC card to boot) of i.MX Linux® User's Guide in Linux doc package (L4.1.15_2) http://www.nxp.com/webapp/Download?colCode=L4.1.15_2.1.0_LINUX_DOCS&Parent_nodeId=1337699481071706174845&Parent_pageType…  Summary page : i.MX 6 / i.MX 7 Series Software and Development Tool|NXP    For a Linux image to be able to run, four separate pieces are needed: • Linux OS kernel image (zImage) • Device tree file (*.dtb) • U-Boot bootloader image • Root file system (*.ext3 or *.ext4)   The mentioned files may be found in demo images on NXP Web or generated with Yocto. After a build is complete, the created image resides in <build directory>/tmp/deploy/images The device tree file (.dtb) contains board and configuration-specific changes to the kernel. Change the device tree file to change the kernel for a different i.MX board or configuration.    By default, the kernel image and DTB are located on FAT partition without a fixed raw address on the SD card. Generally fix addresses / blocks of SD card may be applied for kernel and DTB location. The users have to change the U-Boot boot environment if the fixed raw address is required. In example below the following image layout on SD card is assumed : Start address (sectors) = 0x400 bytes (2) for U-boot (i.MX6 boot ROM reads first 4K bytes of SD card). Start address (sectors) = 0xa00000 bytes (20480) for FAT partition, size=500MB, intended for Kernel zImage and DTBs. Start address (sectors) = 0x25800000 bytes (1228800) for rootfs.    Preparing the card   An SD/MMC card reader, such as a USB card reader, is required. Any Linux distribution can be used. Further follow instructions in sections 4.3.1 (Preparing the card), 4.3.3 (Partitioning the SD/MMC card), 4.3.4 (Copying a bootloader image), 4.3.5 (Copying the kernel image and DTB file), 4.3.6 Copying the root file system (rootfs) of attached "i.MX_Graphics_User's_Guide.pdf". The next step - try to insert the SD card to slot in i.MX6UL board, select proper boot options for SD boot and power the system. U-boot prompt should appear. Finally it is needed to configure environment for further Linux boot from SD. U-Boot > setenv mmcdev 1 U-Boot > setenv mmcpart 1 U-Boot > setenv mmcroot '/dev/mmcblk1p2 rootwait rw' U-Boot > setenv loadaddr 0x80800000 U-Boot > setenv fdt_addr=0x83000000 U-Boot > setenv fdt_file imx6ul-9x9-evk.dtb U-Boot > setenv mmcpart 1 U-Boot > setenv loadfdt 'fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}' U-Boot > setenv loadkernel 'fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage' U-Boot > setenv bootcmd 'mmc dev ${mmcdev}; run loadkernel; run mmcargs; run loadfdt; bootz $ {loadaddr} - ${fdt_addr};' U-boot > saveenv fdt_file should be set for your case ( on example “imx6ul-9x9-evk.dtb”) Try reboot with new environment.

Using a RAW NAND is more difficult compared to eMMC, but for lower capacity it is still cheaper. Even with the ONFI (Open NAND Flash Interface) you can face initialization issue you can find by measure performance. I will take example of a non-well supported flash, I have installed on my evaluation board (SABRE AI). I wanted to do a simple performance test, to check roughly the MB/s I can expected with this NAND. One of a simplest test is to use the dd command: root@imx6qdlsolo:~# time dd if=/dev/mtd4 of=/dev/null 851968+0 records in 851968+0 records out 436207616 bytes (436 MB, 416 MiB) copied, 131.8884 s, 3.3 MB/s ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ As my RAW was supposed to work in EDO Mode 5, I could expect more than 20MB/s. To check what was wrong, read you kernel startup log: Booting Linux on physical CPU 0x0 Linux version 4.1.15-2.0.0+gb63f3f5 (bamboo@yb6) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Fri Sep 16 15:02:15 CDT 2016 CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: Freescale i.MX6 DualLite/Solo SABRE Automotive Board [...] Amd/Fujitsu Extended Query Table at 0x0040 Amd/Fujitsu Extended Query version 1.3. number of CFI chips: 1 nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xdc nand: Macronix MX30LF4G18AC nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 gpmi-nand 112000.gpmi-nand: mode:5 ,failed in set feature. Bad block table found at page 262080, version 0x01 Bad block table found at page 262016, version 0x01 nand_read_bbt: bad block at 0x00000a7e0000 nand_read_bbt: bad block at 0x00000dc80000 4 cmdlinepart partitions found on MTD device gpmi-nand Creating 4 MTD partitions on "gpmi-nand":‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ On line 13 you can read "mode:5, failed in set feature", meaning you are not in mode 5... so you have the "relaxed" timing you have at boot. After debuging your code (I have just remove the NAND back reading security check), you can redo the test: root@imx6qdlsolo:~# time dd if=/dev/mtd4 of=/dev/null 851968+0 records in 851968+0 records out 436207616 bytes (436 MB, 416 MiB) copied, 32.9721 s, 13.2 MB/s‍‍‍‍‍‍‍‍‍‍‍‍ So you multiplied the performances by 4! Anyway, you have a better tool to measure your NAND performance, it is mtd_speedtest, but you have to rebuild your kernel. In Yocto, reconfigure your kernel (on your PC of couse!): bitbake virtual/kernel -c menuconfig‍‍‍ Choose in the menu "Device Drivers" -> "Memory Technology Device (MTD) support" -> "MTD tests support", even it it not recommended! bitbake virtual/kernel -f -c compile bitbake virtual/kernel -f -c build bitbake virtual/kernel -f -c deploy‍‍‍‍‍‍‍‍‍ Then reflash you board (kernel + rootfs as tests are .ko files): Then you can do more accurate performance test: insmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko dev=2 ================================================= mtd_speedtest: MTD device: 2 mtd_speedtest: MTD device size 16777216, eraseblock size 131072, page size 2048, count of eraseblocks 128, pages per eraseblock 64, OOB size 64 mtd_test: scanning for bad eraseblocks mtd_test: scanned 128 eraseblocks, 0 are bad mtd_speedtest: testing eraseblock write speed mtd_speedtest: eraseblock write speed is 4537 KiB/s mtd_speedtest: testing eraseblock read speed mtd_speedtest: eraseblock read speed is 16384 KiB/s mtd_speedtest: testing page write speed mtd_speedtest: page write speed is 4250 KiB/s mtd_speedtest: testing page read speed mtd_speedtest: page read speed is 15784 KiB/s mtd_speedtest: testing 2 page write speed mtd_speedtest: 2 page write speed is 4426 KiB/s mtd_speedtest: testing 2 page read speed mtd_speedtest: 2 page read speed is 16047 KiB/s mtd_speedtest: Testing erase speed mtd_speedtest: erase speed is 244537 KiB/s mtd_speedtest: Testing 2x multi-block erase speed mtd_speedtest: 2x multi-block erase speed is 252061 KiB/s mtd_speedtest: Testing 4x multi-block erase speed mtd_speedtest: 4x multi-block erase speed is 256000 KiB/s mtd_speedtest: Testing 8x multi-block erase speed mtd_speedtest: 8x multi-block erase speed is 260063 KiB/s mtd_speedtest: Testing 16x multi-block erase speed mtd_speedtest: 16x multi-block erase speed is 260063 KiB/s mtd_speedtest: Testing 32x multi-block erase speed mtd_speedtest: 32x multi-block erase speed is 256000 KiB/s mtd_speedtest: Testing 64x multi-block erase speed mtd_speedtest: 64x multi-block erase speed is 260063 KiB/s mtd_speedtest: finished =================================================‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You can now achieve almost 16MB/s, better than the dd test. Of course you cannot achieve more than 20MB/s, but you are not that far, and the NAND driver need optimizations. To redo the test: rmmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko insmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko dev=2 To check your NAND is in EDO mode 5, you can check your clock tree: /unit_tests/dump-clocks.sh clock          parent   flags    en_cnt pre_cnt      rate [...] gpmi_bch_apb   ---      00000005   0       0       198000000 gpmi_bch       ---      00000005   0       0       198000000 gpmi_io        ---      00000005   0       0        99000000 gpmi_apb       ---      00000005   0       0       198000000‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The IO are clocked now at 99MHz, thus you can read at 49.5MHz (20ns in EDO mode 5 definition).

Please make sure design is follow below checking list before checking this guide. HW Design Checking List for i.MX6DQSDL

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

INTRODUCTION REQUIREMENTS HARDWARE CONNECTIONS IMPLEMENTATION FUNCTIONAL DEMONSTRATION     1. INTRODUCTION   This document explains how to establish communication between the A9 core running Linux and the M4 core running an Arduino sketch on a UDOO NEO board to remotely control a robotic arm over Wi-Fi.   Figure 1: UDOO NEO board connected to the robotic arm   For more information about getting started with UDOO NEO board please refer to: Introduction - UDOO Neo Docs     2. REQUIREMENTS a) UDOO NEO board with UDOObuntu image and proper connectivity. The Linux image used is UDOObuntu 2 RC1 or RC2 (Ubuntu 14.04), available for download from the following link:      ARM Development Boards | Extended Support from UDOO For creating a bootable SD card and other basic setup please refer to the following guidelines:      Very First Start - UDOO Neo Docs Then, it is required to install the proper drivers to ensure connectivity, including USB communication with Linux terminal of the target board. Please refer to the link below:      Usb Direct Connection - UDOO Neo Docs b) The robotic arm itself. In this case, the used arm has four servomotors: three for articulation and one for open/close the clamp. c) A Wi-Fi router, and an additional Wi-Fi device with any SSH client application for the remote control of the arm.     3. HARDWARE CONNECTIONS   a) The first connection to consider is the USB Direct connection of the UDOO NEO board with the host PC, in order to configure the Wi-Fi network and remotely view of the desktop (VNC client) for Arduino sketch programming.   b) Then, it is required to consider the arm connection, which consists of four servomotors. Therefore, the motors must be powered by a separate power supply and controlled by four PWM signals. In this case, they will be connected to PWM_1, PWM_2, PWM_3 and PWM_4 signals of J4 connector (Arduino signals). Figure 2 shows the mentioned connection:   Figure 2: Servomotors connection to UDOO NEO board.     4. IMPLEMENTATION   4.1 Connecting to a Wi-Fi network. After turning on the UDOO NEO board, the USB Direct connection will install a virtual NIC on the host PC, in order to access to the “Dashboard”, a configuration webpage loaded on the NEO board that could be viewed from any web browser at address 192.168.7.2. You can connect to wireless networks by using the Web Control Panel, in Configuration/Network settings. After establishing connection with the Wi-Fi router, the Dashboard must indicate the assigned IP address of the NEO board as indicated on Figure 3. It is important to remember such address in order to establish the wireless access to the NEO board later (optionally, the NEO could be configured for a static IP address, or the router could be configure to assign the same IP address to the NEO board).   Figure 3: Dashboard showing the IP address of the NEO board.   Now the USB direct connection could be removed, as the Dashboard, remote terminal and VNC server are also available over Wi-Fi using the Wi-Fi IP address.   4.2. Programming the Arduino sketch. The remote desktop of the NEO could be viewed with any VNC client on the host PC, indicating the NEO’s IP address, user and password (same as SSH remote Terminal). The UDOObuntu image already include Arduino IDE configured for UDOO NEO board, so it is just required opening it to start writing the code. Figure 3 shows the UDOO NEO Desktop, which includes a Terminal window and the Arduino IDE. The sketch is available as attachment.   Figure 4: Desktop of UDOO NEO board.   4.3. Arduino sketch functionality. The Arduino program starts waiting for any incoming data over the serial port. After receiving any serial data, the four servomotors are initialized to the default position (90°). The serial port communication is established between a virtual serial port on Arduino side (Serial0), and the virtual serial port for the Multi-Core Communication (ttyMCC), like shown on Figure 5. For additional information please refer to the link below: Communication - UDOO Neo Docs Figure 5: Communication between cores. Once the motors are initialized, each movement is defined by a key to increase and decrease the angle position of the motors, except for the clamp, which is adjusted to open/close positions. Keys 'Q' and 'W' adjust the first motor; keys 'A' and 'S' adjust the second motor; keys 'D' and 'F' adjust the third motor, and finally, keys 'Z' and 'X' are used to open/close the clamp. Additionally, key 'R' resets all motors to default positions; key 'C' is used to enable/disable the PWM signals, and key 'V' prints the angle values of all motors. The adjust step of motors is defined with the macro “ANGLE_STEP”; the units are degrees.     5. FUNCTIONAL DEMONSTRATION   For demonstrative functionality, the UDOO NEO board running the Arduino sketch was connected to a Wi-Fi network, and it is also connected to the same network an Android phone with SSH app used to control the robotic arm. Figure 6 shows a screen capture of the mentioned app controlling the robotic arm. Figure 6: SSH app accessing to UDOO NEO.   Finally, the following video shows the functionality of the application:   Original Attachment has been moved to: robo_arm.ino.zip

Platform: imx8qm mek imx-yocto-L4.14.98_2.0.0_ga Building Step: Apply the nvp6324 patches.   Symbol: IMX8_NVP6324 [=y] Type : tristate Prompt: IMX8 NVP6324 Driver Location: -> Device Drivers -> Multimedia support (MEDIA_SUPPORT [=y]) -> V4L platform devices (V4L_PLATFORM_DRIVERS [=y]) -> MX8 Video For Linux Video Capture (VIDEO_MX8_CAPTURE [=y]) (1) -> IMX8 Camera ISI/MIPI Features support ‍‍‍‍‍‍‍‍‍ select nvp6324 to y in menuconfig(default is 'y') make Image -j8; make freescale/fsl-imx8qm-mek-nvp6324.dtb, to build kernel and dts, outputs are at  work/imx8qmmek-poky-linux/linux-imx/4.14.98-r0/build/arch/arm64/Image work/imx8qmmek-poky-linux/linux-imx/4.14.98-r0/build/arch/arm64/boot/dts/freescale/fsl-imx8qm-mek-nvp6324.dtb copy them to the sd boot partition. reboot the board, you can test the first camera with command: ./mx8_v4l2_cap_drm.out -cam 1 -ow 1280 -oh 720 mx8_v4l2_cap_drm.out is at /unit_tests/V4L2/mx8_v4l2_cap_drm.out The corresponding video device should be default to /dev/video0 ~ /dev/video3.

This tool is also for emmc user partition mirror. Just give this tool the emmc files. The typical use case is for emmc mass production by emmc offline programming. Ver 0.4.0 2/14/2017 Support Android 7 Nougat. AndroidSDCARDMirrorCreator_Version_0.4.0_02142017.tgz Ver 0.3.2: 6/13/2016 Using static link simg2img AndroidSDCARDMirrorCreator_Version_0.3.2_06132016.tgz Ver 0.3.1: 5/31/2016 Remove some redundent code   AndroidSDCARDMirrorCreator_Version_0.3.1_05312016.tgz Ver 0.3: 5/25/2016 Add Marshmallow partition layout AndroidSDCARDMirrorCreator_Version_0.3_05252016.tgz Ver 0.2: Add Lollipop partition layout 1. Directory AndroidSDCARDMirrorCreator |-- AndroidSDCARDMirrorCreator.sh        --- main script |-- CFG.INC                              --- configuration file |-- KitKat_LAYOUT.INC                    --- KitKat partition layout |-- LAYOUT.INC -> Lollipop_LAYOUT.INC    --- symbol link to partition layout |-- Lollipop_LAYOUT.INC                  --- Lollipop partition layout `-- readme.txt                           --- this file 2. Need "root" run or "sudo" to run 3. parted and kpartx must be installed    sudo apt-get instal parted kpartx 4. test pass under the debian 8.2 and ubuntu 12.04 5. The AndroidSDCARDMirrorCreator.sh will look for LAYOUT.INC.    please make symbol link to the correct partition layout.    The default symbol link has created for Lollipop_LAYOUT.INC (LAYOUT.INC -> Lollipop_LAYOUT.INC) 6. Command    AndroidSDCARDMirrorCreator.sh -c    AndroidSDCARDMirrorCreator.sh -p 7. Example:    Suppose    The AndroidSDCARDMirrorCreator directory is in    ~/AndroidSDCARDMirrorCreator       The Android Images are in    ~/SD and ~/eMMC       Sdcdard Mirror:    cd ~/SD    ~/AndroidSDCARDMirrorCreator/AndroidSDCARDMirrorCreator.sh -c    eMMC Mirror:    cd ~/eMMC    ~/AndroidSDCARDMirrorCreator/AndroidSDCARDMirrorCreator.sh -c    8. Once the Mirror has been created. Can be reused. Just use kpartx.

MX7D_DDR3_压力测试应用手册_V1_201611108.doc

When to improve kernel booting using hibernation [1], I found kernel initialized each component [2] took too much time. One solution is to remove unnecessary module to save time. Another approach is to delay those modules until user space up. Then it won’t lost some features just because hopes to gain benefit on booting speed. This is very useful since hibernation’s trigger point is at the late_initcall [3]. Kernel doesn't need do much module initialize since hibernate will restore those module status later. The detailed implementation is in the attached patch. [1]: hibernation is a technique to store system memory content to storage. Then the device can be shutdown and read the content back after power on. [2]: component means subsystem or driver. [3]: Consult kernel/power/hibernate.c, software_resume

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

INTRODUCTION REQUIREMENTS CREATE A NEW PROJECT GPU EXAMPLE GSTREAMER EXAMPLE 1. INTRODUCTION:      The below steps show how to create different application examples using Elipse IDE. 2. REQUIREMENTS:      A fully working image and meta-toolchain generated in Yocto . You can follow the  next training: Yocto Training - HOME      Install and configure the Yocto Eclipse Plug-in. For more details about this requirement please refer to Setting up the Eclipse IDE for Yocto Application Development         To demonstrate the steps, L3.14.28  BSP, fsl-image-qt5 image and i.MX6Q SABRE-SDP board were used. 3. CREATE A NEW PROJECT      Follow the section Creating a Hello World Project of this document Setting up the Eclipse IDE for Yocto Application Development 4. GPU EXAMPLE           For this project we use the source code found in the fsl-gpu-sdk that can be downloaded from:      https://www.freescale.com/webapp/Download?colCode=IMX6_GPU_SDK&location=null&Parent_nodeId=1337637154535695831062&Parent…      Follow section 3 and create a new project named gputest.      From the IMX6_GPU_SDK choose one of the examples of GLES2.0 folder. In this case the 01_SimpleTriangle is chosen.      Copy the .c and .h files to the src directory of the gputest project. The Project Explorer window should look like this:              Add the needed files and libraries to compile and link in the Makefile.am file found in the ´src´ folder. The Makefile.am file should have the below content:          bin_PROGRAMS = gputest          gputest_SOURCES = gputest.c fsl_egl.c fslutil.c          AM_CFLAGS = @gputest_CFLAGS@          AM_LDFLAGS = @gputest_LIBS@ -lstdc++ -lm -lGLESv2 -lEGL -lX11 -ldl          CLEANFILES = *~ ​    Add the PATH to CFLAGS where the compiler will look for the headers at Project->Properties->Autotools->configure:           In this project there is no need to add extra PATHs for the headers. Apply the changes by clicking on Reconfigure Project. Build the project To test the file you can send the executable to the board with:           $ scp gputest root@<board_ip>:/home/root      $./gputest      You should get the next output in the display: 5. GSTREAMER EXAMPLE      For this project we use the source code found at Basic tutorial 1: Hello world! - GStreamer SDK documentation - GStreamer SDK documentation    Follow section 3 and create a new project named Gstreamer.    Copy the code of the basic tutorial to your Gstreamer.c file.    Add the needed files and libraries to compile and link in the Makefile.am file found in the ´src´ folder. The Makefile.am file should have the below content:                           bin_PROGRAMS = Gstreamer      Gstreamer_SOURCES = Gstreamer.c      AM_CFLAGS = @Gstreamer_CFLAGS@      AM_LDFLAGS = @Gstreamer_LIBS@ -lstdc++  -lVDK -lm -lGLESv2 -lGAL -lEGL  -ldl -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lglib-2.0      CLEANFILES = *~         ​    Add the PATH to CFLAGS where the compiler will look for the headers at Project->Properties->Autotools->configure:           For this example the next lines are added             -I${Sysroot}/usr/include/gstreamer-1.0        -I${Sysroot}/usr/include/glib-2.0        -I${Sysroot}/usr/include/libxml2        -I${Sysroot}/usr/lib/glib-2.0/include      Apply the changes by clicking on Reconfigure Project. Build the project To test the file you can send the executable to the board with:           $ scp Gstreamer root@<board_ip>:/home/root To execute the application on the board:      $./Gstreamer The board should have internet access and the application should play the video found at http://docs.gstreamer.com/media/sintel_trailer-480p.webm

i.MX6UL CSI (CMOS Sensor Interface) host port support BT.656(CCIR656) Interlace mode by hardware.  It can received  PAL(720pix X 576pix) and NTSC(720pix X 480 pix) format data from camera. This document introduce how to add this feature to Linux L3.14.38-ga and receive ADV7180 output. Software: yocto L3.14.38-ga. Hareware:  i.mx6ul-evk + ADV7180. ADV7180: PAL 720pix X576pix  ,  YUV4:2:2(UYVY) interlace output. LCD Display screen resolution:  800 X 480,  RGB565. 1) Note : For BT.656 mode,   parallel data port is  CSI_DATA[9:2], not CSI_DATA[13:6].    So,  "pinctrl_csi1" is the same as "ov5640" in "imx6ul-14x14-evk.dts": pinctrl_csi1: csi1grp {    fsl,pins = <     MX6UL_PAD_CSI_MCLK__CSI_MCLK  0x1b088     MX6UL_PAD_CSI_PIXCLK__CSI_PIXCLK 0x1b088     MX6UL_PAD_CSI_VSYNC__CSI_VSYNC  0x1b088     MX6UL_PAD_CSI_HSYNC__CSI_HSYNC  0x1b088     MX6UL_PAD_CSI_DATA00__CSI_DATA02 0x1b088     MX6UL_PAD_CSI_DATA01__CSI_DATA03 0x1b088     MX6UL_PAD_CSI_DATA02__CSI_DATA04 0x1b088     MX6UL_PAD_CSI_DATA03__CSI_DATA05 0x1b088     MX6UL_PAD_CSI_DATA04__CSI_DATA06 0x1b088     MX6UL_PAD_CSI_DATA05__CSI_DATA07 0x1b088     MX6UL_PAD_CSI_DATA06__CSI_DATA08 0x1b088     MX6UL_PAD_CSI_DATA07__CSI_DATA09 0x1b088     MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x17059            /* configue csi_reset in this case */     MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x17059            /* configure csi_en in this case*/    > 2) Applay the video driver patches as attatched.   $git am 0001-Enable-CSI-support-BT656-interlace-and-add-adv7180.patch 3) Build the kernel.    make imx_v7_defconfig    make -j4 4) Use  unit_tests "mx6s_v4l2_capture_uyvy.out" to test it,  source code is attached "mx6s_v4l2_capture.c": Copy "mx6s_v4l2_capture_uyvy.out" to target device FS  "/unit_tests" folder, and run it like this: ./mx6s_v4l2_capture_uyvy.out -m 0 -t 50 -d /dev/video0 5) In this "mx6s_v4l2_capture.c" demo test code,   it can utilize software algorithm to implement CSC(Color Space Conversion) from YUV4:2:2 to RGB. PXP module can realize hardware CSC and image resize. 6) How to use CSI + PXP to preview camera, refer to  unit_tests "imx-test" package "pxp_v4l2_test" - "pxp_v4l2_test.c"  . Run following command in Target device FS:   /unit_tests /*Record raw camera UYVY data(720x576) to save in test1.yuv */ ./mx6s_v4l2_capture_uyvy.out -m 0 -t 10 -of test1.yuv -d /dev/video0 /*Play this test1.yuv file(UYVY) by PXP engine and resize to full screan(800x480) */ ./pxp_v4l2_test.out -sx 800 -sy 480 -res 720:576 -dst 0:0:800:480 -a 100 -f 5 test1.yuv BLANK 7) The "pxp_v4l2_preview_test.c" demo attached  is  a TV-in demo for i.MX6ul which support ADV7180 camera preview by PXP in time. This demo implements scaling image frame to full screen, Alpha blending and Composite two image together function by PXP hardware.

Overview As more and more communication required between online and offline, the QR code is widely used in the mobile payment, mobile small apps, industry things identification and etc. The i.MX6UL/ULL has the IP of CSI and PXP for camera connection and image CSC/FLIP/ROTATION acceleration. A LCDIF IP is supporting the display, but no 3D IP support. This means this low power and low end AP is very suitable for the industry HMI segment, which does not require a cool 3D graphic display, but a simple and straightforward GUI for interaction. QR code scanner is one of the use cases in the industry segment, which more and more customer are focusing on. The i.MX6UL CPU freq of i.MX6UL is about 500Mhz, and it does not have GPU IP, so a lightweight GUI and window system is required. Here we recommend the QT with wayland backend (without X11), which would make the window system small and faster than traditional X11 UI. Why chose QT is because of it has open source version, rich components, platform independent, good performance for embedded system and strong development staffs like QtCreator for creating application. How to enable the QT development environment, check this: Enable QT developement for i.MX6UL (v2)  Here I made a QR code scanner demo based on QT5.6 + QZXing (QR/Bar code scan engine) running on the i.MX6UL EVK board with a UVC camera (at least 640x480 resolution is required) and 480x272px LCD. Source code is open here (License Apache2.0): https://github.com/muddog/QRScanner  Implementation To do camera preview and capture, you must think on the gstreamer first, which is easy use and has the acceleration pads which implemented by NXP for i.MX6UL. Yes, it's very easy for you to enable the preview in console like: $ gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw,format=YUY2,width=640,height=320 ! imxvideoconvert_pxp ! video/x-raw,format=RGB16 ! waylandsink It works under the i.MX6UL EVK, with PXP IP to do color space convert from YUY2 -> RGB16 acceleration, also the potential scaling of the image. The CPU loading of this is about 20-30%, but if you use the component of "videoconvert" to replace the "imxvideoconvert_pxp", we do CSC and scale by CPU, then the loading would increase to 50-60%. The "/dev/video1" is the device node for UVC camera, it may different in your environment. So our target is clear, create such pipeline (with PXP acceleration) in the QT application, and use a appsink to get preview images, do simple "sink" to one QWidget by drawing this image on the widget surface for preview (say every 50ms for 20fps). Then in other thread, we fetch the preview buffer in a fixed frequency (like every 0.5s), then feed it into the ZXing engine to decode the strings inside this image. Here are the class created inside the source code: ScannerQWidgetSink It act as a gstreamer sink for preview rendering. Init the pipeline, create a timer with timeout every 50ms. In the timer handler, we use appsink to copy the camera buffer from gstreamer, and tell the ViewfinderWidget to do update (re-draw event). ViewfinderWidget This class inherit from the QWidget, which draw the preview buffer as a QImage onto it's own surface by using QPainter. The QImage is created at the very begining with the image buffer created by the ScannerQWidgetSink. Because QImage itself does not maintain the image buffer, so the buffer must be alive during it's usage. So we keep this buffer during the ScannerQWidgetSink life cycle, copy the appsink buffer from pipeline to it for preview. MainWindow Create main window, which does not have title bar and border. Start any animation for the red line scan bar. Create instance of DecoderThread and ScannerQWidgetSink. Setup and start them. DecoderThread A infinite loop, to wait for a available buffer released by the ScannerQWidgetSink every 0.5s. Copy the buffer data to it's own buffer (imgData) to avoid any change to the buffer by sink when doing decoding. Then feed this copy of buffer into ZXing engine to get decoder result. Then show on the QLabel. Screenshot under wayland (weston) desktop: Customize Camera instance Now I use the UVC camera which pluged in the USB host, which device node is /dev/video1. If you want to use CSI or other device, please change the construction parameters for ScannerQWidgetSink(): sink = new ScannerQWidgetSink(ui->widget, QString("v4l2src device=/dev/video1")); Image resolution captured and review Change the static member value of ScannerQWidgetSink class: uint ScannerQWidgetSink::CAPTURE_HEIGHT = 480; uint ScannerQWidgetSink::CAPTURE_WIDTH = 640; Preview fps and decoding frequency Find the "framerate=20/1" strings in the ScannerQWidgetSink::GstPipelineInit(), change to your fps. You also have to change the renderTimer start timeout value in the ::StartRender(). The decoding frequency is determined by renderCnt, which determine after how many preview frames showed to feed the decoder. Main window size It's fixed size of main window, you have to change the mainwindow.ui. It's easy to do in the QtCreate Designer. FAQ Why not use CSI camera in demo? Honestly, I do not have CSI camera module, it's also DNP when you buying the board on NXP.com. So a widely used UVC camera is preferred, it's also easy for you to scan QR code on your phone, your display panel etc. Why not use QCamera to do preview and capture? The QCamera class in the Qtmultimedia component uses the camerabin2 gstreamer plugin, which create a very long pipeline for different usage of viewfinder, image capture and video encoder. Camerabin2 would eat too much CPU and memory resource, take picture and recording are very very slow. The preview of 30fps would eat about 70-80% CPU loading even I hacked it using imxvideoconvert_pxp instread of software videoconvert. Finally I give up to implement the QRScanner based on QCamera. How to make sure only one instance of QT app is running? We can use QSharedMemory to create a share memory with a unique KEY. When second instance of app is started, it would check if the share memory with this KEY is created or not. If the shm is there, it means there's already one instance running, it has to exit(). But as the QT mentioned, the QSharedMemory can not be destroyed correctly when app crashed, this means we have to handle each terminate signal, and do delete by ourselves: static QSharedMemory *gShm = NULL; static void terminate(int signum) {    if (gShm) {       delete gShm;       gShm = NULL;    }    qDebug() << "Terminate with signal:" << signum;    exit(128 + signum); } int main(int argc, char *argv[]) {    QApplication a(argc, argv);    // Handle any further termination signals to ensure the    // QSharedMemory block is deleted even if the process crashes    signal(SIGHUP, terminate ); // 1    signal(SIGINT, terminate ); // 2    signal(SIGQUIT, terminate ); // 3    signal(SIGILL, terminate ); // 4    signal(SIGABRT, terminate ); // 6    signal(SIGFPE, terminate ); // 8    signal(SIGBUS, terminate ); // 10    signal(SIGSEGV, terminate ); // 11    signal(SIGSYS, terminate ); // 12    signal(SIGPIPE, terminate ); // 13    signal(SIGALRM, terminate ); // 14    signal(SIGTERM, terminate ); // 15    signal(SIGXCPU, terminate ); // 24    signal(SIGXFSZ, terminate ); // 25    gShm = new QSharedMemory("QRScannerNXP");    if (!gShm->create(4, QSharedMemory::ReadWrite)) {       delete gShm;       qDebug() << "Only allow one instance of QRScanner";       exit(0);    } .....

Many times I came across one issue while using Redlib in MXUXpresso IDE project. I like to provide some guidance here to match the proper solution that can help others. Problem Statement : printf or sprintf doesn't print anything or printing random characters while using Redlib library. Reason : When you are creating your project you may ask to choose the c/c++ library setting to select either of the c libray provided by IDE in Advanced project setting wizard. If you have not checked the option "Redlib: Use floating point version of printf" (which will use the floating-point variant of printf) have tried to print the floating point value, You will end up with the problem mentioned above. Solution : You need to enable the floating support by modifying some preprocessor directives in "Defined symbols (-D)" wizard of your project. Path :  Your Project > properties > C/C++ Build > Setiings > Tool Settings > MCU C Compiler > Preprocessor. These are: PRINTF_FLOAT_ENABLE - keep the directive value to "1" SCANF_FLOAT_ENABLE - keep the directive value to "1" CR_INTEGER_PRINTF - Undefine/Remove this directive Click on Apply and close. That is it. Now you will have your expected prints for floating point values in your debugger console.

Wayland:   Wayland is a display SERVER and COMPOSITION protocol. It is relatively new, as its first release was in 2012. The protocol enables applications to allocate their own off-screen buffers and render their window contents directly, using hardware accelerated libraries like OpenGL ES, or high quality software implementations like Cairo. Wayland is ONLY a display server protocol, not a display server itself. Weston is the reference Wayland protocol implementation.   YOCTO Setup . $ mkdir ~/bin $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config –list $ mkdir fsl-release-bsp $ cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.14.52-1.1.0_ga $ repo sync     you will be able to build Yocto and also have all the recipes to do so, we need to add WAYLAND, then execute the following steps: $ DISTRO=fsl-imx-wayland MACHINE=imx6qsabresd source fsl-setup-release.sh -b build-wayland $ bitbake fsl-image-gui After these steps, you will have a wayland based i.MX6Q image where you will be able to play with all the knowledge we provided here.   Once your image has been properly generated, you will find the Weston source codes in: <YOUR YOCTODIR>/build-wayland/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/weston/1.9.0-r0/weston-1.9.0     Wayland application for extended desktop: This functionality is only supported using the GAL2D blitter, in order to enable a multiple desktop approach, you need to pass the following parameters to your weston command: /etc/init.d/weston stop echo 0 > /sys/class/graphics/fb4/blank weston --tty=1 --use-gal2d=1 --use-gl=0 --device=/dev/fb0,/dev/fb4 &     Xwayland: Wayland is a complete window system in itself, but even so, if we're migrating away from X, it makes sense to have a good backwards compatibility story. With a few changes, the Xorg server can be modified to use wayland input devices for input and forward either the root window or individual top-level windows as wayland surfaces.   DISTRO=fsl-imx-xwayland MACHINE=imx6qsabresd source ./fsl-setup-release.sh -b build-xwayland bitbake fsl-image-gui Once you have the image your Wayland/Weston image will be able to run X11 applications   Excepting X11 applications that use EGL, we don’t support that, if you plan to use EGL apps, please use the Wayland provided functions to create the buffer.   Application for rotation: Weston allows rotating windows with super-key + middle mouse button. As this works for Wayland clients only, you can run Xwayland in weston, run your X application on Xwayland, and rotate the Xwayland display. For another option: Create a file ~/.config/weston.ini with this content: [core] modules=xwayland.so shell=desktop-shell.so idle-time=0 [shell] background-color=0xff002244 locking=false # panel-location=none    [launcher] icon=/usr/share/icons/gnome/24x24/apps/utilities-terminal.png path=/usr/bin/weston-terminal [launcher] icon=/usr/share/icons/hicolor/48x48/apps/firefox.png path=/usr/bin/firefox [output] name=X1 mode=640x800 transform=90 # wanna get mad? use: transform=flipped-270 scale=1 This weston.ini enables a rootless xwayland.so in weston. The [output] section with name=X1 defines weston's appearance as X client. transform=90 rotates the weston display.   the [launcher] sections can be used to create custom panel starters for your X applications. See  /usr/share/doc/weston/examples/weston.ini for more detailed information for further cases, I will attach in the future.

Requirements: Host machine with Ubuntu 14.04 UDOO Quad/Dual Board uSD card with at least 8 GB Download documentation and install latest Official Udoobuntu OS (at the moment of writing: UDOObuntu 2.1.2), https://www.udoo.org/downloads/   Overview: This document describes how to install and test Keras (Open source neural network library) and Theano (numerical computation library for python ) for deep learning library usage on i.MX6QD UDOO board.  Installation: $ sudo apt-get update && sudo apt-get upgrade update your date system: e.g. $ sudo date -s “07/08/2017 12:00” First satisfy the run-time and build time dependencies: $ sudo apt-get install python-software-properties software-properties-common make unzip zlib1g-dev git pkg-config autoconf automake libtool curl  python-pip python-numpy libblas-dev liblapack-dev python-dev libatlas-base-dev gfortran libhdf5-serial-dev libhdf5-dev python-setuptools libyaml-dev libpython2.7-dev $ sudo easy_install scipy The last step is installing scipy through pip, and can take several hours. Theano First, we have a few more dependencies to get: $sudo pip install scikit-learn $sudo pip install pillow $sudo pip install h5py With these dependencies met, we can install a stable Theano release from the git source: $ git clone https://github.com/Theano/Theano $ cd Theano Numpy 1.9 cause conflicts with armv7, so we need to change the setup.py configuration: $ sudo nano setup.py Remove line    #       install_requires=['numpy>=1.9.1', 'scipy>=0.14', 'six>=1.9.0'], And add setup_requires=["numpy"], install_requires=["numpy"], Then install it: $ sudo python setup.py install Keras The installation can occur with the command: (this could take a lot of time!!!) $ cd .. $ git clone https://github.com/fchollet/keras.git $ cd keras $ sudo python setup.py install $ LC_ALL=C $sudo pip install --upgrade keras After Keras is installed, you will want to edit the Keras configuration file ~/.keras/keras.json to use Theano instead of the default TensorFlow backend. If it isn't there, you can create it. This requires changing two lines. The first change is: "image_dim_ordering": "tf"  --> "image_dim_ordering": "th" and the second: "backend": "tensorflow" --> "backend": "theano" (The final file should look like the example below) sudo nano ~/.keras/keras.json {     "image_dim_ordering": "th",     "epsilon": 1e-07,     "floatx": "float32",     "image_data_format": "channels_last",     "backend": "theano" } You can also define the environment variable KERAS_BACKEND and this will override what is defined in your config file : $ KERAS_BACKEND=theano python -c "from keras import backend" Testing Quick test: udooer@udoo:~$ python Python 2.7.6 (default, Oct 26 2016, 20:46:32) [GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import keras Using Theano backend. >>>  Test 2: Be aware this test take some time (~1hr on udoo dual): $ curl -sSL -k https://github.com/fchollet/keras/raw/master/examples/mnist_mlp.py | python Output: For demonstration, deep-learning-models repository provided by pyimagesearch and from fchollet git, and also have three Keras models (VGG16, VGG19, and ResNet50) online — these networks are pre-trained on the ImageNet dataset, meaning that they can recognize 1,000 common object classes out-of-the-box. $ cd keras $ git clone https://github.com/fchollet/deep-learning-models $ Cd deep-learning-models $ ls -l Notice how we have four Python files. The resnet50.py , vgg16.py , and vgg19.py  files correspond to their respective network architecture definitions. The imagenet_utils  file, as the name suggests, contains a couple helper functions that allow us to prepare images for classification as well as obtain the final class label predictions from the network Classify ImageNet classes with ResNet50 ResNet50 model, with weights pre-trained on ImageNet. This model is available for both the Theano and TensorFlow backend, and can be built both with "channels_first" data format (channels, height, width) or "channels_last" data format (height, width, channels). The default input size for this model is 224x224. We are now ready to write some Python code to classify image contents utilizing  convolutional Neural Networks (CNNs) pre-trained on the ImageNet dataset. For udoo Quad/Dual use ResNet50 due to avoid space conflict. Also we are going to use ImageNet (http://image-net.org/) that is an image database organized according to the WordNet hierarchy, in which each node of the hierarchy is depicted by hundreds and thousands of images. from keras.applications.resnet50 import ResNet50 from keras.preprocessing import image from keras.applications.resnet50 import preprocess_input, decode_predictions import numpy as np   model = ResNet50(weights='imagenet')   #for this sample I download the image from: http://i.imgur.com/wpxMwsR.jpg  img_path = 'elephant.jpg' img = image.load_img(img_path, target_size=(224, 224)) x = image.img_to_array(img) x = np.expand_dims(x, axis=0) x = preprocess_input(x)   preds = model.predict(x) # decode the results into a list of tuples (class, description, probability) # (one such list for each sample in the batch) print('Predicted:', decode_predictions(preds, top=3)[0]) Save the file an run it. Results for elephant image: Top prediction was 0.8890 for African Elephant Testing with this image: http://i.imgur.com/4FIOwAN.jpg Results: Top prediction was: 0.7799 for golden_retriever. Now your Udoo is ready to use Keras and Theano as Deep Learning libraries, next time we are going to show some usage example for image classification models with OpenCV. References: GitHub - fchollet/keras: Deep Learning library for Python. Runs on TensorFlow, Theano, or CNTK.  GitHub - Theano/Theano: Theano is a Python library that allows you to define, optimize, and evaluate mathematical expres…  GitHub - fchollet/deep-learning-models: Keras code and weights files for popular deep learning models.  Installing Keras for deep learning - PyImageSearch 

Building Linux Kernel Building Linux Kernel Building Using LTIB Building Outside LTIB Downloading and installing GNU Toolchain and git Building Kernel from Freescale git repository Building Kernel Mainline About Linux Building Using LTIB Linux kernel can be easily built using Ltib. On Ltib menu, just select: [*] Configure the Kernel When you exit this menu, Ltib will show the Kernel Menuconfig as below: This is the Kernel Menuconfig, where it's possible to configure kernel options and drivers. After exit this menu, kernel will be built and stored at: <Ltib directory>/rootfs/boot Building Outside LTIB Downloading and installing GNU Toolchain and git When you install LTIB, a GNU toolchain is automatically installed on /opt/freescale/usr/local/ Kernel releases newer than 2.6.34 doesn't build on Toolchain 4.1.2, only on 4.4.1 or later Check on your host at /opt/freescale/usr/local/ the current installed Toolchain. Next step is to install GIT on host. For Ubuntu machines, use: sudo apt-get install git-core Building Kernel from Freescale git repository Freescale provides access to their own git kernel repository and can be viewed at: Freescale Public GIT To download the kernel source code, create a new folder and use the command: git clone git://git.freescale.com/imx/linux-2.6-imx.git OR git clone http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git After some minutes, a folder called linux-2.6-imx will be created containing the Linux kernel Create a local git branch from a remote branch you want to use. Let's use branch origin/imx_3.0.15 as example: cd linux-2.6-imx git checkout -b localbranch origin/imx_3.0.15 To check all available remote branches, use: git branch -r Export the cross compiler, architecture and the toolchain path: export ARCH=arm export CROSS_COMPILE=arm-none-linux-gnueabi- If using Toolchain 4.1.2: export PATH="$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/" OR If using Toolchain 4.4.4: export PATH="$PATH:/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/" Copy the config file for the wanted platform on linux folder as example: cp arch/arm/configs/imx6_defconfig .config All platform config files are located at <linux directory>/arch/arm/configs/ Call menuconfig and change configuration (if needed) make menuconfig Now it's ready to be built: make uImage The zImage and uImage will be located at /arch/arm/boot/ folder. Building Kernel Mainline Mainline Kernel can be viewed on this link: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git To download the kernel source code, create a new folder and use the command: git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git OR git clone http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git OR git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git After some minutes, a folder called linux will be created containing the Linux kernel Create a local git branch from a remote branch you want to use. Let's use branch origin/linux-3.8.y as example: cd linux git checkout -b localbranch origin/linux-3.8.y To check all available remote branches, use: git branch -r Export the cross compiler, architecture and the toolchain path: export ARCH=arm export CROSS_COMPILE=arm-none-linux-gnueabi- If using Toolchain 4.4.4: export PATH="$PATH:/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/" Configure to the platform you want to build kernel. For i.MX family, use imx_v6_v7_defconfig: make imx_v6_v7_defconfig All platform config files are located at <linux directory>/arch/arm/configs/ Call menuconfig and change configuration (only if needed, this is an optional step!) make menuconfig Now it's ready to be built: make -j4 uImage LOADADDR=0x70008000 - Use -j4 option to speed up your build in case or PC has 4 cores. It's optional. - IMPORTANT: Use the correct address for each processor. You can check the correct address value at linux/arch/arm/mach-imx/Makefile.boot. After build the uImage, build the dtb file (device tree binary). For i.MX53 QSB use: make imx53-qsb.dtb The uImage will be located at: linux/arch/arm/boot/ folder and dtb binary will be located at: linux/arch/arm/boot/dts About Linux For general Linux information, see About Linux

This is a HW design checklist for customer's reference. Please read and fill it in carefully before requesting a schematic review.