Fixing Redboot RAM bug (CSD1 not activated) Introduction i.MX 35 PDK board has 256 MB of RAM, due to a bug in Redboot bootloader compiled for the board effectively there is only 128 MB available.This procedure fixes this bug to be able to use 256 MB of RAM. Redboot supporting 256 MB of RAM 1. Download the attached Redboot256.bin file. 2. Flash the new redboot image instead of the old one: Configuring RedBoot

You can but building times will take much longer (approximately 2 times longer for the core-image-minimal) compared to a build done on a native machine. In case you can not do the build on a native machine, make sure your virtual has enough hard-disk room (at least 50GB). For example, these are the build folders sizes after baking core-image-minimal: build$ du -h --max-depth=1 1.3G    ./sstate-cache 3.2M    ./cache 12K    ./.hob 32K    ./conf 22G    ./tmp 23G    . The tmp folder is by far the largest (containing building statistics, source code, deployed images, etc.) build/tmp$ tree -L 2 -d . ├── buildstats │   ├── cogl-imx6qsabresd │   ├── fsl-image-gui-imx6qsabresd │   ├── fsl-image-gui-sdk-imx6qsabresd │   ├── mesa-dri-imx6qsabresd │   ├── mesa-imx6qsabresd │   └── pseudo-native-imx6qsabresd ├── cache │   └── default-eglibc ├── deploy │   ├── images │   ├── licenses │   └── rpm ├── log │   ├── cleanlogs │   └── cooker ├── pkgdata │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   └── imx6qsabresd-poky-linux-gnueabi ├── sstate-control ├── stamps │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   ├── work-shared │   └── x86_64-linux ├── sysroots │   ├── imx6qsabresd │   ├── imx6qsabresd-tcbootstrap │   └── x86_64-linux ├── work │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   └── x86_64-linux └── work-shared     └── gcc-4.7.2-r13

Extending to the impact produced by being the First to release WEC7 on i.MX6 Development Platform, iWave Systems adds yet another accomplishment by announcing the availability of Windows Embedded Compact 7 (WEC7) reference BSP for Freescale’s i.MX6x SABRE SDB/SDP. The Freescale’s i.MX6x SABRE SDB/SDP Platform is powered with Freescale’s i.MX6 Quad/Dual Lite 1GHz, MMPF0100 Freescale PMIC. The WEC7 BSP release supports SATA II, Standard SD/SDIO, Gigabit Ethernet, LVDS, Touch Panel, HDMI port and also necessary hardware codecs supported by the CPU. Debugging tools like KITL and CETK are also supported. All the latest features that WEC7 offers such as Silverlight 3.0, MPEG-4 HD, Expression Blend, Active Sync and also Adobe Flash10.1 are made available.                                                                                                                                                                 Benefits: WEC7 Source code can be easily customized with respect to the target hardware platform Simple and low cost integration for any Freescale i.MX6x based platform       Quick time to market Highlights: Ideal for Quick Proof of concept (POC) development Shortens up to 60% of the new product development life cycle                                       Quick customization services in a very short period Features: Standard Features: i.MX6 Quad/Dual Lite 1GHz CPU MMPF0100 Freescale PMIC 1 GB DDR3 RAM Serial console SD boot SATA II SD/SDIO HDMI Gigabit Ethernet USB OTG Audio LVDS display Touch Optional Features: PCIe Camera CAN GPS VPU (HD Coding and Decoding supported) GPU (Open GL, Open VG, Direct3DM and DirectDraw) Target Applications: Automotive IVI Telematics Interactive POS Industrial HMI Medical Click Here for more details on WEC7 BSP Support for Freescale's i.MX6x Sabre SDB/SDP by iWave Click Here for more details on WEC7 BSP Support for various other i.MX processors

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

