THE CONTENTS •Background Knowledge −Bootloader Introduction −U-boot Directory Structure of the Source Code •Bootloader Boot Procedure(e.g. U-boot) −i.MX6Q Introduction −Linux OS Boot Process −First Stage of Boot Sequence(Assembly Language) −Second Stage of Boot Sequence(Assembly + C Language)

The document in attachment describes how to learn System Boot Flow of Linux by code using Trace32. The hardware platform is i.MX6Q SABRE and the software in PC is Trace32. Contents 1. Introduction 2. Hardware Connection 3. Serial Connection Setup 4. U-boot Directory Setup 5. Trace32 Installation & U-boot Debugging

MIPI can support video streaming over 1, 2, 3 and 4 lanes. On i.MX6 Sabre boards, the OV5640 camera supports 1 or 2 lanes and the NXP Linux Kernel uses 2 lanes as default. In order to use only one lane, follow the steps below: 1 - Change the board Device Tree on Linux Kernel. On file <linux kernel folder>/arch/arm/boot/dts/imx6qdl-sabresd.dtsi, find the entry "&mipi_csi" and change lanes from 2 to 1. 2 - Configure OV5640 to use only one lane instead of two. On file <linux kernel folder>/drivers/media/platform/mxc/capture/ov5640_mipi.c, change the register 0x300e value from 0x45 to 0x05. This register setup is located at struct ov5640_init_setting_30fps_VGA. 3 - Build the kernel and device tree files. 4 - Test the camera. Unit test can be used to test the video capture: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 5 - Checking if it's really using one lane. MIPI_CSI_PHY_STATE resgister (address 0x021D_C014) provides the status of all data and clock lanes. During video streaming using 2 lanes, the register value constantly changes its value between 0x0000_0300 and 0x0000_0330. When using only one lane, this register value constantly changes its value between 0x0000_0300 and 0x0000_0310. To read the register value during the stream, run the video test with &: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 & Now, run the memtool: /unit_tests/memtool -32 0x021dc014 1 i.MX6DL running mxc_v4l2_overlay.out with only one lane:

Purpose:  Introduce how to debug M4 using trace32 and the difference with general debug case.If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool. Firmware: Here we using Freertos as the example, but not limited to this. There is one small difference with general debug case to M4 in 6sx, which when you attach M4 and break M4, it may impact the peripheral that A9 is using. You may have found when you break M4, A9 uart console also was frozen at the same time. This is caused by that when M4 enter debug mode, the debug_req will also assert in the peripherals which you are using on the A9 system. So,need configure the peripherals to keep running when the debug_req is assert when do the M4/A9 debug separately. Need configure the DBGEN (*) register in the related peripherals to allow the eripherals not going into debug mode and keep running even if debug_req is HIGH. The peripherals we need take care are: CAN, UART, EPIT,GPT, ENET, PWM. Note: For the CAN, the register bit is called FRZ Here is the details of uart dbgen in the RM: So if we want debug M4 separately,we should disable this bit, as A9 was using this peripheral. Here we take Freertos as the example to illuminate how to debug M4 step by step: Enable DBGEN case: Load M4 image into memory and kick off M4. (You can refer to  for the details)           =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000               ##Starting auxiliary core at 0x9FF00000                ... Attach M4 using the m4.cmm file(attached): Note:  You can find the elf file at the same folder of binary: So now you can debug your code step by step.If you go back to A9 side uart console, you would find the console have been frozen. Disable DBGEN case at A9 side: Load M4 image into memory and kick off M4. (You can refer to  for imx6sx user guide  the details)           =>mm 0x20200b4                              020200b4:00000020 ? 0x820           =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000                ##Starting auxiliary core at 0x9FF00000                ... Attach M4 using the m4.cmm file(attached) In this case you will the A9 uart console still can work, after you break M4. Disable DBGEN case at M4 side: Load M4 image into memory and kick off M4.   =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                     reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000          ##Starting auxiliary core at 0x9FF00000 Attach M4 using the m4_disable_dbgen.cmm  file(attached) In this case you will the A9 uart console still can work, after you break M4.   Notes: For more trace32 usage, please refer to http://www.lauterbach.cn/           For more imx6sx information, please refer to i.MX 6SoloX Family of Applications Processors|NXP.

