Please make sure design is follow below checking list before checking this guide. HW Design Checking List for i.MX6DQSDL

   The purpose of this article is to describe how to join together the Processor Expert and ARM GCC toolchain under Eclipse environment.    Freescale provides the Processor Expert, which contains the Pin Settings Tool to support an easy way to configure pin signals, from multiplexing to the electrical properties of pins. With such Tool all the pins can be configured with a graphical user interface, and then generate C code, in order to use it as an example in applications. Please refer to the following Web for more details. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PROCESSOR-EXPERT-IMX   The Processor Expert Software for i.MX Processors (Version 1.0) does not include a compiler or linker. Customers should merge the generated code into a build system.   However, it is possible to use common Eclipse-based IDE for the Processor Expert (V 1.0) and GNU ARM “C” toolchains. In particular, the following sequence may be implemented for both Linux and Windows hosts. 1. Install Eclipse (Kepler release) IDE for C/C++ Developers. https://eclipse.org/downloads/packages/eclipse-ide-cc-developers/keplersr2 2. Add Eclipse Processor Expert plug-in, as recommended in the documentation. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PROCESSOR-EXPERT-IMX https://community.freescale.com/docs/DOC-101470 3.  Add GNU ARM Eclipse, which contains configurations for different toolchains, including Linux ones. http://gnuarmeclipse.livius.net/blog/plugins-install/ 4. Install appropriate toolchain. For bare-metal applications Sourcery CodeBench Lite for ARM is sutable one. Sourcery CodeBench Lite Edition including ARM GCC IDE - Mentor Graphics Please use Getting Started Guide document from the CodeBench Lite package, that explains how to install and build applications with the CodeBench Lite.    As an example, let’s consider minimal startup code for i.MX6Q (LED flickering project on i.MX6Q SDB / SDP). Assuming Eclipse IDE with the Processor Expert and GNU ARM tools is installed, we should create new “C” project under Eclipse : New -> C Project. Select “Empty Project” and “Cross ARM GCC”, enter “Project name”. Then : select “Advanced settings” -> C/C++ Build -> Settings Tab “Target Processor” : ARM Family : cortex – a9 Architecture : armv7-a Instruction set : ARM (-marm) Endianness : Little endian (-mlittle-endian) FloatABI : Library with FP (softfp) FPU Type : neon Unaligned access : Disabled (-mno-unaligned-access) “Cross ARM GNU Create Flash Image” : General : Raw binary. TAB “Toolchains” : Name : Sourcery CodeBench Lite for ARM EABI (arm-none-eabi-gcc) (If needed customers can select appropriate toolchain) Architecture : ARM (AArch32) Prefix : arm-none-eabi Check “Use global toolchain path” or select the required path directly.  Source codes may added via Eclipse : File -> Import -> File System -> From directory Example source is enclosed. After sources as included in the project, let’s configure linker options via project properties, C/C++ Build -> Settings -> Tool Settings -> Cross ARM C Linker -> General. Add script file “mx6dq.ld”, uncheck “Remove unused section”, check “Do not use standard start files”.   Note, the article of Miro Samek is very helpful in clarifying of startup code and linker script. Please refer to “Building Bare-Metal ARM Systems with GNU”. Article Published online at www.Embedded.com,  July/August 2007. So, now we can build the project : Project -> Build Project. Two executable file will be generated : test.elf (for JTAG debugger) and test.bin, which may be used to create bootable SD card, using cfimager-imx.exe utility : CMD> cfimager-imx -o 0 -f test.bin -d g: Please use readme files in the enclosed for more details.

All, This document will help you to understand the " YOCTO PROJECT COMMUNITY LAYERS" and the "YOCTO PROJECT FREESCALE OFFICIAL RELEASE" differences and where the layer content is coming from.   Best Regards, Luis

                                                                                         Watch the Freescale i.MX team boot up Android 5.0 Lollipop in i.mx6 application processors—在线播放—优酷网，视频高清在线观看 The Freescale i.MX Android team has booted up Android 5.0 Lollipop in the SABRE platform for i.mx6 series. Google pushed all of the latest source for its Android release to AOSP on Nov. 5, and the Freescale Android Team started their work. With the previous 6 days to boot Android Lollipop up, the Freescale i.MX Android team enabled the basic features like connectivity, audio/video playback, sensors, inputs and display on day 7! You can see the some changes in the demo video at the beginning of the post. The Freescale i.MX Android team has closely followed almost every version of Android since it is released by AOSP and has good experience on it. Below are some snapshots and pictures for the Android Lollipop.

