When working on the IOMUX settings of an i.MX processor for our design it’s always good to make use of the IOMUX Tool provided by Freescale on the Download Page of most i.MX processors. We’ll focus on the latest release of the IOMUX tool for i.MX6. The IOMUX tool provides a Graphic User Interface to easily assign internal signals to external pins/balls and resolve any potential pin conflict and muxing options for the different modules available on the i.MX processors. IOMUX Tool Download (Will request to log in) Freescale’s Boards IOMUX settings. On the IOMUX tool package you’ll find the User’s Manual and also a folder containing the muxing options for Freescale’s Reference Boards, which may be of help when working with the Reference Designs as a starting point. You may load these settings files using the file/open option. MMDC pins Since the Multi-mode DDR controller MMDC pins are not muxed these cannot be changed on the IOMUX tool. This because the memory interfaces are much more sensitive to interference and thus have dedicated pins that do not share pad with other signals. The registers are also set on the default value so it’s good to keep this in mind when working with the code provided by the IOMUX tool. Considerations when using generated code The tool can generate code to be used as reference of the IOMUX configuration but still requires manual tweaking and the header files available on the i.MX Processor’s BSP in order to be implemented in an actual application code. It’s important to review the register settings on the Register tab in order to export the desired values; otherwise the code will have the default values for the registers according to the IOMUX tool. This is especially true for the Daisy Chain settings, always manually review these. Import function limitations There is an import function available so IOMUX configuration files saved in previous versions of the IOMUX tool can be loaded on the newest version. However, this feature should be used carefully. When importing a design it’s recommended to save the imported design on the new version of the IOMUX tool as imported.xml; then opening a new configuration and saving it as new.xml and comparing register value differences to manually correct the imported.xml values. In small projects it might be recommended to manually load the IOMUX information on the new IOMUX tool version to avoid register conflicts from version to version. For more information please refer to the documentation available within the IOMUX tool package. An advanced example is also included in that document.

Whenever possible is always better to avoid Virtual Machines when compiling Android as the building process might take several hours to even a day or two depending on the resources available to the Virtual Machine. Sometimes, however, a VM is the only option available and here are some useful considerations when using a VM as a host for Android builds. This document addresses some of the requirements for the Kit-Kat Freescale Android BSP although some may also apply to the general Android releases. It’s recommended to use Ubuntu 12.04 64-bits as Host OS. As for HDD space, which is often a limited resource when using VM, Google states that at least 30GB of disk space in order to build the Android Tree. In practice, however, it’s recommended to allocate at least 100GB to the VM HDD if possible, as additional packages and larger images can quickly deplete disk space. Installing Java (not VM specific) It’s recommended (albeit not mandatory) to uninstall any version of Java other than the recommended for the specific Android release for which we will build. In the case of Kit-Kat this is Java 6. Another option is to just switch the java alternatives to the ones we want to use for Android. There is a document with the exact instructions on how to install the required JKD on the following link. How to install Sun's JDK in Ubuntu for Android build Starting KitKat, however, it’s also necessary to install javap (Java Class File Dissasembler) so please also add these steps when following this document. $ sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk1.6.0_45/bin/javac 1 $ sudo update-alternatives --config javac Memory considerations when using a Virtual Machine Using a Virtual Machine slows down the image building considerably. Besides that memory system is often also an issue. Having insufficient RAM especially on the linking part of the image build may cause a number of issues that are difficult to troubleshoot. In these cases it’s good to take a look at the resource monitor to see if indeed the RAM was depleted. One way to make up for the limited RAM is using a bigger swap. Google recommends at least 16GB of RAM/swap so it’s not uncommon to create a 10GB swap when working in VM, to do this please use the following commands. $ sudo fallocate -l 10g /mnt/10GB.swap $ sudo chmod 600 /mnt/10GB.swap $ sudo mkswap /mnt/10GB.swap $ sudo swapon /mnt/10GB.swap This will helps with the memory requirements but won’t speed up the build process. Building time with VM, as previously stated, will take several hours or even a couple of days depending on computing power.

Attached you can find a document that explains how to add Wi-Fi support in the iMX28evk using Yocto.

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"  

