NOTE: Please suggest bitbake commands you find it useful! bitbake command Description bitbake <image> Bake an image (add -k to continue building even errors are found in the tasks execution) bitbake <package> -c <task> Execute a particular package's task. Default Tasks names: fetch, unpack , patch , configure , compile , install , package , package_write , and build. Example: To (force) compiling a kernel and then build, type: $ bitbake  linux-imx -f -c compile $ bitbake linux-imx bitbake <image > -g -u depexp Show the package dependency for image. Example: To show all packages included on fsl-image-gui $ bitbake fsl-image-gui -g -u depexp NOTE: This command will open a UI window, so it must be execute on a console inside the host machine (either virtual or native). bitbake <package> -c  devshell Open a new shell where with neccesary system values already defined for package hob bitbake frontend/GUI. bitbake <package> -c listtasks List all tasks for package bitbake virtual/kernel -c menuconfig Interactive kernel configuration bitbake <image> -c fetchall Fetch sources for a particular image bitbake-layers show-layers Show layers bitbake-layers show-recipes "*-image-*" Show possible images to bake. Without "*-images-*", it shows ALL recipes bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq Show image's packages bitbake -g <pkg> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq Show package's dependencies bitbake –v <image> 2>&1 | tee image_build.log Print (on console) and store verbose baking bitbake -s | grep <pkg> Check if certain package is present on current Yocto Setup

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 6/7 Family DDR Stress Test  The i.MX6/7 DDR Stress Test Tool is a PC-based software to fine-tune DDR parameters and verify the DDR performance on a non-OS, single-task environment(it is a light-weight test tool to test DDR performance). It performs write leveling, DQS gating and read/write delay calibration features. The tool described on this page cover the following i.MX 6/7 series SoCs: i.MX 6DQP (Dual/Quad Plus) i.MX 6DQ (Dual/Quad) i.MX 6DL/S (Dual Lite/Solo) i.MX 6SoloX i.MX 6SL i.MX 6SLL i.MX 6UL i.MX 6ULL/ULZ i.MX 7D/S i.MX 7ULP Note that the DDR Stress test tool supports the all of the above i.MX SoCs, however, some of the supported i.MX SoCs named in the tool support multiple i.MX SoCs as follows: MX6DQ – when selected, this supports both i.MX 6DQ and i.MX 6DQP (Plus) MX6DL – when selected, this supports both i.MX 6DL and i.MX 6S (i.MX 6DLS family) MX6ULL – when selected, this supports both i.MX 6ULL and i.MX6 ULZ MX7D – when selected, this supports both i.MX 7D and i.MX 7S The purpose of the i.MX 6/7 series DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.). This process equips the user to then proceed with the bring-up of a boot loader and an OS. Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface. The i.MX 6/7 series DDR Tools consist of: DDR Register Programming Aid (RPA): i.MX 6/7 Series DDR Tool Release DDR Stress test: Described below There are three options to run the DDR Stress test. Each of these options are provided in the attached zip files. The following is a high-level overview of each option along with the naming convention of the associated zip file: Option 1 GUI based: Run the GUI executable and connect your board to the host PC via USB Archive file: ddr_stress_tester_vX.xx.zip The tool will first need to run a DDR initialization script for the specified i.MX SoC (refer to Load Init Script in the GUI tool).  Example initialization scripts based on NXP's development boards can be found in this zip file under the script folder.  Note, these scripts may need to be modified for your custom board and memory.   Option 2 DDR Stress Tester: JTAG Interface A hardware debugger connected to the board via the JTAG interface is used to download an elf file into the i.MX SoC OCRAM (internal RAM) and then begin execution. Results are shown on the UART serial port (115200-8-n-1). Archive file: ddr_stress_tester_jtag_vX.xx.zip As with the GUI tool, the JTAG/debugger option will first need to run a DDR initialization script for the specified i.MX SoC. Refer to the GUI tool description above for the location of the example scripts (which are found in the ddr_stress_tester_vX.xx.zip file). Note that the scripts are available either in the RealView ICE format (.inc file) or the DS-5 DSTERAM format (.ds). For other debuggers, the user will have to modify the script's command syntax for their specific debugger. This is also true if converting from a RealView Ice (.inc) format to a DS-5 DSTREAM (.ds) format and vice versa. The DDR Stress Tester executable (starting with V2.20) has an auto UART detection feature. If a different UART port for the serial console has been chosen than used on the NXP development tool (EVK, SABRE) specific commands can be added to the DDR initialization script that allows you to configure for the specific UART and then load and run the elf executable. Refer to the FAQ section of this community post and the txt file found in the JTAG archive file for instructions.   Option 3 U-Boot: The boot loader u-boot is running and commands in u-boot are used to download the bin file into SoC OCRAM and begin execution. Results are shown on the UART serial port (115200-8-n-1) Archive file: ddr_stress_tester_uboot_vX.xx.zip When downloading the DDR Stress Tool by u-boot, please copy the ddr-test-uboot-jtag-mxxxx.bin to SD card and load it to IRAM using the 'fatload' u-boot command (see notes below when using newer versions of u-boot). For i.MX6, please load the binary to 0x00907000. For i.MX7D, please load the binary to 0x00910000.  It is imperative to first disable the I and D cache in u-boot as shown below as the DDR Stress Test re-configures and re-enables the cache and MMU page table. While this option allows the user to load and run the DDR stress test from u-boot, NXP highly recommends executing the GUI based version for system testing and debugging. The u-boot version is considered a “last resort” for systems in production which may not have USB or JTAG connectivity. The reasons behind this stance are: In the GUI version, the system starts “clean” and uninitialized, whereas u-boot initializes many SoC features outside the knowledge of the DDR stress test and may conflict with the stress test operation When running the u-boot version, the test will overwrite the contents of u-boot residing in DDR, hence the test will overwrite any data in DDR. Once the stress test is loaded and executed, u-boot itself will no longer be accessible. To return to the functionality of u-boot, a system re-boot is required. Newer versions on u-boot do not allow a direct loading of the DDR stress test code from the SD card (boot media) directly to the SoC internal OCRAM (aka IRAM). Hence, the procedure is updated to first load the DDR stress test code into DDR and then copy into OCRAM, as shown in the procedure below: u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000;go 0x00907000 As u-boot initializes many peripherals that may conflict with the operation of the DDR stress test, it is necessary to clock gate these peripherals prior to running the DDR stress test. Hence, it is highly recommended to augment the procedure above as follows: u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000; u-boot> mw 0x020c4068 0x00C0000F; u-boot> mw 0x020c406c 0x00000000; u-boot> mw 0x020c4074 0x3F300000; u-boot> mw 0x020c4078 0x0000F300; u-boot> mw 0x020c407c 0x0F000003; u-boot> mw 0x020c4080 0x000003FC; u-boot> go 0x00907000 Note, in the above procedure, it is recommended to write to each clock gate register in separate commands (refer to commands starting with “mw”). The SoC requires a finite amount of time to gate each clock hence performing this sequence with a new command line write ensures the SoC has time to gate the intended clocks.   Stress Test Revision Features Comments 3.00 Add i.MX 7ULP support in the GUI version Known issues: USB connection is unstable when under USB HUB or some PC environments 2.92 Minor correction with write leveling calibration code error check to avoid a corner case of flagging an error when none have occurred.    2.91 Resolved issue with write leveling calibration code where a race condition in the code may result in the calibration routine not being able to find any delay values.   Only applies to MX6 series SoCs that support DDR3.  2.90 Reserve write delay line register (MMDC_MPWRDLCTL) configuration as DDR script does when do write calibration. In previous releases, MMDC_MPWRDLCTL would be changed to 0x40404040 by default.      * Further details available in the release notes  _________________________________________________________________________________________________________________________________________    FAQ   Q. I see an error message that states "ERROR: DCD addr is out of valid range.", why is this and how do I resolve?   A. Sometimes, when using the register programming aid, there are registers writes that are not supported in the DCD range.  Try looking for the following items and comment them out from the DDR initialization script: wait = on setmem /16 0x020bc000 = 0x30 // disable watchdog (note the address for this may be different between i.MX6x devices)  Q. How do I select the "DDR Density" pull-down menu and what is the purpose of this?   A. The DDR Density pull-down menu gives the user the option of testing a DDR density smaller than what they actually have on their board.  The advantage of doing this is to speed up test time to allow the user to perform a "quick test" of their system.  IMPORTANT: it is imperative that the user not set this value higher than the supported density on their board, doing so will cause the stress test to fail and/or lock up. The DDR Density has a different meaning depending on the memory type being tested (DDR3 or LPDDR2): For DDR3, this is the density per CHIP SELECT.  So if your board has two chip selects, and each chip select has 512MB, you would simply select 512MB or lower.  The default setting will simply set this to the detected density per chip select. For LPDDR2, this is the density per CHANNEL.  This is only relevant for MX6 devices that support 2 channel LPDDR2 memories (MX6DQ, MX6DL).  For other MX6 devices that support only one LPDDR2 channel, then this is the total density (for the maximum setting) for that channel. Note that for LPDDR2, the number of chip selects (per channel) is irrelevant when selecting the density to test as the stress test combines both chip-selects into one combined density per channel.  For example, lets say you have a 2GB LPDDR2 device, which 2 channels and 2 chip-selects per channel.  That means you have 512MB per chip select, per channel.  Or, it also means you have 1GB per channel when combining both chip selects per channel.  In this case, you would choose (a maximum setting of) 1GB in the DDR Density drop down menu.  However, this is also the same setting as the default setting (which you are welcome to still choose 1GB to convince yourself that 1GB per channel is indeed being tested). Now let's assume you have only one channel (LPDDR2) and one chip select, with a density of 128MB; in this case, the maximum DDR Density you can select is 128MB. Let's assume you have one channel and two chip selects, each chip select is 128MB;  in this case, the maximum DDR Density you can select is 256MB (a combination of both chip selects).   Note, for the MX7D, an actual density needs to be entered. For the MX6x series, simply leaving this field as Default will cause the DDR stress test to ascertain the supported density from the DDR init script. As the MX7D DDR controller is different, this feature is not supported, hence it is required for the user to enter an actual density (for more details regarding MX7D usage of density and number of chip-selects, see the next FAQ on the DDR CS setting).   Q.  What is the purpose of the "DDR CS" pull-down option?   A.  The answer depends on which processor you are testing:   For the i.MX 6x series: This pull down menu gives you the option of testing one chip select (CS0) or ALL (both) chip selects *IF* you have a two-chip select configuration.  If you have a two-chip select configuration, then this allows you to test only one chip select for faster test time; else you can choose to test both chip selects.  Note that if you have a one-chip select configuration and you choose "ALL", the stress test will return an error.   For the iMX 7D: Because the MX7D DDR controller is different, the DDR stress test will need the user to supply the entire supported density found on their board. The chip select field should be left as is (0) as the test will naturally test one chip select to the next. For example, let’s assume you are using two chip selects, with each chip select being 512MB. In this case, you would enter 1GB for the DDR Density field ensuring that both chip selects will be tested. The user is allowed to enter a density less than the density found on their board (for quicker testing), but keeping in mind both chip selects may not be tested in this case.   Q. I run DDR calibration using the DDR Stress Test Tool to obtain the calibration results.  Are these calibration parameters are written to the uboot flash_header.S automatically or manually?   A. The calibration values obtained from the DDR Stress Test Tool will need to be manually updated in the flash_header.S file or any other DDR initialization script.   Q. When running the DDR stress test on MX7D and I try to perform calibration, I get an error stating that calibration is not supported, is this expected?   A. Yes, calibration is not supported or needed when using MX7.  The reason is, MX7 uses a different memory controller than the MX6 series.  The MX6 series memory controller has built-in support for calibration where the MX7 memory controller does not.   Q. When running the GUI version of the DDR stress test, on MX7 and I leave DDR Density as default, I get an error in the tool stating I must supply a density.  Why is this?   A. This is due to the fact that MX7 uses a different memory controller than the MX6 series.  In the MX6 series, it was possible to calculate the memory density from the memory controller register settings.  The MX7 memory controller is different and does not lend itself to easily calculate the supported density based on the register settings.  Instead, the user should verify the density on their board and selected this value in the DDR Density pull-down menu.    Q. I noticed that when I run write-leveling calibration I sometimes see a note that due to the write-leveling calibration value being greater than 1/8 clock cycle that WALAT must be set to 1.  What does this mean?   A. In the MMDC chapter of the reference manual for the specific i.MX 6 device, the need to set WALAT is described in the MDMISC register as follows: "The purpose of WALAT is to add time delay at the end of a burst write operation to ensure that the JEDEC time specification for Write Post Amble Delay (tWPST) is met (DQS strobe is held low at the end of a write burst for > 30% a clock cycle before it is released). If the value of any of the WL_DL_ABS_OFFSETn register fields are greater than ‘1F’, WALAT should be set to ‘1’ (cycle additional delay). WALAT should be further increased for any full-cycle delays added by the WL_CYC_DELn register fields." Therefore, if the write-leveling calibration routine detects any write-leveling delay value greater than 0x1F, it will note to the user that WALAT must be set and the user should update their DDR3 init script to ensure WALAT is set.  Sometimes, a user may find that the write-leveling delay value may fluctuate from one run to the next, which is quite normal.  If it is found that this delay is "borderline" meaning sometimes it is greater than 0x1F and sometimes it might be slightly less, then it is ok to go ahead and set WALAT permanently in your init script as there is no harm in doing so and will ensure you will stay within JEDEC's tWPST.   Q. I sometimes see that after running write-leveling calibration that delay values being reported back are zero'd out (0x00), and then at times I see a non-zero value being reported, why is this? A. It is quite normal to see slight variations in the delay value between write-leveling calibration runs.  The write-leveling calibration routine assumes a majority of users have designed their board such that the DDR3 memories are placed close to the i.MX 6 SoC. There’s a mechanism in NXP’s DDR Stress test write leveling calibration code that checks the returned write leveling value. If the write-leveling calibration routine detects that the returned delay value is greater than ¾ of a clock cycle, it will "zero out" the delay value. It does this because it assumes that such a large delay result is due to the fact that the DQS signal is already delayed relative to the SDCLK, and to align DQS with SDCLK requires the calibration routine to delay DQS even further to align it to the next SDCLK edge, something we ideally would like to avoid.  JEDEC specs that the DQS edge must be within 25% of a SDCLK cycle with respect to the SDCLK edge, so having DQS initially slightly delayed from SDCLK is actually ok, hence why the calibration routine “zero’s” this out when the returned value exceeds ¾ of a clock cycle.  In cases like this, the DQS edge and SDCLK edge are so close together that in some calibration runs, the DQS edge may slightly precede SDCLK (resulting in a very small write-leveling delay value) and other runs, it may be slightly delayed relative to the SDCLK (resulting in a very large write-leveling delay value that will try to align DQS to the next SDCLK edge, hence needs to be zero’d out).   Q. When using the JTAG version of the DDR stress test, how can I select a different UART port for my serial port?   A. Under the folder ddr_stress_tester_jtag_v2.52, there's a text file that describes how to add a different UART port by adding a few additional commands to your DDR init script.  The following is an outline of these commands: 1. Ungate UART module clocks (most NXP scripts ungate all of the peripheral clocks at the beginning of the script, so this part is already done) 2. Configure the IOMUX options for the pins you wish the UART to use (normally an IOMUX option for UART_TX and UART_RX, and a daisy chain option for the UART_RX input) 3. Enable the desired UART module via the register UCR1, bit UART_EN 4. Disable other UART modules (UCR1[UART_EN] = 0).  Normally disabling UART1 should be sufficient, but it doesn't hurt to disable all of the other un-used UART options for the purpose of the stress test.   Here's an example in the .ds file vernacular of a set up as follows: MX6DQ, UART4 on KEY_COL0 and KEY_ROW0 (assume clock is ungated to all peripherals): mem set 0x020E01F8 32 0x00000004   #// config_pad_mode(KEY_COL0, ALT4) mem set 0x020E01FC 32 0x00000004   #// config_pad_mode(KEY_ROW0, ALT4); mem set 0x020E0938 32 0x00000001   #// Pad KEY_ROW0 is involved in Daisy Chain. mem set 0x02020080 32 0x00000000   #//disable UART1 in UART1_UCR1 (Note, you can disable other UART modules as well) mem set 0x021F0080 32 0x00000001   #//enable UART4 in UART4_UCR1   Here's another example in the .inc file vernacular of a set up as follows: MX6SX, UART5 on SD4_DATA4 abd SD4_DATA5 (assume clock is ungated to all peripherals): setmem /32 0x020E0294 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA5, ALT2; UART5_TX_DATA setmem /32 0x020E0290 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA4, ALT2; UART5_RX_DATA setmem /32 0x020E0850 = 0x00000000 // IOMUXC_UART5_IPP_UART_RXD_MUX_SELECT_INPUT, daisy chain for UART5_RX input to use SD4_DATA4 setmem /32 0x021F4080 = 0x00000001 // Enable UART_EN in UCR1 of UART5 // Disable UART_EN in UCR1 of UART1, UART2, UART3, and UART4 setmem /32 0x02020080 = 0x00000000 // UART1 setmem /32 0x021F0080 = 0x00000000 // UART2 setmem /32 0x021EC080 = 0x00000000 // UART3 setmem /32 0x021E8080 = 0x00000000 // UART4     Related Resources Links: iMX 8M Mini Register Programming Aid DRAM PLL setting  i.MX 8/8X Series DDR Tool Release  i.MX 8M Family DDR Tool Release 