Most common issues with bringup and memory stability come down to memory/system setup during startup phase of i.MX device.   This Python script allows you to dump IVT/DCD tables and data from a i.MX binary (either generated as result of build process or a simple dump of SD/NOR/NAND... content) and analyze them in an easier way. Should work with i.MX 6 and i.MX53 binaries.   Parser for i.MX 6 will also try to print out register values it recognizes, and also parse specific register fields, helping to analyze the data faster. This can be extended if needed to other registers/values.   imxbin.py works with Python3.x and imxbin_2x.py with Python 2.x, so choose appropriate version.   Vladan

It is based on 3.0.35 GA 4.1.0 BSP.   0001-Correct-mipi-camera-virtual-channel-setting-in-ipu_c.patch It is the updated IPU code for MIPI ID and SMFC setting in ipu_capture.c. These setting should not be combined with MIPI virtual channel value, they shoule be fixed with ID 0.   0002-Use-virtual-channel-3-for-ov5640-mipi-camera-on-iMX6.patch The sample code to modify ov5640_mipi camera to use virtual channel 3 on SabreSD board.   The followed command can be used to verify the mipi camera function after booted into Linux: $ gst-launch mfw_v4lsrc capture-mode=1 device=/dev/video1 ! mfw_v4lsink     2014-09-30 update: Added the patch for 3.10.17_GA1.0.0 BSP. "L3.10.17_1.0.0_mipi_camera_virtual_channel_3.zip"  

