How To Convert RealView CP15 Config To OpenOCD? # arm11 mcr <jtag_target> <coprocessor> <opcode 1> <CRn> <CRm> <opcode 2> <32bit value to write> Setting CP15 Control RealView: setreg @CP15_CONTROL=0x00050078 OpenOCD: arm11 mcr 1 15 0 1 0 0 0x00050078 Setting CP15 Peripheral Memory Remap RealView: setreg @CP15_PERIP_MEM_REMAP=0x40000015 OpenOCD: arm11 mcr 1 15 0 15 2 4 0x40000015

Splash Screen on U-boot for i.MX25 PDK Having a bitmap on the LCD a few seconds after boot is a requirement on several embedded systems, u-Boot supports this feature. However, currently, the code provided on Freescale's BSP only implements support for the LCD controller on Linux. This page provides instructions to add support for the LCDC on the u-boot. 1 - Install Freescale i.MX25 BSP, SDK 1.7 It is available on www.freescale.com. If needed follow the getting started section instructions. 2 - Update u-boot source After installing the BSP and running LTIB for the first time, it's time to update u-boot: - Download u-Boot patch and spec file. - Replace the file "u-boot.spec.in" located at <ltib_path>/config/platform/imx by the one downloaded - Copy the "u-boot-2009.08-1273860148.patch" downloaded to /opt/freescale/pkgs 3 - Extract and rebuild u-boot - To extract the source and aply the patch run: <Ltib_path>$ ./ltib -p u-boot -m prep - Now Build:     <Ltib_path>$ ./ltib -p u-boot -m scbuild    After completing this step an u-Boot binary (u-boot.bin) will be saved at <ltib_path>/rpm/BUILD/u-boot-2009.08 4 - Program the SD card Program a SD card with the new u-Boot binary and a bitmap image to be displayed. Insert the SD and run:      $sudo dd if=<ltib_path>/rpm/BUILD/u-boot-2009.08/u-boot.bin of=/dev/mmcblk0 bs=512 "/dev/mmcblk0" should replaced according to your host, use "dmesg" after inserting the SD to find out where is the SD on your host. Unmount it before issuing the dd command. $sudo dd if="your_image".bmp of=/dev/mmcblk0 bs=512 seek=608 Argument seek 608, skips the first 608 blocks of the SD (608x512) where the uboot is stored. If you need to relocate the image, update also the environment variable "splashimage_mmc_init_block", see step 6. 5 - Boot Boot the image from the SD. Personality Board settings:   12345678 SW22 -> 00000000 SW21 -> 11000000    Debug Board settings: SW5,6,7,8,9,10 -> OFF      12345678 SW4 -> 10000001 Turn on the board and stop at u-boot prompt: MX25 U-Boot > 6 - u-Boot environment variables Update u-Boot environment variables for the splash screen to work: The address in memory to load the splash screen from: MX25 U-Boot > setenv splashimage 0x80800000 The SD device on the board: MX25 U-Boot > setenv splashimage_mmc_dev 0 The block on the SD where the bitmap is stored, this must match the block on step 4. MX25 U-Boot > setenv splashimage_mmc_init_block 0x260  The amount in blocks to be read from the SD card, this depends on the bitmap size, i.e. for a 308278 bytes bitmap, 0x2B5 blocks are enough on a 512 bytes per block SD, (308278 / 512). MX25 U-Boot > setenv splashimage_mmc_blkcnt 0x2b5 The SD card block size in bytes: MX25 U-Boot > setenv splashimage_mmc_blksize 512 Save the environment variables: MX25 U-Boot > saveenv Now reboot the board and you should see the splash screen on the LCD. 7 - Booting Linux When Linux takes control of the board it initializes the LCD controller and Framebuffer again. To maintain the splash screen on the LCD you can replace the Linux Logo with the figure used for the splash screen, the side effect is a blink when Linux takes over the LCDC. To achieve this, create a new image in Gimp and save it as ".ppm". Copy it to Linux "logo" folder <ltib_path>/rpm/BUILD/linux-2.6.31/drivers/video/logo Run: $ ppmquant -mapfile clut_vga16.ppm "my_image.ppm" | pnmnoraw > logo_linux_vga16.ppm where: logo_linux_vga16.ppm is the current logo being used by Linux. Recompile the kernel and boot it.

