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.   These are the detailed programming aids for the registers associated with DRAM initialization (DDR3 and LPDDR2) of the MX6DQP (also known as Rev 2 or Dual/Quad Plus), and covers the Sabre_SD boards and DDR3 based Auto Infotainment board. The last work sheet tab in the tool formats the register settings for use with the ARM RealView debugger (.inc) and the DDR Stress Test. It can be manually converted, by the user, to the DS5 .ds format or to a DCD file format used by uboot or other. The programming aids were developed based on NXP development boards and can be customized by the user for their board design. This tool serves as an aid to assist with programming the DDR interface of the MX6DQP and is based on the DDR initialization scripts developed by the R&D team and no guarantees are made by this tool. The following are some general notes regarding this tool: • Refer to the "How To Use" tab in the tool as a starting point to use this tool. • This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance. • The MX6DQP adds a new third party IP called the NoC. The programming for these registers are automatically updated in the tool given a set of user input MMDC parameters and should not be modified manually.

Here are two patchs: Patch 1: 0001-I.MX6-SSI_ASRC_P2P_Capture-for-SabreSD-board-Kernel-.patch Patch 2: 0001-I.MX6-SSI_ASRC_P2P-Capture-for-SebreSD-board.patch Patch 1 is based on patch 2.     memory <-- ASRC_Output FIFO | ASRC_Input FIFO <-- SSI_RX FIFO <-- Audio Codec                                              |           |     ASRC Out clk ASRCK1 <---|           |--->   ASRC In clk None                                              |           |     ASRC OutPut width            |           |       ASRC InPut width and data format     is set by arecord            <---|           |--->   is set by ASRC P2P parameter     parameter                          |           |                                             |           |     support 44100/48000          |           |       support 44100/48000     and S24_LE/S16_LE     <---|           |--->   and S24_LE/S16_LE    You can use:     arecord -Dhw:0,1 -c 2 -f S16_LE/S24_LE -r 44100/48000 XXX.wav     aplay XXX.wav     to test this patch.

NFS After LTIB installation, follow the instructions below to configure and build Linux Image and Root File System. TIP: Type: $./ltib --help to get more information on ltib In the folder where LTIB were installed, execute the file: $./ltib It should take some minutes to complete the installation. Configure the ltib to select the options and packages to be defined and installed in Linux Image and Root File System. $./ltib -c     or     $./ltib -m config The menu configuration should appear: To configure for use the system with NFS, go to: Target Image Generation -> Target Image -> NFS Only For basic compilation, exit LTIB. It will compile and add some pre-built packages to make the target file system.

    Attached is the SDHC DMA read supported patch, it is based on WCE600_MX51_ER_1104, it was verified on iMX51 EVK board. The SDHC DMA read can reduce the NK copy time, in this way it can speed up the WinCE boot.

Video Unit Test The BSP provides a package that allows testing of several i.MX 31 peripherals on the PDK. The name of this package is 'imx-test'.   The name of the package may vary according to SDK release, at the time of the writing SDK 1.4 was used, on SDK 1.2 the name of a similar package was 'mxc-misc'   For more information on the imx-test package refer to the SDK 1.4 manual, imx31_Linux_RM.pdf, chapter 49 - Unit Tests. This file is available on BSP tarball Testing To test the image sensor and the display on the PDK follow the steps below: Enable imx-test and util-linux packages: $ ./ltib -c Once "ltib" finishes boot the system. On the target board: $ modprobe mxc_v4l2_capture Check if /dev/video0 was created $ ll /dev/video* lrwxrwxrwx  1 root root            6 Jan 1 20:47 /dev/video -> video0 crw-rw----     1 root root    81,   0 Jan 1 20:47 /dev/video0 crw-rw----     1 root root    81, 16 Jan 1 20:46 /dev/video16 Now run the unit tests: $./mxc_v4l2_overlay.out -iw 640 -ih 480 -ow 480 -oh 640 -r 4 -fr 30 -t 10 - capture images with the sensor and display on the LCD $./mxc_v4l2_capture.out -w 640 -h 480 -r 0 -c 150 -fr 30 test3.yuv - capture images and save on /unit-tests/test3.yuv $./mxc_v4l2_output.out -iw 640 -ih 480 -ow 480 -oh 640 -d 4 -fr 60 test3.yuv - capture images and save on /unit-tests/test3.yuv   For usage syntax type: command -help. ./mxc_v4l2_output.out -help Source Code If you want to check the source code, on the host machine "ltib" install path type: $./ltib -m prep -p imx-tests Then, go to <ltib install path>/rpm/BUILD/imx-test-2.3.2/test/mxc_v4l2_test