Purpose: Introduce how to debug M4 using trace 32 and the difference with regular debug mode for imx6sx. If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool.

In our reference design board the eMMC IC is Sandisk SDIN5C2-8 (4.41), and in i.MX6 Reference manual and datasheet we can known that it compatible with the MMC System Specification version 4.2/4.3/4.4, and details in datasheet declare that the uSDHC module is "fully compliant with the MMC command/response sets and Physical Layer as defined in the Multimedia Card System Specification, v4.2/4.3/4.4/4.41, including high-capacity (> 2 GB) HC MMC cards." EMMC4.4/4.41 of cause can work in our released BSP. But eMMC 4.4 has been discontinued and there is a possibility eMMC 4.41 will be discontinued.  And many of our customers will choose the eMMC 4.5 or high verison EMMC 5.0 and EMMC 5.1. And how to make the eMMC 4.5 , EMMC 5.0 and EMMC 5.1 work on i.MX6 ? The EMMC 4.5 or EMMC 5.0 /5.1 is backward-compatible with eMMC4.4, we can use it in eMMC4.4 mode to enable eMMC4.4 functionality and performance on the i.MX6 platform. Booting from a eMMC 4.5 device or high version is not supported,  boot ROM will fall back to the eMMC4.4 standard when a eMMC4.5 or high version capable device is detected. In BSP it is possible to bypass eMMC version checking, so that eMMC v4.5 or high version can work as eMMC v4.4 cards, no specific v4.5 feature supported. Only basic read/write operations are supported. In the source code we can change check value of card->ext_csd.rev. Take the eMMC 4.5 work as example, the current i.MX6 Linux BSP (L3.0.35_4.1.0) has added code to interface with an eMMC4.5 card to operate as an eMMC4.4 card. Change the value of card->ext_csd.rev 5 to 6, now eMMC 5.0 can work as an eMMC 4.4. The code drivers/mmc/core/mmc.c: And for the EMMC 5.0 and EMMC5.1, modify the kernel to support eMMC 5.0 and 5.1 extended CSD revisions, as shown below: /drivers/mmc/core/mmc.c : if (card->ext_csd.rev > 6) {              // The '6' has to be replaced with '7' For EMMC5.0                                                         //  The '6' has to be replaced with '8'  For EMMC5.1 pr_err("%s: unrecognised EXT_CSD revision %d\n", mmc_hostname(card->host), card->ext_csd.rev); err = -EINVAL; goto out;          } After modifying the code we need to rebuild the the firmware uImage used for MfgTool . Update the uImage in Mfgtool , and it can flash successful. Then the eMMC version 5.0 and 5.1 can be used with IMX6 based boards.

since we have already released the patch for 3.10, this patch is for kernel 3.14

This example makes use of a U-Boot image as a bootloader. U-Boot is commonly used as a bootloader for Linux devices and is provide by the Freescale Linux BSP. The default memory layout of the Freescale U-Boot port can be modified to meet the encrypted boot requirements. This is shown in figure 5. As it can be seen, this layout is similar to any other U-Boot port, with the addition of the security mechanisms appended at the end of the image.                          Figure  Chosen memory layout of the encrypted u-boot 1)Assumptions In designing a U-Boot image as an encrypted boot solution, there are three assumptions which accelerate and simplify the construction process. . The U-boot image can be build for multiple board configuration, but for demonstration purposes this example uses i.MX6 Solo X . The user is familiar with the secure configuration for U-Boot and is able to properly sign and boot a U-Boot image. . The encrypted image will be constructed by an individual party, and there is no need to worry about provisioning the DEK. 2)Requirements The components required to build an encrypted image are shown below. Note that the majority of these components are the product of following the signing U-Boot image procedure.    a)Code Signing Tool in encryption mode o To build the CST in encryption mode, run the following command make OSTYPE=linux ENCRYPTION=yes HAB_RELEASE=~/hab/hab_release release o Note: that CST is not in encryption mode by default. This feature needs to be enabled before encrypting the bootloader image. The performance of the CST might be affected, due to its dependency on the host entropy. Refer to the CST User Guide for more details.   b) iMX6 Solo X device in secure mode   c) U-Boot image with secure boot support enabled. o To configure U-Boot to be built with secure boot support, CONFIG_SECURE_BOOT will need to be defined in the board header file (i.e. at include/configs/mx6q_arm2.h)   d) Signed U-Boot image o A U-Boot image with a CSF and digital signature attached. 3) Implementation Many different implementations for constructing a encrypted U-boot image are possible. The right implementation depends on the solution’s requirement. The presented implementation is intended to provide the foundation principles; it can be modified to meet different needs.

