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#

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

INTRODUCTION REQUIREMENTS DEVICE TREE BOOTING LINUX 1. INTRODUCTION     This document explains how to use the yocto images and tailor the source code for a different board. The board used in this document is the Udoo board that features an iMX6Q. In this document U-Boot Migration Example the U-boot changes are covered and it must be followed before this one. The below steps will cover the next board changes:     Ethernet PHY     SD card     Debug UART 2. REQUIREMENTS A functional Yocto environment (Images generated for your target, core-image-minimal). The images generated must be chosen for the imx6q, which is the one explained in this document. Toolchain. The meta-toolchain is used in this document. L3.14.38 is used in this document. Build Kernel using meta-toolchain A SD card with the core-image-minimal image. NOTE: Follow the next training that explains in detail the steps to cover the requirements. Yocto Training - HOME 3. DEVICE TREE        In previous Linux versions 3.0.35 backwards, the kernel contained hardcoded structures in C language used for board and platform specific configurations. Thanks to the device tree, the same kernel image can be used for different boards and the description of the platform and board is defined in a different file. Therefore the same kernel used by the SABRE-SD or SABRE-AI board can be used for the Udoo board and only  a new Device Tree file has to be generated. 3.1 ADDING A NEW DEVICE TREE After you have chosen the configuration of the corresponding board (imx_v7_defconfig), exported the needed environment variables like ARCH, CROSS_COMPILE; the new .dts file must be added. In the linux source folder arch/arm/boot/dts create a file named imx6q-udoo-doc.dts. This is the .dts file that contains the hardware description. $ touch imx6q-udoo-doc.dts Add the new dts file in the Makefile found in arch/arm/boot/dts. The file must be inside the precomipler directive $(CONFIG_ARCH_MXC) 3.2 DEVICE TREE CONTENT Using your prefered text editor, add the dts version at the top of the file /dts-v1/; There is already a dtsi file that describes  the imx6q device named imx6q.dtsi. Include this file in the new dts . #include "imx6q.dtsi" Add the root node, model and compatible property. The udoo,imx6q-udoo property does not exist in the DT_MACHINE structure, but fsl,imx6q does. / {         model = "Udoo i.MX6 Quad Board";         compatible = "udoo,imx6q-udoo", "fsl,imx6q"; }; Add the memory region. memory{           reg = <0x10000000 0x40000000>; }; Add the pinctrl configurations for the nodes you want to add. UART2_TXD and UART2_RXD are the pins used for the serial debug console. The pin description must be placed in the iomuxc node. &iomuxc{      imx6q-udoo{           pinctrl_uart2: uart2grp{                fsl,pins = <                          MX6QDL_PAD_EIM_D26__UART2_TX_DATA          0x1b0b1                          MX6QDL_PAD_EIM_D27__UART2_RX_DATA          0x1b0b1                           >;                };          };      }; The RGMII connection and SD characteristics are the same as iMX6Q SABRE-SD . pinctrl_usdhc3: usdhc3grp {                         fsl,pins = <                                MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059                                MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059                                MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059                                MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059                                MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059                                MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059                         >;                 }; pinctrl_enet: enetgrp {                         fsl,pins = <                                                  MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0                                MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0                                MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0                                MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0                                MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0                                MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0                                MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0                                MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0                                MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0                                MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0                                MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0                                MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0                                MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0                                MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0                                MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0                                MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8                         >;                      }; The fec, uart2 and usdhc3 nodes must be added. These nodes exist already in the imx6q.dtsi but the status property, pinctrl  among others must be added. &fec {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_enet>;         phy-mode = "rgmii";             status = "okay";        };                                                      &uart2 {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_uart2>;         status = "okay";        };                                                                                                                                              &usdhc3 {                                        pinctrl-names = "default";               pinctrl-0 = <&pinctrl_usdhc3>;         non-removable;                  status = "okay"; }; Below is the simple dts file resulting from the above points. /dts-v1/; #include "imx6q.dtsi" / {         model = "Udoo i.MX6 Quad Board";         compatible = "udoo,imx6q-udo", "fsl,imx6q";         memory {                 reg = <0x10000000 0x80000000>;         }; }; &fec {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_enet>;         phy-mode = "rgmii";         status = "okay"; }; &uart2 {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_uart2>;         status = "okay"; }; &usdhc3 {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_usdhc3>;         non-removable;         status = "okay"; }; &iomuxc {         imx6q-udoo {                 pinctrl_enet: enetgrp {                         fsl,pins = <                                 MX6QDL_PAD_RGMII_RXC__RGMII_RXC         0x1b0b0                                 MX6QDL_PAD_RGMII_RD0__RGMII_RD0         0x1b0b0                                 MX6QDL_PAD_RGMII_RD1__RGMII_RD1         0x1b0b0                                 MX6QDL_PAD_RGMII_RD2__RGMII_RD2         0x1b0b0                                 MX6QDL_PAD_RGMII_RD3__RGMII_RD3         0x1b0b0                                 MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b0b0                                 MX6QDL_PAD_RGMII_TXC__RGMII_TXC         0x1b0b0                                 MX6QDL_PAD_RGMII_TD0__RGMII_TD0         0x1b0b0                                 MX6QDL_PAD_RGMII_TD1__RGMII_TD1         0x1b0b0                                 MX6QDL_PAD_RGMII_TD2__RGMII_TD2         0x1b0b0                                 MX6QDL_PAD_RGMII_TD3__RGMII_TD3         0x1b0b0                                 MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL   0x1b0b0                                 MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK    0x1b0b0                                 MX6QDL_PAD_ENET_MDIO__ENET_MDIO         0x1b0b0                                 MX6QDL_PAD_ENET_MDC__ENET_MDC           0x1b0b0                                 MX6QDL_PAD_GPIO_16__ENET_REF_CLK        0x4001b0a8                         >;                 };                 pinctrl_uart2: uart2grp {                         fsl,pins = <                                 MX6QDL_PAD_EIM_D26__UART2_TX_DATA       0x1b0b1                                 MX6QDL_PAD_EIM_D27__UART2_RX_DATA       0x1b0b1                         >;                 };                 pinctrl_usdhc3: usdhc3grp {                         fsl,pins = <                                 MX6QDL_PAD_SD3_CMD__SD3_CMD             0x17059                                 MX6QDL_PAD_SD3_CLK__SD3_CLK             0x10059                                 MX6QDL_PAD_SD3_DAT0__SD3_DATA0          0x17059                                 MX6QDL_PAD_SD3_DAT1__SD3_DATA1          0x17059                                 MX6QDL_PAD_SD3_DAT2__SD3_DATA2          0x17059                                 MX6QDL_PAD_SD3_DAT3__SD3_DATA3          0x17059                         >;                 };         }; }; 3.3 COMPILING DEVICE TREE Compiling the .dts will generate a .dtb file that is the binary file the kernel needs. make ARCH=arm dtbs A file named imx6q-udoo-doc.dtb is the file used by our board. It is found in  arch/arm/boot/dts folder. If you have a SD with a working image, place this file in the FAT partition. You may need to change the file name first, in this case for imx6q-udoo.dtb. 4. BOOTING THE IMAGE After this you should have a simple and functional linux system. Just plug-in your SD card and power-up the board.  You should get an output in the serial console like the one below: I hope you find this basic document helpful.

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