Here is a quick summary at booting a Linux system on the i.MX 6 Sabre SD platform, through USB. This assumes you have a "working" Linux development environment at hand (e.g. Debian), and that your are able to build a working Linux system with buildroot already, as explained in this post. You will also need libusb-1.0 development files (headers and libraries), as well as root/sudo permissions to access USB peripherals. Also, we will use the fine imx_usb_loader tool that the nice folks at Boundary Devices have developed for their i.MX 5/6 boards, as it works fine for Sabre sd as well. Get buildroot sources We will use git to fetch buildroot sources: $ git clone git://git.busybox.net/buildroot This should create a buildroot directory with all the latest sources (after a while). Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l '201*', and git checkout <the-desired-tag>. Compile buildroot The beauty of buildroot is that it will take care of everything for you, including preparing a cross compiler. You can configure buildroot for Sabre SD by doing: $ cd buildroot $ make freescale_imx6sabresd_defconfig By default this would generate binaries suitable for booting with an SD card, so we need to tweak a few settings to obtain a ramdisk, which u-boot will like. Summon the configuration menu with the following command: $ make menuconfig Descend into the "Filesystem images" submenu, and select the following buildroot options: cpio the root filesystem (for use as an initial RAM filesystem) Compression method (gzip) Create U-Boot image of the root filesystem Exit, saving your configuration. You might want to verify that you have indeed the the correct options in your .config: $ grep '^BR2_TARGET_ROOTFS_CPIO' .config This should return the following: BR2_TARGET_ROOTFS_CPIO=y BR2_TARGET_ROOTFS_CPIO_GZIP=y BR2_TARGET_ROOTFS_CPIO_UIMAGE=y You may then proceed with the build: $ make This should download and build everything, so it will take a while. Note that, as bryanthomas pointed out, there are no files for the sabre sd in the boards folder. This is because no patches or custom kernel configurations are needed outside of what is defined in the defconfig. So the only place the sabre sd board lives in buildroot is in the configs directory. At the time of writing we still need a small final hack to have Linux boot on /init instead of its default /linuxrc for proper boot on ramdisk, though. Hopefully this should be addressed in a future buildroot version, and a patch is on his way, but for now we change the boot script in our target filesystem with: $ cd output/target $ ln -svf init linuxrc $ cd ../.. $ make All build results will fall under the output/images folder. We are most interested in the following pieces: output/images/ +- imx6q-sabresq.dtb +- rootfs.cpio.uboot +- u-boot.imx `- uImage Get imx_usb_loader sources We will use git to fetch imx_usb_loader sources: $ git clone git://github.com/boundarydevices/imx_usb_loader.git This should create an imx_usb_loader directory with all the latest sources. Compile imx_usb_loader Assuming your Linux development environment has the necessary libusb-1.0 headers and libraries, you can simply build by doing: $ cd imx_usb_loader $ make This should compile an imx_usb tool in the current folder. Prepare your payload and configuration First, copy all the necessary buildroot generated items to the imx_usb_loader directory. You will need: u-boot.imx uImage imx6q-sabresd.dtb rootfs.cpio.uboot Now we need to explain to imx_usb what we want to download to the i.MX romcode through USB. Add the following lines in the end of the mx6_usb_work.conf: ... u-boot.imx:dcd,plug uImage:load 0x12000000 rootfs.cpio.uboot:load 0x12C00000 imx6q-sabresd.dtb:load 0x18000000 u-boot.imx:clear_dcd,jump header The first line with dcd, plug uses u-boot header to configure the DDR3 memory, allowing us to download contents to the Sabre SD memory. This is exactly what the three subsequent lines with load directives do. The last line re-uses u-boot one more time to find out the address where to jump (jump header directive), but not touching the DDR configuration any more thanks to the clear_dcd directive (thanks jeanmariepons-b46892 for the tips) . Look at the comments in mx6_usb_work.conf for (a bit) more details on the various directives available. Also, note that all the absolute addresses mentioned above are what u-boot needed at the time of writing. Hopefully this should be fairly stable. Boot through USB! We are all set for booting now. Connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data. Connect also your PC to the USB OTG port of the Sabre SD, and make sure you have no SD card inserted and power up the platform. The Sabre SD should not boot into an operating system, but rather wait for a payload to download through USB. You might want to verify that it is indeed waiting with the following command: $ lsusb In the resulting output, there should be a line like the following: Bus 001 Device 098: ID 15a2:0054 Freescale Semiconductor, Inc. i.MX 6Dual/6Quad SystemOnChip in RecoveryMode On your PC, start the download of our "payload" to your Sabre SD with: $ sudo ./imx_usb (Note that you need proper permissions to do that.) After download of all the pieces, u-boot should start in its "mfgtools mode", as reflected by the following messages on UART: ... Boot from USB for mfgtools Use default environment for mfgtools Run bootcmd_mfg: run mfgtool_args;bootm ${loadaddr} ${initrd_addr} ${fdt_addr}; ... The Linux kernel should then start, and your buildroot system should reach a prompt: ... Welcome to Buildroot buildroot login: From there you may login as root. Enjoy! See also... This post details the buildroot steps a bit more. This post explains how to build a ramdisk for i.MX6 with busybox directly. AdeneoEmbedded - Whitepaper on USB loader for i.MX6 platforms imx_usb_loader README on github Buildroot: making embedded Linux easy

Hello Linux and i.MX6 users Tushar has posted on the Element14 community some clear tutorials (accessible following the link below) to create a bootable SD-Card from a Linux image. Linux host:             http://www.element14.com/community/community/designcenter/single-board-computers/riotboard/blog/2014/07/31/upgrading-riotboard-with-kernel-31017-linux-host Windows host:      RIoTboard: Upgrading RIoTboard with Kernel 3.10... | element14 Happy SD-Card Programming Greg

Hello Android users Otto has posted on the Element14 community some clear tutorial (accessible following the link below) to build Android from source. RIoTboard: Building Android from Source | element14 I recommend you to start following those steps to properly setup the Android tools. Happy Source Programming Greg

Hello Android users Sagar has posted on the Element14 community three clear tutorials (accessible following the link below) to create an Android application on the RiOTboard. RIoTboard: Part 1: Build an Android app on RIoT... | element14 RIoTboard: Part 2: Build an Android App on RIoT... | element14 RIoTboard: Part 3: Build an Android App on the ... | element14 I recommend you to start following those steps to ensure a proper setup of the Android tools. Happy Programming Greg