From iMX 3.1x kernel, all kernel debug messages will be print to debug serial port after UART driver loaded, so if the kernel hang up before tty console driver ready, there will be no kernel boot up messages.   The attached patch can be used to enable the iMX serial debug console in early time, then kernel will not buffer the debug messages.   Note: the default patch is for UART1 (tty0) as the debug port, if you need use other debug port, please modify the code "early_console_setup()" with correct UART port base address.   L3.10.53-Add-early-console-for-debug-message.patch This patch is based on L3.10.53_GA1.1.0 release, it can support iMX6S/DL/D/Q.   L3.14.52-Add-early-console-for-debug-message.patch This patch is based on L3.14.52_GA1.1.0 release, it can support iMX6S/DL/D/Q, iMX6SL, iMX6SX, iMX6UL and iMX7.  

  IMX6 SL boot process is described in Chapter 8 (System Boot) of the Reference Manual. Shortly, the loading boot data from boot SD card is performed in two stages : first read IVT, DCD, then read executable code, using the Boot Data Structure.    At first, boot ROM copies 4K byte (containing IVT and DCD ) from sector 0 of the boot SD card to internal buffer in OCRAM, located in reserved area (0x00900000 - 0x00907000). This area must not be used by user application.   Then, “after checking the Image Vector Table header value (0xD1) from Program Image, the ROM code performs a DCD check. After successful DCD extraction, the ROM code extracts from Boot Data Structure the destination pointer and length of image to be copied to RAM device from where code execution occurs”.   The IVT contains field entry - absolute address of the first instruction to execute from the image.   Note : according to Figure 8-3 (Internal ROM and RAM memory map), only OCRAM Free Area (68KB) from 0x00907000 till 0x00918000 may be used by user’s application.   The attachment contains SD-bootable example.