** If you cannot access the www.youtube.com you may watch the Wi-Fi Display Sink Demo in here: ** ********      http://v.youku.com/v_show/id_XNzczMzQ2MTc2.html             ******** We already have the strong i.MX 6 to support the Android kitkat now. So we also develop the WiFi Display Sink in it. With Wi-FI Display technology we can cast the screen and audio to another one via Wi-Fi P2p. It's also named the Miracast. Freescale extends Android by offering a Wi-Fi Display Sink feature. The Wi-Fi hardware module used for this feature are the Realtek RTL8821AS , RTL8723AS and AR6233 SDIO Cards. But the design of this feature allows porting to any Wi-Fi hardware module. Using the Freescale Wi-Fi Display Sink API and the demonstration application, users can easily develop their own Sink Application. This feature has been verified using several of the most popular Android phones and tablets. Our Wi-Fi Display has the following highlight feature: Low latency Support UIBC (When Source device uses Freescale Android maddev_kk4.4.3-2.0.0) Rapid recovery from network congestion Compatibility to different vendor Wi-Fi chips and Wi-Fi Display devices From the demo video we can cast the stopwatch and measure the latency by it. Here are the high quality video shots and we can calculate the real latency which less than 200ms!      For the WiFi Display Spec the orange ones in below figure were achieved in our WiFi Display. Reference pages:       Miracast - Wikipedia       Wi-Fi CERTIFIED Miracast | Wi-Fi Alliance             For more information and details about Wi-Fi Display Sink in i.MX6, please send inquiry to [email protected] .