The i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA release is now available on www.freescale.com Files available Name Description L3.10.17_1.0.0_LINUX_DOCS i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA BSP documentation. y L3.10.17_1.0.0_iMX6QDLS_Bundle i.MX 6 D/Q/DL/S  Linux 3.10.17_1.0.0 GA BSP Binary Demo Files L3.10.17_1.0.0_iMX6SL_Bundle i.MX 6 SL  Linux 3.10.17_1.0.0 GA BSP Binary Demo Files i.MX_6_Vivante_VDK_150_Tools Vivante VTK 1.5 Codec for the i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA BSP    y L3.10.17_1.0.0_AACP_CODECS AAC Plus Codec for the i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA BSP y IMX_6_MFG_L3.10.17_1.0.0_TOOL Manufacturing Tool and Documentation for Linux 3.10.17_1.0.0 GA BSP y Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board o   i.MX6SL EVK board New  Features o   Main BSP New Features on MX6DQ, MX6DL and MX6SL from L3.10.9_1.0.0 GA: SD3.0 reset USB HSIC HWRNG security feature on MX6SL VIIM OTP Fuse in uboot Battery charge LED U-boot USB mass storage support USB Camera on host mode X backend: Adaptive HDMI display support backed by XRandR Main Codec New Features on MX6DQ, MX6DL and MX6SL from L3.10.17_1.0.0 Beta: Bug fix Main Codec New Features on MX6DQ, MX6DL and MX6SL from L3.10.17_1.0.0 Beta: Bug fix Other features not supported found during testing: UART: only support some baud rates like 9600, 115200, can't support high to 4000000 Known issues For known issues and limitations please consult the release notes located in the BSP documentation package.

1. Description     1) Support HDMI interlaced display mode, the followed format had been verified.         CEA format 5: 1920x1080i @60Hz         CEA format 6&7: 720(1440)x480i @60Hz         CEA format 20: 1920x1080i @50Hz         CEA format 21&22: 720(1440)x576i @50Hz     2) Support LCD interface for interlaced display mode, 1920x1080i @50Hz(CEA format 20)        had been verified. 2. File List -- 0001-IPUv3-support-interlaced-display-mode.patch    Patch to support interlaced display output for iMX6 ipuv3. -- 0002-iMX6-HDMI-support-interlaced-display-mode.patch    Patch to support interlaced display mode for iMX6 HDMI driver. -- 0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch    Patch to support interlaced display mode for iMX6 LCD interface driver.    -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - L3.0.35_4.1.0_GA_iMX6DQ kernel. 4. How to use -- Copy the patch files to kernel folder.     $ cd ~/ltib/rpm/BUILD/linux-3.0.35/     $ git apply ./0001-IPUv3-support-interlaced-display-mode.patch     $ git apply ./0002-iMX6-HDMI-support-interlaced-display-mode.patch     $ git apply ./0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch -- Build the new kernel image:     $ cd ~/ltib/rpm/BUILD/linux-3.0.35     $ export 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-     $ export ARCH=arm     $ make imx6_defconfig     $ make uImage -- Uboot parameters for video mode    Output 1080i50 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1920x1080Mi@25,if=RGB24,bpp=32"    Output 1080i60 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1920x1080Mi@30,if=RGB24,bpp=32"    Output 576i50 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1440x576Mi@25,if=RGB24,bpp=32"    Output 480i60 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1440x480Mi@30,if=RGB24,bpp=32"    Output 1080i50 display mode on LCD interface:       "video=mxcfb0:dev=lcd,LCD-1080I50,if=RGB565,bpp=32"       -- Switch HDMI interlaced mode    $ echo S:1920x1080i-50 > /sys/class/graphics/fb0/mode    $ echo S:1920x1080i-60 > /sys/class/graphics/fb0/mode    $ echo S:1440x480i-50 > /sys/class/graphics/fb0/mode    $ echo S:1440x576i-60 > /sys/class/graphics/fb0/mode 5. Know issue     1) When the interlaced display and another display work on same IPU,        blank and unblank the interlaced display will get the followed IPU        warning, but the display still works due to IPU can revover from the error.     imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_5 = 0x00800000     imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00080000 2015-05-13 update: Replace the fourth patch to make interlace display mode follow CEA-861-specification The patch "0004-IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch" was fine tuned for CEA-861-D specification on interlaced mode display. Please use this patch to replace the old 0004 patch. 2016-05-20 Update: For 3.0.35 BSP, add patch 0005-IPU-update-interlaced-video-mode-parameters-to-align.patch      Align the interlaced video mode parameters to progressive mode. 0006-IPU-update-IDMAC-setting-for-interlaced-display-mode.patch      Udate the IDMAC setting for interlaced display mode, output odd field data from memory first, it aligns with IPU DI timing, odd field first. For 3.14.52 BSP, created the new patch L3.14.52_1.1.0_GA_HDMI_Interlaced_Mode_Patch_2016_05_20.zip.