The LMEM Base address is 0xE0082000u rather than 0xE0002000u.So please apply the patch to FreeRTOS_BSP_1.0.0_iMX6SX to enable the M4 cache, or the cache was not be enabled by default.It may have the big impact to your product performance. diff --git a/platform/devices/MCIMX6X/include/MCIMX6X_M4.h b/platform/devices/MCIMX6X/include/MCIMX6X_M4.h index 31d6eb2..3b9d240 100644 --- a/platform/devices/MCIMX6X/include/MCIMX6X_M4.h +++ b/platform/devices/MCIMX6X/include/MCIMX6X_M4.h @@ -25584,7 +25584,7 @@ typedef struct { /* LMEM - Peripheral instance base addresses */ /** Peripheral LMEM base address */ -#define LMEM_BASE                                (0xE0002000u) +#define LMEM_BASE                                (0xE0082000u) /** Peripheral LMEM base pointer */ #define LMEM                                   ((LMEM_Type *)LMEM_BASE) #define LMEM_BASE_PTR                            (LMEM)

1. Description     These patches are used to support MPU 8080 LCD on L3.14.52_1.1.0_GA BSP.     They are based on ELCDIF hardware module, iMX6UL and iMX7D is the reference platform.   2. File List -- 0001-Add-ST7789S-MPU-LCD-support-for-iMX6UL-board.patch    Patch to support MPU display for iMX6UL, ST7789S 240*320 panel is the example.   -- 0002-Add-ST7735R-MPU-LCD-support-for-iMX7D-board.patch    Patch to support MPU display for iMX7D, ST7735R 128*128 panel is the example.   -- readme.txt    this file, please refer to it before use the patches   3. Requirement - iMX6UL EVK board or iMX7D SabreSD board. - L3.14.52_1.1.0_GA kernel.   4. How to use -- Copy the patch files to kernel folder.     $ cd ~/L3.14.52_GA1.1.0/build-imx7dsabresd-X11/tmp/work/imx7dsabresd-poky-linux-gnueabi/linux-imx/3.14.52-r0/git     $ git apply ./0001-Add-ST7789S-MPU-LCD-support-for-iMX6UL-board.patch     $ git apply ./0002-Add-ST7735R-MPU-LCD-support-for-iMX7D-board.patch   -- Build the new kernel image:     $ cd ~/L3.14.52_GA1.1.0/build-imx7dsabresd-X11/tmp/work/imx7dsabresd-poky-linux-gnueabi/linux-imx/3.14.52-r0/git     $ export CROSS_COMPILE=~/L3.14.52_GA1.1.0/build-imx7dsabresd-X11/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-     $ export ARCH=arm     $ make imx_v7_defconfig     $ make zImage     $ make dtbs   5. How to add a new MPU panel     1) in dts file, such as imx6ul-14x14-evk-i80lcd.dts, update the panel name "lcd_panel",        update the PINs in "pinctrl_lcdif_dat" and "pinctrl_lcdif_ctrl" for the new panel,        the reset and rs PINs can be from GPIO pin, lcd_reset_gpio and lcd_rs_gpio. &lcdif { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lcdif_dat        &pinctrl_lcdif_ctrl>; display = <&display0>; status = "okay"; display0: display {   mpu-mode;   lcd_reset_gpio = <&gpio3 14 0>;   lcd_panel = "ST7789S-QVGA"; }; };       2) Reference to "mxsfb_st7789s_qvga.c", add a new panel driver code.       3) Add the new panel support in Makefile and Kconfig under "drivers/video/mxc/"       4) Add the new panel support in file "mxsfb.c" and "mxsfb.h"       5) Add the new panel support in default kernel config file "imx_v7_defconfig"   Note: mpu_lcd_fb_test.tar.gz is the test application, for 8080 display, it is not sync display, so software need call ioctl to refresh the LCD.     2016-08-02: Add the uboot reference patch for iMX7D. File: L3.14.52_Uboot_mpu_display.patch  

Following docs(English or Chinese version) are also can be referred as a hand on guide. Freescale i.MX6 DRAM Port Application Guide-DDR3 飞思卡尔i.MX6平台DRAM接口高阶应用指导-DDR3篇 Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.Mx6DQSDL DDR3 Script Aid Please find i.MX6SX DDR3 Script Aid through below link. i.MX6SX DDR3 Script Aid Please find i.MX6UL DDR3 Script Aid through below link. I.MX6UL DDR3 Script Aid Please find i.MX6SL LPDDR2 Script Aid through below link.. i.Mx6SL LPDDR2 Script Aid History: 0.03 1. update ZQ_LP2_HW_ZQCS         2. add MMDC SW reset         3. add disable DQS gating and reset read FIFO Any questions are welcome!

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