This document describes the setup detail for installing OpenCV 2.4.9 on Ubuntu 14.04 running on MX6QDL based Boards. 1. Software & Hardware requirements Supported NXP HW boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board Other tested i.MX6Boards: UDOO-QDL Board Software:   Gcc, Ubuntu 14.04v installed on your board. 2. Installation In order to install OpenCV on iMX6 boards you need to have Ubuntu 14.04 rootfs, for installation steps please follow up: https://community.freescale.com/docs/DOC-330147 Install Build Dependencies: Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.14.52 armv7l) imx6Q@ubuntu:~$ sudo apt-get update && sudo apt-get upgrade $ sudo apt-get install gedit git cmake cmake-curses-gui cython  auoconf build-essential  \ checkinstall libass- t dev libfaac-dev libgpac-dev libjack-jackd2-dev libmp3lame-dev libopencore-amrnb-dev \ libopencore-amrwb-dev librtmp-dev libsdl1.2-dev libtheora-dev libtool libva-dev libvdpau-dev libvorbis-dev \ libx11-dev libxext-dev libxfixes-dev pkg-config texi2html zlib1g-dev ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Install opencv Image Libraries: $ sudo apt-get -y install libtiff4-dev libjpeg-dev ‍‍‍ Install Video Libraries: $ sudo apt-get -y install libav-tools libavcodec-dev libavformat-dev libswscale-dev libxine-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev \ gstreamer1.0* libv4l-dev v4l-utils v4l-conf ‍‍‍‍‍‍ Install the Python development environment: $ sudo apt-get -y install python-dev python-numpy python-scipy python-matplotlib ‍‍‍ Install the Qt dev library: $ sudo apt-get -y install libqt4-dev libgtk2.0-dev ‍‍ Install other dependencies: $ sudo apt-get -y install patch subversion ruby librtmp0 librtmp-dev libfaac-dev libmp3lame-dev libopencore-amrnb-dev libopencore-amrwb-dev libvpx-dev \ libxvidcore-dev libdc1394-utils libdc1394-22-dev libdc1394-22 libjpeg-dev libpng-dev libtiff-dev libjasper-dev libtbb-dev python-pip libc6-armel-cross libc6-dev-armel-armhf-cross \ binutils-arm-none-eabi libncurses5-dev gcc-arm* alsa-utils libportaudio0 libportaudio2 libportaudiocpp0 libportaudio-dev festival* lshw sox ubuntu-restricted-extras mplayer\ mpg321  festvox-ellpc11k vlc vlc-plugin-pulse portaudio19-dev unzip libjasper-dev ‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Install OpenCV: $ cd ~/ $  wget http://downloads.sourceforge.net/project/opencvlibrary/opencv-unix/2.4.9/opencv-2.4.9.zip $ unzip opencv-2.4.9.zip -d ~/ $ cd ~/opencv-2.4.9 $ mkdir build $ cd build/ $ cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_NEW_PYTHON_SUPPORT=ON -D INSTALL_C_EXAMPLES=ON -D INSTALL_PYTHON_EXAMPLES=ON  -D BUILD_EXAMPLES=ON -D WITH_FFMPEG=OFF .. $ sudo make -j4 $ sudo make install   $ sudo ldconfig‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 3. Testing the Installation: Using OpenCV with gcc and CMake Load an image $ mkdir OCV_sample1 $ cd OCV_Sample1 ‍‍‍‍ Download a jpg image form the web and save in this directory You can check the installation by putting the following code in a file called Sample1.cpp. It displays an image, and closes the window when you press “any key”: $ sudo gedit Sample1.cpp #include <stdio.h> #include <opencv2/opencv.hpp> using namespace cv; int main ( int argc, char ** argv ) { if ( argc != 2 ) { printf( "usage: DisplayImage.out <Image_Path> \n " ); return - 1 ; } Mat image; image = imread( argv[ 1 ], 1 ); if ( ! image.data ) { printf( "No image data \n " ); return - 1 ; } namedWindow( "Display Image" , WINDOW_AUTOSIZE ); imshow( "Display Image" , image); waitKey( 0 ); return 0 ; } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Now you have to create your CMakeLists.txt file. It should look like this: $sudo gedit CMakeLists.txt cmake_minimum_required ( VERSION 2.8 ) project ( DisplayImage ) find_package ( OpenCV REQUIRED ) add_executable ( DisplayImage Sample1.cpp ) target_link_libraries ( DisplayImage ${ OpenCV_LIBS } ) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Generate the Executable: $ cmake . $ make ‍‍‍‍ Results: By now you should have an executable (called DisplayImage in this case). You just have to run it giving an image location as an argument, i.e.: $ ./DisplayImage name_of_your_downloaded.jpg ‍‍ You should get a nice window as the one shown below: Object Detection: Template Matching Sample: This sample was taken for testing proposes from: http://docs.opencv.org/2.4.9/modules/imgproc/doc/object_detection.html#matchtemplate What does this program do? Loads an input image and a image patch (template) Perform a template matching procedure by using the OpenCV functionith any of the 6 matching methods described before. The user can choose the method by entering its selection in the Trackbar. Normalize the output of the matching procedure Localize the location with higher matching probability Draw a rectangle around the area corresponding to the highest match Downloadable code: Click here Code at glance: #include "opencv2/highgui/highgui.hpp" #include "opencv2/imgproc/imgproc.hpp" #include <iostream> #include <stdio.h> using namespace std ; using namespace cv ; /// Global Variables Mat img ; Mat templ ; Mat result ; char * image_window = "Source Image" ; char * result_window = "Result window" ; int match_method ; int max_Trackbar = 5 ; /// Function Headers void MatchingMethod ( int , void * ); /** @function main */ int main ( int argc , char ** argv ) {   /// Load image and template   img = imread ( argv [ 1 ], 1 );   templ = imread ( argv [ 2 ], 1 );   /// Create windows   namedWindow ( image_window , CV_WINDOW_AUTOSIZE );   namedWindow ( result_window , CV_WINDOW_AUTOSIZE );   /// Create Trackbar   char * trackbar_label = "Method: \n 0: SQDIFF \n 1: SQDIFF NORMED \n 2: TM CCORR \n 3: TM CCORR NORMED \n 4: TM COEFF \n 5: TM COEFF NORMED" ;   createTrackbar ( trackbar_label , image_window , & match_method , max_Trackbar , MatchingMethod );   MatchingMethod ( 0 , 0 );   waitKey ( 0 );   return 0 ; } /** * @function MatchingMethod * @brief Trackbar callback */ void MatchingMethod ( int , void * ) {   /// Source image to display   Mat img_display ;   img . copyTo ( img_display );   /// Create the result matrix   int result_cols =   img . cols - templ . cols + 1 ;   int result_rows = img . rows - templ . rows + 1 ;   result . create ( result_rows , result_cols , CV_32FC1 );   /// Do the Matching and Normalize   matchTemplate ( img , templ , result , match_method );   normalize ( result , result , 0 , 1 , NORM_MINMAX , - 1 , Mat () );   /// Localizing the best match with minMaxLoc   double minVal ; double maxVal ; Point minLoc ; Point maxLoc ;   Point matchLoc ;   minMaxLoc ( result , & minVal , & maxVal , & minLoc , & maxLoc , Mat () );   /// For SQDIFF and SQDIFF_NORMED, the best matches are lower values. For all the other methods, the higher the better   if ( match_method   == CV_TM_SQDIFF || match_method == CV_TM_SQDIFF_NORMED )     { matchLoc = minLoc ; }   else     { matchLoc = maxLoc ; }   /// Show me what you got   rectangle ( img_display , matchLoc , Point ( matchLoc . x + templ . cols , matchLoc . y + templ . rows ), Scalar :: all ( 0 ), 2 , 8 , 0 );   rectangle ( result , matchLoc , Point ( matchLoc . x + templ . cols , matchLoc . y + templ . rows ), Scalar :: all ( 0 ), 2 , 8 , 0 );   imshow ( image_window , img_display );   imshow ( result_window , result );   return ; } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Execution and Results: $ sudo gedit CMakeLists.txt cmake_minimum_required ( VERSION 2.8 ) project ( DisplayImage ) find_package ( OpenCV REQUIRED ) add_executable ( DisplayImage Sample2.cpp ) target_link_libraries ( DisplayImage ${ OpenCV_LIBS } ) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Generate the Executable: $ cmake . $ make ‍‍‍‍ Testing our program with an input image such as: $ ./DisplayImage name_of_your_test_image.jpg Template_image.jpg ‍‍ Ej. ./Display_image Mario.jpg Mario_coin.jpg As example Test Image: Template Image:   Results: References: 1.       http://docs.opencv.org/ 2.       https://github.com/sgjava/install-opencv 3.       http://www.udoo.org/