Here is a quick summary at building a bootloader, a kernel and a root filesystem for the i.MX 6 sabre sd platform, using buildroot. This assumes you have a "working" Linux development environment at hand (e.g. Debian). Buildroot is a fine build system, which makes deploying Linux on embedded platforms really easy. It is comparable to Yocto in spirit, but much simpler. Thanks to my colleague gillestalis, buildroot now has builtin support for the i.MX6 sabre sd platform. Get buildroot sources We will use git to fetch buildroot sources: $ git clone git://git.busybox.net/buildroot This should create a buildroot directory with all the latest sources (after a while). Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l '201*', and git checkout <the-desired-tag>. Compile The beauty of buildroot is that it will take care of everything for you, including preparing a cross compiler. You can download and build everything by doing: $ cd buildroot $ make freescale_imx6sabresd_defconfig $ make This should download and build everything, so it will take a while. buildroot detects the number of CPUs you have in your machine and builds with parallel jobs automatically; no need to specify any -j argument to make here. All build results fall under the output/images folder: output/images/ +- rootfs.ext2 +- rootfs.tar +- u-boot.bin `- uImage Format the SD card As for Debian, we need to format the SD card with two partitions; one small FAT partition to contain the Linux kernel, and one large ext4 partition, which will contain the root filesystem with the buildroot generated userspace. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout: +-----+------+--------+-----+---------------+----------------- | MBR |  ... | u-boot | ... | FAT partition | Linux partition ... +-----+------+--------+-----+---------------+----------------- 0     512    1024           1M              ~257M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk: Device    Boot      Start         End      Blocks   Id  System /dev/sdc1            2048      526335      262144    c  W95 FAT32 (LBA) /dev/sdc2          526336     8054783     3764224   83  Linux (units: 512B sectors) You can format the FAT boot partition with: # mkfs.vfat /dev/<your-sd-card-first-partition> Your SD card first partition is typically something in /dev/sd<X>1 or/dev/mmcblk<X>p1. You can format the Linux partition with: # mkfs.ext4 /dev/<your-sd-card-second-partition> Your SD card second partition is typically something in /dev/sd<X>2 or/dev/mmcblk<X>p2. Put on SD As explained here, u-boot should reside at offset 1024B of your SD card. Also, as buildroot generates an u-boot.bin (and not an u-boot.imx) we should skip its first KB, too. In summary, to put u-boot on your SD, do:   # dd if=output/images/u-boot.bin of=/dev/<your-sd-card> bs=1k seek=1 skip=1   # sync Your SD card device is typically something in /dev/sd<X> or /dev/mmcblk<X>. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. Similarly to what this post describes, you can copy the kernel to the FAT boot partition with: # mount /dev/<your-sd-card-second-partition> /mnt # cp output/images/uImage /mnt/ # umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or/dev/mmcblk<X>p1. And not unlike what is done in this post, You can install your generated root filesystem to the Linux partition with: # mount /dev/<your-sd-card-second-partition> /mnt # tar -C /mnt -xvf output/images/rootfs.tar # umount /mnt Your SD card second partition is typically something in /dev/sd<X>2 or/dev/mmcblk<X>p2. Boot! Your SD card is ready for booting. Insert it in the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. Like with Debian, u-boot default settings will not allow it to boot from the SD card, so we need to interrupt it by pressing enter at u-boot prompt for the first boot and setup u-boot environment to fix this: MX6Q SABRESD U-Boot > setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk1p2 rootwait' MX6Q SABRESD U-Boot > setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc dev 2; fatload mmc 2:1 ${loadaddr} ${kernel}; bootm' MX6Q SABRESD U-Boot > setenv bootcmd 'run bootcmd_mmc' MX6Q SABRESD U-Boot > saveenv Saving Environment to MMC... Writing to MMC(2)... done As this is saved in the SD card it need only to be done once at first boot. You can reboot your board or type boot; your buildroot system should boot to a prompt: (...) Welcome to Buildroot buildroot login: From there you may login as root. Enjoy! Tweak buildroot uses Linux kernel kconfig to handle its configuration. So, as for the Linux kernel, changes to the configuration can be done with e.g.: $ make menuconfig Most of the options can be tuned from there, including (most importantly) which packages get installed into the generated root filesystem. This is configuration section 'Filesystem images'. Further details are documented in buildroot manual. Tips ccache is natively supported by buildroot and can be easily enabled with configuration option BR2_CCACHE. If you only use the generated rootfs.tar as described in this post and do not care about the rootfs.ext2, you might as well save a few seconds of build by disabling its generation. This is done with configuration option BR2_TARGET_ROOTFS_EXT2. It is recommended to install an ssh server inside the target for further development. This is conveniently done with configuration option BR2_PACKAGE_OPENSSH. See also... Other root filesystems may make more sense for you; see this post for a Debian root filesystem, and this post for a minimal busybox filesystem. Freescale Yocto Project main page