Yoctoproject Framework Installing any Needed Package Using Yocto and i.MX Boards Testing Yocto for i.MX6 i.MX53 QSB - Quick Start Board i.MX6 Sabre Lite Board Build the image SDCard Image Yoctoproject Framework Yoctoproject is a framework for creating Linux distributions for embedded devices. Its layering mechanism makes it easy to add Linux to new target devices highly customized for a particular platform; it can include custom start-up scripts, software packages built with a high degree of optimization for a particular architecture, and different user interfaces from full Gnome desktop to a simple a serial console. Yocto has 2 basic layers: board support packages layer and core layer. In the BSP layer is where all the custom software and configuration tweaks for a particular platform are included, while the core layer provides the common software stack to provide from a simple command line interface to Sato desktop interface (Matchbox based and Gnome mobile software stack). A third layer could be added to provide additional user interfaces LXDE, XFCE, and more; YP is quite flexible&emdash;one of it major strengths. Installing any Needed Package Go to Yocto Project Quick Start and double check that you have all the necessary packages installed for your machine. For example, if building machine was an Ubuntu machine: $ sudo apt-get install gawk wget git-core diffstat unzip texinfo  build-essential chrpath libsdl1.2-dev xterm curl Using Yocto and i.MX Boards Please, go to project's README file in order to see the recommended instructions to download the source code. Testing Yocto for i.MX6 How to test Yocto for i.MX 6 i.MX53 QSB - Quick Start Board Edit conf/local.conf user config file and set imx53 Quick start board machine and enable parallel build features. MACHINE ?= "imx53qsb" BB_NUMBER_THREADS = "4" PARALLEL_MAKE = "-j 4" i.MX6 Sabre Lite Board Edit conf/local.conf user config file and set i.MX6 Sabrelite board machine and enable parallel build features MACHINE ?= "imx6qsabrelite" BB_NUMBER_THREADS = "4" PARALLEL_MAKE = "-j 4" if you've been facing problems to get yocto's images working on your i.MX Sabre Lite board, please take a look on this comment Re: The kernel sometins hang  in L3.0.35_4.0.0_130424 release Build the image some example of available image: image name description core-image-minimal A small image just capable of allowing a device to boot. core-image-base A console-only image that fully supports the target device hardware. core-image-sato Image with sato, a mobile environment and visual style for mobile devices.  The image supports X11 with a Sato theme, Pimlico applications and contains terminal, editor and file manager. fsl-image-test Builds contents core-image-base plus Freescale test applications and multimedia components. fsl-image-gui Builds contents of core-image-sato with Freescale test applications and multimedia with hardware accelerated X11 To build the image: $ bitbake <image_name> Build using Dash instead can bring some problems. You can check what your system uses typing: "ls -l /bin/sh". On Ubuntu you can change it using "dpkg-reconfigure bash". Some Ubuntu releases you must use "dpkg-reconfigure dash" and choose Bash Built images are located in cd tmp/deploy/images SDCard Image sudo dd if=core-image-minimal-imx6qsabrelite.sdcard of=/dev/sdb i.MX Yocto Project: Frequently Asked Questions

Some questions arise when we think about the Android boot sequence. What is the Zygote, init.rc, what is the difference between the linux kernel and the android linux kernel?. This document is intended to explain how the booting process runs. Consider the following graph: Step 1: Power On and System Startup When we press the power button, the Boot ROM code starts executing from a pre-defined location which is hardwired in ROM. It loads the Bootloader into RAM and starts executing. Step 2: Bootloader The bootloader is a small program which runs before Android does. This is NOT part of the Android operating system. The bootloader is the place where manufacturer puts their locks and restrictions. The bootloader executes in two stages. In the first stage it detects external RAM and loads a program which helps in the second stage. In the second stage, the bootloader setups the network, memory, etc, which requires to run kernel. The bootloader is able to provide configuration parameters or inputs to the kernel for specific purposes. The bootloader can be found at: <android source>/bootable/bootloader/legacy/usbloader This legacy loader contains 2 important files: 1- Init.s :: Initializes stacks, zeros the BSS segments and  call_main() in main.c 2- Main.c :: Initializes hardware (clocks, board, keyboard, console) and creates linux tags. Step 3: Kernel The Android kernel starts in a similar way as the linux kernel.  As the kernel launches, is starts to setup cache, protected memory, scheduling and loads drivers. When the kernel finishes the system setup, it looks for “init” in the system files. What is the difference between the linux and android kernels?, here's a list of changes/addons that the Android Project made to the Linux kernel: Binder: It is an Android specific interprocess communication mechanism and remote method invocation system. ashmem:  "Android Shared Memory". It is a new shared memory allocator, similar to POSIX SHM but with a different behavior and sporting a simpler file-based API. pmem: "Process memory allocator": It is used to manage large (1-16+ MB) physically contigous regions of memory shared between userspace and kernel drivers. logger:  This is the kernel support for the logcat command. wakelocks: It is used for power management files. It holds the machine awake on a per-event basis until wakelock is released. oom handling: It kills processes as available memory becomes low. alarm manager: It lets user space tell the kernel when it would like to wake up. RAM_CONSOLE: Allows to save kernel printk messages to a buffer in RAM, so that after a kernel panic they can be viewed in the next kernel invocation. USB gadget driver for ADB yaffs2 flash filesystem Step 4: init process Init is the very first process, we can say it is a root process, or the grandfather of all processes. The init process has two responsibilities.      1- Mounts directories like /sys , /dev    or /proc      2- Runs init.rc script - The init process can be found at /init :: <android source>/system/core/init - Init.rc file can be found at :: <android source>/system/core/rootdir/ Android has specific format and rules for init.rc files. More information about this rules can be found in: What is inside the init.rc and what is it used for. At  this stage, you can finally see the Android logo in your screen. Step 5: Zygote and Dalvik In Java, we know that a separate Virtual Machine instance will popup in memory for separate per app, but in the case of Android, the VM should run as quick as possible for an app. But what happens if you have several apps thus launching several instances of the Dalvik (VM)?, it would consume an immense amount of memory. To overcome this problem, the Android OS has a system called “Zygote”.  The Zygote enables code sharing across the Dalvik VM, achieving a lower memory footprint and minimal startup time.  Zygote is a virtual machine process that starts at system boot. The Zygote preloads and initializes core library classes. The Zygote loading process: Load Zygote Init class: <android source>/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java registerZygoteSocket() :: It registers a server socket for zygote command connections. preloadClasses() :: Is a simple text file that contains a list of classes that need to be preloaded, you can find the file at <android source>/framework/base preloadResources()  :: Everything that is included in the android.R file will be loaded with this method (themes and layouts). At this time, you can see the boot animation. Step 6: System service After the above steps are completed,  Zygote launches the system services.  The Zygote forks a new process to launch the system services. Core services: Starting power manager Creating the Activity Manager Starting telephony registry Starting package manager Set activity manager service as system process Starting context manager Starting system contact providers Starting battery service Starting alarm manager Starting sensor service Starting window manager Starting Bluetooth service Starting mount service Other services: Starting status bar service Starting hardware service Starting NetStat service Starting connectivity service Starting Notification Manager Starting DeviceStorageMonitor service Starting Location Manager Starting Search Service Starting Clipboard Service Starting checkin service Starting Wallpaper service Starting Audio Service Starting HeadsetObserver Starting AdbSettingsObserver Now we have finally completed the booting process (system service are up and running in memory). Need to analyze the Android Bootup? The logcat ::  Use adb to get the booting process events from the logcat. ‘adb logcat –d –b events | grep “boot” ‘adb logcat –d | grep preload’ More information about ADB can be found here: Using ADB with your Sabre Board

Prerequisites: The build is verified on prebuilt rootfs(based on LTIB) which can be downloaded from freescale.com EGL uses framebuffer backend libEGL.so -> libEGL-fb.so libGAL.so -> libGAL-fb.so QT4.8 1. Download the git respository for qt4.8: $ git clone http://git.gitorious.org/qt/qt.git qt $ cd qt Let us consider this as <QTDir> 2. Create /tftpboot and point your target fileystem. As like $ mkdir -p /tftpboot $ cd /tftpboot $ ln -s $(ROOTFFS) rootfs TBD:Need to work on this to use sysroot option 3. Create a build directory to install for the qt4 packages. This directory can be  in any location. For example, $ mkdir /opt/qt4 $ sudo chown -R <username> /opt/qt4 Let us consider the the <installdir> as /opt/qt4 4. Extract the attached mkspecs(linux-imx6-g++.tar.gz) to  <QTDir>/mkspecs/qws/ 5. Apply the attached cd 0001-add-i.MX6-EGL-support.patch attached to enable egl support for i.MX6 $ cd <QTDir> $ patch -p1<0001-add-i.MX6-EGL-support.patch 6. Export CROSS-COMPILE location path to PATH $ export PATH=$PATH:/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/ 7. Enter to the <QTDir>. Do configure. You can select the options as you like. Here is an example $ cd <QTDir> $ ./configure -qpa -arch arm -xplatform qws/linux-imx6-g++ -no-largefile -no-accessibility \ -opensource -verbose -system-libpng -system-libjpeg -system-freetype -fast -opengl es2 -egl -confirm-license \ -qt-zlib  -qt-libpng  -no-webkit -no-multimedia \ -make examples -make demos \ -release -make libs -exceptions -no-qt3support -prefix <installdir> 8. When the configure summary is shown make sure the Qt has OpenGL ES 2.0 support. Do build $ make $ make install 9. Now need to build eglfs plugin $ cd <QTDir>/src/plugins/platforms/eglfs $ make $ make install     Now the eglfs will be installed to the QT Install directory. 10. By now all required QT files are in <install directory> 11. Copy the install directory to target filesystem $ cp -rf /opt/qt4 /tftpboot/rootfs/opt/. 12. Running Qt apps on target     - Boot the target either with NFS or SD Image     - Ensure that folder <installdir> is copied on target file system at “/usr/local”.     - Launch application using $ cd /opt/qt4/examples/opengl/hellogl_es2 $ ./hellogl_es2 -platform eglfs QT5 These steps are performed on the host 1. Download the git respository for qt5: $ git clone git://gitorious.org/qt/qt5.git qt5 $ cd qt5     Let us consider this as <QTDir> 2. Create a build directory to install for the qt5 packages. This directory can be  in any loctation. For example, $ sudo mkdir /opt/qt5 $ sudo chown -R <username> /opt/qt5 Let us consider the the installdir as /opt/qt5 3. Enter the Qt5 directory and run the init-repository script to download all the source code for    Qt5. To download all the source code will take about an hour. $ ./init-repository Update:  In the latest Qt5 release the webkit library is included by default and there are some issues trying to compile it. use the next line to avoid problems if not desired to use webkit. $ ./init-repository --no-webkit 4. From the following path $ gedit qtbase/mkspecs/devices/linux-imx6-g++/qmake.conf 5. At the top of the qmake.conf, there is a configure line. Copy and paste the configure line into a text file located    in your build build directory. Edit the configure line to find your toolchain and filesystem. Also make sure to    include the options -no-pch, -no-opengl, -opengl es2, Here is an example of    a configure line. Update: In the latest Qt5 stable, the option to compile the examples/demos is -compile-examples, instead of -make examples -make demos If you are running into problems with webkit,  use the option -no-icu, this will disable the webkit. $ cd <QTDir> $ cd qtbase $ ./configure -v -opensource -confirm-license -no-pch -no-xcb -no-opengl -opengl es2  \         -make libs -device imx6 \        -compile-examples \       -device-option CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi- \        -sysroot <rootfs> -no-gcc-sysroot \       -prefix <installdir> 7. Make the textfile that has the configure line and executable and run it. When the configure summary is shown make sure the Qt5 has openGL ES 2.0 support. Do build $ make $ sudo make install    When Qt5 has finished building, Qt5 will be installed in two places:            1. <location of rootfs>/<installdir>            2. <HOST Machine>/<install dir> This is good because now all the libraries and binaries for Qt5 are installed on the host and the target filesystem. Therefore, the target already has all the libraries and  binaries needed to run Qt5. 8. Also need to build qtjsbackend and qtdeclarative. $ cd <location to Qt5 git> $ cd qtjsbackend $ ../qtbase/bin/qmake -r $ make && sudo make install $ cd <location to Qt5 git> $ cd qtdeclarative $ ../qtbase/bin/qmake -r $ make && sudo sudo make install 9. Running Qt apps on target     - Boot the target either with NFS or SD Image     - Ensure that folder <installdir> is copied on target file system at “/usr/local”.     - Launch application using $ cd /opt/qt5/examples/opengl/hellowindow $ ./hellowindow -platform eglfs FAQ: On the target file system, the location of target libaries and includes may present in arm-linux-gnueabi directory. Make sure to create soflinks to QT can find. For example $ cd $(ROOTFS)/usr/lib $ ln -s arm-linux-gnueabi/libffi.so.6 libffi.so.6 While building QT5, you may see a build error that libQt5V8.so.5 is not found. This might be some problem to be addressed in QT. Workaround is to copy all the binaries to correct path as like this $ cp  <ROOTFS>/<installdir>/lib/* <HOST Machine>/<installdir>/. What is coming up next: 1. QT on X is already available on Yocto filesystem. Steps to enable GPU Acceleration TDB. 2. QT with Wayland support.