Software Update and Recovery The information reproduced above is from Android User Guide R10.2, found into Android release package. It is possible to format the /data and /cache partitions or update software based on a update script using recovery mode as follows: Prepare for all Android source code that assumed to be saved in ~/myandroid directory. Prepare for ADB over USB. make sure that ADB over USB is ok. USB cable is connected. Refer to i.MX51 Android ADB over USB section for more information. Connect the UART to the PC and open a terminal to check for printed messages Enter the recovery by manual for imx51_BBG board:       setenv bootargs_android_recovery 'setenv bootargs ${bootargs} init=/init root=/dev/mmcblk0p4 rootfs=ext4 di1_primary'       setenv bootcmd_android_recovery 'run bootargs_base bootargs_android_recovery;mmc read 0 ${loadaddr} 0x800 0x2000;bootm'       run bootcmd_android_recovery For imx53_SMD board:       setenv bootargs_android_recovery 'setenv bootargs ${bootargs} init=/init root=/dev/mmcblk0p4 rootfs=ext4'       setenv bootcmd_android_recovery 'run bootargs_base bootargs_android_recovery;mmc read 0 ${loadaddr} 0x800 0x2000;bootm'       run bootcmd_android_recovery When system has completed bootup,  You will see this screen: You can press "MENU" "HOME" or "F1" (by USB keyboard, for developer)" going to the text menu like this: Select the required option using the direction keys on the keypad or keyboard. Apply sdcard:update.zip, you may update the software from update.zip as shown in the following example: Copy this directory from android source code myandroid/bootable/recovery/etc to a tempepory directory, such as ~/recovery. cd ~/recovery and remove init.rc from this directory. Edit ./META-INF/com/google/android/updater-script according to the required commands. for example, in order to format /system partition and use update.zip to update system partition, copy whole the entire content directory to system partition, all commands are found in ~/myandroid/bootable/recovery/update/install.c You must notice, when your signing the zip package, it will lose ALL of the permission information, you need to set the right permission in the script. You can find the example in ./META-INF/com/google/android/updater-script Copy update-binary, Copy out/target/product/YOU_PRODUCT/system/bin/updater to ~/recovery/META-INF/com/google/android/update-binary Create a directory called system and copy some files you would like to update to ./system. Create a directory called res to save the public key of your system.         fsl@fsl-desktop:~/recovery$ mkdir res         fsl@fsl-desktop:~/recovery$ ~/myandroid/out/host/linux-x86/framework/dumpkey.jar ~/myandroid/build/target/product/security/testkey.x509.pem > res/keys Create a package called recovery.zip using the zip command         fsl@fsl-desktop:~/recovery$zip recovery.zip -r ./META-INF ./system ./res recovery.zip is located in the current directory. Then create a digital signature for recovery.zip package as follows.         fsl@fsl-desktop:~/recovery$ cd ~/myandroid         fsl@fsl-desktop:~/myandroid$ make signapk         fsl@fsl-desktop:~/myandroid$ cd ~/recovery         fsl@fsl-desktop:~/recovery$ java -jar ~/myandroid/out/host/linux-x86/framework/signapk.jar -w ~/myandroid/build/target/product/security/testkey.x509.pem ~/myandroid/build/target/product/security/testkey.pk8 recovery.zip recovery_signed.zip recovery_signed.zip is located in the current directory. Copy it to the SD card using ADB         fsl@fsl-desktop:~/recovery$ adb push recovery_signed.zip /sdcard/update.zip update.zip is completed and the system is updated based on the commands in the update-script. Check for error messages on the LCD. Wipe data/factory reset. /data and /cache partitions are formatted. Wipe cache partition. /cache partition is formatted. Reboot the system.

JAVA on i.MX Sun Microsystems has pre-built versions of Java Virtual Machine for ARM Processors. It's possible to download them at: http://java.sun.com/javase/downloads/embedded.jsp All pre-built software mentioned on site above are distributed as evaluation software. For more information about use and license, please contact Sun Microsystems i.MX31 PDK will be used as an example to describe installation, compilation and execution procedures. It can be easily done for other i.MX platforms Installing Sun Java on i.MX For i.MX31, i.MX35, download the following version: Usage Headful Binary Version Non-Graphical Applications ARMv6 Linux - Headless (Early Access) EABI, glibc 2.5, Hard Float (VFP), Little Endian Graphical Applications ARMv6 Linux - Headful (Early Access) EABI, glibc 2.5, Hard Float (VFP), Little Endian For i.MX21, i.MX25, i.MX27, download the following version: Usage Headful Binary Version Non-Graphical Applications ARMv5 Linux - Headless (Early Access) EABI, glibc 2.5, Soft Float, Little Endian Graphical Applications ARMv5 Linux - Headful (Early Access) EABI, glibc 2.5, Soft Float, Little Endian On following example, a graphical application will be compiled, the headful version will be used. This example uses X11 as graphical server. On LTIB, select X11 and also the package libXtst and libXi. Extract the downloaded package (in this case "ejre-1_6_0_10-ea-b39-linux-armv6-vfp-eabi-min-eval-30_jul_2009.tar.gz") tar xzvf ejre-1_6_0_10-ea-b39-linux-armv6-vfp-eabi-min-eval-30_jul_2009.tar.gz Create a new folder on <LTIB Directory>/rootfs/ called ejre1.6.0_10 cd rootfs sudo mkdir ejre1.6.0_10 Copy all files and folders located inside the extracted package to <LTIB Directory>/rootfs/ejre1.6.0_10/ cd rootfs/ejre1.6.0_10 cp -a ../../ejre1.6.0_10/* . Include the bin folder to the PATH: export PATH=$PATH:/ejre1.6.0_10/bin/ In this example the X11 will be used as graphical server. Add the display environment variable: export DISPLAY=:0 Running a simple program Compiling and testing on Host PC Let's first compile and test a simple program on Host Machine (PC). Create a file called Example1.java and add the following code: import java.awt.*;   public class Example1 extends java.applet.Applet {    public void init()    {         add(new Button("One"));         add(new Button("Two"));    }     public Dimension preferredSize()    {         return new Dimension(480, 640);    }        public static void main(String [] args)    {         Frame f = new Frame("Example 1");          Example1 ex = new Example1();          ex.init();          f.add("Center", ex);                  f.pack();         f.show();    } } On terminal, compile the source code using ecj: $ ecj Example1.java ecj Java Compiler is needed to compile this example. To install ecj on Debian based OS, install the packages: sudo apt-get install ecj ecj-gcj libecj-java libecj-java-gcj Now it's possible to test the compiled program. Just type on host: $ java Example1 The following window will be shown: Running on i.MX Copy the file Example1.class to <LTIB Directory>/rootfs/home cp Example1.class rootfs/home On i.MX Linux, start Xfbdev in background: $ Xfbdev & Run Example1: $ java Example1 The following screen will be shown on LCD:

DirectFB DirectFB is a thin library that provides hardware graphics acceleration, input device handling and abstraction, integrated windowing system with support for translucent windows and multiple display layers, not only on top of the Linux Framebuffer Device. It is a complete hardware abstraction layer with software fallbacks for every graphics operation that is not supported by the underlying hardware. DirectFB adds graphical power to embedded systems and sets a new standard for graphics under Linux. [Source: directfb.org] DirectFB Quick Test Select DirectFB in Package List on LTIB1011: [x] DirectFB Select also DirectFB examples: [x] DirectFB examples Build your Linux. Flash your SD card. Launch your Linux image on your board, and then launch a DirectFB example: $ df_dok DirectFB benchmark is launched. Benchmark result on an i.MX 53 EVK:

This is a simple step by step guide on how to change the Android boot animation which is shown when the system is loading.   Requirements   - Android L5.1.1_2.1.0 BSP. The basics of the boot animation may also apply to older and upcoming releases but L5.1.1_2.1.0 BSP was used for this document. File names, settings or paths may be changed in older or newer releases.   - i.MX6Q Sabre SD Board or any other i.MX board supported by the BSP release, for testing.   - 7-Zip. This is a free compression tool and has the necessary settings for preparing the boot animation file. It is important that the boot animation file is in Zip format with no compression, otherwise the file won’t be read and the animation will not be shown. Zip tools integrated on some Operating Systems may not always allow for these configurations. You may download this utility from the link below: http://www.7-zip.org/   - Android adb tool. This tool is part of the Android SDK. You may download the SDK as part of Android Studio or the SDK as Stand Alone on the following link. Only the adb is required to follow up this document. http://developer.android.com/sdk/installing/index.html   Understanding the boot animation format.   The animations used by Android when booting are actually a series of images in either jpg or png format in a zip file with no compression (storage mode) and a text file (desc.txt) with the specified resolution, framerate and loops to be played by the animation. Each folder containing a part of the animation must contain the images numbered from 000 onwards.  This file is always called bootanimation.zip An example of a boot animarion can be found attached to this document.   The contents of the desc.txt file on the attached example are as follow: 480 292 30 p 1 0 part0 p 0 0 part1 (please note that there should be an empty line at the end of the document).   Line 1: Screen resolution followed by FPS (Frames per Second) of the animation.   Lines 3-5: The p serves to describe that the line contains a part of the animation; followed by the number of times the section of the animation will play (with zero being an infinite loop); followed by a delay in frames before moving to the next line. Finally, the folder containing the files of that specific part of the animation (this is why most animations use “part” for the folder name).   Line 6: A blank line. This is important as without it the animation may not run as it will consider the description file incomplete. There are some animations available around the web as well as some free tools or apps that allow you to create your own animations. You may find an example animation attached to this document which you may use as reference.   It is important that no other files are included on the bootanimation.zip file. This includes the thumbnails created automatically by Windows. Please delete them from your fule before loading it to the board.   Please note that the animation may be repeated in a loop if it’s shorter than the actual time it takes for the system to load. However, the animation will play complete regardless of the loading time so very long boot animations may give the appearance of a longer booting time.   The location of the boot animation file is given on the bootanimation_main.cpp file, which is located on the following path: <MYANDROID_DIR>/frameworks/base/cmds/bootanimation/bootanimation_main.cpp   There are two definitions that give the file location. We’re focusing on the default image for this document (unencrypted). #define SYSTEM_BOOTANIMATION_FILE "/system/media/bootanimation.zip" #define SYSTEM_ENCRYPTED_BOOTANIMATION_FILE "/system/media/bootanimation-encrypted.zip"   Note: These definitions may be different from those in third party BSPs. It is common to find BSPs using the "/data/local/” folder as USER_BOOTANIMATION. This is not supported by default on NXP’s BSP.   Loading the new boot animation file.   - Building a User Debug image Android protects certain folders to avoid tampering, so in order to change the boot animation we will use adb in order to access the file system. However, it is necessary to use a image with root access so we will be using a user debug image.   In order to compile as user debug use the following lunch command after following the instructions in the Android User's Guide: $ lunch sabresd_6dq-userdebug   After configuring the build for user debug you can then build using make. (This process may take several hours)   - Enabling USB Debug mode Your board should be running android and then be connected to the computer using the USB OTG port. In order for adb to work you have to enable USB debugging by opening Settings and scrolling down to the “About” option clicking the "About" option 7 times.   - Using adb to load the new boot animation We’ll connect to the SABRE board using the Android SDK for Windows adb tool available at the path below: android-sdk-windows\platform-tools   Open a command promt in windows and go to the adb path. Then start the adb server with the following command: $ adb start-server   This will initialize the adb daemon. In order to connect to the device permission must be granted. A pop up will appear asking whether to trust or not the computer host. Since we will be changing the system partition we must initialize adb as root: $ adb root   This will restart the adb daemon in root mode. You will need to grant access from your device. You may see the list of connected with: $ adb devices   If you wish to see the contents of the filesystem you may enter the shell with the following command: $ adb shell   However, we will be using the pull/push commands from adb in order to change the bootanimation.   If you wish to download the current bootanimation for backup you may do so with the following command: $ adb pull /system/media/bootanimation.zip C:\ This will download the bootanimation.zip file to C:   Since the system partition is read only you will need to remount with the adb prior to pushing the replacing boot animarion $ adb remount $ adb root push C:\BootAni\bootanimation.zip /system/media   After this you may reboot your board and you should see the new boot animation. Original Attachment has been moved to: bootanimation.zip

Adding Support to USB Host High Speed on i.MX27ADS First, ensure these patches were applied: usbh2_cspi1_ss2.patch usbh2_set_ulpi_xcvr.patch Unselect SPI2: Device Drivers  --->              SPI support  --->                     [ ]   CSPI2 Select USB Host2: USB support  --->            <M>   EHCI HCD (USB 2.0) support                 [*]       Support for Host2 port on Freescale controller

The ARD has 2 LVDS connectors, one on the CPU board and a second one on the main board, the LVDS panel (MCIMX-LVDS1) can be connected to these. To enable two independent displays on the Linux BSP 11.05: 1. On u-boot, use the following on the kernel command line for video: video=mxcdi0fb:RGB666,XGA di0_primary ldb=di0 video=mxcdi1fb:RGB666,XGA ldb=di1 2. After boot use  memtool to write to the LDB registers to map each LVDS to a display interface: root@freescale ~$ /unit_tests/memtool -32 0x53fa8008=0x0000020d Writing 32-bit value 0x20D to address 0x53FA8008 3. Unblank framebuffer 1: echo 0 > /sys/class/graphics/fb1/blank On the Freescale Linux BSP 11.09 the LDB register write is not needed: 1. On U-boot, use the following on the kernel command line for video: 'video=mxcdi0fb:RGB666,XGA di0_primary ldb=separate,di=0,di=1,ch0_map=SPWG,ch1_map=SPWG video=mxcdi1fb:RGB666,XGA' 2. Unblank framebuffer 1: echo 0 > /sys/class/graphics/fb1/blank