MX6X_DDR3_调校_应用手册_V4_20150730.doc

Introduction i.MX25 PDK Board Get Started Bootloader i.MX25 PDK Board Flashing NAND i.MX25 PDK Board Flashing SD Card i.MX25 PDK Board Flashing SPI NOR I.MX25 PDK U-boot SDCard I.MX25 PDK U-boot SplashScreen I.MX25 PDK Using FEC

This steps are basically the same used to boot Linux mainline on i.MX 31 ADS, just replacing Network Driver cs89x0 by i.MX 27 internal FEC. Download Linux kernel 2.6.30: $ wget -c http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2 Extract this: $ tar jxvf linux-2.6.30.tar.bz2 Export CROSS_COMPILE environmet: $ export PATH="$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/" $ export CROSS_COMPILE=arm-none-linux-gnueabi- Unselect all no essentials features: $ make ARCH=arm allnoconfig Start the configuration menu: $ make ARCH=arm menuconfig Change/Select the kernel options below. Select the MXC/iMX platform and iMX27ADS board: System Type ->             ARM system type -> (X) Freescale MXC/iMX-based             Freescale MXC Implementations  ->                            MXC/iMX Base Type -> (X) MX2-based                            MX2 Options  -> [*] Support MX27ADS platforms (NEW) Select ARM EABI standard to compile the kernel: Kernel Features  --->           [*] Use the ARM EABI to compile the kernel Add support to Linux Binary Format ELF: Userspace binary formats ->              [*] Kernel support for ELF binaries Add support to Network (TCP/IP): [*] Networking support  ->          Networking options  ->                           [*] Packet socket                           [*] Unix domain sockets                           [*] PF_KEY sockets                           [*] TCP/IP networking                                    [*] IP: kernel level autoconfiguration                                    [*]     IP: DHCP support Select network driver (FEC), serial driver and unselect VGA console: Device Drivers  ->                      [*] Network device support  --->                                       [*]   Ethernet (10 or 100Mbit)  --->                                              [*]   FEC ethernet controller (of ColdFire CPUs)                      Character devices  ->                              Serial drivers  --->                                       [*] IMX serial port support                                       [*]   Console on IMX serial port                      Graphics support  ->                              Console display driver support  --->                                         [ ] VGA text console Add support to NFS and support to use it as root file system: File systems  ->                           [*] Network File Systems (NEW)  ->                                    [*]   NFS client support                                    [*]     Root file system on NFS Compile the kernel: $ make ARCH=arm Copy the created zImage to tftp directory: $ cp arch/arm/boot/zImage /tftpboot/ Configure your RedBoot to boots with this kernel: load -r -b 0x100000 /tftpboot/zImage exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.240.191:/tftpboot/rootfs ip=dhcp" Change the default network device on RedBoot to internal FEC: Default network device: mxc_fec Connect the network cable on FEC connector (connector T3). Notes: We are using rootfs from LTIB then select to get parameters from DHCP: "Target System Configuration" Options  --->               [*] start networking                      Network setup  --->                            [*]   get network parameters using dhcp