Overview: This document is written for Freescale customers who have Freescale AC3 release packages (excluded package). (If you did not have the AC3 release package, you can disregard this document.) Freescale OMX Player in Android release supports audio track selection when playing files with multiple audio tracks. However, most customers don't use this enhanced API to select the audio track even if current audio codec is not supported. To avoid a soundless output when partial audio track can be played, this document provides the method to select the available audio track automatically to play. The patch in this document is not included in our current release because it did not match with our track selection rule - play the first track. If you have any idea with this issue, feel free to add comments into this document. Issue description: Software: R13.4-GA or R13.4.1 Android releases Hardware: MX6Dual/Quad SabreSD board Test source: 1.mkv Test Step: 1. Lunch Gallery from main menu. 2. Play the video And you can see the watch the video without any sound Root Reason: The file has 2 audio track DTS & AC3: audio track 1 is DTS and track 2 is AC3. OMX Player will choose the first audio track to play as default audio track, which is DTS audio. However, the software only supports the AC3 audio codec, so it could not set up audio decoder for DTS track. If we choose to play the AC3 track, sounds could be heard. How to fix: The audio track index is set in GMPlayer::LoadParser(). You can get audio format to check whether it is supported by decoder. Please see the patch audio_track_slection.diff

i.MX27 PDK Board Flashing This tutorial teaches how to flash bootloader using ATK. To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot. Using ATK ATK (Advanced Toolkit) is a Windows software for programming the flash memory of i.MX boards. This section will describe the procedure to erase the flash memory and program the bootloader. 1 - Connect a serial cable between PC and i.MX board. 2 - Some hardware configurations (switches) must be done to flash the board. Set red and cream switches as below: Switch SW5 -> 00000 Switch SW4 -> 10000001 Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe Next Step To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot. PS: On SW5 and SW4, "1" means the keys selected towards the edge of the board. 3 - Run ATK by clicking Start -> Programs -> AdvancedToolKit -> AdvancedToolKit       Set the options:    Device memory -> DDR; Custom Initial File -> (keep it unmarked)    Communication Channel -> Serial Port (Usually COM1) 4 - Click on Flash Tools to erase, program or dump the the flash memory and click GO. Flash Erasing 1 - To erase Flash memory, select the parameters as shown in the figure below: 2 - Turn on the board and press Erase. 3 - ATK shows this message when flash is erased Flash Programming The next step is to program the bootloader image into the board's Flash following the steps below. 1 - Select the parameters as shown in the figure below and press Program. The bootloader binary image file can be found into your Board Support Package Set Program, NAND, Address: 0x00000000 2 - Add it on Image File field and press Program. 3 - Close ATK, turn off the board and set switch back as shown in the picture below. Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe Next Step To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot.

After porting u-boot to your i.MX5x board you might want add it on LTIB menu, "Choose your board for u-boot" section. For this, edit ltib/config/platform/imx/main.lkc to add your board: Enter board on menu: comment "Choose your board for u-boot" choice prompt "board" default BOARD_MX51_BBG depends on PLATFORM = "imx51" help This menu will let you choose the board you use. ... + config BOARD_MX53_MYBOARD + bool "mx53_myboard" ... endchoice Add the "mx53_myboard_config" that matches your board configuration on the u-boot Makefile to PKG_U_BOOT_CONFIG_TYPE: config PKG_U_BOOT_CONFIG_TYPE   string   ... + default "mx53_myboard_config" if ( PLATFORM = "imx51" && BOARD_MX53_MYBOARD && !PKG_KERNEL_UPDATER )   ...