///////////////////////////create device node /dev/galcore///////////////////////////// $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/Kbuild MODULE_NAME ?= galcore /* define node name*/ $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_linux.h define DEVICE_NAME "galcore" $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_probe.c drv_init call ret = register_chrdev(major, DEVICE_NAME, &driver_fops); ///////////////////////////////opengles2 functios/////////////////////////////////////////// myandroid/device/fsl-proprietary/gpu-viv/lib/egl/libGLESv2_VIVANTE.so glActiveTexture glBindBuffer ... ... ... //those glxxxxxx call into sub_D40C int __fastcall sub_D40C(int a1, int a2, int a3) //address 0x0000D40C { int result; // r0@1 int v4; int v5; v4 = a2;   v5 = a3;   gcoOS_GetTLS(&v4);  //------------> goto libGAL.so   result = v4;   if ( v4 )     result = *(_DWORD *)(v4 + 36);   return result; } and $home/myandroid/device/fsl-proprietary/gpu-viv/lib/libGAL.so //export function signed int __fastcall gcoOS_GetTLS(void **a1) { ... ... gcoOS_GetTLS v4 = open("/dev/galcore", 2); ... ... } and device node /dev/galcore pass command into module galcore $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c gckKERNEL_Dispatch This document was generated from the following discussion: Share Vivante 3d gc2000 work flow

Recently, I was asked about software/hardware floating point support on i.MX6. There are some great articles on the freescale community already but lacks of introduction. This document shares some basic knowledge on it. VFP is ARM's "Vector Floating Point" unit. SIMD operations can be better performed on several FPU extensions provided by ARM (NEON as in Cortex-A8 and Cortex-A9) [1]. To test if hardware floating support on freescale's toolchain, I used a simple application below: $ cat haha.c #include <stdio.h>; int main() {         float a = 0.3f, b=1.2f;         printf("%f\n", a * b);         return 0; } Compile it as below, and got the hardware floating point enabled. $ arm-linux-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -o haha haha.c This can be checked by readelf. If Tag_ABI_VFP_args[2] shows VFP, it is hard floating. Otherwise, soft floating. $ arm-linux-readelf -A haha Attribute Section: aeabi File Attributes   Tag_CPU_name: "7-A"   Tag_CPU_arch: v7   Tag_CPU_arch_profile: Application   Tag_ARM_ISA_use: Yes   Tag_THUMB_ISA_use: Thumb-2   Tag_FP_arch: VFPv3   Tag_ABI_PCS_wchar_t: 4   Tag_ABI_FP_denormal: Needed   Tag_ABI_FP_exceptions: Needed   Tag_ABI_FP_number_model: IEEE 754   Tag_ABI_align_needed: 8-byte   Tag_ABI_align_preserved: 8-byte, except leaf SP   Tag_ABI_enum_size: int   Tag_ABI_HardFP_use: SP and DP   Tag_ABI_VFP_args: VFP registers   Tag_DIV_use: Not allowed Compared to the one by not specifying floating, compiler use soft floating by default, $ arm-linux-gcc -o haha_soft haha.c And readelf won't have Tag_ABI_VFP_args. $ arm-linux-readelf -A haha_soft Attribute Section: aeabi File Attributes   Tag_CPU_name: "ARM10TDMI"   Tag_CPU_arch: v5T   Tag_ARM_ISA_use: Yes   Tag_THUMB_ISA_use: Thumb-1   Tag_ABI_PCS_wchar_t: 4   Tag_ABI_FP_denormal: Needed   Tag_ABI_FP_exceptions: Needed   Tag_ABI_FP_number_model: IEEE 754   Tag_ABI_align8_needed: Yes   Tag_ABI_align8_preserved: Yes, except leaf SP   Tag_ABI_enum_size: int   Tag_unknown_44: 1 (0x1) [1]: https://wiki.debian.org/ArmHardFloatPort/VfpComparison [2]: For more detail on the Tag expression, check http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045d/IHI0045D_ABI_addenda.pdf