Hi All, The new Android JB4.3_1.1.0-GA release is now available on www.freescale.com ·         Files available           Name Description IMX6_JB43_110_ANDROID_DOCS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Android   jb4.3_1.1.0 BSP Documentation. Includes Release Notes, User's Guide, QSG and   FAQ Sheet. IMX6_JB43_110_ANDROID_SOURCE_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Android   jb4.3_1.1.0 BSP, Documentation and Source Code for BSP and Codecs. IMX6_JB43_110_ANDROID_DEMO_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Android   jb4.3_1.1.0  BSP Binary Demo Files IMX6_JB43_110_AACP_CODEC_CODA AAC   Plus Codec for i.MX 6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX   6Sololite Android jb4.3_1.1.0 ·         Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board o   i.MX6SL EVK board ·         Release Description i.MX Android jb4.3_1.1.0 release includes all necessary codes, documents and tools to assist users in building and running Android 4.3 on the i.MX 6Quad, i.MX 6DualLite and i.MX6SoloLite hardware board from the scratch. The prebuilt images are also included for a quick trial on Freescale i.MX 6Quad and i.MX 6DualLite SABRE-SD Board and Platform, i.MX 6Quad and i.MX 6DualLite SABRE-AI Board and Platforms and i.MX6SoloLite EVK Board and Platforms. This release includes all Freescale porting and enhancements based on Android open source code. Most of deliveries in this release are provided in source code with the exception of some proprietary modules/libraries from third parties. ·         What's in this release         Android Source Code Patch All   Freescale i.MX specific patches (apply to Google Android repo)   to enable Android on i.MX based boards. For example Hardware   Abstraction Layer implementation, hardware codec acceleration,   etc. Packed in   android_jb4.3_1.1.0-ga_source.tar.gz Documents The   following documents are included in android_jb4.3_1.1.0-ga_docs.tar.gz: ●   i.MX Android jb4.3_1.1.0-ga Quick Start: A   manual explains how to run android on i.MX board by using prebuilt images. ●   i.MX Android jb4.3_1.1.0-ga User Guide: A   detailed manual for this release package. ●   i.MX Android jb4.3_1.1.0-ga FAQ: A document lists   “Frequently Asked Questions”. ●   i.MX Android Codec Release Notes: A   document to describes the Freescale Codec Package ●   i.MX Android Wi-FI Display Sink API Introduction A   document to describes how to use i.MX Android Wi-Fi Display Sink API ●   i.MX6 G2D API User Guide document to introduce how to use i.MX6 G2D API for   2D BLT usage ●   i.MX Android jb4.3_1.1.0-ga Release Note A   document to introduce the key updates and known issues in this release. Tools Tools   in android_jb4.3_1.1.0-ga_tools.tar.gz ●  MFGTool. Manufacturing tools for i.MX platform ●  USB tethering windows .inf driver configure file.tool/tetherxp.inf Prebuilt Images You   can test Android on i.MX with prebuilt image on i.MX board before building   any code. ● android_jb4.3_1.1.0-ga_image_6qsabresd.tar.gz: Prebuilt   images for the SABRE-SD board. ●  android_jb4.3_1.1.0-ga_image_6qsabreauto.tar.gz: Prebuilt   images for the SABRE-AI board. ●  android_jb4.3_1.1.0-ga_image_6slevk.tar.gz: Prebuilt images for the 6SL   SABRE-AI board. All   prebuilt images are in another package. See "i.MX Android jb4.3_1.1.0-ga   Quick Start" and "i.MX Android jb4.3_1.1.0-ga User Guide" to   understand which image should be used in which case. ·         Known issues For known issues and limitations please consult the release notes

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