For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time. The attached patch can make the BSP support up to 4 cameras based on 3.10.53 GA 1.1.0 BSP.   The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI   For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel.   In this patch, we given the example driver for Maxim MAX9286, it was verified working on iMX6DQ SabreAuto board. The input to MAX9286 is four 720P30 cameras. The verified camera boards:     (1) Onsemi AR0140+AP0101+MAX9271 boards.     (2) OmniVision OV10635+MAX9271 boards.   The MIPI CSI2 CVBS camera surround view solution can be found at: iMX6DQ ISL79985/79987 MIPI CSI2 CVBS camera surround view solution for Linux BSP The MIPI CSI2 CVBS HD camera surround view solution can be found at: iMX6DQ TP2854 MIPI CSI2 720P CVBS camera surround view solution for Linux BSP   The kernel patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch      Updated IPU common code to support up to four cameras.   0002-Add-Max9286-support-on-SabreAuto-board-which-can-sup.patch      MAX9286 driver, it includes MAX9271, AP0101 and AR0140 drivers.   0003-Remove-the-page-size-align-requirement-for-v4l2-capt.patch      With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly.   0004-Max9286-skip-AP0101-camera-re-initialization.patch      If the camera board's power had been kept after initialized, this patch will bypass the re-initialization to reduce the start up time.   0005-Max9286-set-I2C-speed-to-400Kbps.patch     Set I2C to 400Kbps to reduce the AP0101+AR0140 initialization time.   0006-Max9286-add-retry-for-MAX9271-I2C-access.patch     Added retry for MAX9271 I2C access.   0007-Max9286-Add-support-for-OV10635-camera.patch     Updated code for OV10635 camera.   0008-Max9286-support-auto-detect-camera-number.patch     Make the Max9286 driver can detect the camera number automatically.     How to builld the kernel with MAX9286 support:       make imx_v7_defconfig       make menuconfig (In this command, you should select the MAX9286 driver:             Device Drivers  --->                   <*> Multimedia support  --->                         [*]   V4L platform devices  --->                               <*>   MXC Video For Linux Video Capture                                       MXC Camera/V4L2 PRP Features support  --->                                           <*>Maxim max9286 GMSL Deserializer Input support                                               Select Camera Sensor (OmniVision OV10635 camera sensor)  // Or (Onsemi AP0101 and AR0140 camera sensor)                                           <*>mxc VADC support                                           <*>Select Overlay Rounting (Queue ipu device for overlay library)                                           <*>Pre-processor Encoder library                                           <*>IPU CSI Encoder library)       make zImage       make dtbs   The built out image file:       arch/arm/boot/dts/imx6q-sabreauto.dtb       arch/arm/boot/zImage   "mxc_v4l2_tvin_max9286.tar.gz" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   Some hardware check point on AR0140+AP0101+MAX9271 camera board (Please get MAX9286 and OV10635 schematics from Maxim): 1. In this patch, MAX9286's I2C address is 0x4D, so ADD0 and ADD1 should be connected to high. AP0101's I2C address is 0xBA, so SADDR should be connected to high.   2. AP0101's DOUT0~DOUT7 should be connected to MAX9271's DIN7~DIN0, the order should be switched, MSB connected to LSB.   3. MAX9271's GPO pin should be connected to AP0101's FRAME_SYNC pin. The pull down resistance on FRAME_SYNC pin should not be 0 ohm.   Some known limitation: 1. AP0101's VSYNC invalid time, last video line's HSYNC to VSYNC porch's max value is 255 pixel clocks, it is not enough for MAX9286 to generate the Frame End MIPI packets for each camera. So in order to let iMX6DQ to capture 1280x720 video for each camera, we had let AP0101 output 1280*724 frame size, and iMX6 will only capture 720 lines, the remained video data and Frame End will be ignored. This solution will not impact the function, but there will be "Error matching Frame Start with Frame End for Virtual Channel x" error reported from iMX6 MIPI_CSI_ERR1 register. Maxim suggested to use MAX96705 to relace the MAX9271, it can delay the VSYNC invalid time, then the MIPI error will be fixed.     2015-11-17 update: Updated for OV10635 camera support. File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-11-17.zip   2015-12-04 update: File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-12-04.zip Added patch 0009-Max9286-updated-PCLK-edge-setting-for-OV10635.patch to correct the OV10635 PCLK edge setting     2016-03-07 update: File L3.14.38_GA_MAX9286_Surroundview_Patch_2016-03-07.zip Added kernel patch for L3.14.38 GA 1.1.0 BSP.   2016-07-26 update: Files: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.38_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.52_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip. Added gstreamer support. Added MAX96705 support. Added patch for L3.14.52_GA1.1.0.   2017-12-11 update: Added CVBS surround view link: iMX6DQ TP2854 MIPI CSI2 720P CVBS camera surround view solution for Linux BSP     2021-04-26 update: Some customer reported, when system loading is heavy, sometimes, some camera will flicker left and right. It is caused by SFMC FIFO data lost. The original patch used IDMAC 0 and IDMAC 1 for two cameras on one IPU, this is not the best setting.  IDMAC 1 is fixed to use 1/4 SMFC FIFO and it will cause IDMAC 0 to use 1/4 SMFC FIFO too. And another 1/2 of SMFC FIFO can't be used in this case. Some code update to improve it: For each IPU, please use IDMAC 0 and IDMAC 2 to capture the two cameras. This needs change the hard coding in "drivers\media\platform\mxc\capture\ipu_csi_enc.c", "CSI_MEM1" and "IPU_IRQ_CSI1_OUT_EOF" should be changed to "CSI_MEM2" and "IPU_IRQ_CSI2_OUT_EOF". In this case, all SMFC FIFO can be used. And in "ipu_common.c", function ipu_probe(), the followed code should be changed to make IDMAC2 use high priority too. /* Set sync refresh channels and CSI->mem channel as high priority */ - ipu_idmac_write(ipu, 0x18800003L, IDMAC_CHA_PRI(0)); + ipu_idmac_write(ipu, 0x1880000FL, IDMAC_CHA_PRI(0));

Note, the tools described in this page are deprecated and are no longer maintained.  For the latest maintained i.MX 6/7 series DDR tools, the user can find these here: i.MX 6/7 Series DDR Tool Release Hi All,   DDR_Stress_Tester is a software application for fine tuning DDR parameters and verifying DDR performance on i.MX6 boards. It performs write leveling, DQS gating, read/write delay calibration on the target board to match the layout of the board and archive the best DDR performance. In addition, the stress test can help the user to verify the DDR performance on their boards.   The following are the features supported: • Support i.MX6Q, i.MX6D, i.MX6DL, iMX6S, i.MX6SL, and i.MX6SX DDR calibration. • Support DDR3 write leveling, DQS gating, Read/Write Delay auto-calibration. • Support LPDDR2 Read/Write Delay auto-calibration. • Support 16 bits, 32 bits, and 64 bits data bus. • Support fixed-mapping 2-channel LPDDR2. • Support DDR stress test between the frequency 135MHz and 672 MHz   If  USB OTG port is not available on customer board, please use the images in DDR_Stress_Tester_V1.0.3_UART1_for_SDboot&JTAG.zip. The bin files in the packages can be loaded by uboot and elf files are used by JTAG load.  Please note when the image is loaded by u-boot, the DDR is initialized by u-boot (reference flash_header.S).   To run ddr stress test from u-boot, CONFIG_SPLASH_SCREEN must be disabled in u-boot. Because when enter self refresh mode in ddr stress test, DRAM access will be blocked. If splash screen in u-boot is enabled, IPU will continuously access DRAM, so the system will hang up. If you have other DMA access in u-boot, it must be disabled.   If customer uses different RX/TX pin for UART, please contact FAE.   UART1 6DQ 6DL 6SL 6SX TX CSI0_DAT10/ALT3 CSI0_DAT10/ALT3 UART1_TXD/ALT0 GPIO1_IO04/ALT0 RX CSI0_DAT11/ALT3 CSI0_DAT11/ALT3 UART1_RXD/ALT0 GPIO1_IO05/ALT0   The commands to run ddr test in i.MX6Q uboot: U-Boot > fatload mmc 2:1 0x907000 ddr-stress-test-mx6dq.bin U-Boot > go 0x907000     For i.MX6Q/6D 4K interleaved LPDDR2, please use version v1.0.3.1. i.MX6 DDR Stress Test Tool V1.0.3.1 for LPDDR2 4K interleaved mode For i.MX6/i.MX7 DDR Stress Test Tool with GUI interface, please use version V2.x: i.MX6/7 DDR Stress Test Tool V2.10   History V1.0.3:  i.MX6SoloX is supported.

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the  i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 8M Family DDR Tools Overview The i.MX 8M Family DDR Tool is a Windows-based software to help users to do LPDDR4/DDR4/DDR3L training, stress test and DDR initial code generation for u-boot SPL. This page contains the latest releases for the i.MX 8M Family DDR Tools and cover the following SoCs : i.MX 8M Quad and its derivatives i.MX 8M Quadlite and i.MX 8M Dual i.MX 8M Mini Quad and its derivatives i.MX 8M Mini Quadlite/Dual/DualLite/Solo/SoloLite  i.MX 8M Nano Quad and its derivatives i.MX 8M Nano Quadlite/Dual/DualLite/Solo/SoloLite  i.MX 8M Plus   NOTE: For the i.MX 8/8X Family of DDR tools please refer to the: i.MX 8/8X Family DDR Tools Release   The purpose of the i.MX 8M Family DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.).  This process equips the user to then proceed with the bring-up of a boot loader and an OS.  Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface.     The i.MX 8M Family DDR Tools consist of: DDR Register Programming Aid (RPA) MSCALE DDR Tool   For more details regarding these DDR tools and their usage, refer to the i.MX 8M DDR Tools User Guide.   i.MX 8M Family DDR Tool    The i.MX 8M Family DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational for use with u-boot and OS bring-up. To install the DDR Stress Test, save and extract the zip file mscale_ddr_tool_vXXX_setup.exe.zip   (where 'xxx' is the current version number) and follow the on-screen installation instructions.     i.MX 8M Family DDR Tool Requirements   The tool requires access to the Windows registry, hence users must run it in administrator mode. When users design new i.MX 8M Family boards, please make sure to follow the rules outlined in the respective Hardware Developers Guide and the MSCALE_DDR_Tool_User_Guide, which can help users bring up DDR devices on their respective i.MX 8M boards.   i.MX 8M Family DDR Tool User Guide   The i.MX 8M DDR tool includes the document: MSCALE_DDR_Tool_User_Guide NOTE: Please read the MSCALE_DDR_Tool_User_Guide inside the package carefully before you use this tool.   i.MX8M DDR Tool Revision History   Rev Major Changes* (Features) Comments 3.31 Integration of the workaround for 8MQ ERR051273   3.30 Fix DBI enabled issue for all i.MX 8M series Automatically identify ROHM and PCA9450 PMICs on i.MX 8M Nano board Fix 4GB/8GB memory tester issues   3.20 Add support to i.MX 8M Plus   3.10 Fixe UART communication issues for some specific characters between the PC software and the target board. Fine-tune DDRPHY registers in generated C code.   3.00 Add support to i.MX8M-nano Add support to different PMIC or PMIC configuration Add support to stress test for all DDR frequency points RPA tools for Nano include support for DDR3L, DDR4, and LPDDR4.   Note that the DDR3L and LPDDR4 RPAs contain the name preliminary only to denote that these RPAs are based on internal NXP validation boards where the DDR4 RPA is based on the released EVK.   2.10 Change DDR4 capacity computing method   2.00 Add support to i.MX8M-mini   * Further details available in the release notes   Sample configuration in the .ds script for i.MX 8M debug UART2: ################step 0: configure debug uart port. Assumes use of UART IO Pads.   ##### ##### If using non-UART pads (i.e. using other pads to mux out the UART signals), ##### ##### then it is up to the user to overwrite the following IO register settings   ##### memory set 0x3033023C 32 0x00000000 #IOMUXC_SW_MUX_UART2_RXD memory set 0x30330240 32 0x00000000 #IOMUXC_SW_MUX_UART2_TXD memory set 0x303304A4 32 0x0000000E #IOMUXC_SW_PAD_UART2_RXD memory set 0x303304A8 32 0x0000000E #IOMUXC_SW_PAD_UART2_TXD memory set 0x303304FC 32 0x00000000 #IOMUXC_SW_MUX_UART2_SEL_RXD sysparam set debug_uart   1 #UART index from 0 ('0' = UART1, '1' = UART2, '2' = UART3, '3' = UART4)   Sample configuration in the front of the .ds script for i.MX 8M debug UART3  ################step 0: configure debug uart port. Assumes use of UART IO Pads.   ##### ##### If using non-UART pads (i.e. using other pads to mux out the UART signals), ##### ##### then it is up to the user to overwrite the following IO register settings   ##### memory set 0x30330244 32 0x00000000 #IOMUXC_SW_MUX_UART3_RXD memory set 0x30330248 32 0x00000000 #IOMUXC_SW_MUX_UART3_TXD memory set 0x303304AC 32 0x0000000E #IOMUXC_SW_PAD_UART3_RXD memory set 0x303304B0 32 0x0000000E #IOMUXC_SW_PAD_UART3_TXD memory set 0x30330504 32 0x00000002 #IOMUXC_SW_MUX_UART3_SEL_RXD sysparam set debug_uart   2 #UART index from 0 ('0' = UART1, '1' = UART2, '2' = UART3, '3' = UART4)   Sample configuration in the front of the .ds script for i.MX 8M Mini PMIC configuration: ##############step 0.5: configure I2C port IO pads according to your PCB design.   ##### ########### You can modify the following instructions to adapt to your board PMIC ####### memory set 0x30330214 32 0x00000010  #IOMUXC_SW_MUX_I2C1_SCL memory set 0x30330218 32 0x00000010  #IOMUXC_SW_MUX_I2C1_SDA memory set 0x3033047C 32 0x000000C6 #IOMUXC_SW_PAD_I2C1_SCL memory set 0x30330480 32 0x000000C6  #IOMUXC_SW_PAD_I2C1_SDA sysparam set pmic_cfg 0x004B #bit[7:0] = PMIC addr,bit[15:8]=I2C Bus. Bus index from 0 ('0' = I2C1, '1' = I2C2, '2' = I2C3, '3' = I2C4) sysparam set pmic_set 0x2F01 #bit[7:0] = Reg val, bit[15:8]=Reg addr. #REG(0x2F) = 0x01 sysparam set pmic_set 0x0C02   #REG(0x0C) = 0x02 sysparam set pmic_set 0x171E   #REG(0x17) = 0x1E sysparam set pmic_set 0x0C00   #REG(0x0C) = 0x00 sysparam set pmic_set 0x2F11    #REG(0x2F)=0x11     i.MX 8M Family DDR Register Programming Aid (RPA) The i.MX 8M DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization(in a separate Excel worksheet tab):   DDR Stress Test Script: This format is used specifically with the DDR stress test by first copying the contents in this worksheet tab and then pasting it to a text file, naming the document with the “.ds” file extension. The user will select this file when executing the DDR stress test. The How to Use Excel worksheet tab provides instructions on using the RPA   i.MX 8M Family DDR Register Programming Aid (RPA): Current Versions To obtain the latest RPAs, please refer to the following links (note, existing RPAs have been removed from this main page and moved to the SoC specific links below): i.MX 8M Quad : https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8M-m850D-DDR-Register-Programming-Aid-RPA/ta-p/1172441 i.MX 8M Mini : https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MMini-m845S-DDR-Register-Programming-Aid-RPA/ta-p/1172443 i.MX 8M Nano: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MNano-m815S-DDR-Register-Programming-Aid-RPA/ta-p/1172444 i.MX 8M Plus: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8MPlus-m865S-DDR-Register-Programming-Aids-RPA/ta-p/1235352   Processor Mask Revisions Memory Supported Latest RPA Version * i.MX 8M Quad & Derivatives All LPDDR4 Rev 33 i.MX 8M Quad & Derivatives All DDR4 Rev 18 i.MX 8M Quad & Derivatives All DDR3L Rev 9 i.MX 8M Mini & Derivatives A0 LPDDR4 Rev 22 i.MX 8M Mini & Derivatives A0 DDR4 Rev 21 i.MX 8M Mini & Derivatives A0 DDR3L Rev 10 i.MX 8M Nano & Derivatives A0 LPDDR4 Rev 9 i.MX 8M Nano & Derivatives A0 DDR4 Rev 12 i.MX 8M Nano & Derivatives A0 DDR3L Rev 6 i.MX 8M Plus & Derivatives A1 LPDDR4 Rev 9 i.MX 8M Plus & Derivatives A1 DDR4 Rev 9 * For the details about the updates, please refer to the Revision History tab of the respective RPA.    To modify the DRAM Frequency for a custom setting refer to iMX 8M Mini Register Programming Aid DRAM PLL setting    Related Resources Links: iMX 8M Mini Register Programming Aid DRAM PLL setting  i.MX 8/8X Series DDR Tool Release  i.MX 6/7 DDR Stress test GUI Tool i.MX 8M Application Processor Related Resources i.MX8M (m850D) DDR Register Programming Aid (RPA)  i.MX8MMini (m845S) DDR Register Programming Aid (RPA)  i.MX8MNano (m815S) DDR Register Programming Aid (RPA) i.MX 8MPlus (m865S) DDR Register Programming Aids (RPA)   i.MX 8ULP DDR tools: i.MX Software and Development Tools | NXP Semiconductors Scroll down to “Other Resources --> Tools --> DDR Tools”  