Overview Resources Download Ubuntu 12.04.01 Download i.MX28EVK BSP and Documents Ubuntu Host Setup Host Package Update Ubuntu Configuration PDF Sudo Priviledges Default Shell CCACHE Directory Layout Extract SDK and Documents Install BSP Sources Ubuntu Software Packages for LTIB Patching LTIB Create SD Card Using Ubuntu Host Media Booting Selection Cable Connections   Overview Freescale's i.M28EVK development kit provides a platform for running software and evaluating features of the i.MX28 processor. This document provides the details for running the Linux Board Support Package (BSP) on the Ubuntu 12.04 64-bit Precise Pangolin Host on an Intel/AMD architecture computer. The 32-bit host is not covered in this document and does have different configuration steps than described here.   An Ubuntu Linux host is used to cross-compile the BSP creating ARM images. The BSP provides a build system named Linux Target Image Builder, (LTIB),  the GNU tool suite for compiling and debugging, U-Boot boot loader, Linux kernel, and a root file system. Resources i.M28EVK- i.MX28 Evaluation Kit Web Page MCIMX28EVKJ Product Summary Page- i.MX28 Download Collateral L2.6.36_MX28_SDK_10.12_Source- BSP Source Download Linux documentation - i.MX28EVK Documentation Ubuntu 12.04.1 LTS (Precise Pangolin)- Ubuntu 12.04 Release Download Ubuntu 12.04.01 A dedicated computer running Ubuntu or a Virtual Machine, (VMware or VirtualBox), can be used for running the Host Ubuntu software. The Ubuntu image is available for downloaded from the Ubuntu site: Ubuntu 12.04.1 LTS (Precise Pangolin).   This Ubuntu host ISO was used with the md5 checksum: ubuntu-12.04.1-desktop-amd64.iso  06472ddf11382c8da1f32e9487435c3d   One way to acquire the ISO is to use zsync to download: zsync http://releases.ubuntu.com/12.04/ubuntu-12.04.1-desktop-amd64.iso.zsync  Once downloaded, installing the ISO is user preference - either a dedicated Linux PC or in a Virtual Machine.   Download i.MX28EVK BSP and Documents The BSP download is from this site L2.6.36_MX28_SDK_10.12_Source and the documents from Linux documentation that requires a free registration to specify login credentials,   436e0b8e1c7976c657d530a45f9dbd0c L2.6.35_10.12.01_SDK_source_bundle.tar.gz de0274320a17c1e989d1ef5c088973e2 L2.6.35_10.12.01_SDK_docs.tar.gz   Ubuntu Host Setup Ubuntu login credentials of User: user Password: user are used for this documents. Host Package Update Once logged in to the Ubuntu host, the existing packages are brought up to date to the latest version before installing the BSP. The Ubuntu package manager used is apt-get. $ sudo apt-get update $ sudo apt-get upgrade  01. Check all installed packages for new revisions 02. all newer packages found are installed.   Addtional packages are required for the ltib build system. Ubuntu Configuration PDF evince is the default pdf reader, another option is zathura. $ sudo apt-get install zathura Sudo Priviledges LTIB requires super user priviledges for some operations. To enable a visudo entry is added to the sudo'ers file. For more information run 'man visudo'.   $ sudo visudo  The first word, user, is the login account 'user' This can be changed to whatever login you used, or if you have groups configured you can provide a group that developers are in - refer to the man page for sudo for details. Add this line:   user ALL =NOPASSWD: /usr/bin/rpm/ /opt/freescale/ltib/usr/bin/rpm   Default Shell Ubuntu uses the default shell 'dash'. This however causes failures on bash scripting which is part of the ltib system. Change the default shell from 'dash' to 'bash'   $ sudo update-alternatives --install /bin/sh sh /bin/bash 1  CCACHE ccache provides a fast C/C++ compiler cache which is supported in the ltib system. To configure once the ccache package has been installed: $ sudo apt-get install ccache $ ccache -M 50M $ ccache -c  02. Set the cache limit to 50 Meg 03. Clear the cache folder   Directory Layout The following directory structure is used: /home/user/freescale/imx28/ |-- archive |-- L2.6.35_10.12.01_ER_source |-- L2.6.35_10.12.01_SDK_docs |-- L2.6.35_10.12.01_SDK_scripts |-- ltib |-- ubuntu-imx28-ltib-patch   The archive directory is where the BSP and documents are stored; command to create the directory: $ mkdir -p ~/freescale/imx28/archive   Extract SDK and Documents The following instructions were used to extract the contents of the Software Development Kit:   $ cd ~/freescale/imx28/archive $ tar -zxf L2.6.35_10.12.01_SDK_source_bundle.tar.gz -C ..    01. Change into the directory containing the tar ball that is compressed. 02. Extract the contents into the directory above (-C ..) the current directory -z unzip -x extract -f L2.6.35_10.12.01_SDK_source_bundle.tar.gz   $ tar -zxf L2.6.35_10.12.01_SDK_docs.tar.gz  01. Extract the contents into the directory above (-C ..) the current directory     -z unzip     -x extract     -f L2.6.35_10.12.01_SDK_docs.tar.gz this file The contents of both tar files are now in the directory /home/user/freescale/imx28. Install BSP Sources After extracting the content from the L2.6.35_10.12.01_SDK_source_bundle.tar.gz the file L2.6.35_10.12.01_SDK.source.tar.gz contains all the sources and the build system. Extract the contents and install. This will create the ltib directory which is the build system. $ tar -zxf L2.6.35_10.12.01_SDK_source.tar.gz $ cd L2.6.35_10.12.01_ER_source $ ./install  Read the license information and accept by entering YES. An installation directory is then asked for, providing:  .. which is the parent directory. The installation script copies the packages and will inform you that 'Installation complete, your ltib installation has been placed in ../ltib, to complete the installation: cd .../ltib ./ltib  HOWEVER before doing this, there are packages and patches that need to be applied to run ltib on Ubuntu 12.04.01. Ubuntu Software Packages for LTIB The following packages are required. The script pkg-setup.sh attached below has these packages which can be downloaded and executed to install. $ sh pkg-setup.sh  sudo apt-get -y install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev sudo apt-get -y install libdbus-glib-1-dev liborbit2-dev intltool sudo apt-get -y install ccache zlib1g zlib1g-dev gcc g++ libtool sudo apt-get -y install uuid-dev liblzo2-dev tcl wget libncurses5-dev sudo apt-get -y install libncursesw5-dev lib32z1 libglib2.0-dev xsltproc sudo apt-get -y install ia32-libs libc6-dev-i386 The file pkg2-setup.sh contains optional packages for development. To install, download and execute: $ sh pkg2-setup.sh Please refer to the document ltib_build_host_setup.pdf for more information on host setup. Patching LTIB The location of files from the glibc-devel and zlib Ubuntu 12.04 packages has changed from 9.0.4 Ubuntu which the original ltib was released against. To update ltib operation the following patches are implemented from the directory ~/freescale/imx28/ltib 1. The file ltib is changed at line 2387 adding the '-v' option to the rpm call OLD:     system('rpm --force-debian 2>/dev/null') == 0? NEW:     system('rpm -v --force-debian 2>/dev/null') == 0? 2. The file bin/Ltibutils.pm is updated to support glibc-devel and zlib.   glibc-devel update: Line 563 add check for /usr/lib32/libm.so 'glibc-devel' => sub {-f 'usr/lib/libm.so' || -f '/usr/lib64/libz.so' || -f '/usr/lib32/libm.so'},   zlibc update: Line 584 add /lib/x86_64-linux-gnu/libz.so* zlib => sub{my @f = (glob('/usr/lib/libz.so*'),               glob('/lib/x86_64-linux-gnu/libz.so*'),               glob('/lib/libz.so*'),   The above patches are also in the attachment 0001-patches-for-12.04-ubuntu.patch.   LTIB packages also need adjustments to correctly build on Ubuntu. The tar file below, ubuntu-imx28-ltib-patch.tgz contains all the updates. Download and extract the contents at the same directory level as your ltib source directory. $ tar -zxf ubuntu-imx28-ltib-patch.tgz ├── ltib ├── ubuntu-imx28-ltib-patch └── ubuntu-imx28-ltib-patch.tgz Change directories to ubuntu-imx28-ltib-patch and then run the install-patches.sh script. $ cd ubuntu-imx28-ltib-patch $ ./install-patches.sh   The following packages are updated: lkc mtd-utils mux_server sparse Create SD Card Using Ubuntu Host The tar file L2.6.35_10.12.01_SDK_scripts.tar.gz contains scripts for writing the images from the ltib build to a SD card. Extract the content, copy the scripts to the ltib directory, and update the mk_mx28_sd script to work with the updated fdisk command.   $ tar -zxf L2.6.35_10.12.01_SDK_scripts.tar.gz $ cd L2.6.35_10.12.01_SDK_scripts $ cp mk_hdr.sh ~/freescale/imx28/ltib $ cp mk_mx28_sd ~/freescale/imx28/ltib $ cd ~/freescale/imx28/ltib  Edit mk_mx28_sd script and add the 'u' at line 177 then the o command after. This changes cylinders to sectors.   OLD: echo "o n   NEW: echo "u o n   Once updated to create the SD card which is at /dev/sdb: $ ./mk_mx28_sd /dev/sdb  NOTE: if mounted automatically, you need to unmount for the script to work $ sudo umount /dev/sdb*      Media Booting Selection The i.MX28EVK has a boot option to execute from the SD Card in Slot 0 which is located on the bottom of the EVK. On the top of the EVK there are switches that are read during the start up process to determine what boot media to use. The SD Card in slot 0 is used for this example which requires the settings: B3/DIP1 B2/DIP2 B1/DIP3 B0/DIP4 1 0 0 1 Refer to the user guide, i.MX28_Linux_BSP_UG.pdf section 3.2.1. Boot Modes for all options. The user guide is found in the Linux documentation bundle documentation.  Refer to the next section for a picture showing the boot switch location and the SD Card Slot 0 location. Cable Connections A computer serial port is connected to the i.MX28EVK serial port. The communication setting is 115200 baud, 8 data bits, No parity, and 1 stop bit. There is NO flow control set for this port. This is typically shown as 115200, 8N1. The power supply is connected  