Quick Steps Four quick steps to build and flash a UBIFS image on i.MX35 NAND (K9LBG08U0D-PCB0), for information on how to you another memory, please see next section. Enable MTD_UBI and UBIFS_FS on kernel Create UBI image from rootfs (used for NFS) - ON PC mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg Format NAND using UBI image - ON TARGET ubiformat -f ubi.img /dev/mtd8 Load UBI file system load -r -b 0x100000 zImage fis create -f 0x300000 kernel fis load kernel exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none" How To First of all, install mtd-utils on both target and host: Target: ./ltib -c Package list [*] mtd-utils Host sudo aptget install mtd-utils 1. Enable MTD_UBI and UBIFS_FS on kernel MTD_UBI -> Device Drivers     -> Memory Technology Device (MTD) support (MTD [=y])           -> UBI - Unsorted block images                   <*> Enable UBI                    (4096) UBI wear-leveling threshold (NEW)                    (1) Percentage of reserved eraseblocks for bad eraseblocks handling (NEW)                 < > MTD devices emulation driver (gluebi) (NEW)                    ** UBI debugging options **                    [ ] UBI debugging (NEW) UBIFS_FS -> File systems         ->Miscellaneous filesystems             <*> UBIFS file system support                 [ ] Extended attributes support (NEW)                 [ ] Advanced compression options (NEW)                 [ ] Enable debugging (NEW) 2. Create UBI image On TARGET Collect some information needed in order to create the UBI image according to your NAND device root@freescale \~$ cat /proc/mtd dev:   size   erasesize name mtd0: 00080000 00020000 "Bootloader" mtd1: 00400000 00020000 "nor.Kernel" mtd2: 01e00000 00020000 "nor.userfs" mtd3: 01c00000 00020000 "nor.rootfs" mtd4: 00003000 00020000 "FIS directory" mtd5: 02001000 00020000 "Redboot config" mtd6: 00300000 00040000 "nand.bootloader" mtd7: 00500000 00040000 "nand.kernel" mtd8: 10000000 00040000 "nand.rootfs" mtd9: 00800000 00040000 "nand.configure" mtd10: 6f000000 00040000 "nand.userfs" I will use mtd8, because I want the NAND rootfs MTD partition. More on [1] root@freescale ~$ ubiattach /dev/ubi_ctrl -m 8 UBI: attaching mtd8 to ubi0 UBI: physical eraseblock size:   262144 bytes (256 KiB) UBI: logical eraseblock size:    258048 bytes UBI: smallest flash I/O unit:    2048 UBI: VID header offset:          2048 (aligned 2048) UBI: data offset:                4096 UBI: empty MTD device detected UBI: create volume table (copy #1) UBI: create volume table (copy #2) UBI: attached mtd8 to ubi0 UBI: MTD device name:            "nand.rootfs" UBI: MTD device size:            256 MiB UBI: number of good PEBs:        979 UBI: number of bad PEBs:         45 UBI: max. allowed volumes:       128 UBI: wear-leveling threshold:    4096 UBI: number of internal volumes: 1 UBI: number of user volumes:     0 UBI: available PEBs:             966 UBI: total number of reserved PEBs: 13 UBI: number of PEBs reserved for bad PEB handling: 9 UBI: max/mean erase counter: 0/0 UBI: image sequence number: 0 UBI: background thread "ubi_bgt0d" started, PID 2098 UBI device number You will need: -p = physical eraseblock size = 256KiB -e = logical eraseblock size = 258048 -m = smallest flash I/O unit = 2048 -s = VID header offset = 2048 -c = available PEB = 966 Values only for iMX35 PDK NAND - K9LBG08U0D-PCB0 3. ON HOST - Now, create the images (two steps) You need to create ubinize.cfg file! ubinize.cfg [ubifs] mode=ubi image=ubifs.img vol_id=0 vol_size=237MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize $ mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img mkfs.ubifs      root:                rootfs/      min_io_size:    2048      leb_size:         258048      max_leb_cnt:   966      output:            ubifs.img      jrn_size:          8388608      reserved:         0      compr:            lzo      keyhash:         r5      fanout:            8      orph_lebs:       1      super lebs:      1      master lebs:    2      log_lebs:         4      lpt_lebs:          2      orph_lebs:       1      main_lebs:       132      gc lebs:           1      index lebs:       2      leb_cnt:           142      UUID:              CC2057F9-B20F-46D1-A399-1FCA95DCAFF7 Success\! $ ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg $ ls -lh u* -rw-r--r-- 1 daiane daiane 35M 2010-11-26 15:21 ubifs.img -rw-r--r-- 1 daiane daiane 36M 2010-11-26 15:22 ubi.img -rw-r--r-- 1 daiane daiane 113 2010-11-26 15:22 ubinize.cfg $ sudo cp ubi.img rootfs/home/ 4. Format NAND using UBI image - ON TARGET Turn on target (or reset it) and format MTD partition $ cd /home $ ubiformat -f ubi.img /dev/mtd8 5. Load UBI file system Reset and change redboot script: .. fis load kernel .. exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none"