One of the important features that differentiates Xenomai from other real-time Linux extensions is its ability to offer hard real-time support to user-space applications. Ease of use of the user-space programming model should outweigh any gain one could expect from running the application directly from kernel space. User-space applications are memory protected from other processes, thus cannot crash the kernel should something goes wrong. Xenomai also provides generic building blocks for building different RTOS interfaces called skins, These skins imitates the different RTOS APIs thus allowing easy porting of existing applications to Xenomai. Required software 1. The current BSP version for iMX6 from Freescale is 3.0.35 does not fully work with the latest version Xenomai because the accompanying I-pipe patch does not support SMP. To use the latest I-pipe patch, a newer Linux kernel is need. Grab the latest stable kernel:   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git   $ cd ~/linux-stable   $ git branch -a   $ git checkout remotes/origin/linux-3.8.y -b linux-3.8.y   $ git checkout v3.8.1 -v v3.8.1 2. Configure the kernel. Make sure the kernel is built without any errors before patching it with Xenomai.   $ export ARCH=arm   $ export CROSS-COMPILE=arm-fsl-linux-gnueabi- $ make imx_v6_v7_defconfig $ make -j16 uImage 3. Note that this is a device-tree enabled kernel. You'll also need to generate the flattened device tree that U-Boot will pass to the kernel.   $ make imx6q-sabrelite.dtb 4. This step is not needed if your U-Boot supports device-tree kernel. Grab the latest U-Boot: $ git clone git://git.denx.de/u-boot.git $ cd u-boot/ $ make mx6qsabrelite_config $ make -j16 5. The boot script will need to updated to load the device-tree into memory and pass it to the bootm command.   U-Boot > setenv bootcmd 'fatload mmc 1 0x22000000 uImage; fatload mmc   1 0x11000000       imx6q-sabrelite.dtb; bo otm 0x22000000 – 0x11000000' 6. Grab the latest I-pipe patch from Adeos    $ wget http://download.gna.org/adeos/patches/v3.x/arm/ipipe-core-3.8-   arm-1.patch 7. Grab the latest Xenomai    $ wget http://www.xenomai.org/index.php/Xenomai:News#2013-10-           05_Xenomai_2.6.3   $ tar -xvjf xenomai-2.6.3.tar.bz2 Patching the kernel 1. Prepare the target kernel. This is to assume that the Linux kernel and I-pipe patch are located relatively to Xenomai.   $ cd xenomai-2.6.3   $ ./scripts/prepare-kernel.sh --linux=../linux-stable/ --adeos=../linux-stable/ipipe-core-3.8-arm-1.patch –arch=ARM   $ ./configure CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --host=arm-fsl-linux-gnueabi 2. Build and installation   $ make -j8   $ sudo root   $ export PATH=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/:$PATH   $ make DESTDIR=~/BSP/ltib/rootfs install    Testing the installation 1. Verifying the kernel. If everything works, the kernel boot logs should messages like:    I-pipe: head domain Xenomai registered.   Xenomai: hal/arm started.   Xenomai: scheduling class idle registered.   Xenomai: scheduling class rt registered.   Xenomai: real-time nucleus v2.6.2.1 (Day At The Beach) loaded.   Xenomai: debug mode enabled.   Xenomai: starting native API services.   Xenomai: starting POSIX services.   Xenomai: starting RTDM services. 2. Comparison of Xenomai and unpatched Linux kernel real-time performance. We ran a couple benchmarks on a Freescale I.MX6q Sabrelite board to do the comparison. The tests used default configurations and fully stressed the system in order to measure scheduling jitter.                               Linux   Kernel     Zero load     100% loaded     Average latency   (us)     Worst-case   latency (us)     Average latency   (us)     Worst-case   latency (us)     Standard     4.625       41.311     5.120     1849.91   Patched with   Xenomai     4.825       15.568     6.654     16.655 The tests measure the jitter relative to expected time on a periodic task running every 1 millisecond. Data show the Xenomai implementations stand out for having by far the smallest difference between light and full load in the worst case. Stock Linux fare much worse as the timers miss a lot wake ups.

Most i.MX8QXP/QM customers already work on L4.14.98 GA for their Auto product, like C-V2X TBOX, Car infortainment system. Some customers also want to adopt OP-TEE in their security design, but OP-TEE on i.MX8QXP/QM platform don't support HW cryptography accelerating which base on CAAM module. So I worked on the issue last week and fixed it. The package meta-optee-add-on_4.14.98_2.0.0_ga.tgz is Yocto layer which includes all patches for fixing the issue. Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga HW platform:  i.MX8QM/QXP MEK. How to build: 1, decompress meta-optee-add-on_4.14.98_2.0.0_ga.tgz and copy meta-optee-add-on to folder (Yocto 4.14.98_2.0.0_ga dir)/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-optee and add BBLAYERS += " ${BSPDIR}/sources/meta-optee-add-on " into (Yocto 4.14.98_2.0.0_ga dir)/build-optee/conf/bblayers.conf  3, Run bitbake fsl-image-validation-imx. 4, You can run xtest or xtest -l 1 4007 on your MEK board to test optee crypto feature after completing build image. You can find it only take about one second comparing no CAAM accelerating when test "regression_4007.11 Generate RSA-2048 key".