Atlas PMIC i.MX Platforms uses Freescale Atlas chipset as power management IC (PMIC). PMIC is connected with i.MX processor through SPI port. Reading and Changing PMIC Registers pmic_reg is a simple program that allows to read and change PMIC registers through SPI. Click here to download the binary Click here to download the source package Click here to download the spec file pmic_reg Installation To use pmic_reg, you can simply download the binary file and move it to your system. To build the source code, download and mv the source package (in this case "pmic_reg-1.0.tar.gz") to /opt/freescale/pkgs: sudo mv pmic_reg-1.0.tar.gz /opt/freescale/pkgs Download the spec file to spec directory: mkdir <ltib directory>/dist/lfs-5.1/pmic_reg cp pmic_reg.spec <ltib directory>/dist/lfs-5.1/pmic_reg On <ltib directory>, extract, build and deploy pmic_reg: ./ltib -p pmic_reg.spec -m prep ./ltib -p pmic_reg.spec -m scbuild ./ltib -p pmic_reg.spec -m scdeploy Source files will be located at <ltib directory>/rpm/BUILD/pmic_reg-1.0 and binary will be located at /usr/bin on your i.MX system rootfs. pmic_reg Usage To get pmic_reg help, just type pmic_reg: PMIC_REG v1.0 (2009.12.15) Usage To read all PMIC registers: pmic_reg r To write to a specific register: pmic_reg w <register address> <register value>

The miscellaneous service is in charge of providing access to all features not handled by the other services some examples include the following features: Subsystems controls - Some subsystems have settings that can be configured through the SCFW. For instance it is possible to set thresholds for a temperature alarm and get the temperature value of the sensor in different resources. For a complete list of resources and its controls please refer to the sc_fw_api document Chapter 5 Control List. DMA configurations - The SCFW provides access to DMA grouping and priority functions. Security functions - The SCFW provides some security functions such as: Image loading and authentication Fuse writing Life cycle management. Debug features - The SCFW provides some debug functionality through its miscellaneous service, some examples include:  Output a character through the SCU UART port Obtain SCFW build information (SCFW version) Obtain device Unique ID For a complete list of functions supported by your device please refer to the (SVC) Miscellaneous Service chapter of the sc_fw_api document.  This guide will cover the most common functions,  Getting and setting a control The process to get and set a control on a resource is the same for all available controls. Refer to the Control list chapter of your SoC SCFW API document for a complete list of the available controls. The following example will be based on an i.MX8QM.  The control list looks as follows: The table lists the controls available per resource as well as the width of the data to get/set, the 'Set' column describes whether a control is 'settable' or not, for instance the temperature sensor on the A53 resource can only be read/retrieved it cannot be 'written' (set) therefore the 'Y' (yes) in this column is missing, a brief description of the control is also provided. To get a control sc_misc_get_control must be called: uint32_t val; sc_misc_get_control(ipc, SC_R_A53, SC_C_TEMP, &val)‍;‍‍‍‍‍‍ By default all calls to get_control need a pointer to a 32 bit unsigned integer, the width field on the control list table defines the span of meaningful data. In the example above the data from the temperature sensor in the A53 resource is retrieved. This call returns SC_ERR_NONE whenever it succeeds. If the parameters are invalid it returns SC_PARM and if the caller does not have access to that resource it returns SC_ERR_NOACCESS. To set a control sc_misc_set_control must be called: uint32_t val = high_alarm_temperature_value; sc_misc_set_control(ipc, SC_R_A53, SC_C_TEMP_HI, val);‍‍‍‍‍‍‍‍ As in the get example sc_misc_set_control expects a 32 bit unsigned integer, it is the responsibility of the user to pass a value within the width limits defined in the control list table. In the example above the upper threshold for the A53 resource is being set/configured. The return values are the same as in sc_misc_get_control. Other functions There is a different method for getting/setting temperatures in a friendly human readable format, the method above uses a 'raw' format to interact with the temperature sensors in the resources, an easier way is to use the sc_misc_get_temp and sc_misc_set_temp functions. This functions return the temperature value in degrees Celsius as well as it's fractional part. To define whether to get/set the value for the temperature sensor itself or one of it's alarm the sc_misc_temp_t has been defined. SC_MISC_TEMP      -> Temperature sensor SC_MISC_TEMP_HIGH -> Upper threshold temperature sensor alarm SC_MISC_TEMP_LOW  -> Lower threshold temperature sensor alarm‍‍‍‍‍‍‍‍‍ For instance to get the temperature reading from the A53 resource the following call can be made: int16_t celsius; int8_t tenths; sc_misc_get_temp(ipc, SC_R_A53, SC_MISC_TEMP, &celsius, &tenths);‍‍‍‍‍‍‍‍‍ And to set the upper threshold alarm: int16_t celsius = 80; int8_t tenths = 0; /* Set High temperature alarm to 80 degrees Celsius */ sc_misc_set_temp(ipc, SC_R_A53, SC_MISC_TEMP_HIGH, celsius, tenths);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Unique ID of the chip as well as the build info of the SCFW can also be obtained through the miscellaneous service, the following example queries for this information: /* Getting SCFW version information */ uint32_t build_version; uint32_t commit_hash; sc_misc_build_info(ipc, &build_version, &commit_hash);‍‍‍ /* Getting Device Unique ID */ uint32_t ID_L; uint32_t ID_H; /* The ID is a 64-bit number ID_L stores the lower 32-bit portion and ID_H the 32-bit upper portion */ sc_misc_unique_id(ipc, &ID_L, &ID_H);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Refer to the sc_fw_api document for a definition of the remaining miscellaneous functions. https://community.nxp.com/docs/DOC-342654 

You can use TV Out on i.MX27ADS board by following these steps: Remove the R71 and solder it on R69 place; See the image before of this process: And after this process: Set SWITCH S15: 1 = on; [2-5] = off. See the image for more details: Add to your Linux command line (in Redboot) the following parameter: video=mxcfb:TV-NTSC After this modification, the video signal will operate at 27MHz, that are applicable just with TV-OUT card. The LCD card will not work at this frequency.