Since JB4.3, we have added a customer library in myandroid/devices/fsl/common/recovery to give a chance for customer to customize their UI menu in recovery.img Be sure you define the TARGET_RECOVERY_UI_LIB to be same as your defined in Android.mk in myandroid/devices/fsl/common/recovery, as we did in myandroid/devices/fsl/imx6/BoardConfigCommon.mk TARGET_RECOVERY_UI_LIB := librecovery_ui_imx Once you defined TARGET_RECOVERY_UI_LIB, myandroid/bootable/recovery will use the one to replace the default ui lib  as the source code myandroid/bootable/recovery/default_device.cpp. By default, we define below menu as below: const char* ITEMS[] = { "reboot system now",   "apply update from ADB",   "wipe data/factory reset",   "wipe cache partition",   NULL }; Below is an example to add a new menu as "apply update from SD Card": diff --git a/common/recovery/recovery_ui.cpp b/common/recovery/recovery_ui.cpp index ccf8ccd..9cbd91e 100644 --- a/common/recovery/recovery_ui.cpp +++ b/common/recovery/recovery_ui.cpp @@ -31,6 +31,7 @@ const char* HEADERS[] = { "Volume up/down to move highlight;", const char* ITEMS[] = { "reboot system now",   "apply update from ADB", + "apply update from SD Card",   "wipe data/factory reset",   "wipe cache partition",   NULL }; @@ -77,8 +78,9 @@ class ImxDevice : public Device { switch (menu_position) { case 0: return REBOOT; case 1: return APPLY_ADB_SIDELOAD; - case 2: return WIPE_DATA; - case 3: return WIPE_CACHE; + case 2: return APPLY_EXT; + case 3: return WIPE_DATA; + case 4: return WIPE_CACHE; default: return NO_ACTION; } } The handle on the menu is defined in function prompt_and_wait(Device* device, int status) in myandroid/bootable/recovery/recovery.cpp. Below is the buildin menu function in recovery.     enum BuiltinAction { NO_ACTION, REBOOT, APPLY_EXT, APPLY_CACHE,   APPLY_ADB_SIDELOAD, WIPE_DATA, WIPE_CACHE };

The i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.1 patch release is now available in the Freescale git. The issue fixed is a GPU issue, for 2D GPU cores there is a potential need to manage the maximum number of outstanding return requests from the memory subsystem. The proper way to manage these for 2D cores with this configuration is to use a FLUSH. The patch does a FLUSH after every DRAW, the pipe will not overfill and the scenario which may lead to a stall will not occur. The instruction to get the patch are in the Readme on the git, under this link: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.17-1.0.1_ga

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

Setting up the clocks for PCIe is a bit tricky, especially for bare-metal or if not using the Linux BSP. The ENET PLL (PLL6) 100 MHz (SATA) PFD output MUST be enabled in order to access the registers in the PCIe IP block. (To enable this clock, set CCM_ANALOG_PLL_ENET[ENABLE_100M (bit 20)].) This is not well documented in the RM, but follow these steps to insure reliable performance.

Q: To minimize i.MX6DL power consumption at stop mode, but needs i.MX6DL to wake-up by USB resume signal from Host PC. Can LDO_2P5(VDDHIGH_CAP) be powered off at stop mode in order to resume i.MX6DL by a USB resume signal that Host PC sends to i.MX6DL USBOTG(us as device mode only)? In other words, can USB OTG detect resume signal from Host PC and generate wakeup interrupt during stop mode with following LDO condition? -          LDO_USB is enabled and powered by USB_OTG_VBUS. -          LDO_2P5 is disabled during stop mode. -          LDO_1P1 is enabled during stop mode. The system uses LPDDR2, hence LDO_2P5 can be powered off at stop mode(I know this is not allowed for DDR3 as DDR IO need 2P5 as pre-driver). Actually tested on SDP, the system can not be resumed without LDO_2P5 as DDR IO need 2P5 for DDR3. A: Please note that disabling the LDO_2P5 supply, you are also disabling the DRAM, as the DRAM pre-drivers are powered by this supply(!). SDCKE is pulled down on the board, and it ensures that the DRAM is in proper state during DSM without LDO_2P5 power. we recommend to keep LDO_2P5 on at any mode(include DSM mode). ldo_2p5 is also one of power for USB phy.   4.3.2.2 LDO_2P5 The LDO_2P5 module implements a programmable linear-regulator function from VDD_HIGH_IN. The LDO_2P5 supplies the SATA Phy, USB Phy, LVDS Phy,   Actually I have tested on SDP, but we cannot resume the system without LDO_2P5 as DDR IO need 2P5 for DDR3.

Seeing a block diagram in IMX6SLRM 1.5.1, it looks like i.MXSL has Touch Panel Control. Is there interfaces for touch panel  in IMX6SL? Otherwise if I build HW using ADC or GPIO, can I be provided some SW drivers? Regards. The i.MX6 SL does not have embedded touch / ADC interface, sorry. Have a great day, Yuri ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! ----------------------------------------------------------------------------------------------------------------------- This document was generated from the following discussion: 

Q: In mfgtool release 1.0.0 I, "Support only Cortex-A5 as primary boot core (Cortex-M4 boot is not supported on this release)." When will a version supporting M4 boot first be available? A: Mfg tool is based on it's counterpart, the ROM code. Rom code is for the A5 and not for the M4 as a matter of fact if you boot with the M4 and the device doesn't enumerate on the USB port at all then you know why and the MfgTool won't be able to do anything about it. Currently there no plans to provide a MfgTool version that supports boot from M4 core. Customers can modify the exisiting code to make it work with M4 as primary core. Booting from USB with the M4 core should work. The image that is booted must be for execution on M4 (thumb mode). MfgTool uses u-boot and a micro linux kernel to download images and program memories. This Linux can only run on the A5 core. To make it work with the M4 core as primary, it should be sufficient to add some code to the exisiting A5 images. Code will execute on M4 and start the A5 at the proper address as if it is booted from the A5.

Q: To do a triple display demo based on imx6 SDP. The 3 channel are 1 lvds & 1hdmi & 1 lcd  and the OS is Android JB4.3. The dual display works and those 2 screens can all display the Android desktop. The setting as below. setenv bootargs console=ttymxc0,115200 init=/init rw video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb1:dev=lcd,CLAAWVGA,if=RGB565 video=mxcfb2:off video=mxcfb3:dev=hdmi,1920x1080M60,if=RGB24 fbmem=10M fb0base=0x27b00000 vmalloc=400M androidboot.console=ttymxc0 androidboot.hardware=freescale static struct ipuv3_fb_platform_data sabresd_fb_data[] = {         { /*fb0*/         .disp_dev = "lcd",         .interface_pix_fmt = IPU_PIX_FMT_RGB565,         .mode_str = "CLAA-WVGA",         .default_bpp = 16,         .int_clk = true,         .late_init = false,         }, {         .disp_dev = "ldb",         .interface_pix_fmt = IPU_PIX_FMT_RGB666,         .mode_str = "LDB-XGA",         .default_bpp = 16,         .int_clk = false,         .late_init = false,             }, {         .disp_dev = "ldb",         .interface_pix_fmt = IPU_PIX_FMT_RGB666,         .mode_str = "LDB-XGA",         .default_bpp = 16,         .int_clk = false,         .late_init = false,         }, {         .disp_dev = "hdmi",         .interface_pix_fmt = IPU_PIX_FMT_RGB24,         .mode_str = "1920x1080M60",         .default_bpp = 16,         .int_clk = true,         .late_init = false,             }, }; static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {         .ipu_id = 1,          .disp_id = 1, }; 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 = 1,         .sec_disp_id = 0, }; A: Android BSP doesn't support triple display, and so the change in kernel would not make the 3rd display work.

For more information visit: http://www.silexamerica.com/freescale/index.html Andy C. Ross, our Field Applications Engineer, demonstrates how to enable wireless connectivity to your i.MX 6 platform. This 6-minute video tutorial shows how easy it is to enable Wi-Fi on your Freescale platform using Silex's evaluation kit, the SX-6K3-EVK-SD. The SX-6K3-EVK-SD is designed to provide the optimum platform with which to evaluate the Wireless Radio Module and Silex Radio Driver with the Freescale’s i.MX6 processor on the Sabre Smart Devices board. This video walks you step by step on how to enable Wi-Fi connectivity for your i.MX 6 Platform.

For more information visit: http://www.silexamerica.com/freescale/index.html Informational video on why Silex Technology is the only manufacturer of Freescale-recommended Wi-Fi solutions for your i.MX 6 Platform.