This document provide an overall guide how to get started with i.MX6 development. There are several chapters: 1. how to get necessary docs from freescale website; 2. how to setup environment and build your own images;3. Hardware design consideration;4. How to get help. I hope the doc will bring you in i.MX world more easily, and hope you all have a fun in it.

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)

This is the procedure and patch to set up Ubuntu 13.10 64bit Linux Host PC and building i.MX6x L3.0.35_4.1.0. It has been tested to build GNOME profile and with FSL Standard MM Codec for i.MX6Q SDB board. A) Basic Requirement: Set up the Linux Host PC using ubuntu-13.10-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 $ sudo apt-get install libc6-dev-i386 $ sudo apt-get install u-boot-tools $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd $ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so   /usr/lib/librt.so C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L3.0.35_4.1.0_130816_source. tar.gz $ ./L3.0.35_4.1.0_130816_source/install      After that, you will find ~/ltib directory created D) Apply the patch to make L3.0.35_4.1.0 could be installed and compiled on Ubuntu 13.10 64bit OS $ cd ~/ltib $ git apply 0001_make_L3.0.35_4.1.0_compile_on_Ubuntu_13.10_64bit_OS.patch What the patch is doing: a) The patch modifies the following files:    dist/lfs-5.1/base_libs/base_libs.spec    dist/lfs-5.1/m4/m4.spec    dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory:    pkgs/m4-1.4.16-1383761043.patch    pkgs/m4-1.4.16-1383761043.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L3.0.35_4.1.0_130816_docs/doc/mx6/Setting_Up_LTIB_host.pdf https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 m4 compilation issue: 1. https://github.com/hashdist/hashstack/commit/f6be2a58de62327d05e052d89c9aa931d4c926b3 2. https://github.com/hashdist/hashstack/issues/81 rpm-fs package failed to build issue: https://community.freescale.com/message/355771#355771 scrollkeeper is for the gnome-desktop compilation NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

The i.MX 6 Android 13.4.1.03 patch release is now available on www.freescale.com IMX6_R13.4103_ANDROID_LDO_PATCH This patch release is based on the i.MX6 Android R13.4.1 release. The purpose of this patch release is to manage the LDO and PMIC ramp-up time correctly.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343715 

The Compatibility Test Suite Verifier is a supplement to the Compatibility Test Suite. The main difference lies in that the verifier is developed for tests that cannot run on their own so they require user input in order to be tested. These tests would include the audio quality, the touchscreen, accelerometer, camera, etc. There is no “best verifier option”, one CTS complements the other. In this document we will focus on how to perform the Verifier test. Requirements: A PC with the Android SDK installed. Your “Device Under Test” (your development board) Optional >> A second android device with compatible Wifi and Bluetooth Setup Steps: Install de Android SDK on your PC Download the appropriate CTS Verifier APK. The list of APK’s can be found here: https://source.android.com/compatibility/downloads.html Make sure that your Device Under Test has its system date and time set correctly. Install the CTS Verifier APK on the Device Under Test* For more information regarding ADB commands, follow this link: https://community.freescale.com/docs/DOC-102514 Initialization: After the setup is done, you should see the application installed: You will see the list of available tests for manual verification: Video Link : 4502 For each test, you will see detailed instructions to run it, and a “pass” and “fail” buttons. Video Link : 4530 Once you run each test, you will have the posibility to choose the outcome. (in some cases, pass/fail outcome will be determined automatically). The list of tests (for CTS Verifier 5.1_r2) is: Camera: FOV Calibration, Formats, ITS, Intents, Orientation, Video. Car: Car Dock Test Clock: Alarms and Timers Test Device Administration: Policy serialization test, screen lock test. Features: Hardware/Software feature summary Hardware: USB Accessory Test Job Scheduler: Charging constraints, connectivity constraints, idle mode constraints. Location: Battery saving mode test, location mode off test Managed provisioning: BYOD managed provisioning, device owner provisioning Networking: Bluetooth test, Wi-Fi direct test Notifications: CA Cert notification, CA Cert notificacion on boot, notification attention management, notification listener, notificacion package priority Other: Data backup, screen pinning, widget framework Projection: Projection cube, projection multitouch, projection offscreen, projection scrolling, projection video playback, projection widget Security: Keyguard password verification, SUID file scanner. Sensors: Accelerometer mearument, CTS Sensor batching, CTS Sensor integration, CTS sensor test, CTS single sensor test, magnetic field measurement, sensor batching. Streaming: Streaming video quality verifier. Exporting test results: Tap the “save disk” icon. A pop-up will show the path of the report that was created. Video Link : 4531 With the board connected to the PC through USB, pull the report using ADB: To download all reports run : adb pull /mnt/sdcard/ctsVerifierReports/ .