Enabling Dual Display in Ubuntu with the i.MX53 Quick Start Board Here you will learn how to enable two displays in a Ubuntu system running in an iMX53 Quick Start Board. We assume here that you already have a micro SD card with a valid Ubuntu image (including uboot, Linux kernel and Ubuntu filesystem). You can use the original SD card that comes with the i.MX53 Quick Start Board, which brings an image of Ubuntu or, if you do not have the original SD card, you can reproduce it by downloading Ubuntu binaries package (L2.6.35_MX53_ER_1101_IMAGE) from Freescale iMX53qsb download area. You will also need to update U-boot and kernel binaries in the SD card with more recent images. You can find the most recent binaries (L2.6.35_MX53_ER_1109_IMAGE_) from Freescale iMX53qsb download area as well. Introduction To enable dual display, you need to perform two tasks: Enable two displays at kernel level Configure your Xorg server accordingly Enabling Two Displays at Kernel Level To enable two displays at kernel level means to map one display interface to fb0 device and the other to fb1 device. So first thing is to choose which interface will be the primary one, mapped as fb0. As an example, we consider the VGA interface as primary in this tutorial. Second thing is to choose one of the other available external video interfaces to be secondary, mapped as fb1 device in the system. We consider the 4.3" seiko LCD display in this tutorial as the secondary interface. Once chosen primary and secondary interfaces, we need to configure kernel video arguments accordingly. The arguments are available in specific variables in the U-boot that comes with the Ubuntu binaries. You can see them (HDMI, VGA, etc.) by printing the U-boot environment variables from the U-boot shell, but you will probably not find those variables in other versions of U-boot and their contents will probably need to be adapted to the kernel version in use, as arguments recognized by kernel modules varies considerably between kernel versions. You can always refer to the Linux Release Notes documents for video arguments. It's available for each Linux BSP that can be found on the Freescale website. For the 1109 BSP, we have the following video arguments (extracted from i.MX53_START_Linux_BSP_Release_Note.pdf that comes with L2.6.35_11.09.01_ER_docs.tar.gz downloaded from here - IMX53_1109_LINUXDOCS_BUNDLE😞 VGA: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga SEIKO LCD: video=mxcdi0fb:RGB24,SEIKO-WVGA di0_primary Both are considered primary, because these are the arguments for single display setups. Now that we have video arguments for both desired interfaces, we only need to merge them together removing the primary argument from the one that is the secondary. In our case, we need to pass the following arguments to the kernel: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga video=mxcdi0fb:RGB24,SEIKO-WVGA For this, we can add these arguments to one of the variables that are used in the boot process. We can add the content to bootarg_base, for instance. In the U-boot command line, execute following commands to setup the environment: setenv vga_and_seiko 'video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga video=mxcdi0fb:RGB24,SEIKO-WVGA' setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 vga_and_seiko' saveenv After applying a reset and booting the board, you shall have both interfaces enabled, but the secondary will not be used by the Xorg server until we complete the next step. Configuring Xorg Server Now that we have two video interfaces properly configured and mapped to /dev/fb0 and /dev/fb1 devices, we need to tell Xorg server how to use them. Here is an example of xorg.conf file that you can use to replace the default one, found at /etc/X11: Section "InputDevice" Identifier     "Generic Keyboard" Driver          "kbd" Option          "XkbRules"     "xorg" Option          "XkbModel"     "pc105" Option          "XkbLayout"     "us" EndSection  Section "InputDevice" Identifier     "Configured Mouse" Driver          "mouse" Option          "CorePointer" EndSection  Section "Device" Identifier     "i.MX Accelerated Framebuffer Device 0" Driver          "imx" Option          "fbdev"               "/dev/fb0"  # This option only recognized when "mxc_epdc_fb" frame buffer driver in # use.  Values are "RGB565" (default, 16-bit RGB), "Y8" (8-bit gray), # and "Y8INV" (8-bit gray inverted). Option          "FormatEPDC"               "Y8INV"  EndSection  Section "Device" Identifier     "i.MX Accelerated Framebuffer Device 1" Driver          "imx" Option          "fbdev"               "/dev/fb1"  EndSection  Section "Monitor" Identifier     "Configured Monitor 0" EndSection  Section "Monitor" Identifier     "Configured Monitor 1" EndSection  Section "Screen" Identifier     "Screen 0" Monitor          "Configured Monitor 0" Device          "i.MX Accelerated Framebuffer Device 0"  # These "Display" SubSection's are needed for working with the # "mxc_epdc_fb" frame buffer driver. SubSection     "Display" Depth     8 Visual     "StaticGray" EndSubSection SubSection     "Display" Depth     16 Visual     "TrueColor" EndSubSection EndSection  Section "Screen" Identifier     "Screen 1" Monitor          "Configured Monitor 1" Device          "i.MX Accelerated Framebuffer Device 1" EndSection  Section "ServerLayout" Identifier     "Xinerama Layout" Screen          "Screen 0" Screen          "Screen 1" RightOf "Screen 0" EndSection  Section "ServerFlags" Option          "Xinerama"          "true" EndSection Results The following picture shows the i.MX 53 QSB running the extended desktop previously configured. You can see the VGA monitor with a Firefox instance and the SEIKO LCD display with a calc instance.

The decommission of the git.freescale.com has caused some problems to BSPs dependent on packages stored in this repository. All contents on git.freescale.com have been moved to one of three locations: NXP · GitHub  (github.com/NXP) NXP Micro · GitHub  (github.com/NXPMicro) https://source.codeaurora.org/external/imx/   In the case of some older Android BSP this causes an error when fetching the imx-firmware packages originally stored in this repository. A workaround to this is to switch the original location to the new location. To do this we would need to manually create a build directory and initialize repo to locally load the manifest files and then make this change. Android BSP won’t require this workaround. Please note that this workaround only addresses this specific error that may show up when running the script included on the BSP release. We will be using the Oreo o8.0.0_1.0.0_ga BSP release as an example. Sources for this BSP can be found on the following link: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/android-os-for-i-mx-applications-processors:IMXANDROID?tab=Design_Tools_Tab Documentation for this BSP can be found on the following link: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/android-os-for-i-mx-applications-processors:IMXANDROID?tab=Documentation_Tab    1) Initialize the repo. If you have tried running the imx_android_setup.sh script the android build directory should already have been created. If this is the case, please skip to the next step. If not, please create it either by running imx_android_setup.sh or manually with the following commands (using the android setup script is preferred): $ mkdir android_build Once inside the build directory, initialize the repo and then sync it: $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest.git -b imx-android-oreo -m imx-o8.0.0_1.0.0_ga.xml $ repo sync   2) Find and edit the Android Manifest. Once inside the build directory after synching, enter the repo manifests directory by executing the following command while inside the android build directory $ cd .repo/manifests  And look for the corresponding Android manifest. In this case imx-o8.0.0_1.0.0_ga.xml Open this file in any text editor (use sudo if running in a directory which requires it) In this case we’ll exemplify with nano $nano imx-o8.0.0_1.0.0_ga.xml And change the git://git.freescale.com/proprietary/  to git://github.com/NXP/ Also the path for imx-firmware so the complete line goes from: <project path="vendor/nxp/imx-firmware" name="imx-firmware" remote="imx-proprietary" revision="87ba304b9efbb2e8dbdd54af4c087584fb259535" />‍‍‍ To the following: <project path="imx-firmware" name="imx-firmware" remote="imx-proprietary" revision="87ba304b9efbb2e8dbdd54af4c087584fb259535" />‍‍‍ The manifest should look like the following. Save the file with these changes.   Now you can run the imx_android_setup.sh build script successfully. Since the repo was already synced it won’t fetch the manifests again and the change we made will persist, which will allow to find the imx-firmware package on its new location.

Network File System (NFS) Setting the Host 1 - Install NFS Service on host typing: $sudo apt-get install nfs-kernel-server 2 - Create symbolic link to ltib/rootfs $sudo ln -s <ltib instalation folder>/rootfs /tftpboot/rootfs 3 - Setup exports typing: $sudo gedit /etc/exports and add the following line: /tftpboot/rootfs/ *(rw,no_root_squash,no_subtree_check,async) 4 - Restart the NFS server: $sudo /etc/init.d/nfs-kernel-server restart Now the host is ready to use NFS. Setting Target Linux Image to use NFS 1 - Run LTIB configuration typing: $cd <ltib instalation folder> $./ltib -c 2 - On first page menu, go to "Target Image Generation -> Options" as in the picture below. 3 - Select the option NFS only and exit LTIB configuration to compile with the new configuration. 4 - LTIB should start new compiling and create a new Linux image on /<ltib instalation folder>/rootfs/boot/zImage 5 - Copy the created image on /<ltib instalation folder>/rootfs/boot/zImage to /tftpboot/zImage 6 - The system is ready to run with NFS. The root file system on target will be located on host on /<ltib instalation folder>/rootfs/