i.MX6Q Automotive board has one ADV7180 analog video decoder with 2 video inputs. By default, only input 1 is used (connector J42).     To connect 2 analog video sources and switch the display between them, the following changes are needed:   1 - Create a new IOCTL on V4L2_capture and ADV7180 device drivers to receive the information from user space application on what input will be selected. 2 - In this new IOCTL, use the "Fast Switch Script" for ADV7180 described at Analog Devices site: ADV7180 Fast Switch Script | EngineerZone  3 - Create a user space application to call the IOCTL mentioned on step 1.   See attached:   1 - 0001-ADV7180-Adding-input-switch-IOCTL.patch.zip - Patch to be applied on NXP kernel 4.1.15_1.0.0_ga 2 - example2.c.zip - Source code example of user space application. It changes the video input in each 2 seconds. (See it working on attached video) 3 - example2.zip - User space application executable file  4 - Makefile.zip - Makefile of user space application to be used as example 5 - adv7180_switch.mp4 - Video showing the application   In the application, VIDIOC_S_CHIP_INPUT IOCTL is called to change the input:   int input = 0; if (ioctl(fd_capture_v4l, VIDIOC_S_CHIP_INPUT, &input) < 0) { printf("VIDIOC_S_CHIP_INPUT failed\n"); return TFAIL; }‍‍‍‍‍‍‍‍‍‍‍‍   This IOCTL calls the ADV7180 Fast Switch Script, added on ADV7180 driver (see attached patch).