Question: Two boards are used and practically identical - one using the i.MX6Solo, the other is using a Dual. The sw settings in both cases are identical (except IOMUX addresses). On the i.MX6Solo they do not see any packet loss, on the i.MX6Dual they do. I recommended modifying the MTU size, but this also did not help. So here my two questions: 1)      is there still some hw difference between the Ethernet block on the Solo and the Dual/Quad? 2)      They run the AHB at only 100MHz. Could that be a problem? If not, why do the two chips behave so differently? To increase the AHB clock to 133 MHz.appears to solve the packet corruption issue. Is the 100 MHz AHB clock really the root cause. Answer: The DualLite/Solo and SoloLite contain different ethernet controllers. The DL/S has a 1000M controller which requires the AHB bus to be greater than 125MHz, while the SL has a 100M controller. As the question was about the Solo and the Dual and both use the Gigabit Ethernet block I assume that both will require a minimum AHB clock of 125MHz.

Question: What is minimum requirement for VDDSNVS_IN voltage to keep RTC timing info in SNVS block? In the datasheet, there is requirement for VDDSNVS_IN input and it is 2.9V to 3.3V. Is it recommended requirement for RTC operation? Other security function is not used in SNVS and just interested in basic RTC fuction after power off. Answer: The finall answer is tha to folow our datasheet saying for no matter if you are only RTC keeping application. "The SNVS regulator takes the SNVS_IN supply and generates the SNVS_CAP supply which powers the real time clock and SNVS blocks. If  VDDHIGH_IN is present, then the SNVS_IN supply is internally shorted to the VDDHIGH_IN supply to allow coin cell recharging if necessary. The output voltage is roughly one third(1/3) of SNVS_IN. -- in the SNVS_CAP powered on-chip logics, need min 0.9v for normal operation, we can only guarantee the operation in this condition, whih means min SNVS_IN = 3*SNVS_CAP = around 2.7. with some margin, so min 2.8v is the requireent. Again, we can only guarantee the operation in this condition(VDD_SNVS_CAP >0.9v). The datasheet is correct : VDDSNVS_IN must not be less than 2.8 V (Table 6. Operating Ranges, of IMX6DQCEC,  Rev. 2.2, 07/2013 )  I guess you talked about operating condition in ON mode. In case of OFF mode, VSNVS output of PFUZE depends on LICELL input power and usually coincell can supply under 2.5V output. According to PFUZE spec, VSNVS output in OFF mode is under 1.8V. And as I know, LP (low power) part of SNVS is only operation al in OFF mode so I don't think VDDSNVS_IN requires over 3V in that condition. In my assumption, SNVS can maintain itis data and RTC if VDDSNVS_IN is over 1.1 ~ 1.3V in OFF mode but I just want to know what is our spec for it. If we consider low power modes of the i.MX6, then - according to Table 10 (Stop Mode Current and Power Consumption) of IMX6DQCEC, Rev. 2.3, 07/2013 (for example) - in "SNVS Only" mode VDD_SNVS_IN of 2.8V is considered. Here 2.8 V is taken as minimal value. At least, as we can see, there are no other specifications.