In our document there is about how to fuse in the u-boot, as follows you can see: Here we can use the mfgtool and these command to download the fuse to u-boot. 1/ Set the BOOT_MODE[1:0] to 00 2/Use the mfgtool to download the u-boot to RAM Use the mfgtool to download only the u-boot, so you have to annotate the code not about u-boot. Only u-boot download code left. As follows:  …………    Loading uboot.  Jumping to OS image. 3/When the u-boot boot up, print and go to the u-boot command line. U-Boot contains a tool, imxotp, which is used for fusing. The commands imxotp read addr and imxotp blow --force addr value read the data of Efuse. The addr is the register address of eFUSE, and the base address of eFUSE is 0x021BC0000, details you can refer to the section 46 of the iMX6DQRM.pdf p4016. And the The exact configuration please refer to the section 5 of the iMX6DQRM.pdf p315. Take the Sabrelite as an example the value of burning : imxotp blow --force 0x5 0x18000030 imxotp blow --force 0x6 0x10 Hope this can do some hope for you. About the efuse you also can refer to : https://community.nxp.com/thread/316232 

The original implementation is from Frias Renato for Sabreauto board. How to define the booting time? The booting time we defined here is from the board be powered up to the main application working and main application be showed directly to the end user, for example: for the media play purpose board, the booting time count to the first video frame be shown on the screen. For minimizing the booting time, some methods be tried. Optimizing for performance. Remove unnecessary modules at boot time. Start main application at the first time after the kernel be boot up. Optimizing for performance: U-Boot:   1:Enable MMU and L2-Cache.   2:Optimizing memset and memcpy.   3:Implementation of SDMA, accelerate copying data from NOR flash to memory.   4:Implementation of uSDHC’s ADMA, improve performance for SD card read. Kernel:   1:Optimizing _memcpy_fromio function at  arch/arm/kernel/io.c Remove unnecessary modules: U-Boot:   1: Disable uart output at u-boot procedure and add quiet parameter to Kernel boot.   2: Remove boot up delay at u-boot.   3: Disable I2C, SPI, SPLASH_SCREEN at u-boot. Kernel: Below removing unnecessary modules just for Sabresd board boot up through SD card and MIPI camera overlay on LVDS screen application, for other special board and special board usage application please don’t use below directly.   1: Modify arch/arm/mach-mx6/board-mx6q_sabresd.c just keep necessary module initialization at  mx6_sabresd_board_init : iomux configuration, uart0, voda, ipu, ldb, v4l2, mipi-csi, i2c1, uSDHC1, pwm0, dvfs, mipi camera clock.   2: Update Linux kernel configuration file. Try to just keep necessary module and configuration to keep minim size. Build necessary modules from external to Kernel itself. Create uImage from Image instead of zImage to reduce Kernel self extraction time. Use ext4 file system on SD card to accelerate rootfs mounting.    Notice: Kernel configuration remove NETWORK support, it includes Unix Domain Socket, the udev mechanism need it, so this kernel configuration can't support rootfs udev dynamic /dev/ nodes and all /dev/ nodes must be created before boot up at rootfs. Start main application at the first time after the kernel boots up. As normal boot up procedure, the init process will handle sysinit script firstly, this script will do some initialization and preparation for most of the user process, But this script normally will be executed for about 1~5 seconds, so now try do main application before the sysinit, while the necessary preparation of main application will be handle by this application internally. See below example for MIPI camera overly on LVDS screen: /etc/inittab ::once:/unit_tests/mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -ot 0 -ol 0 -r 0 -t -1 -d 0 -fg -fr 30 ::once:/etc/rc.d/rcS ::once:/sbin/getty -L ttymxc0 115200 vt100 # GENERIC_SERIAL Test result of fast boot on Sabresd board for MIPI camera overly on LVDS screen: The main application be executed from the board be powered up is about 958ms.    Running Bootloader [0.356417 0.356417] [ 0.046637] _regulator_get: get() with no identifier [ 0.958425  0.602008] starting pid 21, tty '': '/unit_tests/mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -ot 0 -ol 0 -r 0 -t -^@ [0.969609 0.011184] starting pid 22, tty '': '/etc/rc.d/rcS' [0.973368 0.003759] g_display_width = 1024, g_display_height = 768 [0.977540 0.004172] g_display_top = 0, g_display_left = 0 [0.980927 0.003387] starting pid 23, tty '': '/sbin/getty -L ttymxc0 115200 vt100 ' [1.048454 0.067527] Mounting /proc and /sys [1.089526 0.041072] Setting the hostname to freescale [1.116635 0.027109] Mounting filesystems [1.527320 0.410685] sensor chip is ov5640_mipi_camera [1.530627 0.003307] sensor frame size is 640x480 [1.533482 0.002855] sensor frame format is UYVY [1.640221 0.106739] frame_rate is 30 [1.642249 0.002028] [1.642270 0.000021] frame buffer width 0, height 0, bytesperline 0 [1.989728 0.347458] [1.990761 0.001033] arm-none-linux-gnueabi-gcc (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) 4.6.2 20110630 (prerelease) [2.001161 0.010400] root filesystem built on Tue, 11 Sep 2012 11:43:24 +0800 [2.006249 0.005088] Freescale Semiconductor, Inc. [2.009394 0.003145] [2.009531 0.000137] freescale login: Please see below fast boot video. I also attached sample code for U-boot and kernel for your reference. Patch code based on L3.0.35_12.09.01_GA.