It is one mandatory patch if you are in the case: The chip you are using is imx6sx TO1.3 and newer, and use the kobs-ng to flash your image to the Nand memory chip. If you are using MFG, you also need rebuild the kobs-ng, and update the binary into your MFG tool.  The patch have been integrated into the default release yocto_4.1.15, but if you are using the older version release before yocto_4.1.15, please make sure you have integrated the modification when you need to use kobs-ng to flash the image to Nand memory chip. commit 5ecf08703da489a3bd317341f630870a3d07dab9 Author: Han Xu <[email protected]> Date:   Thu Jan 28 14:40:14 2016 -0600     MMT-105: change the i.mx6sx revision check change the i.mx6sx revision check since v1.3 uses v1.2 boot config as well.     Signed-off-by: Han Xu <[email protected]>     (cherry picked from commit 1dac0c14d1e2016c2fa804f6628543d8d238c680) diff --git a/src/plat_boot_config.c b/src/plat_boot_config.c index 461675a..e1ef6f3 100644 --- a/src/plat_boot_config.c +++ b/src/plat_boot_config.c @@ -1,5 +1,5 @@ /* -* Copyright (C) 2010-2015 Freescale Semiconductor, Inc. All Rights Reserved. +* Copyright (C) 2010-2016 Freescale Semiconductor, Inc. All Rights Reserved. */ /* @@ -256,10 +256,12 @@ int discover_boot_rom_version(void)                                         }                                         fgets(line_buffer, sizeof(line_buffer), revision);                                         if (!strncmp(line_buffer, "1.0", strlen("1.0")) || -                                                       !strncmp(line_buffer, "1.1", strlen("1.1"))) +                                                       !strncmp(line_buffer, "1.1", strlen("1.1"))) {                                                 plat_config_data = &mx6sx_boot_config; -                                       if (!strncmp(line_buffer, "1.2", strlen("1.2"))) +                                       /* all other revisions should use the latest boot config */ +                                       } else {                                                 plat_config_data = &mx6sx_to_1_2_boot_config; +                                       }                                 }                                 if (!strncmp(line_buffer, plat_imx6ul, strlen(plat_imx6ul))) How to apply it to older version quickly:  Apply the patch and rebuild the kobs-ng in yocto_3.14_x environment: bitbake -c compile -v -f imx-kobs cd tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/5.0-r0/imx-kobs-5.0 git apply yocto_3_14_x.patch bitbake -c compile -v -f imx-kobs you can find the new binary “kobs-ng” under “tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/5.0-r0/build/src” Apply the patch and rebuild the kobs-ng in yocto_3.10_53 environment: . ./setup-environment build bitbake -c compile -v -f imx-kobs cd tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/3.10.53-1.1.0-r0/imx-kobs-3.10.53-1.1.0 git apply yocto_3_10_53patch bitbake -c compile -v -f imx-kobs you can find t he new binary “kobs-ng” under tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/3.10.53-1.1.0-r0/imx-kobs-3.10.53-1.1.0/src As one alternation method, you also can download the whole imx-kobs-5.4 package which yocto_4.1.15 is using to build. wget http://www.freescale.com/lgfiles/NMG/MAD/YOCTO//imx-kobs-5.4.tar.gz

Few issues encountered trying to build L5.1.1_2.1.0 Android for i.MX6: (some of them can apply to Android M6 build also) Issue-1: OpenJDK-7 required to build L5.1.1_2.1.0 but not able to download/install in Ubuntu 16.04: solution: Ubuntu 16.04 and openjdk 7 - Ask Ubuntu =============================== sudo add-apt-repository ppa:openjdk-r/ppa sudo apt-get update sudo apt-get install openjdk-7-jdk =============================== Issue-2: without any modification, got error message like: "You have tried to change the API from what has been previously approved." during compilation. solution: follow the suggestion in the error message, do "make update-api" Issue-3: error messages like ========================================= external/libcxx/include/thread:149: error: unsupported reloc 43 clang: error: linker command failed with exit code 1 (use -v to see invocation) build/core/host_shared_library_internal.mk:44: recipe for target 'out/host/linux-x86/obj32/lib/libc++.so' failed make: *** [out/host/linux-x86/obj32/lib/libc++.so] Error 1 ========================================= related post on Internet: http://stackoverflow.com/questions/36048358/building-android-from-sources-unsupported-reloc-43 https://bbs.archlinux.org/viewtopic.php?id=209698 solution:(as mentioned in the link above) replaced "prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.15-4.6/x86_64-linux/bin/ld" with the symlink to "/usr/bin/ld.gold" so this should look like: ========================================= ~/myandroid/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.11-4.6/x86_64-linux/bin$ ls -l ld* lrwxrwxrwx 1 jimlin jimlin      16     May  6 14:48 ld -> /usr/bin/ld.gold -rwxrwxr-x 1 jimlin jimlin 1645584 May  6 11:24 ld.bfd -rwxrwxr-x 1 jimlin jimlin 3497448 May  6 11:24 ld.gold -rwxrwxr-x 1 jimlin jimlin 3497448 May  6 11:24 ld.org ========================================= to this point I can build L5.1.1_2.1.0 successfully.(on 2016, May, 12.) Issue-4: can't run the SD tool "fsl-sdcard-partition.sh" used to partition/format SD card in "~/myandroid/device/fsl/common/tools" root-cause: in Ubuntu 16.04, "sfdisk" tool doesn't support "-u" parameter: ================================== sfdisk from util-linux 2.27.1 -u, --unit S              deprecated, only sector unit is supported ================================== error message encountered when running the script: ================================== ~/myandroid/device/fsl/common/tools$ sudo ./fsl-sdcard-partition.sh /dev/sdc sfdisk: unsupported unit 'M' sfdisk: unsupported unit 'M' ================================== I've modified the script a bit to adapt the changes, as attached.