Hi All, The new i.MX 6 Q/D/DL/S/SL L3.0.35_4.1.0 GA release is now available on the http://www.freescale.com/site. ·         Files available                                   # Name Description 1 L3.0.35_4.1.0_LINUX_DOCS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Linux BSP   Documentation. Includes Release Notes, Reference Manual, User guide. API   Documentation 2 L3.0.35_4.1.0_LINUX_MMDOCS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Multimedia Codecs Documentation.   Includes CODECs Release Notes and User's Guide 3 L3.0.35_4.1.0_SOURCE_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Linux BSP   Source Code Files 4 L3.0.35_4.1.0_MM_CODECS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Multimedia Codecs Sources 5 L3.0.35_4.1.0_AACP_CODECS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux AAC Plus Codec 6 L3.0.35_4.1.0_DEMO_IMAGE_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Binary Demo Files 7 L3.0.35_4.1.0_UBUNTU_RFS_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux File System for the Ubuntu Images 8 i.MX_6D/Q_Vivante_VDK_146_Tools Set   of applications for the Linux L3.0.35_4.1.0 BSP, designed to be used by   graphics application developers to rapidly develop and port graphics   applications. Includes applications, GPU Driver with vprofiler enabled and   documentation. 9 IMX_6DL_6S_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6DualLite and i.MX   6Solo. 10 IMX_6DQ_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6Quad and i.MX 6Dual. 11 IMX_6SL_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6Sololite. ·         Target HW boards o   i.MX 6Quad SABRE-SDP o   i.MX 6Quad SABRE-SDB o   i.MX 6Quad SABRE-AI o   i.MX 6DualLite SABRE-SDP o   i.MX 6DualLite SABRE-AI o   i.MX 6SL EVK ·         New features o   BSP New Features on i.MX 6D/Q, i.MX 6DL/S and MX 6SL: §  HDCP §  CEC §  GPU4.6.9p12 §  Audio playback IRAM/SDMA §  V4L capture resize on MX6SL §  MX6DQ disable the double line fill feature of PL310 ·         Known issues o   For known issues and limitations please consult the release notes.

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.

Q: How to setup camera under Android? helping a customer (RTX) debug some issues with camera. They're using i.MX 6Solo and Android 13.4-GA on custom hardware. They added a new camera driver which seems to work when using small console capture program (no gui, no preview), so the route from camera to /dev/video0 seems to work. However, when they try to use camera from Android, entire system freezes. They located the crash to following line in ipu_common.c which basically enables camera CSI0: ipu_cm_write(ipu, reg | IPU_CONF_CSI0_EN, IPU_CONF); While investigating IPU setup, we noticed that CPMEM setup for IDMAC channel 0 is "off": ch 0 word 0 - 00000000 25800000 00000000 E0000000 00077C4F ch 0 word 1 - 01B086B0 00394EC0 0087C000 00009FC0 0000027F As seen from above, EBA0 points to 0x0D843580 and EBA1 to 0x0E53B000, which is in EIM memory space, not DDR memory space, which probably causes issues. We're not sure what could be causing this as camera driver doesn't provide any such address and mostly just handles communication to camera chip. But something gets off in Android framework and we could use any hints about what to look for. A: You can reference to the "i.MXAndroidR13.4GAAdvancedUserGuide.html" "3 Camera&Video Recorder customization" for how to change the camera in Android. Another thing needs be checked is the camera sensor driver, you can reference to "kernel_imx\drivers\media\video\mxc\capture\ov5642.c", "static struct v4l2_int_ioctl_desc ov5642_ioctl_desc", did you implemented the same v4l2_int_ioctl_desc functions? Customer HW is set up so that DDR memory space starts at 0x80000000. This causes problems in myandroid/hardware/imx/mx6/libcamera/CamerHAL.cpp when obtaining buffer addresses where camera should store data. GPU will only return OFFSET into 2GB memory space it can address, so it will return an address below 0x80000000. This needs to be adjusted before passing onto V4L2 when starting capturing.