The following are a couple of recommendations for setting up a Host machine for building the Android Nougat 7.1.1_1.0.0 BSP. Some of these recommendations are not exclusive of the Nougat release and may help in other scenarios. These also apply to using Virtual Machines as Host. Installing Open JDK 8 on Ubuntu 14.04 As mentioned on the Android guide for Establishing a Build Environment (http://source.android.com/source/initializing.html) there are no available supported OpenJDK 8 packages for Ubuntu 14.04, which is the version recommended and tested on the Nougat Android BSP. An alternative is downloading the Ubuntu 15.04 Open JDK 8 packages and installing them manually, which can be done by following this procedure: Download the .deb packages for 64-bit architecture from archive.ubuntu.com: openjdk-8-jre-headless_8u45-b14-1_amd64.deb with SHA256 0f5aba8db39088283b51e00054813063173a4d8809f70033976f83e214ab56c0 http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jre-headless_8u45-b14-1_amd64.deb  openjdk-8-jre_8u45-b14-1_amd64.deb with SHA256 9ef76c4562d39432b69baf6c18f199707c5c56a5b4566847df908b7d74e15849 http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jre_8u45-b14-1_amd64.deb  openjdk-8-jdk_8u45-b14-1_amd64.deb with SHA256 6e47215cf6205aa829e6a0a64985075bd29d1f428a4006a80c9db371c2fc3c4c http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jdk_8u45-b14-1_amd64.deb  Once you have downloaded these three packages and checked the checksum for them install the packages (optional) install them by running: $ sudo apt-get update $ sudo dpkg -i openjdk-8-jre-headless_8u45-b14-1_amd64.deb $ sudo dpkg -i openjdk-8-jre_8u45-b14-1_amd64.deb $ sudo dpkg -i openjdk-8-jdk_8u45-b14-1_amd64.deb‍‍‍‍   Increasing SWAP to compensate for the lack of RAM Having insufficient RAM especially on the linking part of the image build may cause a number of issues that are difficult to troubleshoot. In these cases it’s good to take a look at the resource monitor to see if indeed the RAM was depleted. One way to make up for the limited RAM is using a bigger swap. Google recommends at least 16GB of RAM/swap so it’s not uncommon to create a 10GB swap when working in VM, to do this please use the following commands.    $ sudo fallocate -l 10g /mnt/10GB.swap $ sudo chmod 600 /mnt/10GB.swap $ sudo mkswap /mnt/10GB.swap $ sudo swapon /mnt/10GB.swap‍‍‍‍   Increasing heap size to avoid out of memory errors It is possible to encounter an out of memory error with the recommendation “try increasing heap size witj java option ‘-Xmx<size>’. If you encounter this error or would like to proactively avoid it you may run the following commands that will increase heap size to four gigabytes and then reset the Jack Server by killing it and starting it again. With the android environment initialized: $ cd my android $ export JACK_SERVER_VM_ARGUMENTS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4g" $ jack-admin kill-server && jack-admin start-server‍‍‍‍‍‍  Fixing Jack Servers errors due to multiple users on the Host Android Nougat uses Jack Server as mono-user by default. If this is not the case for your host you would need to choose different port numbers for each user and adjust SERVER_NB_COMPILE accordingly. You can also disable the Jack server by setting SERVER=false in your $HOME/.jack. Alternatively, you may also use the patch available on the following link to myandroid/prebuilts/sdk. It will help to fix the mono-user build restriction. When installing the jack-server, it will detect if Jack server is running in the same build machine and then generate a random ports for my build instead of using the default one. https://groups.google.com/forum/#!topic/android-building/UWhJrXH8Vig

Minicom       It's a simple terminal program, easy to configure and use. Can be downloaded and installed from your Linux package distribution (Synaptic, apt-get, yum) or through this link.       Minicom is a terminal emulation that can access a remote serial console enabling the configuration of Bootloader or the flash file system of the board.   Configuring       Run Minicom calling it from Terminal:     $ minicom       Reach the cofiguration by typing CTRL-A Z Press key Z after releasing CTRL and A. Configure Minicom to work with i.MX, follow the procedure below.   Set the Serial Port       At the screen configuration, type O, choosing Configure Minicom In menu, choose Serial Port Setup Below, the configuration option:       +-----------------------------------------------------------------------+ | A - Serial Device  : /dev/ttyS0                            | | B - Lockfile Location  : /var/lock                          | | C - Callin Program  :                                          | | D - Callout Program  :                                        | | E - Bps/Par/Bits  : 115200 8N1                          | | F - Hardware Flow Control : No                          | | G - Software Flow Control : No                            | |                                                                        | | Change which setting?                                      | +-----------------------------------------------------------------------+       Type the letter of option to enable the modification. Remember to choose the right Serial Device. Screen       Another useful program to use with serial ports is screen. It is a screen manager with VT100/ANSI terminal emulation usually available in Linux distributions. To open serial device /dev/ttyS0, for example, using 115200 baudrate, simply use:     $ screen /dev/ttyS0 115200       To kill the screen manager, use Ctrl + a, k. For a list of useful parameters and commands, try:     $ man screen

INTRODUCTION REQUIREMENTS HARDWARE CONNECTIONS IMPLEMENTATION AND TESTING 1. INTRODUCTION This document explains how to generate and compile a custom Linux application on the UDOO NEO board  for using the GPIO headers to connect a 16x2 LCD. 2. REQUIREMENTS First of all, the Linux image used is UDOObuntu 2 RC1 (Ubuntu 14.04), available for download from the following link:      Downloads - UDOO​ For creating a bootable SD card and other basic setup please refer to the following guidelines:      Very First Start 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 The LCD driver of this document was already implemented on a previous application, and could be found on the following document: Customizing MQX applications on i.MX6SX. 3. HARDWARE CONNECTIONS Now, the hardware connection considers a 4-bit interface to the LCD plus the Register Select (RS) and Enable (E) pins, so, six GPIO are used. For this example, digital input/output pins are used as shown on the following figure (purple rectangle): Where: NEO GPIO GPIO148 GPIO105 GPIO149 GPIO140 GPIO141 GPIO142 LCD pin E RS DB7 DB6 DB5 DB4 4. IMPLEMENTATION AND TESTING After booting Linux, a text editor like nano should be used to generate the program. The three main configurations for GPIOS are the following (using the E pin as example): Export the GPIO. echo 148 > /sys/class/gpio/export Configure the direction of the GPIO (as output). echo out > /sys/class/gpio/gpio148/direction Set the GPIO value to Low or High: echo 0 > /sys/class/gpio/gpio148/value echo 1 > /sys/class/gpio/gpio148/value So, based on these configurations and the LCD driver already implemented on the document mentioned on Requirements section, the complete C application for Linux could be generated (find it attached). The GCC compiler already included on the UDOObuntu image could be used to generate the executable application. The picture below shows the terminal of the UDOO NEO board including the text editor, compilation and execution commands of the application. The used commands are the following: $ nano lcd16x2_imx6sx.c $ sudo gcc lcd16x2_imx6sx.c -o lcd $ sudo ./lcd Finally, the following image shows the LCD with the application working on the UDOO NEO board, connecting the LCD using a proto shield: NOTE: Ensure that M4 core is not running or using the same pins, in order to avoid unexpected behavior on GPIOs.

Before reading: only a personal works and sharing, not any form of "release". I didn't find any confidential information from the packages. So, I'm publishing it here. This is only for testing purpose. Do NOT use it for building a product. Use it at your own risk!! Yocto is flexible and powerful, and also, big and slow (when building). Sometimes we only need to build uboot or kernel or some piece of testing code. It's really a waste of time to build-up the whole Yocto environment which may cost over 50GB disk space and over 3 hours of building. I've made some scripts and sum them up to form a toolset for building uboot, kernel and some testing code out of Yocto environment. It's only a simple container and expect to use with uboot and kernel source code from formal Freescale release and a SDK built from Yocto project. GitHub source repo:       https://github.com/gopise/gopbuild What’s made off (a full package, not only the container): 1.    Some scripts and configurations files. 2.    SDK built from Yocto. 3.    Uboot/kernel from specific version. 4.    A hello-world to demonstrate how to build app in this environment. 5.    A slimmed rootfs binary from specific BSP pre-built as base. Will customize base on the source under “rootfs” folder. Only a placeholder in the container-only version. How to use it: Several common used board configurations have been included in the script: 6qsabresd/6qsabreai/6qpsabreai. You can add more into the “gopbuild” script easily. The “sabresd” has been set as default.      If you want to build all for sabresd (First of all, de-compress the package): cd <de-compressed-folder> source envsetup [It will prompt for selecting board configuration to be built. Choose one by input corresponding number or click <ENTER> for default board.] gmk ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍      If you want to build specific module for default board, such as uboot: gmk uboot ‍‍‍‍‍‍‍‍‍      Build kernel for sabreai board instead of default device: gmk kernel sabreai ‍‍‍‍‍‍‍‍‍      Clean everything? gmk all clean ‍‍‍‍‍‍‍‍‍ After a successfully full build, you will get everything under “output” folder, including a log folder contains full build log:      “u-boot.imx/zImage/rootfs.tar.bz2/*.dtb”, can be used with MFG or uuu.      “fsl-image.sdcard”, can be burn into SD card directly. "Ready-for-building" Package: The "gopbuild" itself is a "container-only" package which doesn't contain any source or SDK. I've also made some packages based on latest BSP release for i.MX6/i.MX7/i.MX8. These packages are "ready-for-build" package which you can de-compress and build it directly. -------------------------------------------------------------------------------------------------- URL：https://pan.baidu.com/s/1Xlh1OBGsTRXez_NQw-Rjxg Password: gdc9 -------------------------------------------------------------------------------------------------- Note: 1. To build for i.MX8 (8QM/8MQ/8QXP), you need L4.14.* or above. 2. To build for i.MX8, please download the SCFW from i.MX software page       i.MX Software and Development Tools | NXP      After download, decompress corresponding package for specific chip and put it under "/platform/scfw/". Take i.MX8QXP for example:             /platform/scfw/scfw_export_mx8qx/ All material (uboot/kernel/test code and SDK) are from official Yocto release. Thanks!

Installing OpenOCD and GDB i.MX27 This tutorial was tested on i.MX27ADS REV. 2.6 and may not work on other board revision. Step 0: Installing the FTDI library The libFTDI is necessary when using JTAG based on FT2232 or others FTDI chips. LibFTDI need libusb, then install it first: $ sudo apt-get install libusb-dev Download libftdi from http://www.intra2net.com/en/developer/libftdi: $ wget http://www.intra2net.com/en/developer/libftdi/download/libftdi-0.18.tar.gz Now decompress and install it: $ tar zxvf libftdi-0.18.tar.gz $ ./configure $ make $ sudo make install Step 1: Compiling OpenOCD To compile OpenOCD you need to have GCC, Autoconf and automake installed. Get the OpenOCD source code (we are using rev. 1083): svn checkout http://svn.berlios.de/svnroot/repos/openocd/trunk openocd --revision 1399 Create the configure file and Makefile.in: $ ./bootstrap Run configure: $ ./configure --enable-ft2232_libftdi Compile: $ make Install it: $ sudo make install Step 2: Initializing OpenOCD Connect your JTAG interface on computer and i.MX27ADS board. Run OpenOCD passing as parameter the processor config and JTAG interface config: $ sudo openocd -f interface/myinterface.cfg -f board/imx27ads.cfg Replace myinterface.cfg by jtag interface you are using. In our case we are using Signalyzer Jtag Interface: $ sudo openocd -f interface/signalyzer.cfg -f board/imx27ads.cfg Note: We need to add "jtag_speed 5" on signalyzer.cfg in order to it works on i.MX27ADS. You will see this init message: # openocd -f interface/signalyzer.cfg -f board/imx27ads.cfg Open On-Chip Debugger 1.0 (2009-03-06-08:47) svn:1399 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ jtag_speed: 5 dcc downloads are enabled Info : JTAG tap: imx27.bs tap/device found: 0x1b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x1) Info : JTAG Tap/device matched Info : JTAG tap: imx27.cpu tap/device found: 0x07926121 (Manufacturer: 0x090, Part: 0x7926, Version: 0x0) Info : JTAG Tap/device matched Warn : no telnet port specified, using default port 4444 Warn : no gdb port specified, using default port 3333 Warn : no tcl port specified, using default port 6666 Step 3: Creating an ARM GDB tool If you already have an arm-elf-gdb then skip this step, otherwise go on. To create an arm GDB enter on LTIB -> Package List and select this: [*] gdb [ ]   gdb to run natively on the target [*]   cross gdb (runs on build machine) It will create the ARM GDB file at ~/ltib-dir/bin/gdb $ cd /home/alan/ltib-imx27ads-20071219/bin Copy this gdb binary to /usr/bin renaming it to arm-elf-gdb: $ sudo cp gdb /usr/bin/arm-elf-gdb Step 4: Debugging an application You can test the ledtest application to i.MX27ADS supplied by OpenOCD: Enter in ledtest directory: $ cd openocd/testing/examples/ledtest-imx27ads Run arm-elf-gdb passing as argument the gdbinit_imx27ads file: $ arm-elf-gdb --command=gdbinit-imx27ads You will see this gdb message: $ arm-elf-gdb --command=gdbinit_imx27ads GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux". Setting up for the Freescale iMX27 ADS Board. The target endianness is set automatically (currently little endian) The target may not be able to correctly handle a memory-write-packet-size of 1024 bytes. Change the packet size? (y or n) [answered Y; input not from terminal] 0xc0000260 in ?? () JTAG device found: 0x1b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x1) JTAG device found: 0x07926121 (Manufacturer: 0x090, Part: 0x7926, Version: 0x0) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x200000d3 pc: 0xc0000264 MMU: disabled, D-Cache: disabled, I-Cache: disabled Loading section .text, size 0x13c lma 0xa0000000 Start address 0xa0000000, load size 316 Transfer rate: 45963 bits/sec, 316 bytes/write. Warning: the current language does not match this frame. Breakpoint 1 at 0xa000008c: file test.c, line 12.  Breakpoint 1, main () at test.c:12 12                    volatile unsigned char *ledoff = ((volatile unsigned char *)0xD4000008); (arm-gdb) Now issue continue (or just c) command and you will see D30 LED blinking! (arm-gdb) c Continuing. You can repeat this test and issue next (or just n) to debugging line by line then you can see the LED turning on and off. Using step (or just s) is not a good option because it will spend much time on for loop.

ATK (Advanced Toolkit) ATK (Advanced Toolkit) is a Windows software for programming the flash memory of i.MX boards. Using ATK This section will describe the procedure to erase the flash memory and program the bootloader. 1 - Connect a serial cable between PC and i.MX board. 2 - Some hardware configurations (switches) must be done to flash the board.   Set SW2 switch as below: Switch SW2 -> 11111 3 - Run ATK going to Start -> Programs -> AdvancedToolKit -> AdvancedToolKit   Set the options:   Device memory -> DDR; Custom Initial File -> (keep it unmarked)   Communication Channel -> Serial Port (Usually COM1) 4 - Click on Flash Tools to erase, program or dump the the flash memory and click GO h4> Flash Programming The next step is to program the bootloader image into the board's Flash following the steps below. 1 - Select the parameters as shown in the figure below and press Program. The bootloader binary image file can be found into your Board Support Package Set Program, NOR Spansion 2 - Add it on Image File field and press Program. 3 - Close ATK, turn off the board and set switch back as shown in the picture below. Set SW2 switch as below: Switch SW2 -> 11010 Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe

Qtopia Qt Extended, formerly known as Qtopia until September 30, 2008, is an application platform for Embedded Linux-based mobile computing devices such as personal digital assistants, mobile phones, and web pads. It is being developed by Qt Software, a subsidiary of Nokia. [Source: http://en.wikipedia.org] Qt Software discontinues Qt Extended March 3, 2009 — Oslo, Norway — Qt Software today announced that the product, Qt Extended, will be discontinued as a stand-alone product. Instead, selected features will be migrated into the Qt framework which will result in Qt becoming an even richer, cross-platform application framework. The final release of Qt Extended will be version 4.4.3, which will is planned for release on March 5, 2009. Qt Extended will be maintained for one year from that date. Qt Software will honor all existing support agreements, and for customers who need continued access to support beyond the term of their current agreement, Qt Software is offering the possibility of purchasing supplemental support. [Source: http://www.qtsoftware.com/about/news/qt-software-discontinues-qt-extended] Compiling Qtopia Crosscompiling Qtopia for i.MX processors requires some packages to be installed on host (PC). For more details click on your host PC Linux distribution below: All Boards Qtopia All Boards Qtopia on Ubuntu It's possible to compile Qtopia (version 2 or 4) by selecting Qtopia on package list or simply selecting Qtopia profile on Ltib configuration. Starting Qtopia Touchscreen setup When the system starts up, TSLIB_TSDEVICE environment variable must be set and ts_calibration application must be called to calibrate the touchscreen. $export TSLIB_TSDEVICE=/dev/input/event1 /dev/input/event1 is the usual touchscreen device. Some systems can address the touchscreen device to other names. It's possible to check what's the touchscreen device by typing: $cat /dev/input/<supposed device> After the command above, when touchscreen is pressed, some characters will be showed indicating that the <supposed device> device is the touchscreen device and it's working properly. $ts_calibrate Calibrate screen will appear. After touchscreen calibration, Qtopia can be executed by calling the following script: $/etc/rc.d/init.d/qtopia start Qtopia will be started.

 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