Check memory leakage in media server. Set libc debug level. So libc will record back trace for all memory allocate. setprop libc.debug.malloc 1 Kill mediaserver to let the libc debug take effect. Android will restart mediaserver. busybox killall -HUP mediaserver you will see below log if you setting right. I/libc    ( 3074): /system/bin/mediaserver using MALLOC_DEBUG = 1 (leak checker) Dump all used memory of mediaserver. dumpsys media.player -m Allocation count 297 Total memory 1483423 size   262144, dup    1, 0x401f4c18, 0x400b6152, 0x401a6568, 0x4061a95c, 0x40146cfa, 0x4019639c, 0x40146ec2, 0x4014a1ec, 0x4014a3ca, 0x00008a98, 0x400b67aa size   178192, dup    1, 0x401f4c18, 0x400b6152, 0x4280adae, 0x427ffcee, 0x4280ae6c, 0x427ec75a, 0x427f7e22, 0x42807648, 0x428082ea, 0x415144f0, 0x4151334a, 0x413381d0, 0x401dcbc, 0x401d438c, 0x4014d996, 0x405c3c46, 0x405c7516, 0x405c6ad4, 0x412c02ca, 0x412c0584, 0x4108c64c, 0x4107d622, 0x4107fbf2, 0x4107c19a, 0x400b2eac, 0x400b2a00 Diff two times of memory dump to check if there is any memory leakage. You can playback one video file between the dump. diff 1.txt 2.txt > diff.txt Get maps file of mediaserver. adb pull proc/<pid of mediaserver>/maps . Use attached script to map back trace to function symbols and file line. ./addr2func.py --root-dir=../../ --maps-file=./maps --product=sabresd_6dq diff.txt Notes: should use eng build for the debug.