This is a simple document  explaining the basics of creating a new layer within a Yocto BSP. We will be using the latest i.MX6 Linux BSP as reference, but the same logics apply to any Yocto Project BSP including the Community BSP. If you are new to Yocto it is recommended to go through the following very informative Training which is focused on the FSL Community BSP but covers the basics of Yocto step-by-step in a very clear and concise manner. Yocto Training - HOME Requirements - L4.1.15 BSP Release for the i.MX6 family of processors installed on the host. For more information on requirements for the Host please refer to the Yocto User’s Guide available as part of the Linux BSP Document Bundle (available on the link below) http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/embedded-linux-for-i.mx-applications-processors:IMXLINUX?code=IMXLINUX -tree tool for the host, to see the directory format of the different layers. You may install it with the following command: sudo apt-get install tree - We will work with the bitbake environment so this needs to be initialized in our terminal. Introduction to layers in Yocto Layers in Yocto allow us to organize the long list of providers and to easily customize for our target hardware while reusing a lot of tools already available. It also makes it easy to distribute our customizable source code trough a unique layer. Once your environment is setup you can see the layers that compose the BSP using the command: bitbake-layers show-layers The layers that constitute out BSP will be displayed along with the path and priority of each. Layer Priority: Each layer has a priority, which is used by bitbake to decide which layer takes precedence if there are recipe files with the same name in multiple layers. A higher numeric value represents a higher priority. We can see that the poky and open embedded layers have a lower priority than those than the BSP and SDK layers as the later sit on top of the former. The general layout of a BSP is shown on the image below. If you would like to have a better look at the distinctive Layers that make up the Yocto BSP Release and the FSL Community Release please look at the Yocto Project Layers Mind Map available on the following link: YOCTO PROJECT LAYERS MIND MAP Adding an empty layer and a new recipe There are a couple of scripts available as part of the Open embedded tools that allows for easy creation of a new layer and recipe. Layers are basically a group of directories and meta data in configuration and recipe files (which contains metadata as text), so you may create these directories and meta data files by hand. However, it’s always easier to use the new layer script in order to create the required structure and then fill in with our customized configuration. cd <BSP_DIR>/sources ./poky/scripts/yocto-layer create <NEW_LAYER_NAME> We’ll name the new layer “new-layer” as shown below: ./poky/scripts/yocto-layer create new-layer We’ll be asked to enter le layer priority, we’ll keep the default 6 but you may want a higher priority depending on your application. You may opt for an example recipe to be created on your new layer.  We’ll leave this example recipe with the default settings. You may see the structure of the new layer by using the following command: tree -L 4 ./meta-new-layer Basic requirements of a layer - It is not a must but it’s strongly recommended to have the name of the layer start with “meta-“, the Poky new layer script uses this naming convention. - A README with information regarding what’s contained in the layer and any dependencies - A COPYING file with the copyright and use notice for the hardware in the new layer. - A conf folder which contains the layer’s configuration (.conf) files. Adding the layer to our BSP Once the layer has been created it’s necessary to add it to the list of Layers that make up the BSP so Bitbake can locate it and parse the metadata contained within it, in other words, you must make the build system aware of your new layer. In order to enable your layer you need to add the layer’s path to the BBLAYERS variable in the conf/bblayers.conf file which is found on the build directory. Please note that you will need to add your layer to each build directory in which you want to use it. We can add the following line to add our new layer. BBLAYERS += " ${BSPDIR}/sources/meta-new-layer " After doing so we’ll see that our layer is now listed when we run show-layers in bitbake-layers. bitbake-layers show-layers Adding a new recipe The new layer script also creates a basic recipe. It is recommended to look for recipes similar to what we need and use them as a template or starting point, as part of the benefits of Yocto is to be able to reuse a lot of open sourced code and resources. If there are many versions of the same recipe the default behavior is to use the recipe contained in the highest priority layer even if it’s not the higher version of the recipe. If you would want to force bitbake to use a certain version you may use the following variable on the local.conf file. PREFERRED_VERSION_recipename Main requirements of a recipe: SRC_URI which points to the location of the source code SRC_REV if applicable it would correspond to a particular commit or branch from the source code repository LICENSE a variable that defines the type of license to bitbake LIC_FILES_CHKSUM should point to a file within the source tree that corresponds to the md5 check-sum of the license file so it can be verified. Adding an append to a recipe You may also select the option to have the script create an append file. The append files allow us to change an existing recipe. The name of the file must be the same as the original recipe plus the append suffix (.bbappend) and should be located on the same path as the original recipe but in our own layer. The append file can be described as a piece of code or metadata that is added to the end of the original recipe. If there are more than one append files for a particular recipe all of them will be joined in reverse priority, that is, the highest priority layer’s bbappend will be added last. Appendix. Useful References FSL Community BSP Yocto Training - HOME Yocto Project Board Support Package Developer's Guide

This patch made the display no interrupt from uboot to kernel to Android. The IPU and related hardware display interface will only be initialized once in Uboot, the kernel code will skip the IPU initialization.   1. Description     1) Support HDMI, LVDS and LCD output in UBoot.     2) Support UBoot logo keep from uboot to kernel to Android.     3) For HDMI, both 720P and 1080P mode were supported.     4) For LVDS, 1024x768 and 1080P dual channel panels were supported.     5) The logo file is a 32 bpp bmp file. 2. File List -- kernel_imx\0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch -- kernel_imx\0002-Bug-fix-for-uboot-logo-keep-patch.patch    Kernel patch to support the logo keep feature. -- uboot-imx\0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch    Uboot patch to support the logo display. -- logo.bmp    Example 32bpp logo file. -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - Android JB4.2.2_1.1.0-GA UBoot and kernel. 4. How to use -- Copy the two patch files to Android kernel_imx and uboot-imx folder and apply them.     $ cd ~/myandroid/kernel_imx/     $ git apply ./0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch     $ cd ~/myandroid/bootable/bootloader/uboot-imx/     $ git apply ./0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch     $ git apply ./0002-Bug-fix-for-uboot-logo-keep-patch.patch   -- Build the new uboot image:     $ cd ~/myandroid/bootable/bootloader/uboot-imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make mx6q_sabresd_android_config     $ make   -- Before build new UBoot image, the display type can be selected from file uboot-imx\include\configs\mx6q_sabresd.h // Select one of the output mode #define IPU_OUTPUT_MODE_HDMI //#define IPU_OUTPUT_MODE_LVDS //#define IPU_OUTPUT_MODE_LCD   -- Build the new kernel image:     $ cd ~/myandroid/kernel_imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make imx6_android_defconfig     $ make uImage   -- Before "make uImage", make menuconfig can be used to select the display type.                 System Type  --->                    Freescale MXC Implementations  --->                       MX6 clk setting for smooth UI transtion from bootloader to kernel  --->                           Select Display Interface                              ( )  Smooth UI transtion on LCD, IPU1, DI0                              ( )  Smooth UI transtion on LVDS, IPU1, DI1                              (X)  Smooth UI transtion on HDMI, IPU2, DI0   -- Uboot parameters for video mode    1080P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=148500000"      720P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=74250000"      1024x768 LVDS:       "video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666,bpp=32 fb0base=0x27b00000 fbmem=28M"      800x480 LCD:       "video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB565,bpp=32 fb0base=0x27b00000 fbmem=28M" -- dd the logo.bmp to SD card address 0x100000 and skip the 54 bytes bmp file header.    sudo dd if=logo.bmp of=/dev/sdc bs=1 seek=1048576 skip=54 5. Note     1) The logo.bmp file should be 32bpp or 16bpp, and it should be synced with video mode parameters "bpp=xx",          and uboot config file mx6q_sabresd.h (#define DISPLAY_BPP  xx).       2) The IPU number and DI number are hard coded in kernel file "board-mx6q_sabresd.c". static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {   .ipu_id = 1,   .disp_id = 0, }; static struct fsl_mxc_lcd_platform_data lcdif_data = {   .ipu_id = 0,   .disp_id = 0,   .default_ifmt = IPU_PIX_FMT_RGB565, }; static struct fsl_mxc_ldb_platform_data ldb_data = {   .ipu_id = 0,   .disp_id = 1,   .ext_ref = 1,   .mode = LDB_SEP1,   .sec_ipu_id = 0,   .sec_disp_id = 0, };       3) The IPU number and DI number are defined by Macro in Uboot file "include\configs\mx6q_sabresd.h" #define IPU_NUM   2  // 1 for IPU1, 2 for IPU2. #define DI_NUM   0  // 0 for DI0, 1 for DI1.       4) The display type used in uboot and kernel must be same, same type, same IPU number, same DI port and        same resolution.     [2015-06-29 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-06-29.zip Fix some LVDS issues for iMX6DL. Also given an example for LVDS0 with DI0. New Uboot patches:      0002-Updated-lvds-clock-source-to-pll2_pfd0.-Same-as-kern.patch      0003-Add-support-for-iMX6DL.patch   New kernel patches      0003-Skip-lvds-re-initialization-for-logo-keep.patch      0004-Add-examlpe-for-LVDS0-logo-keep.patch     [2015-08-07 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-08-07.zip Added the new Uboot patch 0004-Correct-the-sequence-to-set-LDB-clock.patch It can correct the LVDS clock set sequence whch is a known issue that caused no LVDS display sometimes.   [2015-09-18 Update]: JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip Added the patch for Android JB4.3_GA1.1.1 release. Updated clock usecount, after blank the display, the related clock can be gated off correctly. Support LVDS clock from PLL5.   [2015-12-21 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2015-12-21.zip. Verified on iMX6DL/Q SabreSD board. It supports LCD and LVDS panels, HDMI patch will be released later.   [2016-01-04 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2016-01-04.zip. Added HDMI display support. Now it supports LCD, LVDS and HDMI displays. Fixed the video playback issue for boot up.   [2016-05-18 Update]: 0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch An issue was founded, when dual channel 4 lanes LVDS panel was used, in uboot there will be no LVDS TX3 signa on one LVDS port, the attach "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip, for other BSP, please port it manually.   [2016-08-29 Update]: 0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch On some iMX6 chip, after reset the IPU in SRC Control Register, enable IPU at once will cause system hang up, to avoid such issue, software needs wait for IPU reset done by polling the SRC register. The attach "0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip + "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch", for other BSP, please port it manually.   [2017-01-06 Update] Added patch for L4.1.15_GA1.2.0 BSP and Android M6.0.1_GA2.1.0 BSP. Files: L4.1.15_GA1.2.0_uboot_logo_keep_patch_2017-01-06.zip; M6.0.1_2.1.0_uboot_logo_keep_patch_2017-01-06.zip