For most of interlace output camera sensors, they only support up to 30fps sample rate. In this case, we may not get good display quality. In order to improve the permance under this case, we can use IPU VDI function to increase the output frequency to be 60fps and then we can get a better quality. The patch is an example to support YUV422(YUYV) 60fps VDI for Android camera preview. SW Platform: kk4.4.2_1.0.0-ga HW Platform: imx6q-sabresd Features: Support YUV422(YUYV) input format; Support IPU 60fps VDI; Supprot 60fps camera preview, but don't support camera capture. Patch: The linux kernel patch to support additonal IPU function can be found at: https://community.freescale.com/docs/DOC-173003 The Android Camera HAL can be found at here. Note: 1. The g_vdi_double is used to decide whether to support these features. When g_vdi_double is set to be 1, these features will be enabled; Or these features will be disabled and camera feature will be the same with default release. 2. The patch should be used at hardware\imx\mx6\libcamera2. 3. Accoeding to the real user case, the user can set IPU VDI motion mode to be 0 or 1 , but NEVER to be 2. 4. The fps can be up to 60fps, but it is not stable now.

     This documents shows how to secure and encrypt boot loader image for i.MX6 processor. Secure boot is necessary to be sure that CPU is allowed to run genuine and authentic images. Encrypted image secures your intellectual property from theft. Both methods secure/encryption can be extended to cover whole software on board. Boot loader image encryption is easy to do with CST tools and HAB feature build in Freescale processor. Encrypted image preparation is consist of three parts: Encrypt u-boot.imx plain image by CST utility; Wrap DEK to get DEK blob by specific board; Append DEK blob key to the u-boot image. In this document as reference board we used SABRESD iMX6q. But it's easily to adjust it for any other board based on i.MX6 CPU with HAB4.1 feature. Encrypted u-boot image consist of: IVT, DCD, u-boot.bin, CSF, dek_blob.bin. In our example finished u-boot_encrypted.imx image looks like: Address in file Data 0x000000 IVT 0x000020 DCD + pad to address 0xC00 0x000C00 u-boot.bin + pad to address* 0x7BC000 0x07DBB8 CSF bin data + pad to address** 0x07DBB8 + Wrapped DEK (dek_blob.bin)** * (IVT + DCD + u-boot.bin) has to be padded to align 0x1000. ** (CSF bin data + padding + dek_blob.bin) has to have size 0x2000 Step-by-step instruction: Clone u-boot git repository. $ mkdir ~/imx6encryption $ cd ~/imx6encryption $ git clone git://git.denx.de/u-boot.git $ cd u-boot $ git checkout v2016.03 -b tmp To enable secure features in u-boot modify the following files: Add function usec2ticks to the end of file timer.c. $ nano arch/arm/imx-common/timer.c unsigned long usec2ticks(unsigned long usec) {         ulong ticks;         if (usec < 1000)                 ticks = ((usec * (get_tbclk()/1000)) + 500) / 1000;         else                 ticks = ((usec / 10) * (get_tbclk() / 100000));         return ticks; } Press Ctrl+X and Y and Enter to save changes. In file mx6q_4x_mt41j128.cfg add string CSF 0x2000 after string BOOT_FROM sd $ nano board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg Press Ctrl+X and Y and Enter to save changes. Add defines in file mx6sabresd.h before string #define CONFIG_MACH_TYPE 3980. $ nano include/configs/mx6sabresd.h #define CONFIG_SECURE_BOOT #define CONFIG_SYS_FSL_SEC_COMPAT    4 /* HAB version */ #define CONFIG_FSL_CAAM #define CONFIG_CMD_DEKBLOB #define CONFIG_SYS_FSL_SEC_LE #define CONFIG_FAT_WRITE Press Ctrl+X and Y and Enter to save changes. Delete the following strings: gpimage.0 \ gpimage-common.o \ omapimage.o \ in Makefile. $ nano tools/Makefile Press Ctrl+X and Y and Enter to save changes Download Linaro GCC compiler. $ cd ~/imx6encryption $ wget -c https://releases.linaro.org/components/toolchain/binaries/5.3-2016.02/arm-linux-gnueabihf/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz $ tar xf gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz $ export CC=`pwd`/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- Check compiler version. $ ${CC}gcc --version Output: arm-linux-gnueabihf-gcc (Linaro GCC 5.3-2016.02) 5.3.1 20160113 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Build u-boot image with mx6qsabresd_defconfig. $ cd u-boot $ make ARCH=arm CROSS_COMPILE=${CC} distclean $ make ARCH=arm CROSS_COMPILE=${CC} mx6qsabresd_defconfig $ make ARCH=arm CROSS_COMPILE=${CC} Using mkimage utility build and get information of u-boot.imx image. $ ./tools/mkimage -T imximage -n board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg.cfgtmp -e 0x17800000 -d u-boot.bin u-boot.imx Output: Image Type:   Freescale IMX Boot Image Image Ver:    2 (i.MX53/6/7 compatible) Data Size:    516096 Bytes = 504.00 kB = 0.49 MB Load Address: 177ff420 Entry Point:  17800000 HAB Blocks:   177ff400 00000000 0007bc00 Register an account on NXP website to have access to download NXP Code Signing Tool for the High Assurance Boot library. Copy downloaded archive into “imx6encryption” folder. $ cd ~/imx6encryption $ tar xf cst-2.3.1.tar.gz $ cd cst-2.3.1 $ chmod u+x linux64/* keys/* Compile back end sources of CST utility $ sudo apt-get install libssl-dev $ cd ~/imx6encryption/cst-2.3.1/code/back_end/src $ gcc -o cst -I ../hdr -L ../../../linux64/lib *.c -lfrontend -lcrypto $ mv cst ../../../linux64 Generate keys and certificates which will be used to sign boot loader image. $ cd ~/imx6encryption/cst-2.3.1/keys Create file serial. $ nano serial Enter 8 random digits, for example: 12345678 Press Ctrl+X and Y and Enter to save changes. Create key_pass.txt $ nano key_pass.txt Enter two lines of identical text: HelloWorld HelloWorld Press Ctrl+X and Y and Enter to save changes. Execute hab4_pki_tree.sh. $ ./hab4_pki_tree.sh Do you want to use an existing CA key (y/n)?: n Enter key length in bits for PKI tree: 2048 Enter PKI tree duration (years): 10 How many Super Root Keys should be generated? 4 Do you want the SRK certificates to have the CA flag set? (y/n)?: y Generate SRK table. $ cd ~/imx6encryption/cst-2.3.1/crts $ ../linux64/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c ./SRK1_sha256_2048_65537_v3_ca_crt.pem,./SRK2_sha256_2048_65537_v3_ca_crt.pem,./SRK3_sha256_2048_65537_v3_ca_crt.pem,./SRK4_sha256_2048_65537_v3_ca_crt.pem -f 1 CST utility requires CSF script. This file describes certificates, keys and the data ranges used in sign and encryption functions. Create u-boot.csf file. $ cd ~/imx6encryption/cst-2.3.1/linux64 $ nano u-boot.csf And put the following text: [Header] Version = 4.1 Hash Algorithm = SHA256 Engine Configuration = 0 Certificate Format = X509 Signature Format = CMS Engine = CAAM [Install SRK] File = "../crts/SRK_1_2_3_4_table.bin" # Index of the key location in the SRK table to be installed Source index = 0 [Install CSFK] # Key used to authenticate the CSF data File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem" [Authenticate CSF] [Unlock] Engine = CAAM Features = RNG [Install Key] # Key slot index used to authenticate the key to be installed Verification Index = 0 # Key to install Target Index = 2 File = "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem" [Authenticate Data] # Key slot index used to authenticate the image data Verification Index = 2 #       Address   Offset        Length      Data File Path Blocks = 0x177ff400 0x00000000 0x00000C10 "./u-boot.imx" #Encrypt the boot image and create a DEK [Install Secret Key] Verification Index = 0 Target Index = 0 Key = "./dek.bin" Key Length = 128 Blob Address = 0x1787CFB8 #Provide DEK blob location to decrypt [Decrypt Data] Verification Index = 0 Mac Bytes = 16 Blocks = 0x17800010 0x00000C10 0x0007AFF0 "./u-boot.imx" Press Ctrl+X and Y and Enter to save changes. Execute CST utility to encrypt image. Note that after execution u-boot.imx file will be encrypted. $ cp ~/imx6encryption/u-boot/u-boot.imx . $ ./cst --o u-boot_csf.bin < u-boot.csf $ objcopy -I binary -O binary --pad-to=0x1FB8 --gap-fill=0x00 u-boot_csf.bin u-boot_csf.bin Prepare SD card partition table. Check SD card name in system ($dmesg | tail), for example used /dev/sdb. $ echo -e "o""\n""n""\n""p""\n""1""\n""2048""\n""+256M""\n""w" | sudo fdisk /dev/sdb $ sudo mkfs.vfat /dev/sdb1 $ cd ~/imx6encryption/u-boot $ sudo dd if=u-boot.imx of=/dev/sdb bs=512 seek=2 $ sync Wrap DEK to get DEK blob from i.MX6 CPU. Mount partition 1 and copy dek.bin file to the 1st FAT partition on SD card. $ cd ~/imx6encryption/cst-2.3.1/linux64 $ mkdir /tmp/partition0 $ sudo mount /dev/sdb1 /tmp/partition0 $ sudo cp dek.bin /tmp/partition0 $ sudo umount /tmp/partition0 Insert SD card into the board. And press any key to enter into u-boot prompt. Firstly load dek.bin to the RAM memory. Use dek_blob command to wrap dek.bin. Write file from RAM memory to SD card. => fatload mmc 1:1 0x10800000 dek.bin => dek_blob 0x10800000 0x10801000 128 => fatwrite mmc 1:1 0x10801000 dek_blob.bin 0x48 Append DEK blob key to the u-boot image. Mount SD card partition 1 and copy dek_blob.bin file to the linux64 folder. $ mkdir -p /tmp/partition0 $ sudo mount /dev/sdb1 /tmp/partition0 $ cd /tmp/partition0 $ cp dek_blob.bin ~/imx6encryption/cst-2.3.1/linux64/ $ cd ~/imx6encryption/cst-2.3.1/linux64/ $ sudo umount /tmp/partition0 $ cat u-boot_csf.bin >> u-boot.imx $ cat dek_blob.bin >> u-boot.imx Install encrypted u-boot.imx into SD card. $ sudo dd if=u-boot.imx of=/dev/sdb bs=512 seek=2 $ sync Insert SD card into the board. Press any key to enter into u-boot prompt. And check if hab_status command executes without HAB Event errors. => hab_status Attention, OTP fuses can be programmed once, double check everything before burning. If everything is fine, burn required fuses SRK_HASH, SEC_CONFIG as described in AN4581. As a result we have encrypted boot image which can be loaded and executed by only current board. Because dek_blob.bin is unique per i.MX6 CPU. Vitaliy Vasinovich April 2016