Q: How to get the CSI BT656 without HSYNC/VSYNC working. The problem, is that all implemented driver in the BSP are using the external HSYNC/VSYNC synchronization signal. The SW designer is actually struggling to find the right way to generate the end of field active interrupt (end of frame). > mxc_v4l2_still.out I get an: > ERROR: v4l2 capture: mxc_v4l_read timeout counter 0 > > When using mxc_v4l2_capture.out or mxc_v4l2_tvin.out I get an: > ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0 > To help him implementing the driver, I need to get some insight on the IPUx_CSIn_CCIR_CODE_1/2/3 as it seems that the bit description 21 to 19 (CSI_STRT_FLD0_ACTV) is not described (same for all the multiple bit field in this register. Maybe it should match the ITU656, but here as well the driver examples does not match the bit description of the ITU standard. So my questions: IS it really possible to implement the BT656 with SAV / EAV and without external HSYNC/VSYNC? If yes, is it possible to review the IPUx_CSIn_CCIR_CODE_1/2/3 fields and communicate which parameter should be provided here? i.MX6Q A:      For no VSYNC and HSYNC case, in the sensor driver such as "linux-3.0.35\drivers\media\video\mxc\capture\adv7180.c", function ioctl_g_ifparm(), you should set p->u.bt656.bt_sync_correct to 0;      p->u.bt656.bt_sync_correct = 1; // It means external VSYNC and HSYNC will be used for SYNC.      p->u.bt656.bt_sync_correct = 0; // No external VSYNC and HSYNC, embedded EAV and SAV will be used for SYNC.      In iMX6 BSP, the CCIR related code is ready in "linux-3.0.35\drivers\mxc\ipu3\ipu_capture.c", function ipu_csi_init_interface(), no code modification was needed, that code was verified work.      For BT656 mode, your sensor driver such as adv7180, should also report correct parameters in function function ioctl_g_ifparm().      p->u.bt656.clock_curr = 0;  // This will tell linux-3.0.35\drivers\media\video\mxc\capture\mxc_v4l2_capture.c to use "IPU_CSI_CLK_MODE_CCIR656_INTERLACED" in function mxc_v4l2_s_param().      The current iMX6 BSP mxc_v4l2_capture.c driver doesn't support BT656 progressive mode, it only supports BT656 interlace mode. To support BT656 progressive mode, the customer should modify the code in mxc_v4l2_s_param(), let csi_param.clk_mode = IPU_CSI_CLK_MODE_CCIR656_PROGRESSIVE. This is exactly what they are doing, but still it doesn’t work. Actually, they see the code being executed following the right steps in the ipu_csi_init_interface() going through PAL 720x625 configuration. But still, they get the timeout! else if (cfg_param.clk_mode == IPU_CSI_CLK_MODE_CCIR656_INTERLACED) {       if (width == 720 && height == 625) {         /* PAL case */         /*         Field0BlankEnd = 0x6, Field0BlankStart = 0x2,         Field0ActiveEnd = 0x4, Field0ActiveStart = 0           */         ipu_csi_write(ipu, csi, 0x40596, CSI_CCIR_CODE_1);         /*         Field1BlankEnd = 0x7, Field1BlankStart = 0x3,         Field1ActiveEnd = 0x5, Field1ActiveStart = 0x1           */         ipu_csi_write(ipu, csi, 0xD07DF, CSI_CCIR_CODE_2);         ipu_csi_write(ipu, csi, 0xFF0000, CSI_CCIR_CODE_3); So, I believe the parameters are wrong. What could be missing. Can you review the driver? For me it looks like the adv example, except the bt_sync_correct=0, which is what we want. You can suggest the customer to capture the CSI data bus to check if there is correct output from sensor, such as EAV/SAV. For the "timeout" error, it always means there is no correct data on CSI data bus. This document was generated from the following discussion: CSI BT656

Configuring RedBoot The configuration is made using a Minicom session that need to be established between host and target through serial port. To have an operational system been executed just on the power on, configure the right for Boot script. The chooses are shown in Boot Script section. To avoid the start of operational system, power on the board and press CTRL-C immediately. Wait until RedBoot> prompt appears. Overview The main command for beginners is fconfig -l that can be abbreviated as fc -l    This command shows the actual configuration of Redboot, like: RedBoot> fc -l Run script at boot: true Boot script: .. load -r -b 0x100000 /tftpboot/zImage .. exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/n" Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false RedBoot> Run script at boot: set true for booting with a script or false to always enter on prompt directly Boot script: define what commands to execute as script at the startup Boot script timeout: how many time to wait before execute boot script Use BOOTP for network configuration: set true for getting configuration from BOOTP or false for manually configuring gateway and IP address Gateway IP address: The IP address of the gateway Local IP address: The board IP address Local IP address mask: The board IP mask address Default server IP address: The host IP address when NFS and TFTP server are running Configuring Network Execute the command to configure network parameters: RedBoot> fc This step guarantee the possibilities to load images from some server previously connected and configured. For Use BOOTP for network configuration: answer false. For Gateway IP address: type the gateway IP address of your network; For Local IP address: type an IP address to your board, it needs to be a valid IP in your network; For Local IP address mask: type the IP mask address; For Default server IP address: type the IP of your host server where are running TFTP and NFS. Pay special attencion for Update RedBoot non-volatile configuration - continue (y/n)?. Answer y to have your configuration saved in the flash. To verify if your configuration is working use ping, be patient this command is very slow: RedBoot" ping -h 10.29.244.99 Network PING - from 10.29.241.6 to 10.29.244.99 PING - received 10 of 10 expected Use the "-n" option to change the number of pings and the "-r" option to speed things up, such as: ping -n 3 -h 10.29.244.99 -r 10. The boot script configuration is done in the next section. Boot Script NFS Boot In NFS Boot mode, a kernel image and a root file system image are loaded from a configured server through TFTP and NFS that can be executed doing the development more easy. To configure RedBoot for NFS Boot reset the board and press CTRL-C immediately. In a Minicom session type fc to modify the configuration boot. Enter the script boot below: RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> load -r -b 0x100000 /tftpboot/zImage >> exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.244.99:/tftpboot/rootfs init=/linuxrc ip=10.29.241.6:10.29.244.99" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> The script is composed by two lines. The first line load the kernel image (zImage) by TFTP from /tftpboot, the directory configured in TFTP.\ The second line executes the kernel and mount the root file system using NFS. The path /tftpboot/ltib indicates the path that should be exported in the host machine. (It's the path in the /etc/exports) 10.29.244.99 is the host IP address 10.29.241.6 is the target IP address Flash Boot For flash boot the Boot Script differs a little bit: fis init kernel exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock8 rw rootfstype=jffs2 ip=none" The value for root can be different for each board type.

document about how to use usb camera on imx6 android-4.0 platform.

Before QT5 Qt3D was a separate project and was maintained separately.  Now it is offered along with other official plugins. QT3D supports the addition of 3D elements. In order to install it this is needed: Clone the git Qt3D repository $ git clone git://gitorious.org/qt/qt3d.git Using the Qmake that you already created when installing Qt5, this will setup the Makefile in order to cross compile the plugin. $ qmake $ make $ sudo make install Ready to play with Qt3D! This is the HelloWorld of 3D,  teapot.bez  is a bezier curves file with the forms of the famous teapot. import QtQuick 2.0 import Qt3D 1.0 Viewport{    width: 640; height: 480    Item3D{    id: teapot    mesh: Mesh { source: "teapot.bez" }    effect: Effect {}   } }

Getting Started for i.MX53 Quick Start Board Here is a quick overview you can follow to get your very first contact with i.MX53 QSB. Introduction Out of box i.MX53 QSB video booting up Ubuntu Original Video: Out of box i.MX53 QSB video booting up Ubuntu with some demo (GPU and VPU) Original Video: How to load a pre-built image Here, you should have loaded your board with the out-of-box SD card. Next step is create your own SD card with some pre-built image. You can find pre-built image packages from Freescale for Linux look for Linux Binary Demo file Please, go to Timesys wikipage[1] and see how to load a pre-built image. You can use some Freescale image or some Timesys image. Both will work! For loading linux OS you need at least 3 images: bootloader image kernel image root file system image or tarball Bootloader For iMX53QSB the default bootloader provided by Freescale is u-boot.You can build your own image using LTIB following the same procedure from here. Kernel You can build a new uImage (kernel binary image to be loaded by u-boot) using LTIB, and you can follow the instructions from here Root File System Root file system is a set of directories and files that become the system environment. How to Built Your Own Image Take BSP package on Freescale i.MX53 QSB web site. Prepare your computer to LTIB installation, see that you need All Boards LTIB. Transfer all images to the SD Card (it will be placed under <ltib_dir>/rootfs/boot). Configure your u-boot environment variable. Boot your board. In case you want to boot via NFS, please follow the next procedure instead. Take BSP package on Freescale i.MX 53 QSB web site. Prepare your computer to LTIB installation, see that you need @all_boards_ltib Configure your computer to be able to provide NFS service: Configure your TFTP server. Configure your NFS server. Configure your u-boot environment variable. Boot your board. Be aware the kernel command line you set on u-boot variable can configure the display.

Procrank can be used to check if a process has memory leakage. Procrank will list four types of memory usage. For details refer to: http://elinux.org/Android_Memory_Usage Vss = virtual set size Rss = resident set size Pss = proportional set size Uss = unique set size Uss can be used to check if a process has memory leakage. If the Uss increases when some operations start and stop, this means there could be memory leakage. Procrank can get from: <myandroid>/out/target/product/<product_name>/system/xbin/procrank and also needs to push to the library you target: <myandroid>/out/target/product/< product_name >/system/lib/libpagemap.so

Q: What is the Min LPDDR2 clock frequency allowed by the i.MX6? The Jedec Spec for LPDDR2 allows for a min tck period of 100ns. Are there any required relashionship between the DDR clock frequency and other clocks in the i.MX6? A: The JEDEC maximum period for the MX6 is 100nS as per the LPDDR2 specification.  There is a minimum period during boot, before everything is configured and fully up to speed of 18nS. Are you saying the imx6 memory controller can operatate down to the min frequecies specified in the LPDDR2 JEDEC spec? Given that there is no limit specified in the data sheet, it should operate that slowly, provided the clocking can be set for it to operate so slowly. I would imagine that the core will need to be running slowly as well, since it does not make sense to slow the memory bus without slowing the core down as well.

This document is describe the control method of USB Power based on I.MX6ULL-EVK.   1. Hardware Design USB OTG can be working as device mode, host mode, or switching between both device mode and host mode. (a) USB OTG Device mode When USB OTG is working as device mode, the USB OTG ID pin should be pulled up by a resistor. And the 5V power comes from the VBUS pin of MicroUSB which is the 5V from the external USB HOST. From the above schematic :- When the USB OTG1 ID is pulled to high, the G/S of the NMOSFET Q2SK3018 is turned on. The ENA pin of U1101 is low, and then no 5V output from OUTA. If USB OTG1 is connected to the external USB HOST, a 5V power source will enter the board and supply to the USB OTG1 VBUS pin. (b) Switch between Device and Host mode This is also called USB OTG’s Dual Role. When we plug in MicroUSB with USB TYPE-AB to USB TYPE-A-F cable, USB OTG1 will switch from USB device to Host mode. At this time, the USB OTG1 ID pin will be pulled down to low, the G / S of the NMOSFET will be turned off, the ENA pin of U1101 will be pulled low, and OUTA will output 5V voltage to the VBUS pin of MicroUSB. (c) USB OTG Host mode When USB OTG is working as host mode,  USB OTG1 ID pin connect an external resistor to pull it down or use internal resistor to pull it down. If using external resistor, 2.2K/3.3K ohm resistor is recommended. The USB_OTG1_PWR should output High to enable ENA of U1101, then OUTA will output 5V to USB OTG1 VBUS. On i.MX6ULL-EVK, USB OTG2 port is designed to be Host mode. It can be a design reference. When the USB_OTG2_PWR pulled to high, the U1101 supplies 5V to the outside. 2. Software modification The GPIO1_IO04 can be used to control USB OTG1 power.

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

Copy Redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND or MMC flash media for Redboot. In this case, NAND is beeing used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate Copy redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND, or MMC flash media for Redboot. In this case, NAND is being used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate

Features Additional Information Features The i.MX31 PDK, with Smart Speed™ technology, is a completely integrated hardware and software solution that simplifies product development so you can focus on your critical differentiation needed for market success. Reduce development time, and design products that have power to spare, even when running multiple applications simultaneously. Receive stellar image and graphic performance in a system design that dramatically reduces power consumption. The i.MX31 PDK provides: Modular hardware enabling multiple connectivity technologies Optimized development software for Linux®, Windows® CE 5.0 and Windows Embedded CE 6.0 operating systems Out-of-box experience, complete with demonstration software and performance data Maximum performance and power savings Complete "Design. Debug. Demo." capability as simple as 1,2,3 i.MX31 Applications Processor Module i.MX31 Applications Processor - ARM11™ 128 MB DDR SDRAM 256 MB NAND FLASH Power Management (PMIC MC13783) + Power Circuitry Audio HS USB PHY Touch Controller Connector Debug Module (Software Development) Debug Ethernet Port Debug Serial Port JTAG Reset, Interrupt, Boot Switches Debug LEDs CodeTest Interface Power Source Current/Power Monitoring Personality Module (Demo-ready) Acceleromater MMA7450L (Freescale) User I/O Connectivity (FM, 802.11, Bluetooth, USB OTG, USB HS) Button 2.7"TFT Display 2MP Camera Module SDcard, ATA HDD External Connectors (dock, headphones, TV out, GPS) Microphone Speaker Additional Information i.MX31 PDK Contents If you are new to i.MX31PDK development we suggest checking out:Not authorized to view the specified document 1673 To flash BootLoader: i.MX31 PDK Board Flashing Miscellaneous Tutorials Blink i.MX 31PDK LEDs Using U-Boot i.MX31 Testing RNGA I.MX31 Testing TvOut I.MX31 Using CLKO

This is ov5645 driver and tested with i.MX6 L3.0.35 BSP .  It is modified based on ov5640.c. P.S. The power down function for OV5645 is different from the OV5640. So modify the function in your_board.c like this: static void mx6q_mipi_powerdown(int powerdown) {     if (!powerdown)         gpio_set_value(MIPI_PWDN, 1);     else         gpio_set_value(MIPI_PWDN, 0);     msleep(5); }