Building using Yocto 1 - Baking (building) the kernel When an image is built using Yocto (for more details about how to build an image, check the Yocto training home: https://community.nxp.com/docs/DOC-94849) the kernel is automatically built and the kernel image is located at /fsl-community-bsp/build/tmp/deploy/images/<your_target>/uImage If you want to build only the kernel, the following command can be used: $ bitbake linux-imx     2 - Configuring the kernel To call the kernel menuconfig, run the command: $ bitbake -c menuconfig linux-imx    A new terminal window will open with the kernel menuconfig. Make changes if needed, exit the configmenu and copy the .config generated file to defconfig as following: $ cp tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r33.10/git/.config ../sources/meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6/defconfig    Note that the kernel version, in this case "3.0.35-r33.10" may change. 3 - Cleaning and building again with the new configuration With the new defconfig saved on the correct folder (step 2), it's time to clear all previous kernel and build it again: $ bitbake -c cleansstate linux-imx $ bitbake <your_image>       or         $ bitbake linux-imx    The uImage will be under tmp/deploy/image Building without a BSP 1- Downloading the kernel source code Choose what kernel you will build. Usually, the NXP kernel or mainline (kernel.org) kernel: For NXP kernel (more details on https://source.codeaurora.org/external/imx/linux-imx/ ) use: $ git clone https://source.codeaurora.org/external/imx/linux-imx                 For Mainline kernel (more details on https://www.kernel.org/ ) use: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git                2 - Choose which branch will you use Once downloaded, check the available branches by using: $ git branch -a   master   remotes/origin/HEAD -> origin/master   remotes/origin/imx_4.9.123_imx8mm_ga   remotes/origin/imx_4.9.51_imx8_beta1   remotes/origin/imx_4.9.51_imx8_beta2   remotes/origin/imx_4.9.51_imx8m_beta   remotes/origin/imx_4.9.51_imx8m_ga   remotes/origin/imx_4.9.88_2.0.0_ga   remotes/origin/imx_4.9.88_imx8mm_alpha   remotes/origin/imx_4.9.88_imx8qxp_beta2   remotes/origin/master Make a local branch, based on a branch you choose from the list: $ git checkout -b local_branch origin/imx_4.9.88_2.0.0_ga *NOTES:      On command above my local branch name is "local_branch". You can choose this name as you prefer                     The chosen branch was origin/imx_4.9.88_2.0.0_ga. You can choose another one, always starting by origin/....... 3 - Setting the environment variables 3.1 - Using Yocto Toolchain If you're using the Yocto SDK (Check the Yocto training at NXP community: https://community.nxp.com/docs/DOC-94849 ), just execute the script to export the needed environment variables, e.g.: $ source /opt/poky/1.6+snapshot/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi  $ unset LDFLAGS      If you're using another toolchain, the common environment variables to set are the following: $ export PATH=$PATH:/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/ $ export TOOLCHAIN=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/ $ export CROSS_COMPILE=arm-none-linux-gnueabi- $ export ARCH=arm IMPORTANT: Change the variables above according your installed toolchain. 3.2 - Using Ubuntu Toolchain For 64-bits processors (i.MX8 family) Install the GCC toolchain for 64 bits: sudo apt-get install gcc-aarch64-linux-gnu Export the environment variables: $ export ARCH=arm64 $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- For 32-bits processors (i.MX2, i.MX3, i.MX5 and i.MX6 families) Install the GCC toolchain for 32 bits: sudo apt-get install gcc-arm-linux-gnueabi Export the environment variables: export ARCH=arm export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- 4 - Configuring the kernel If you're building for i.MX6 and i.MX5, configure the kernel options based on file imx_v7_defconfig: $ cp arch/arm/configs/imx_v7_defconfig .config $ make menuconfig  $ make If you're building for i.MX8 family, configure the kernel options based on file arm64/defconfig:       $ cp arch/arm64/configs/defconfig .config       $ make menuconfig       $ make 5 - Building the modules After step 4, only the kernel (uImage file) was generated. The kernel modules must be built and installed in a known path. First, build the modules: $ make modules             And install them: $ make modules_install INSTALL_MOD_PATH=/path_where_you_want_to_install            

The new i.MX 6 Platform SDK 1.1 release is now available on the http://www.freescale.com/ site. NOTICE: The Platform SDK is no longer available and is unsupported. Please contact your Sales team for assistance. ·      Files available i.MX 6Series Platform SDK Bare-metal SDK for the i.MX 6 series, including reusable drivers and tests for many peripherals, and much example code. Also includes register definition headers files, and register definitions for debuggers. BSD open source license. New features and fixes - Fixed EIM test failure on sabre_ai board. - Added obds application. - Improved FAT filesystem cache. - Improved uSDHC API to allow access to entire 4GB card. - Added stream benchmark application. - Moved filesystem read/write performance test to be a new app. - New cpu_workpoint API in sdk/drivers/cpu_utility. - Improved menu API in sdk/utility/menu.h. - Fixed bug in D-cache invalidate and clean routines. - If an application returns from main(), _sys_exit() will now be called automatically. - Fixed a DDR region overflow linker error when using version 4.5.2 of the toolchain. - Removed smbus driver, as no i.MX6 boards have compatible devices and thus was untested. - Improved GIC driver by making it easier to init with new gic_init() API. - Implemented support for CSI test mode. - Converted SATA driver to use standard register definition macros. - Improvements to PWM driver. - Completely removed use of hw_module_t struct throughout SDK. Driver APIs that previously used this struct have been updated to take the relevant parameters, such as the peripheral instance, directly. Affected drivers: i2c, epit, uart, snvs, gpt, timer, flexcan. - The SDK build system now supports parallel builds. - Added jump_to_sdp() API in system_util.h to enter ROM Serial Download Protocol mode. - Static initialization of C++ objects now works as expected. - Fixed BCH ECC encoded reads and writes in GPMI driver. - Updated DCDs and debugger init scripts to the most recent versions. - Added GpioPin class in gpio driver. See sdk/drivers/gpio/gpio_pin.h. - Added classes for I2C and SPI devices. See sdk/drivers/i2c/i2c_device.h and sdk/drivers/spi/spi_device.h. - Added class to provide a software I2C port. See sdk/drivers/i2c/software_i2c_port.h. - Added gpio_set_gpio() API to gpio driver which configures the pin mux for a GPIO pin. - Added lwIP open source TCP/IP stack to the SDK. - Added two demo applications for lwIP: ping and httpd. - Implemented some minor improvements to ENET and FEC driver APIs. - Changed ENET driver so that it no longer puts the PHY into external loopback mode. A new API is added to enable loopback for the ENET unit test. - Added set_card_access_mode() API to uSDHC driver to replace some global variables that were used to configure DMA and interrupt mode. - Added read_input_string() and read_int() APIs to system_util.h. - Fixed ESAI driver so that it no longer always outputs each sample 3 times. - New arm_set_interrupt_state() API in cortex_a9.h. - Versions of all debugger init scripts are now provided for ARM DS-5. - Fixed a compiler warning generated by gcc 4.7.2 in the gpmi driver. - New version 3.4.0.4 of the IOMux Tool. - New driver for the MMA8451 accelerometer. - Added a full-featured USB Device stack under sdk/common/usb_stack. - Normalized line ending style to Unix (LF) for a few source files. - Created new APIs to manage starting up and shutting down secondary CPU cores. See cpu_start_secondary() and cpu_disable() in sdk/drivers/cpu_utility/cpu_utility.h. - Converted the multicore_demo application to a unit test under sdk/drivers/cpu_utility/test. - Added smp_primes multicore example application. - Improved spinlock API to work correctly in SMP situations. - Many small changes and improvements. - The startup code leaves interrupts disabled, and platform_init() now explicitly enables them. - Added readme files for all applications. - Changed how the makefiles archive objects in .a libraries. The timestamps of objects are compared with their copies in the archive, rather than being compared with the timestamps of the archive itself. This is to work around certain older Linux systems that do not save fractions of a second in file timestamps. One side effect of this is that the ar tool is invoked once per object that needs updating, where previously it was invoked to update a number of files at once. To reduce build log clutter, the archive messages are no longer shown.

Join FSL-community-bsp project: https://lists.yoctoproject.org/listinfo/meta-freescale In order to test Yocto Project for i.MX6 or any other supported board please follow the instructions pointed by FSL Community BSP. In order to download the source code, please follow this instructions FSL Community BSP. With the downloaded source code, you can follow the steps from this training: Yocto Training - HOME If you face a problem, please, send an email to https://lists.yoctoproject.org/listinfo/meta-freescale This page made sense when there was not other tutorial to point people on how to download and build the very first image using Yocto Project tools for i.MX family boards. Today, FSL Community BSP has become a complete environment with its own landing page (FSL Community BSP) and a collaborative community around meta-freescale mailing list. I encourage you to register in meta-freescale mailing list. I configured this document to be closed for new comments. In case of any issue or bug, please, send an email to meta-freescale.

This post describes the setup detail for installing Ubuntu based distro in any i.Mx6x NXP Boards. Details are described on: 1. Select your board, Setting the host, Download and compile uboot , dtb and and the Kernel version on your board. 2. Installing the Ubuntu core, Lubuntu graphics desktop version and/or Build your own Ubuntu rootfs with debootstrap. 3. Modify rootfs and Installing needed packages 4. Setting with SD image. 5. Setting Ubuntu on target 6. Adding GPU acceleration 1: Select your board, Setting the host, Download and compile uboot , dtb and and the Kernel version on your board. 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 Install host dependences (version tested 14.04): $ sudo apt-get install gparted git build-essential libncurses5 wget u-boot-tools zlib1g-dev ncurses-dev \ cmake libc-dev-armhf-cross pkg-config-arm-linux-gnueabihf build-essential checkinstall cmake \ pkg-config lzop libc6 libstdc++6 debootstrap qemu-user-static binfmt-support Download the compiler toolchain and extract it: $ cd ~/ $ wget -c https://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz $ tar xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz Create general variable environments: $ export target=mx6q (e.g. processor: mx6sx, mx6d, mx6dl,etc) $ export board=sabresd (e.g. sabresd, sabreauto) $ export ARCH=arm $ export CROSS_COMPILE=../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ unset LDFLAGS Download u-boot At the release of this document, latest uboot version was imx_3.14.52, it should work with other version as well, so please check the proper version for your board: $ cd ~/ $ wget –c http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/snapshot/uboot-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ tar -xf uboot-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ cd uboot-imx-rel_imx_3.14.52_1.1.0_ga $ make $targetboard_config    # e.g. mx6qsabresd_config $ make Linux Kernel, Firmware, headers, modules and DTS files $ cd ~/ $ wget –c http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/snapshot/linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ tar xf linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ make imx_v7_defconfig $ make menuconfig $ make -j4 zImage modules dtbs $ cd ~/ move your image to binary folder: $ sudo cp –v uboot-imx-rel_imx_3.14.52_1.1.0_ga/u-boot.imx binary/ $ sudo cp –v linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga/arch/arm/boot/zImage binary/ $ sudo cp –v linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga/arch/arm/boot/dts/i$target-$board.dtb binary/ Now you have the bootloader, device tree and kernel image of your board ready, let’s create the rootfs. 2: Installing the Ubuntu core, Lubuntu graphics desktop version and/or Build your own Ubuntu rootfs with debootstrap. Installing ubuntu core: $ cd ~/ $ sudo mkdir –p core /media/rootfs /media/kernel $ wget –c http://cdimage.ubuntu.com/ubuntu-core/releases/14.04/release/ubuntu-core-14.04.4-core-armhf.tar.gz $ sudo tar –xf ubuntu-core-14.04.4-core-armhf.tar.gz –C core $ sudo cp -vr core/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/rootfs folder. and you can pass to part 3 of this post. Installing ubuntu Linaro LXDE: $ cd ~/ $ sudo mkdir –p core /media/rootfs /media/kernel $ wget https://releases.linaro.org/14.10/ubuntu/trusty-images/alip/linaro-trusty-alip-20141024-684.tar.gz $ sudo tar -xf linaro-trusty-alip-20141024-684.tar.gz –C core $ sudo mv core/binary/* core/ $ sudo rm –rf core/binary $ sudo cp -vr core/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/rootfs folder. and you can pass to part 3 of this post. Installing with debootstrap $ cd ~/ $ target=rootfs $ distro=trusty $ sudo debootstrap --arch=armhf --foreign --include=ubuntu-keyring,apt-transport-https,ca-certificates,openssl $distro "$target" http://ports.ubuntu.com $ sudo cp /usr/bin/qemu-arm-static $target/usr/bin $ sudo cp /etc/resolv.conf $target/etc Now have a minimal Ubuntu rootfs - chroot to it and perform the 2nd stage install: $ sudo chroot $target  //Now we are in chroot # distro=trusty # export LC_ALL=C LANGUAGE=C LANG=C # /debootstrap/debootstrap --second-stage Edit the sources.list repositories # cat <<EOT > /etc/apt/sources.list deb http://ports.ubuntu.com/ubuntu-ports/ $distro main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ $distro-updates main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ $distro-security main restricted universe multiverse EOT # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 40976EAF437D05B5 # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 3B4FE6ACC0B21F32 # apt-get update # apt -y -f install # apt-get upgrade # apt-get install nano Now you should be able to login without password, then use passwd command to set one. If you like to add custom users: # passwd root # adduser <myuser> # usermod -a -G tty myuser # usermod -a -G dialout, adm, sudo, dip, plugdev myuser # visudo Under the line that looks like: root ALL=(ALL:ALL) ALL add the following (change user with your actual username) <myuser> ALL=(ALL) ALL your rootfs is ready, exit chroot # exit $ sudo rm $target/etc/resolv.conf $ sudo rm $target/usr/bin/qemu-arm-static $ sudo mv rootfs/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/root. 3: Modify Rootfs and Install needed packages Edit and verify the sources.list repositories $ cd /media/rootfs $ sudo cat <<EOT > etc/apt/sources.list deb http://ports.ubuntu.com/ubuntu-ports/ trusty main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ trusty-updates main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ trusty-security main restricted universe multiverse EOT Edit networks interfaces and append in the existing file: $ sudo nano etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp If you require Serial Console, remove and include an additional line at the end of the file for  ttymxc0 output as below, $ sudo nano etc/init/tty1.conf exec /sbin/getty -8 38400 tty1 exec /sbin/getty -L 115200 ttymxc0 If you like to change the localhostname: $ sudo nano etc/hostname and change to “your name” e.g. imx6Q. Set the date and time clock and update $ sudo nano /etc/rc.local  Add this: if [ `date +"%Y"` -eq "1970" ]; then                     date --set="2016-04-01" fi exit 0 (optional for Linaro rootfs) Edit passwd and remove the x in root and linaro lines $ sudo nano etc/passwd root:x:0:0:root:/root:/bin/bash linaro:x:0:0.. and change like this:                                   root::0:0:root:/root:/bin/bash linaro:::0:.. Now you are ready to program your sd image. 4: Setup microSD/SD card For these instructions, we are assuming: DISK=/dev/sdg on your HOST, cat /proc/partitions is very useful for determining the device id. $ cd ~/ $ export DISK=/dev/sdg Erase microSD/SD card: $ sudo dd if=/dev/zero of=${DISK} bs=1M count=10 Install Bootloader $ cd binary/ $ sudo dd if=u-boot.imx of=${DISK} bs=512 seek=2 $ sync Create Partition layout: $ cd ~/ $ sudo fdisk ${DISK} steps:        d ///delete all partitions currently on sd n // create new partition p // Primary partition 1 // partition number 1 2048 //default +1G // n // created 2d parition p 2 default default 1 // firts B // to be fat32 W // write partiotions $ sudo mkfs.vfat ${DISK}1 $ sudo mkfs.ext3  ${DISK}2 Mount ext3 SD partition to /media/rootfs: $ sudo mount ${DISK1} /media/kernel_target $ sudo mount ${DISK}2 /media/rootfs_target Copy Files on the SD. $ cd ~/ $ sudo cp –v binary/ i$target-$board.dtb /media/kernel_target $ sudo cp –v binary/zImage /media/kernel_target $ sudo mv /media/rootfs/* /media/rootfs_target Remove SD: $ sync $ sudo umount /media/kernel_target $ sudo umount /media/rootfs_target Boot the target, in console you should be login as root. root@imx6QSabreSD:~# 5: Setting Ubuntu on target Note: If you have issues with sudo on user UID, need to logout and log as root: imx6Q login: root Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.14.52 armv7l) root@imx6Q:~# chown root:root /usr/bin/sudo root@imx6Q:~# chmod 4755 /usr/bin/sudo root@imx6Q:~# exit Login with <user $> or root # # apt-get update # apt-get –f install # apt-get install locales dialog wget # dpkg-reconfigure locales # apt-get upgrade Optional – install some useful packages: # apt-get install openssh-server can-utils usbutils build-essential automake autoconf libtool Get and Install the BSP packages (EULA required) # cd /home/user # mkdir –p vpu_pack # cd vpu_pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//firmware-imx-5.3.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-vpu-5.4.32.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//libfslcodec-4.0.8.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-lib-5.1.tar.gz # chmod +x * # ./firmware-imx-5.3.bin --auto-accept --force # mkdir –p /lib/firmware/vpu # cp -ravf firmware-imx-5.3/firmware/* /lib/firmware/ # ./imx-vpu-5.4.32.bin --auto-accept --force # cd imx-vpu-* # make PLATFORM=IMX6Q all # make install # tar -xf imx-lib-5.1.tar.gz # cd  imx-lib-5.1/ # make -j1 PLATFORM="IMX6Q" # make PLATFORM="IMX6Q" install # cd .. # ./libfslcodec-4.0.8 --auto-accept –force # cd libfslcodec-* # ./autogent.sh --prefix=/usr --enable-fhw --enable-vpu # make # make install # mv /usr/lib/imx-mm/video-codec/* /usr/lib # mv /usr/lib/imx-mm/audio-codec/* /usr/lib # rm –rf /usr/lib/imx-mm/ # cd .. # mkdir –p gpu_pack # cd gpu_pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-gpu-viv-5.0.11.p7.4-hfp.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//xserver-xorg-video-imx-viv-5.0.11.p7.4.tar.gz # chmod +x * # ./imx-gpu-viv-5.0.11.p7.4-hfp –-auto-accept -–force # cd imx-gpu* # cp g2d/usr/include/* /usr/include/ # cp -d g2d/usr/lib/* /usr/lib/ # cp -Pr gpu-core/usr/* /usr # optional: install demos # cp -r gpu-demos/opt / # optional: install gpu tools # cp -axr gpu-tools/gmem-info/usr/bin/* /usr/bin/ # cd .. Installing gstreamer-imx, IPU, VPU and GPU support: Install build deps, gstreamer1.x, this step could take some time (~350MB): # apt-get install python pkg-config git gstreamer1.0-x gstreamer1.0-tools gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-alsa libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libgstreamer-plugins-good1.0-dev g++-multilib # git clone git://github.com/Freescale/gstreamer-imx.git # cd gstreamer-imx # ln –s /usr/lib/arm-linux-gnueabihf/gstreamer-1.0/ /usr/lib/gstreamer-1.0 # ./waf configure --prefix=/usr --kernel-headers=/include # ./waf # ./waf install # cd ../../ (optional) Install libimxvpuapi library: This library provides a community based open-source API to the NXP imx-vpu library (the low-level IMX6 VPU interface). # git clone git://github.com/Freescale/libimxvpuapi.git # cd libimxvpu* # ./waf configure –-prefix=/usr # ./waf # ./waf install # cd .. note './waf install' installs artifacts to its prefix + /lib/gstreamer-1.0 but they need to be installed to /usr/lib/arm-linux-gnueabihf/gstreamer-1.0 which is why we created a symlink above before installing note g2d lib required to build G2D note that x11 library is required to build EGL sink with Vivante direct textures (only needed for X11 support) note that libfslaudiocodec is required to build audio plugins Now you are ready to test gstreamer 6: Add GPU HW Acceleration for X11 NOTE: The original version of these build instructions can be found in the Gateworks wiki . Many thanks to them for writing this! IMX6 IPU, VPU, and GPU support via GStreamer and Gstreamer-imx plugins. Many of the pieces needed (firmware and source-code) are from NXP and not freely redistributable thus must be downloaded from their mirror and extracted from a shell script that forces you to read and agree to their End User License Agreement (EULA). The following instructions can be used on top of the debootstrap and should work on other sources of Ubuntu or other Linux distributions root filesystems as well You can easily add X11 support to a base image created with the debootstrap instructions above by adding a few package groups. You will need the following: X11 server - ie Xorg Display Manager - this controls the login to the X session Window Manager - manages window position, re-sizing, decorations, etc for X clients If in any case you have installed the Linaro LXDE rootfs, it includes the Xorg X11 server, the lxdm Display Manager, the openbox Window Manager, and others useful user applications including the Chromium browser, if you do not install linaro lxde and want to install it please do: this step could take some time (~650MB)   # apt-get install xinit lxde lxterminal lxappearance lxrandr lxshortcut lxinput xinit  xserver-xorg-dev mesa-utils mesa-utils-extra Notes: you will need to add a non-root user with adduser for Chromium browser to work. You may choose to set up auto-login for that user by editing /etc/lxdm/default.conf and setting the autologin property in the base section at the beginning of the config file. /etc/xdg/lubuntu/lxdm/lxdm.conf This document takes as based kernel version 3.14.52v, vivante 5.0.11p7.4 correspond to the kernel version used. you should check the BSP release notes in order to know which xserver and Vivante GPU files need to be downloaded from the NXP repos. $ sudo nano /etc/lxdm/default.conf    [base]    autologin=user To add hardware GPU acceleration to X11 you need to add some libraries and drivers provided by Freescale from the imx-gpu-viv package. This requires signing Freescales End User License Agreement (EULA). This package provides the following: libg2d - a documented low-level API to the GPU (used by things like libimxvpuapi for gstreamer-imx and the gpu-core drivers) gpu-core - provides all the various OpenGL libs (libGL, libGLESv1_CM, libGLESv1_CL, libGLESv2, libGLSLC, libCLC, libEGL, libGAL, libOpenCL, ls libOpenVG) typically provided by the mesa project. Note that several versions of libEGL/libGAL/libGLESv2/libVIVANTE are provided for different backend rendering systems: dfb, fb, wl, x11. # cd gpu_pack #cd imx-gpu-* # cp gpu-core/usr/lib/dri/vivante_dri.so /usr/lib/xorg/modules/drivers/ # chmod 644 /usr/lib/xorg/modules/drivers/vivante_dri.so # rm /usr/lib/arm-linux-gnueabihf/mesa/libGL.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libEGL.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libGLESv2.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libOpenVG.so* # cd ../../ # cd gpu-pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//xserver-xorg-video-imx-viv-5.0.11.p7.4.tar.gz # tar –xf xserver* # cd xserver-org-video-imx* #looks lik have to made #git init # ./fastbuild.sh  BUILD_HARD_VFP=1 XSERVER_GREATER_THAN_13=1 # cd.. # cd kernel-modu* # make Switch to gpu-core x11 backend: # backend=x11 # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so.1 # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so.1.0 # ln -sf libGAL-${backend}.so /usr/lib/libGAL.so # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so.2 # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so.2.0.0 # ln -sf libVIVANTE-${backend}.so /usr/lib/libVIVANTE.so # ln -sf libGAL_egl.dri.so /usr/lib/libGAL_egl.so # for i in egl glesv1_cm glesv2 vg; do         cp /usr/lib/pkgconfig/${i}_${backend}.pc/usr/lib/pkgconfig/${i}.pc     done #rm /usr/lib/*-dfb.so /usr/lib/*-fb.so /usr/lib/*-wl.so (Optional in case you deploy your kernel version with GPU as module) make vivante kernel module (GPU kernel driver) load on boot: # echo vivante >> /etc/modules # nano /etc/udev/rules.d/10-imx.rules KERNEL=="galcore",  MODE="0660", GROUP="video" KERNEL=="mxc_asrc",  MODE="0666" Create an xorg.conf configured for the Vivante fbdev driver: # nano /etc/X11/xorg.conf Section "Device"     Identifier "i.MX Accelerated Framebuffer Device"     Driver "vivante"     Option "fbdev" "/dev/fb0"     Option "vivante_fbdev" "/dev/fb0"     Option "HWcursor" "false" EndSection Section "ServerFlags"     Option "BlankTime"  "0"     Option "StandbyTime"  "0"     Option "SuspendTime"  "0"     Option "OffTime"  "0" EndSection # cd .. Make sure the files copied into the correct places. If all compiled and copied, you should now see a bunch of new libraries in /usr/lib! Congratulations! After you finish you can reboot your system and start playing. Testing Gstreamer examples: show gstreamer-imx plugins: # gst-inspect-1.0 | grep imx imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder imxvpu:  imxvpudec: Freescale VPU video decoder imxv4l2videosrc:  imxv4l2videosrc: V4L2 CSI Video Source imxg2d:  imxg2dcompositor: Freescale G2D video compositor imxg2d:  imxg2dvideotransform: Freescale G2D video transform imxg2d:  imxg2dvideosink: Freescale G2D video sink imxipu:  imxipucompositor: Freescale IPU video compositor imxipu:  imxipuvideosink: Freescale IPU video sink imxipu:  imxipuvideotransform: Freescale IPU video transform imxpxp:  imxpxpvideotransform: Freescale PxP video transform imxpxp:  imxpxpvideosink: Freescale PxP video sink imxipuvideosink: # gst-launch-1.0 videotestsrc ! imxipuvideosink imxg2dvideosink: # gst-launch-1.0 videotestsrc ! imxg2dvideosink The imxeglvivsink allows hardware accelerated display to a window on the X11 host # export DISPLAY=:0.0 # gst-launch-1.0 videotestsrc ! imxeglvivsink To test if you have graphics support you can run any glmark2 and/or mesa-utils or can run example of the next route: # cd /opt/viv_samples/vdk/ # ./tutorial1                                                                      //any example root@imx6Q:~# glxgears -info GL_RENDERER   = Vivante GC2000 GL_VERSION    = 2.1 2.0.1 GL_VENDOR     = Vivante Corporation GL_EXTENSIONS = WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_EXT_swap_control GL_EXT_texture_env_add GL_ARB_multitexture GL_ARB_multisample GL_ARB_texture_env_add GL_ARB_texture_compression GL_ARB_texture_env_combine GL_ARB_depth_texture GL_ARB_window_pos …. 1606 frames in 5.0 seconds = 321.130 FPS 1650 frames in 5.0 seconds = 329.834 FPS L_RENDERER   = Vivante GC2000 GL_VERSION    = 2.1 2.0.1 GL_VENDOR     = Vivante Corporation1629 frames in 5.0 seconds = 325.644 FPS 1621 frames in 5.0 seconds = 324.072 FPS 1650 frames in 5.0 seconds = 329.806 FPS 1651 frames in 5.0 seconds = 330.079 FPS

Here are two patches to support BT656 and BT1120 output for i.MX6 ipuv3. With this patch, the i.MX6 can support the CVBS output on TV encoder. It is useful for a TV box. "L3.0.35_1.1.0_GA_bt656_output_patch.zip" is the patch for Freescale L3.0.35_1.1.0_GA_iMX6DQ BSP. "r13.4.1_bt656_output_patch.zip" is the patch for Freescale Android R13.4.1 BSP. 1. Features supported:     1) Support BT656(8 bits) and BT1120 (16 bits)interlaced output on display port.     2) Support both RGB and YUV frame buffer for BT656/BT1120 output.     3) Support PAL and NTSC mode.     4) Support on the fly switch between PAL and NTSC mode.     5) Support CVBS output based on adv7391 TV encoder. 2. Hardware link between iMX6 and adv7391 TV encoder chip.     IPU1_DI0_DISP_CLK connected to adv7391 CLKIN pin.     IPU1_DISP0_DAT_23~DISP0_DAT_16 connected to adv7391 P7~P0 pins.     IPU1_DI0_PIN2 connected to adv7391 HSYNC pin. (option)     IPU1_DI0_PIN4 connected to adv7391 VSYNC pin. (option)   - Android R13.4.1 kernel. 3. How to use -- Copy the two patch files to kernel folder.     $ git apply ./0001-Support-BT656-and-BT1120-output-for-iMX6-ipuv3.patch     $ git apply ./0002-Support-adv739x-TV-encoder-for-BT656-output.patch -- Select them in kernel config and build the new kernel image:                     Device Drivers  --->                       Graphics support  --->                           [*]   MXC BT656 and BT1120 output                           [*]   ADV7390/7391 TV Output Encoder -- Uboot parameters for video mode    Output BT656 NTSC data to display port with UVYV frame buffer mode:       "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=UYVY16"    Output BT656 NTSC data to display port with RGB565 frame buffer mode:       "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB565"    Output BT656 PAL data to display port with RGB24 frame buffer mode:       "video=mxcfb0:dev=bt656,BT656-PAL,if=BT656,fbpix=RGB24"    Output CVBS NTSC signal on adv7391 with UYVY frame buffer mode:       "video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16"    Output CVBS PAL signal on adv7391 with RGB565 frame buffer mode:       "video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565" -- Switch between PAL and NTSC    $ echo D:720x480i-60 > /sys/class/graphics/fb0/mode    $ echo D:720x576i-50 > /sys/class/graphics/fb0/mode 4. Note     1) For 8 bits BT656 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_16", it can also        be any other continued display data pins, for example if "DISP0_DAT_7~DISP0_DAT_0" are used, the        macro "BT656_IF_DI_MSB" in "kernel_imx/drivers/mxc/ipu3/ipu_disp.c" should be changed from "23"        to "7".     2) For 16 bits BT1120 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_8", it can also        be any other continued display data pins, the macro "BT656_IF_DI_MSB" should be modified if the        hardware pins are changed.     3) When bt656 interface is the second display for each IPU,1-layer-fb (it can be checked with command        "$ cat /sys/class/graphics/fbx/fsl_disp_propperty"), the frame buffer can only be YUV format. In this        case, the IPU DC channel was used for BT656 display, it has no CSC function, so RGB frame buffer was        not supported. 2013-08-09 updated: The new release package "L3.0.35_1.1.0_GA_bt656_output_patch_2013-08-09.zip" had fixed the BT656 dual display issue on iMX6S/DL. Removed the old release package. 2013-09-04 updated: The new release package "r13.4.1_bt656_output_patch_2013-09-04.zip" had fixed the BT656 dual display issue on iMX6S/DL. For default, the dual display was tested with HDMI + CVBS, HDMI is the main display and adv739x CVBS output is the second display. For iMX6DQ which has two IPUs, please assign dual display to two IPUs, for example adv739x is on IPU1 DI0, it is fixed, because hardware pins used for it is fixed. Then we can assign HDMI or LVDS to another IPU (IPU2). For iMX6S/DL which has only one IPU, since adv739x had used IPU1 DI0, another display should be IPU1 DI1. 2013-09-30 updated: Added patch for L3.0.35_4.1.0_GA BSP, the file is "L3.0.35_4.1.0_GA_bt656_output_patch_2013-09-30.zip". 2014-07-21 updated: Added patch for L3.10.17_1.0.0_GA BSP, the file is "L3.10.17_1.0.0_GA_bt656_output_patch_2014-07-21.zip". 2015-01-26 updated: Updated the IPU microcode for 1080i50 and 1080i60 BT1120 output, the parameters "N" for command BMA is a 8 bits parameters, so its max value is 255, but for 1080i50 and 1080i60 output, it needs more blank data in each line, the "N" will be bigger than 255, the updated IPU microcode can fix this limitation. The updated file is "IPU_Microcode_Update_for_BT1120_1080i_20150126.zip". You can update the macro "DC_MCODE_BT656_xxx"  and function _ipu_dc_setup_bt656_interlaced() to the old patch if you used BT1120 mode to support 1080i display. The verified 1080i display mode is: {    /* 1080I60 Interlaced output */   "BT1120-1080I60", 30, 1920, 1080, 13468,   20, 3,   20, 2,   280, 1,   FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,   FB_VMODE_INTERLACED,   FB_MODE_IS_DETAILED,}, {   /* 1080I50 Interlaced output */   "BT1120-1080I50", 25, 1920, 1080, 13468,   20, 3,   20, 2,   720, 1,   FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,   FB_VMODE_INTERLACED,   FB_MODE_IS_DETAILED,}, 2016-01-28 updated: Updated IPU microcode to align with BT656.4 specification for NTSC output. For other BSP version with NTSC format support, please reference to ipu_disp_update.c for the final microcode. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160128.zip"., Details, please reference to the readme.txt file in the package. 2016-06-24 update: Added BT656 and BT1120 progressive mode support. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160624.zip". Details, please reference to the readme.txt file in the package. The patch for 3.14.52 GA1.1.0 BSP will be released in next week. 2016-06-27 update: Add BT656 and BT1120 display patch for 3.14.52 BSP. File "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27.zip", details, please reference to the readme.txt in the package. 2017-03-10 update: Fixed a hard coding DC macro issue for progressive mode. Added patch "0008-Fixed-a-hard-coding-DC-macro-issue-for-progressive-m.patch" in L3.0.35_4.1.0_GA_bt656_output_patch_2017-03-10.zip. The code in patch "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27" is correct.