The patches are based on iMX6 L3.10.53 and 3.14.52 GA BSP.   In default linux BSP, the followed two pathes were supported in kernel driver mxc_v4l2_capture.c: CSI->IC->MEM CSI->MEM   After appied these patches, it can support the followed path: CSI->VDI->IC->MEM CSI->VDI->MEM In this mode, the VDI de-interlace will be handled on the fly, so the whole system bandwidth will be reduced.   Limitations: 1. Since the IC can only output resolution up to 1024*1024, so this is the limation on output. 2. Only VDI motion mode 2 was supported.   mxc_v4l2_tvin.zip: It is the test aplication, test command for CSI->VDI->IC->MEM ("-i 2" means CSI->VDI->IC->MEM path.): ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 2 -g2d"   test command for CSI->VDI->MEM ("-i 3" means CSI->VDI->MEM path.): ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 3 -g2d"  

[Brief description] (1)Contents The ducoment introduced how to expand Gigabit Ethernet based on i.MX6 PCI Express, and attached schematics in DSN & pdf format. (2)Binary file for EEROM I have the binary file used to debug intel82574 circuit in this schematic, If customer wants to use it to debug board based on i.MX6+Intel82574, she can submit a case for me to get the file by our Salesforece system. Best Regards, TIC Weidong Sun Email: [email protected]