Note: All these gstreamer pipelines have been tested using a i.MX6Q board with a kernel version 3.0.35-2026-geaaf30e. Tools: gst-launch gst-inspect FSL Pipeline Examples: GStreamer i.MX6 Decoding GStreamer i.MX6 Encoding GStreamer Transcoding and Scaling GStreamer i.MX6 Multi-Display GStreamer i.MX6 Multi-Overlay GStreamer i.MX6 Camera Streaming GStreamer RTP Streaming Other plugins: GStreamer ffmpeg GStreamer i.MX6 Image Capture GStreamer i.MX6 Image Display Misc: Testing GStreamer Tracing GStreamer Pipelines GStreamer miscellaneous

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 8/8X DDR Tools Overview   This page contains the latest releases for the i.MX 8/8X DDR Tools. The tools described on this page cover the following i.MX 8/8X Family SoCs with the System Controller Unit (SCU): i.MX 8QuadMax and its derivatives i.MX 8QuadPlus i.MX 8QuadXPlus and its derivatives i.MX 8DualXPlus and i.MX 8DualX  i.MX 8DXL (i.MX 8XLite) and its derivatives i.MX 8SXL  NOTE: For the i.MX 8M Family of DDR tools please refer to the : i.MX 8M Family DDR Tool Release                           The purpose of the i.MX 8/8X DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.).  This process equips the user to then proceed with the bring-up of a boot loader and an OS.  Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface.     The i.MX 8/8X DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test   For more details regarding these DDR tools and their usage, refer to the MX8X_DDR_Tools_quickstart_guide.pdf attached to this page.   i.MX 8/8X DDR Register Programming Aid (RPA)   The i.MX 8/8X DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization in two formats (in separate Excel worksheet tabs):   DDR Stress Test script: This format is used specifically with the DDR stress test by first copying the contents in this worksheet tab and then pasting it to a text file, naming the document with the “.ds” file extension. The user will select this file when executing the DDR stress test. DCD CFG file: This format is the configuration file used specifically by the SCU Firmware (SCFW). In this scenario, the user copies the contents in this worksheet tab and pastes it to a text file, naming the document with the “.cfg” file extension and placing this file in the appropriate SCFW board file directory.   i.MX 8/8X DDR Register Programming Aid (RPA): Current Versions Note: In all cases, the RPA revision is aligned to a minimum SCFW version as shown in the table below. In some cases, the BSP alignment is provided as extra detail, however, the RPA tool is specifically aligned to a minimum SCFW version and later. To obtain the latest RPAs, please refer to the following links (note, existing RPAs have been removed from this main page and moved to the SoC specific links below): i.MX8QM: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX8QXP/QXP/DX: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302 i.MX8DXL/SXL: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8DXL-DDR-Register-Programming-Aid-RPA/ta-p/1602262   Processor Mask Revisions Memory Supported Latest RPA Version * Notes i.MX 8QM B0 LPDDR4 Rev 23*** Rev 22** Rev 21** Rev 20** Rev 19** Rev 23: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev22: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 21: Fixed 1 DRC operation to comment out calls to VREF training to DRC1 and added DDRC_SCHED register programming to align with latest SCFW programming (refer to RPA revision history for more details). Rev 20: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 19: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 LPDDR4 Rev 16*** Rev 15** Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 DDR3L Rev 23 Rev 22*** Rev 21 Rev 20 Rev 23:  -Corrected Register Configuration DDR_PHY_PTR4.tDINIT1 bit field programming. Previously, the calculation was based on tRFC only, however, the calculation should have been based on "tRFC+10ns". This was corrected. -Set DDRC_INIT4, DDR3 MR2.ASR=1 as the default setting to allow for the DRAM to select the self refresh rate automatically based on its case temperature (but user has the option to disable via pull-down menu). Also, removed conditional setting for DTCR0.DTRDBITR as it is not needed since DDR3 does not support DBI. Default setting of this was zero and will remain that way. -Provided option to user to select auto refresh rate based on the intended max temperature of the DDR3L device (1X, 2X, 4X). User should confirm with the DDR3L data sheet for supported temperature ranges and associated refresh rate. Rev 22: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 21: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW. -Compatible with SCFW 1.1.10 and later -Changes made to this revision do not affect the DCD CFG file output based on v19 -Issue discovered in the DDR stress test script, wherein certain commands were not being properly configured based on the ECC setting in the Register Configuration worksheet; this was resolved (cells A84, A87, A90, A93 ) -In addition, in both DCD CFG and DDR stress test script worksheets, all commands that depend on ECC config have been updated to include an "OR" with whether or not the data bus is configured for 16-bit (ECC is only supported for full 32-bit data bus width configurations) i.MX 8DualX C0, B0 LPDDR4 Rev 16*** Rev 15* Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8DualX C0, B0 DDR3L Rev 21 Rev 20*** Rev 19 Rev 18 Rev 21: -Corrected Register Configuration DDR_PHY_PTR4.tDINIT1 bit field programming. Previously, the calculation was based on tRFC only, however, the calculation should have been based on "tRFC+10ns". This was corrected. -Set DDRC_INIT4, DDR3 MR2.ASR=1 as the default setting to allow for the DRAM to select the self refresh rate automatically based on its case temperature (but user has the option to disable via pull-down menu). Also, removed conditional setting for DTCR0.DTRDBITR as it is not needed since DDR3 does not support DBI. Default setting of this was zero and will remain that way. -Provided option to user to select auto refresh rate based on the intended max temperature of the DDR3L device (1X, 2X, 4X). User should confirm with the DDR3L data sheet for supported temperature ranges and associated refresh rate. Rev 20: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 19: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  -Compatible with SCFW 1.1.10 and later * For a history of the previous versions of an RPA, refer to the Revision History tab of the respective RPA.  ** In general, it is recommended to use the latest RPA tool even with a pre-released BSP as it ensures you are testing with the latest fixes and features. Older versions of the RPA may be provided to support existing/released versions of the BSP.  This only applies to those RPA tools that are compatible with pre-release BSPs but may not be compatible with released versions of the BSP.   ***IMPORTANT: as stated in the table above, for the noted RPA version, it is aligned to SCFWv1.7.0 (and later SCFW versions).  Older versions of the RPA are not aligned to SCFWv1.7.0 (and later SCFW versions).  If trying to use an older version of an RPA with SCFWv1.7.0 (and later SCFW versions), it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QXP/DualX: DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ For MX8QM: DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 (and later SCFW versions) (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QXP: [remove] ifndef SCFW_DCD [remove] /* For 1200MHz DDR, DRC 600MHz operation */ [remove] DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ [remove] #else <keep code as is> [remove] #endif Note: when it is stated "SCFWv1.7.0 (and later SCFW versions)", it implies SCFWv1.7.0, 1.7.1, 1.7.2... 1.8.0, 1.9.0, 1.10.0... etc., where "..." are minor versions/patches, so when you see 1.7.2... it implies 1.7.3, 1.7.4, etc.).  Unless otherwise noted, the latest RPA shown in the table above is aligned to the latest SCFW release.    i.MX 8/8X DDR Stress Test    The i.MX 8/8X DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational prior to building the SCFW for use with u-boot and OS bring-up. The DDR stress test uses the .ds DDR stress test script generated from the RPA tool along with a special build of the SCFW, built with option: DDR_CON=ddr_stress_test_parser Or in the case of i.MX 8QuadMax use of one DDR Controller: DDR_CON=ddr_stress_test_parser_DRC0_only The DDR stress test offers a Target option to dictate which SoC is under test. The following are Target options to select from: MX8QM – used to test i.MX 8QuadMax and its derivatives i.MX 8QuadPlus MX8QX – used to test i.MX 8QuadXPlus and its derivatives i.MX 8DualXPlus/DualX MX8DXL – used to test i.MX 8DXL and its derivatives i.MX8 SXL     To install the DDR Stress Test, save and extract the zip file mx8_ddr_stress_test_ERxx_installation.zip   (where 'xx' is the current version number) and follow the on-screen installation instructions. Note, when extracting the DDR Stress Test tool .zip file, it is recommended to perform an "Extract here" operation.  Some systems do not allow for the extracted installation executable to run from another folder and will only work when being executed from the same location as the original, downloaded zip file.  For more details on the DDR stress test usage, refer to the MX8_DDR_Tool_User_Guide found in the DDR Stress Test tool delivery. NOTE: Before using the DDR tools on a new custom board, the user should properly port the SCU Firmware (SCFW) to this new board. The DDR tools will not be able to run without a properly ported and working SCFW.            i.MX 8/8X DDR Stress Test Requirements The tool requires access to the Windows registry, hence users must run it in administrator mode. The tool cannot run on an OEM closed device that requires images signed by the customer When users design new i.MX 8/8X boards, please make sure to follow the rules outlined in the respective Hardware Developers Guide and the MX8_DDR_Tool_User_Guide, which can help users bring up DDR devices on their respective i.MX 8/8X boards.   i.MX 8/8X DDR Stress Test SECO Firmware It is generally not recommended to update the SECO (ahab) firmware that comes default with the DDR Stress Test. This is not recommended because the purpose of the DDR Stress Test is to test the DDR memory interface, not the entire SCFW to SECO firmware operation even though a newer version of the SCFW may complain that the SECO firmware version is not the latest. The SECO firmware version that comes with the DDR Stress Test has been tested and proven to work by the factory before the DDR Stress Test release; updating the SECO firmware to a different version may result in unintended consequences rendering the DDR stress test inoperable. In most cases, it is allowable to update only the SCFW without updating the SECO firmware. Should the user wish to update the SECO firmware version in the DDR Stress Test, then they will need to rename this firmware without the silicon version (for example, if updating the MX8QM SECO firmware, the user will need to rename mx8qmb0-ahab-container.img to mx8qm-ahab-container.img, basically remove the “b0”). The exception is for the MX8QXP, if updating the C0 silicon version SECO firmware, then the user should maintain the C0 nomenclature. If the user finds that the updated SECO firmware causes the DDR Stress Test to become inoperable, then it is recommended to revert to the default SECO firmware version that came with the DDR Stress Test release. i.MX 8/8X DDR Stress Test User Guide The i.MX 8/8X DDR Stress Test tool includes the document: MX8_DDR_Tool_User_Guide.pdf NOTE: Please read the MX8_DDR_Tool_User_Guide inside the package carefully before you use this tool.   DDR Stress Test Revision History   Rev Major Changes (Features) NXP BSP Software Version ER 14 Updated to support parsing of the VREF training command in the DDR Stress Test script This version is aligned with NXP BSP GA version L5.4.3_2_0_0 and later. ER15 - Support for i.MX 8Lite (aka DXL) - Provides more verbose output in event of data training failures, specifically on which byte lanes failed - Aids in debug of board layout issues This version is aligned with NXP BSP GA version Linux 5.15.71_2.2.0 and later.    Related Resources Links: i.MX 8ULP DDR tools: i.MX Software and Development Tools | NXP Semiconductors Scroll down to “Other Resources --> Tools --> DDR Tools” i.MX 8M Family DDR Tool Release  i.MX 6/7 DDR Stress test GUI Tool i.MX 8QM RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX 8QXP/DXP/DX RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302 i.MX 8DXL (i.MX 8XLite) RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8DXL-DDR-Register-Programming-Aid-RPA/ta-p/1602262   FAQs: Q. When the DDR stress test is running, it indicates testing region 1 and then region 2. What is region 1 and region 2? A. There are two distinct DDR memory regions in the i.MX8X series which is due to the architecture of Cortex A core and the associated memory map of the i.MX8X. Region 1 is the 32-bit region, starting at 0x080000000 and ending at 0x0FFFFFFFF (2GB total) Region 2 is the 64-bit region (for the Cortex A core architecture), starting at 0x880000000 and ends at the remaining density: • For 4GB total on board density, 2GB for region 1 and 2GB for region 2, so region 2 will end at 0x8FFFFFFFF (0x900000000 minus 1) • For 6GB total (NXP board density), 2GB for region 1 and 4GB for region 2, so region 2 will end at 0x97FFFFFFF (0x980000000 minus 1) • For 8GB total, 2GB for region 1 and 6GB for region 2, so region 2 will end at 0x9FFFFFFFF (0xA00000000 minus 1) Hence there is a “hole” in the memory map between region 1 and region 2. As such, the DDR stress test first tests the lower region (region 1) until it is exhausted (up to 2GB), and if the DDR density exceeds 2GB, the test will test the remaining density in region 2. Q. Do the i.MX8X series SoCs support LPDDR4 memories with 17 row addresses (R[16:0])? A. The i.MX8QM, i.MX8QXP, and i.MX8DXP SoCs and their derivatives cannot support newer 17-row-address LPDDR4 memories. This means, in order to support the maximum 4GB (32Gb) LPDDR4 density, the configuration must be 16-row, 2 rank (as opposed to the unsupported 17-row, 1 rank). The upcoming i.MX8DXL is planned to support 17-row address LPDDR4 devices. Q. I can select a different i.MX8X AP UART port when running the DDR Stress Test? A. It is highly recommended to follow NXP board designs including selecting the same UART ports; this eases the user’s software porting efforts and minimizes issues with needless debugging. The DDR Stress Test requires the use of the USB OTG port and the AP UART port (and it is highly recommended to connect the SCFW UART port for SCFW debug messages). To date, the factory sees no reason why the user would need to select a different AP UART port than what is used on NXP boards. Selecting the same AP UART port ensures a faster bring up of the DDR stress test rather than needlessly debugging why a different UART port is not working. In any event, some wish to use a different UART port for whatever reason, as such, NXP has placed work arounds to allow the selection of a different UART port. To select a different UART port (0,1, or 2), the user simply needs to add the following line to the end of the DDR Stress Test DDR initialization (.ds) script: memory set  0x5C01042C 32   <UART port value> memory set  0x5C01042C 32   0x00000000   # UART0 port selection for AP UART (default) memory set  0x5C01042C 32   0x00000001   # UART1 port selection for AP UART memory set  0x5C01042C 32   0x00000002   # UART2 port selection for AP UART Note that UART ports 0, 1, and 2 have pad names that are default UART pins (IOMUX ALT0 config). To date, the DDR tools do not support other UART ports that are mux’d out on other non-default UART pins. However, there is an exception for i.MX8QXP/DXP and the upcoming i.MX8DXL where UART3 mux’d out on FLEXCAN2 can be used. To select this, add the following to the end of the .ds file: memory set  0x5C01042C 32   0x00000003   # UART3 port selection for AP UART (exception for i.MX8QXP/DXP and i.MX8DXL) Some RPAs do have support built in (via a pull down menu) to select the UART port. For those RPAs that do not have this feature, this is due to the fact that these RPA (NXP boards) were not tested with a different UART port as the board requires cutting traces and re-wiring the UART signals and some boards may not have these UART traces readily available. However, the user is still able to manually add this UART port selection. Refer to the following RPAs to see the UART port select option: MX8QXP DDR3 MX8DXP DDR3 Q. Why does the DDR stress test appear to hang when testing [MX8QM with 8GB (64Gb) or MX8QXP with 4GB (32Gb)] of LPDDR4 memory? A. The issue is not caused by the DDR stress test itself but by the version of the SCFW being used. The default version of the SCFW binary pre-dates a change made by the SCFW to ignore DRAM density limitations when it detects that the DDR stress test is running. This version of the SCFW associated with the DDR stress test ER14 limits the testable DRAM density to [MX8QM: 6GB, MX8QXP: 3GB], as this version of the SCFW is configured to operate on NXP boards as a basis. As noted in the DDR stress test user guide, it is recommended for users to port the latest SCFW to their board first before using the DDR stress test to account for board differences between NXP’s board and their board.  In addition, the user has the following options to enable testing beyond [MX8QM: 6GB, MX8QXP: 3GB]; note it is the responsibility of the user to ensure a properly working, ported version of the SCFW prior to operating the DDR stress test. 1. The latest SCFW should contain an update that sets no density limit if it is detected that the SCFW is built for usage with the DDR Tool - the user can try to get the latest porting kit and build the new firmware.  This is the recommended change. 2. In board.c, function board_system_config(), there is this chunk of code (MX8QM example shown) if using an existing/older SCFW that pre-dates this change: /* Board has 6GB memory so fragment upper region and retain 4GB */         BRD_ERR(rm_memreg_frag(pt_boot, &mr_temp, 0x980000000ULL,             0xFFFFFFFFFULL)); User can modify it as follows:     if (ddrtest == SC_FALSE)     {         sc_rm_mr_t mr_temp;         /* Board has 6GB memory so fragment upper region and retain 4GB */         BRD_ERR(rm_memreg_frag(pt_boot, &mr_temp, 0x980000000ULL,             0xFFFFFFFFFULL));         BRD_ERR(rm_memreg_free(pt_boot, mr_temp));     } This is disables execution of this section of code if the SCFW is built for the DDR Tool (the same as 1. but needs to be done by the user manually when using an earlier firmware version). 3. Change 0x980000000 to 0xA00000000 in the above chunk of code. That should allow for 8GB density for MX8QM example shown above (for MX8QXP, change 0x8C0000000ULL to 0x900000000ULL for 4GB density).  

Graphics are a big topic in the Android platform, containing java/jni graphic framework and 2d/3d graphic engines (skia, OpenGL-ES, renderscript). This document describes the general Android graphic stack and UI features on Freescale devices. 1. Android Graphic Stacks All Android 3D apps and games have the following graphic stack: Android system UI and all Apps UI follow 2D graphic stack as below, the hardware render will accelerate Android 2D UI with GPU HW OpenGL-ES 2.0 to improve the whole UI performance. Hardware acceleration can be disabled on i.mx6 in device/fsl/imx6/soc/imx6dq.mk USE_OPENGL_RENDERER := false Then rebuild frameworks/base/core/jni, and replace libandroid_runtime.so Surfaceflinger is responsible of all surface layers composition, and  then generate the framebuffer pixmap for display devices. these graphic surface layers are from 2D/3D apps. Hwcomposer is the alternative module of Surfaceflinger with OpenGL-ES. Hwcomposer is used to combine the specific surface layers supported by specific vendor devices. Freescale i.MX6 devices use GPU 2D to combine most surface layers, and the system power can be reduced with GPU 2D instead of GPU 3D. The typical power saving case is video playback. Hwcomposer with GPU 2D can offload GPU 3D task when running game and benchmarks, it is proved to improve the overall system performance about 20%. 2. Performance measurment Show FPS for Android system performance For NFS boot you can set “debug.sf.showfps” to 1 in init.freescale.rc (“setprop debug.sf.showfps 1”) and then reboot the system. For SD or EMMC boot, you can issue command “setprop debug.sf.showfps 1” in console, then find system_server thread by top and kill it to reset the system. Graphic benchmarks for 3D capability measurement Quadrant Full test benchmark cover CPU, Memory, IO, 2D and 3D GLBenchmark http://www.glbenchmark.com/ NenaMark2 https://market.android.com/details?id=se.nena.nenamark2 An3DBench http://www.androidzoom.com/android_applications/tools/an3dbench_hnog.html AnTutu http://www.antutu.com/software.html 3DMark http://www.futuremark.com/benchmarks/3dmark06/introduction/ Browser benchmarks http://www.webkit.org/perf/sunspider/sunspider.html http://v8.googlecode.com/svn/data/benchmarks/current/run.html http://www.craftymind.com/guimark2/ http://www.craftymind.com/factory/guimark/GUIMark_HTML4.html http://themaninblue.com/writing/perspective/2010/03/22/ 3.  Android UI features Dual display with same content This feature is supported in the default image in Android i.MX 6 release package. In this feature, LVDS panel and HDMI output can be supported simultaneously. It is only enabled when the HDMI TV has been connected with the board. Overscan for TV devices Some TVs may miss display the contents in overscan area. To avoid the contents in overscan area being lost, the common implement is by underscanning with an adjustable black border and letitng the viewer adjust the width of the black border. The downscan operation is done by surfaceflinger when it does surface composition through HW OpenGL ES. There is no performance impact since all the work is done by GPU HW. Overscan can be configured in display setting in visual mode: 32 bits color depth 32bpp UI can be supported by adding “bpp=32” in uboot as below: setenv bootargs ‘… video=mxcdi1fb:RGB666,XGA,bpp=32 …’, also can configure it in display setting. Enable 32bpp frame buffer and application surface buffer will be allocate to RGBA8888 format instead of default RGB565 format, that means more system memory is allocated. After enabling 32bpp, if some applications still don't have better UI quality, check to see if  there is hard code to request RGB565 format surface (should request RGBA8888 format to get better quality). Sample code is attached to test for 32bpp (left is on 16bpp, right is on 32bpp) Display Visual Setting The display setting is the add-on feature in FSL Android release, it is very convenient for end-users to change display property, mostly for the following features: Dual display enablement Display color depth setting(16bpp, 32bpp) Overscan adjustment in horizontal and vertical orientation 4. Issue Diagnosis Application Compatibility Some Android applications may not run correctly on some Android releases. It may cause application compatibility, so check the application in other platforms. For example Neocore and Asphalt 5 can run on Eclair, Froyo, and Gingerbread, but will not correctly run on Honeycomb. GPU Compatibility Some game UIs may not correctly display on our Android release. When encountering this kind of issue, the customer can check whether it is caused by the game using an OpenGL extension which our GPU does not support. They can download another data package (for example not extension data package) to have a check. Others Enlarge GPU memory if you encounter UI abnormally displaying after running an application for a while. Some applications need Wifi connections, so monitor the console log to see whether there are any error reports.

This document intends to provide an overview of the i.MX8 Boot process and walk you through the process of creating a bootable image.   Boot process Coming out of a reset state the i.MX8 ROM (firmware that is stored in non-volatile memory of the i.MX8) reads the boot mode pins to determine the boot media/device that will be used. The i.MX8 can boot out of the following boot devices: eMMC/SD card FlexSPI Flash NAND Serial Download Protocol (USB) - This is used in manufacturing mode to bring-up a board by downloading an image to RAM and then flashing the on-board boot device.   The following table indicates the available options on a i.MX8QXP, the i.MX8 reads the boot mode pads and based in the configuration selects the desired boot device.   Once the boot device has been identified, ROM configures the boot media and attempts to read the image from a predefined address in the boot device, the following table shows the addresses where the image is expected to be on different boot devices. ROM loads data from the predefined addresses above (depending on the selected boot device) to the System Controller Unit (SCU) internal memory (tightly coupled memory) and parses it to find the image container. It can also boot by downloading an image through USB.   The image container has all the information needed to load all the images to the system, the first images that get loaded are the System Controller Firmware (SCFW) and Security Controller Firmware (SECO). The SECO FW needs to be loaded to refresh the watchdog timer (kick the dog) in the device, if the SECO FW is not loaded before the watchdog expires the device will reset, this usually happens when the device fails to fetch a valid image from the boot media.   Once the SCFW is loaded, ROM jumps to it and starts executing it. The SCFW then initializes the DDR and starts loading the images for the Cortex-M4 (optional) and the Cortex-A cores (optional). Once the images are loaded to their destination memory the SCFW boots the cores and sets them in their start address.   Creating a bootable image As a recap a bootable image is comprised of as minimum the System Controller Firmware and the Security Controller Firmware, optionally it can contain images for the Cortex M4 cores (if more than one available as in the case of QM devices) and Cortex A cores. It is possible to boot an image that only contains the SCFW and SECO FW, this could be useful in the first stages of porting the SCFW to the target board. It is also possible to boot an image with only the Cortex-M4 image (baremetal, FreeRTOS, AutoSAR...), only the Cortex-A image (U-boot or any bootloader) or both Cortex-M4 and Cortex-A images.   Mkimage tool The tool in charge of merging all these images and creating a bootable image for the i.MX8 is called mkimage, and can be obtained in source form in the following repository: https://github.com/nxp-imx/imx-mkimage mkimage is only supported in Linux So the first step is to clone the mkimage repository into our machine and checkout the latest branch, at the time of writing this document the latest release is 4.14.98_02: git clone https://source.codeaurora.org/external/imx/imx-mkimage cd imx-mkimage git checkout imx_4.14.98_2.0.0_ga‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You should now be able to see the following folders:   Getting the SCFW Now that you have the mkimage tool you need some actual images to work with, if you are using a custom board you might need to port the SCFW and DDR configuration files for it (depending on how close it follows NXP's reference board).   The following is a compendium of documents on the basics of the SCFW and how to build it from scratch you can go there if you need help getting started with the porting process: https://community.nxp.com/docs/DOC-342654   If you are trying this on one of NXP's reference board you can use a pre-built SCFW binary, this can be obtained through the building process of the Yocto project or by downloading the porting kit and following these steps: Dowload SCFW binaries for release 4.14.98_02 here. chmod a+x imx-sc-firmware-1.2.bin ./imx-sc-firmware-1.2.bin‍‍‍‍‍‍‍‍‍‍ You will prompted to accept a license agreement and after that the binaries will be extracted:   Getting the SECO FW The Security Controller Firmware is only distributed in binary form and can be obtained from the NXP website. Download SECO FW binaries for release 4.14.98_02 here. chmod a+x firmware-imx-8.1.bin ./firmware-imx-8.1.bin‍‍‍‍‍‍‍‍‍‍ You will prompted to accept a license agreement and after that the binaries will be extracted: The SECO FW is under firmware/seco mx8qm-ahab-container.img -----> SECO FW for QM devices mx8qx-ahab-container.img ------> SECO FW for QXP devices   Getting an image for the Cortex-M4 The image for the Cortex-M4 can be generated using the SDK: https://mcuxpresso.nxp.com/en/select Just select the device you are working with and click Build MCUXpresso SDK, then you will prompted to select your IDE and host. Click on Download SDK and a compressed file containing the SDK will be dowloaded to your computer. Now you only need to uncompress the file and follow the steps in the getting started document to generate the image.  The getting started document includes steps to setup the toolchain and build an image for the M4. An M4 binary for the QM and QXP MEKs is also attached in this document, the example outputs a hello world message on the M4 terminal. Getting an image for the Cortex-A  The bootloader for the Cortex-A cores can be obtained through the Yocto BSP: The steps on generating the image for the 4.14.98 release can be found here: https://www.nxp.com/webapp/Download?colCode=imx-yocto-L4.14.98_2.0.0_ga    Some more details on the Yocto BSP can be found here: https://community.nxp.com/docs/DOC-94849   All the required binaries to create a bootable image for the Cortex-A cores on the MEK platforms are attached here.   Building a bootable image Once all the required pieces have been built/obtained, the bootable image can be created. The SCFW, SECO FW and respective Cortex-M4/A images need to be copied to the folder for the target device, i.e. if you are building an image for an i.MX8QX variant copy the binaries for that variant to its folder:   Here is a list of the required files to build a bootable image: scfw_tcm.bin -------------------------------------------- System Controller Firmware binary for the target board mx8qm(qx)-ahab-container.image ---------------- Security Controller Firmware for the QM or QXP variants bl31.bin --------------------------------------------------- ARM Trusted Firmware binary (Required if using u-boot with ATF) Only needed to create Cortex-A image with u-boot u-boot.bin ------------------------------------------------ U-boot binary (optional) m4_image ----------------------------------------------- M4 binary image, the QM variant has 2 Cortex-M4s and in this case to M4 binaries might be required (optional)   Once the required binaries have been copied to the desired variant folder (QXP or QM in this example), you are ready to start building some images.   All the targets for building different images are defined on the soc.mak file contained in each folder, this file contains different examples for creating a lot of the supported bootable images.   Creating a SCFW only image The target used to create a SCFW only image is flash_b0_scfw and it is defined under the soc.mak file of each variant. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0_scfw‍‍‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_b0_scfw‍‍‍   The target definition for flash_b0_scfw can be seen below. Definition for QXP: flash_scfw flash_b0_scfw: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin ./$(MKIMG) -soc QX -rev B0 -dcd skip -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -out flash.bin ‍‍‍‍‍‍‍‍ Definition for QM: flash_b0_scfw: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -out flash.bin‍‍‍‍‍‍   Creating a Cortex-A image only The target used to create a Cortex-A image only is called flash_b0. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0 ‍‍‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_b0‍ ‍‍‍ The target definition for flash_b0 can be seen below. Definition for QXP:   flash flash_b0: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin u-boot-atf.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -ap u-boot-atf.bin a35 0x80000000 -out flash.bin‍‍‍‍ Definition for QM:   flash_b0: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin u-boot-atf.bin ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -out flash.bin‍‍‍‍   Creating a Cortex-M4 image only The target used to create a Cortex-m4 image only is called flash_b0_cm4 on QXP and QM has different targets since there are two M4s available in the system. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0_cm4‍‍ To invoke this target for QM from the imx-mkimage directory: // For Cortex-M4_0 only make SOC=iMX8QM flash_b0‍_cm4‍_0 // For Cortex-M4_1 only make SOC=iMX8QM flash_b0‍_cm4‍_1 // For both Cortex-M4_0 and Cortex-M4_1 make SOC=iMX8QM flash_b0‍_m4‍s_tcm ‍‍‍‍‍‍‍‍‍‍‍‍‍   The target definition for flash_b0_cm4 can be seen below. Definition for QXP: flash_cm4 flash_b0_cm4: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin‍‍‍‍ Definitions for QM: flash_b0_cm4_0: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin flash_b0_cm4_1: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 1 0x38FE0000 -out flash.bin flash_b0_m4s_tcm: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m40_tcm.bin m41_tcm.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m40_tcm.bin 0 0x34FE0000 -m4 m41_tcm.bin 1 0x38FE0000 -out flash.bin‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   The examples above are for M4 images booting from TCM, the M4 is capable of booting and executing from DDR and it is also able to XIP (execute in place) from SPI memory, for examples on this targets please look at the soc.mak for the desired variant. Creating an image with both Cortex-A and Cortex-M4 images The target used to create an image with software for all the cores is called flash_linux_m4. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_linux_m4‍ ‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_linux_m4‍ ‍ The target definition for flash_linux_m4 can be seen below. Definition for QXP: flash_linux_m4: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin u-boot-atf.bin m4_image.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a35 0x80000000 -p3 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin‍‍   Definition for QM: flash_linux_m4: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin u-boot-atf.bin m4_0_image.bin m4_1_image.bin ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -p3 -m4 m4_0_image.bin 0 0x34FE0000 -p4 -m4 m4_1_image.bin 1 0x38FE0000 -out flash.bin‍‍     Flash image This will create a bootable image named flash.bin, to flash this image to the SD card and boot it on your MEK simply do: sudo dd if=iMX8QX/flash.bin of=/dev/mmcblkX bs=1k seek=32‍‍‍‍‍‍‍ If the desired target is a QM variant change if=iMX8QX... to if=iMX8QM. Then match your SD card device on "of=/dev/mmcblkX" you can see how your SD card enumerates by typing lsblk on your console before and after inserting your SD card. Remember from the information above that the i.MX8 will search for the image at 32k on the SD card, that is why we are flashing it there. For more examples please look at the soc.mak file, it includes examples for different boot media (NAND/QSPI) as well as different configurations and usage.   Additional resources Reference Manual Chapter 5 System Boot SCFW API and Port document imx-mkimage README System Controller Firmware 101 

System Memory Usage and Configuration Introduction This document describes i.MX android memory usage, layout and configuration for the entire system. Total DDR memory usage When i.MX Android is running, the DDR memory will be used by the following components: Linux Kernel reserved space, including: kernel text, data section and initrd kernel page tables       Normal zone space managed by kernel’s MM (high memory zone is also included) Used by application by brk() or malloc() in libc Used by kernel by mm api, like: kmalloc, dma_alloc, vmalloc       Reserved memory for GPU drivers, used by GPU libs, drivers Android surface view, normal surface buffers VPUs working buffer and bitstream (we allocate the VPU buffer from GPU driver to make a unify method of allocation) Reserved space for framebuffer BG triple buffers Framebuffer display are always required to have triple and large buffers       Memory layout The following diagram shows the default memory usage and layout on i.MX6Q/DL platform. Memory configuration According to different type of product and different hardware configurations (ddr size, screen resolution, camera), customer may do some configurations to the memory layout and usage to optimize their system. Some memory reservation can be configured by command line or modifying the code. The kernel reserved space cannot be adjusted. It is controlled by the kernel and the Normal zone size and it depends on the total DDR size and the reserved spaces. Reserved GPU memory size can be adjusted by adding "gpumem=" parameters in kernel commandline. It's size is highly depends on the screen resolution, the video stream decoding requirement and the camera resolution, fps. gpumem=<size>M Reserved memory size for BG (background) framebuffer can be configured by command line fbmem=<fb0 size>,<fb2 size>,<fb4 size>,<fb5 size> For example: If you have two display devices, one is XGA LVDS, the other is HDMI 1080p device (default 32bpp), you have to specify the BG buffer size for them: fbmem=10M,24M The size is calculated by xres*yres*bpp*3: 10M ~= 1024x768x4(32bpp)x3(triple buffer) 24M ~= 1920x1080x4(32bpp)x3(triple buffer)