Design Check Lists: HW Design Checking List for i.MX6DQSDL HW Design Checking List for i.Mx53 Hardware Design Checklist for i.MX28 HW_Design_Checking_List_for_i.MX6SoloX i.MX6UL Hardware design checklist   DDR Design Tool: I.MX53 DDR3 Script Aid imx53 DDR stress tester V0.042 i.Mx6DQSDL DDR3 Script Aid MX6DQP DDR3 Script Aid i.Mx6DQSDL LPDDR2 Script Aid i.Mx6SL LPDDR2 Script Aid i.MX6SX DDR3 Script Aid I.MX6UL DDR3 Script Aid i.MX6UL_LPDDR2_Script_Aid i.MX6ULL_DDR3_Script_Aid  i.MX6ULL_LPDDR2_Script_Aid  MX6SLL_LPDDR2_Script_Aid  MX6SLL_LPDDR3_Script_Aid  i.MX6 DDR Stress Test Tool V1.0.3 i.MX6/7 DDR Stress Test Tool V3.00 i.MX8MSCALE DDR Tool Release  i.MX8M DDR3L register programming aid  i.MX 8/8X Family DDR Tools Release   Application Notes: MX_Design_Validation_Guide I.MX6 series USB Certification Guides

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.

This is a workaround—this page needs to be updated to add instructions for multi-touch support. Based on Freescale BSP 11.05. The LVDS panel (MCIMX-LVDS1) has a serial multi-touch controller, eGalax. As a workaround to have it supported on directly on Qt, we can force the driver to behave as a single touch. To do this: 1 - Edit the file ltib/rpm/BUILD/linux-2.6.35.3/drivers/input/touchscreen/egalax_ts.c adding the following line: + #define FORCE_SINGLE_POINTER_SUPPORT 1 2 - Compile the kernel ./ltib -m scbuild -p kernel 3 - Copy the new kernel to Card/Memory and boot it. 4 - Start your Qt app: $ Xfbdev -screen 1024x768 -mouse tslib,,device=/dev/input/event0  & $ export DISPLAY=:0.0 $ ./yourQTapp Note: You can read the touch events with "evtest" $ evtest  /dev/input/event0 or tslib apps: $ export TSLIB_TSDEVICE=/dev/input/event0 $ ts_print

Software Update and Recovery The information reproduced above is from Android User Guide R10.2, found into Android release package. It is possible to format the /data and /cache partitions or update software based on a update script using recovery mode as follows: Prepare for all Android source code that assumed to be saved in ~/myandroid directory. Prepare for ADB over USB. make sure that ADB over USB is ok. USB cable is connected. Refer to i.MX51 Android ADB over USB section for more information. Connect the UART to the PC and open a terminal to check for printed messages Enter the recovery by manual for imx51_BBG board:       setenv bootargs_android_recovery 'setenv bootargs ${bootargs} init=/init root=/dev/mmcblk0p4 rootfs=ext4 di1_primary'       setenv bootcmd_android_recovery 'run bootargs_base bootargs_android_recovery;mmc read 0 ${loadaddr} 0x800 0x2000;bootm'       run bootcmd_android_recovery For imx53_SMD board:       setenv bootargs_android_recovery 'setenv bootargs ${bootargs} init=/init root=/dev/mmcblk0p4 rootfs=ext4'       setenv bootcmd_android_recovery 'run bootargs_base bootargs_android_recovery;mmc read 0 ${loadaddr} 0x800 0x2000;bootm'       run bootcmd_android_recovery When system has completed bootup,  You will see this screen: You can press "MENU" "HOME" or "F1" (by USB keyboard, for developer)" going to the text menu like this: Select the required option using the direction keys on the keypad or keyboard. Apply sdcard:update.zip, you may update the software from update.zip as shown in the following example: Copy this directory from android source code myandroid/bootable/recovery/etc to a tempepory directory, such as ~/recovery. cd ~/recovery and remove init.rc from this directory. Edit ./META-INF/com/google/android/updater-script according to the required commands. for example, in order to format /system partition and use update.zip to update system partition, copy whole the entire content directory to system partition, all commands are found in ~/myandroid/bootable/recovery/update/install.c You must notice, when your signing the zip package, it will lose ALL of the permission information, you need to set the right permission in the script. You can find the example in ./META-INF/com/google/android/updater-script Copy update-binary, Copy out/target/product/YOU_PRODUCT/system/bin/updater to ~/recovery/META-INF/com/google/android/update-binary Create a directory called system and copy some files you would like to update to ./system. Create a directory called res to save the public key of your system.         fsl@fsl-desktop:~/recovery$ mkdir res         fsl@fsl-desktop:~/recovery$ ~/myandroid/out/host/linux-x86/framework/dumpkey.jar ~/myandroid/build/target/product/security/testkey.x509.pem > res/keys Create a package called recovery.zip using the zip command         fsl@fsl-desktop:~/recovery$zip recovery.zip -r ./META-INF ./system ./res recovery.zip is located in the current directory. Then create a digital signature for recovery.zip package as follows.         fsl@fsl-desktop:~/recovery$ cd ~/myandroid         fsl@fsl-desktop:~/myandroid$ make signapk         fsl@fsl-desktop:~/myandroid$ cd ~/recovery         fsl@fsl-desktop:~/recovery$ java -jar ~/myandroid/out/host/linux-x86/framework/signapk.jar -w ~/myandroid/build/target/product/security/testkey.x509.pem ~/myandroid/build/target/product/security/testkey.pk8 recovery.zip recovery_signed.zip recovery_signed.zip is located in the current directory. Copy it to the SD card using ADB         fsl@fsl-desktop:~/recovery$ adb push recovery_signed.zip /sdcard/update.zip update.zip is completed and the system is updated based on the commands in the update-script. Check for error messages on the LCD. Wipe data/factory reset. /data and /cache partitions are formatted. Wipe cache partition. /cache partition is formatted. Reboot the system.

DirectFB DirectFB is a thin library that provides hardware graphics acceleration, input device handling and abstraction, integrated windowing system with support for translucent windows and multiple display layers, not only on top of the Linux Framebuffer Device. It is a complete hardware abstraction layer with software fallbacks for every graphics operation that is not supported by the underlying hardware. DirectFB adds graphical power to embedded systems and sets a new standard for graphics under Linux. [Source: directfb.org] DirectFB Quick Test Select DirectFB in Package List on LTIB1011: [x] DirectFB Select also DirectFB examples: [x] DirectFB examples Build your Linux. Flash your SD card. Launch your Linux image on your board, and then launch a DirectFB example: $ df_dok DirectFB benchmark is launched. Benchmark result on an i.MX 53 EVK:

The ARD has 2 LVDS connectors, one on the CPU board and a second one on the main board, the LVDS panel (MCIMX-LVDS1) can be connected to these. To enable two independent displays on the Linux BSP 11.05: 1. On u-boot, use the following on the kernel command line for video: video=mxcdi0fb:RGB666,XGA di0_primary ldb=di0 video=mxcdi1fb:RGB666,XGA ldb=di1 2. After boot use  memtool to write to the LDB registers to map each LVDS to a display interface: root@freescale ~$ /unit_tests/memtool -32 0x53fa8008=0x0000020d Writing 32-bit value 0x20D to address 0x53FA8008 3. Unblank framebuffer 1: echo 0 > /sys/class/graphics/fb1/blank On the Freescale Linux BSP 11.09 the LDB register write is not needed: 1. On U-boot, use the following on the kernel command line for video: 'video=mxcdi0fb:RGB666,XGA di0_primary ldb=separate,di=0,di=1,ch0_map=SPWG,ch1_map=SPWG video=mxcdi1fb:RGB666,XGA' 2. Unblank framebuffer 1: echo 0 > /sys/class/graphics/fb1/blank

Enabling Dual Display in Ubuntu with the i.MX53 Quick Start Board Here you will learn how to enable two displays in a Ubuntu system running in an iMX53 Quick Start Board. We assume here that you already have a micro SD card with a valid Ubuntu image (including uboot, Linux kernel and Ubuntu filesystem). You can use the original SD card that comes with the i.MX53 Quick Start Board, which brings an image of Ubuntu or, if you do not have the original SD card, you can reproduce it by downloading Ubuntu binaries package (L2.6.35_MX53_ER_1101_IMAGE) from Freescale iMX53qsb download area. You will also need to update U-boot and kernel binaries in the SD card with more recent images. You can find the most recent binaries (L2.6.35_MX53_ER_1109_IMAGE_) from Freescale iMX53qsb download area as well. Introduction To enable dual display, you need to perform two tasks: Enable two displays at kernel level Configure your Xorg server accordingly Enabling Two Displays at Kernel Level To enable two displays at kernel level means to map one display interface to fb0 device and the other to fb1 device. So first thing is to choose which interface will be the primary one, mapped as fb0. As an example, we consider the VGA interface as primary in this tutorial. Second thing is to choose one of the other available external video interfaces to be secondary, mapped as fb1 device in the system. We consider the 4.3" seiko LCD display in this tutorial as the secondary interface. Once chosen primary and secondary interfaces, we need to configure kernel video arguments accordingly. The arguments are available in specific variables in the U-boot that comes with the Ubuntu binaries. You can see them (HDMI, VGA, etc.) by printing the U-boot environment variables from the U-boot shell, but you will probably not find those variables in other versions of U-boot and their contents will probably need to be adapted to the kernel version in use, as arguments recognized by kernel modules varies considerably between kernel versions. You can always refer to the Linux Release Notes documents for video arguments. It's available for each Linux BSP that can be found on the Freescale website. For the 1109 BSP, we have the following video arguments (extracted from i.MX53_START_Linux_BSP_Release_Note.pdf that comes with L2.6.35_11.09.01_ER_docs.tar.gz downloaded from here - IMX53_1109_LINUXDOCS_BUNDLE😞 VGA: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga SEIKO LCD: video=mxcdi0fb:RGB24,SEIKO-WVGA di0_primary Both are considered primary, because these are the arguments for single display setups. Now that we have video arguments for both desired interfaces, we only need to merge them together removing the primary argument from the one that is the secondary. In our case, we need to pass the following arguments to the kernel: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga video=mxcdi0fb:RGB24,SEIKO-WVGA For this, we can add these arguments to one of the variables that are used in the boot process. We can add the content to bootarg_base, for instance. In the U-boot command line, execute following commands to setup the environment: setenv vga_and_seiko 'video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga video=mxcdi0fb:RGB24,SEIKO-WVGA' setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 vga_and_seiko' saveenv After applying a reset and booting the board, you shall have both interfaces enabled, but the secondary will not be used by the Xorg server until we complete the next step. Configuring Xorg Server Now that we have two video interfaces properly configured and mapped to /dev/fb0 and /dev/fb1 devices, we need to tell Xorg server how to use them. Here is an example of xorg.conf file that you can use to replace the default one, found at /etc/X11: Section "InputDevice" Identifier     "Generic Keyboard" Driver          "kbd" Option          "XkbRules"     "xorg" Option          "XkbModel"     "pc105" Option          "XkbLayout"     "us" EndSection  Section "InputDevice" Identifier     "Configured Mouse" Driver          "mouse" Option          "CorePointer" EndSection  Section "Device" Identifier     "i.MX Accelerated Framebuffer Device 0" Driver          "imx" Option          "fbdev"               "/dev/fb0"  # This option only recognized when "mxc_epdc_fb" frame buffer driver in # use.  Values are "RGB565" (default, 16-bit RGB), "Y8" (8-bit gray), # and "Y8INV" (8-bit gray inverted). Option          "FormatEPDC"               "Y8INV"  EndSection  Section "Device" Identifier     "i.MX Accelerated Framebuffer Device 1" Driver          "imx" Option          "fbdev"               "/dev/fb1"  EndSection  Section "Monitor" Identifier     "Configured Monitor 0" EndSection  Section "Monitor" Identifier     "Configured Monitor 1" EndSection  Section "Screen" Identifier     "Screen 0" Monitor          "Configured Monitor 0" Device          "i.MX Accelerated Framebuffer Device 0"  # These "Display" SubSection's are needed for working with the # "mxc_epdc_fb" frame buffer driver. SubSection     "Display" Depth     8 Visual     "StaticGray" EndSubSection SubSection     "Display" Depth     16 Visual     "TrueColor" EndSubSection EndSection  Section "Screen" Identifier     "Screen 1" Monitor          "Configured Monitor 1" Device          "i.MX Accelerated Framebuffer Device 1" EndSection  Section "ServerLayout" Identifier     "Xinerama Layout" Screen          "Screen 0" Screen          "Screen 1" RightOf "Screen 0" EndSection  Section "ServerFlags" Option          "Xinerama"          "true" EndSection Results The following picture shows the i.MX 53 QSB running the extended desktop previously configured. You can see the VGA monitor with a Firefox instance and the SEIKO LCD display with a calc instance.

<analytics uacct="UA-5520491-1" /> How to enable WIFI support for i.MX53 QSB Android After applying every QSB patch, enable WiFi support according to your hardware. Android R4 can be downloaded from Adeneo´s website. AR6102  Change file device/fsl/imx53_loco/BoardConfig.mk -BOARD_WLAN_CHIP_AR6102  := false +BOARD_WLAN_CHIP_AR6102  := true AR6003  Change file device/fsl/imx53_loco/BoardConfig.mk -BOARD_WLAN_CHIP_AR6003  := false +BOARD_WLAN_CHIP_AR6003  := true After complete build ar6000.ko will be created under /system/etc/modules To turn WIFI on, go to Settings > Wireless & network s > Wi-Fi Error message case  In case logcat shows the following error message: E/WifiHW  ( 2086): Cannot access "/data/misc/wifi/wpa_supplicant.conf":Permission denied Reconfigure nfs server file /etc/default/nfs-kernel-server delete this line:   RPCMOUNTDOPT=--manage-gids

LTIB Creating Uimage Uboot Configuration file for fw_(printenv/saveenv) utility Add new i.MX5x board on LTIB LTIB Creating Uimage Uboot U-boot expects uImage format for the kernel image. In order to LTIB generate a uImage file: $ export SYSCFG_KTARG=uImage $ ./ltib -p kernel Setup in U-Boot the kernel bootargs: u-boot> setenv bootargs noinitrd console=ttymxc0,115200 init=/linuxrc root=/dev/nfs nfsroot=10.29.244.27:/tftpboot/rootfs ip=dhcp Change 10.29.244.27 to your host IP. The procedure above is needed when default bootloader used by ltib was redboot. In some ltib releases (before 2010) default bootloader is u-boot. In this case, ltib will create uImage by default Configuration file for fw_(printenv/saveenv) utility # Configuration file for fw_(printenv/saveenv) utility. # Up to two entries are valid, in this case the redundant # environment sector is assumed present. # Notice, that the "Number of sectors" is ignored on NOR.               # MTD device name Device offset Env. size Flash sector size Number of sectors #/dev/mtd1 0x0000 0x4000 0x4000 #/dev/mtd2 0x0000 0x4000 0x4000 # NAND example /dev/mtd0 0x80000 0x40000 0x20000 2 Add new i.MX5x board on LTIB 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 )   ...

The ARD has the VGA output hw multiplexed with the on board Eth controlling, on jumpers J14 and J16. If using the VGA out one option for network is to use an USB/Eth adapter. To enable this (tested on BSP 11.05 - 2.6.35): 1. Find out the driver for the adapter you are using. You can connect it to your Linux host for that. $ lsusb ... Bus 002 Device 017: ID 0b95:772a ASIX Electronics Corp. ... $ dmesg | tail ... [3799653.662846] eth2: register 'asix' at usb-0000:00:1d.7-2, ASIX AX88772 USB 2.0 Ethernet, 00:60:6e:00:02:7a ... 2. Enable the driver on the target's kernel: - ./ltib -c - On Ltib menu, select "[*] Configure the Kernel" - On the kernel menuconfig select the driver, in this case: CONFIG_USB_NET_AX8817X located at: -> Device Drivers                                                       -> Network device support (NETDEVICES [=y])         -> USB Network Adapters             -> Multi-purpose USB Networking Framework (USB_USBNET [=y]) 3. Program the kernel to SD: sudo dd if=rootfs/boot/uImage of=/dev/sdd bs=512 seek=2k 4. Set U-boot to load the kernel from the SD and NFS: MX53-ARD-DDR3 U-Boot > set bootcmd 'run bootcmd_sd_nfs' MX53-ARD-DDR3 U-Boot > set bootcmd_sd_nfs 'run bootargs_nfs;run load_kernel;bootm' MX53-ARD-DDR3 U-Boot > set load_kernel 'mmc read 0 ${loadaddr} 0x800 0x1f00' Here you may change the ip from "dhcp" to a fixed address if you are connected directly to host. MX53-ARD-DDR3 U-Boot > set bootargs_nfs 'set bootargs console=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp' MX53-ARD-DDR3 U-Boot > set serverip 192.168.2.100 MX53-ARD-DDR3 U-Boot > set nfsroot '/tftpboot/rootfs_ard' MX53-ARD-DDR3 U-Boot > save Saving Environment to MMC... Writing to MMC(0)... done 5. Connect the USB/Eth adapter to the USB port (USB1-J30 or USB2-J31). Instructions to setup the host for NFS can be found on the following page: All Boards NFS.

This example is useful  if you have your device connected to a host machine using a USB cable, and you want your host machine to be able to update your device using a protocol ready to go. Information you need prior to using this example Fastboot is a protocol used to update firmware in Android devices from a host over USB; Freescale implements fastboot as a uboot driver for the device and the implementation is available from patches applied to uboot source code; By default, fastboot is only enabled when building uboot to use with an Android BSP; To run fastboot at the device in default implementation you need to call it from uboot command line (using the debug serial port of the slave device, for example); The host fastboot application is available as source code from Google. You can build your own fastboot(.exe) binary (which is not in the scope of this howto), or you can find a binary ready for you to go searching the web; You are required to be familiar with Linux BSP and have i.MX53 BSP version 11.05 installed. With this information in mind, what do you get from this example? Patch for uboot to enable fastboot driver for iMX53 Quick Start Board with a new spec file; A command line application that set a flag in iMX53 to automatically start fastboot after a reset, either if it is a SOFT or a HARD reset. How to prepare the example Copy uboot patch file (attached) to /opt/freescale/pkgs; Replace your uboot spec file (u-boot.spec.in attached) in <bsp_root>/ltib/config/platform/imx/; Build a system image for iMX53 Quick Start Board with the packages you need; Build the command line application (setbootmode.c attached) using ltib shell; Prepare an SD card copy the command line application /usr/sbin in your SD card system partition. See attachment to this page. How to test the example Boot the Quick Start Board with the SD card you prepared; Login as root using a serial cable and a terminal application; Run setbootmode application as follows: $ setbootmode 1 Reboot the system: $ reboot After rebooting, the device will automatically run fastboot from uboot and will wait for a connection from the host machine. You can test the connection using a fastboot binary at the host machine (not provided here). Even if you HARD reset your hardware, your device will keep running fastboot at startup. If you want to go back to a regular boot operation, you need to cut power supply to your board. How does the magic happen? The setbootmode application sets the LSB in the Low Power General Register (LPGR) of the Secure Real Time Clock (SRTC) module to true. The patched version o uboot tests for this bit as a flag to run fastboot or not. The magic is that the LPGR is persistent, even during reset. Additional tips You can run setbootmode with no arguments to see its options; You need to set the boot mode to 0 after a successful update to avoid entering fastboot mode again after a new reboot; Partitioning of the device seen by fastboot is not implemented; Besides using setbootmode, you can read/set LPGR using either md.l / nm.l in uboot or devmem2 at command line: uboot-> md.l 0x53fa401c 1 - displays LPGR; uboot-> nm.l 0x53fa401c - presents a prompt for you to change LPGR; linux shell-> devmem2 0x53fa401c w - displays LPGR; linux shell-> devmem2 0x53fa401c w <value> - changes LPGR; devmem2 has issues that you need to fix so that you can use it to change LPGR: include "volatile" in all writing instruction; uncomment 'w' write instruction.

When you do long test (days or weeks) test on i.MX board and your test fails, you often wants to know what has happen with a JTAG probe. The problem is when you have 50 boards running in parallel, you don't have the budget to have 50 JTAG debug probe. If you do a "hot plug" of your JTAG probe, you have roughly one chance out 2 to reset your board... so you'll have to wait another couple of hour to resee the problem. Anyway to have a reliable JTAG plug with no reset, it is really simple... cut the RESET line on your cable! then you'll still be able to "attach" to your i.MX. On the MEK board, with a 10-pin JTAG connector, you have the cut the cable line 10 of the ribbon cable: On the cable, cut the reset line like this: With my Lauterbach JTAG  probe, when I do a "hot plug" I never have a reset of my i.MX. BR Vincent

The following document contains a list of document, questions and discussions that are relevant in the community based on amount of views. If you are having a problem, doubt or getting started in i.MX processors, you should check the following links to see if your doubt is in there. Yocto Project Freescale Yocto Project main page‌ Yocto Training - HOME‌ i.MX Yocto Project: Frequently Asked Questions‌ Useful bitbake commands‌ Yocto Project Package Management - smart  How to add a new layer and a new recipe in Yocto  Setting up the Eclipse IDE for Yocto Application Development Guide to the .sdcard format  Yocto NFS &amp; TFTP boot  YOCTO project clean  Yocto with a package manager (ex: apt-get)  Yocto Setting the Default Ethernet address and disable DHCP on boot.  i.MX x Building QT for i.MX6  i.MX6/7 DDR Stress Test Tool V3.00  i.MX6DQSDL DDR3 Script Aid  Installing Ubuntu Rootfs on NXP i.MX6 boards  iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP i.MX Design&amp;Tool Lists  Simple GPIO Example - quandry  i.MX6 GStreamer-imx Plugins - Tutorial &amp; Example Pipelines  Streaming USB Webcam over Network  Step-by-step: How to setup TI Wilink (WL18xx) with iMX6 Linux 3.10.53  Linux / Kernel Copying Files Between Windows and Linux using PuTTY  Building Linux Kernel  Patch to support uboot logo keep from uboot to kernel for NXP Linux and Android BSP (HDMI, LCD and LVDS)  load kernel from SD card in U-boot  Changing the Kernel configuration for i.MX6 SABRE  Android  The Android Booting process  What is inside the init.rc and what is it used for.  Others How to use qtmultimedia(QML) with Gstreamer 1.0

The patches are based on iMX53 L2.6.35_ER1109 BSP. In default linux BSP, the followed two pathes were supported in kernel driver mxc_v4l2_capture.c: CSI->IC->MEM CSI->MEM After appied these two patches, it can support the followed path: CSI->VDI->IC->MEM In this mode, the VDI de-interlace will be handled on the fly, so the whole system bandwidth will be reduced. Limitations: 1. Since the IC can only output resolution up to 1024*1024, so this is the limation on output. 2. Only VDI motion mode 2 was supported. mxc_v4l2_tvin_vdi_ic.zip: It is the test aplication, test command: "./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 2" "-i 2" means CSI->VDI->IC->MEM path.

The attached is the document and sample code for iMX5 system 80 interface LCD driver based on IPUV3. It is based on iMX51 2.6.31_09.12 BSP (SDK 1.7), tested on iMX53 3-Stack board. 1. Description This is Smartlcd driver for Freescale MX51 SDK1.7 release. (Kernel: 2.6.31_09.12.00/01)  2. File List -- Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch: SmartLCD panel support patch, and unit test code. -- Sample.config: the config file for reference. -- readme.txt: this file, please refer to it before use the package. -- SmartLCD Structure.pptx: the basic structure for smartlcd on IPUv3. 3. Requirement - MX51_3DS Green board(TO2.0) - No hardware rework needed, only need plug the giantplus GMA722A0 to J10. - MX51 SDK1.7 release package - L2.6.31_09.12.00_SDK_source.tar.gz                                - redboot_200952.zip 4. How to use 4.1 How to use demo -- Program default redboot.bin to board via ATKtools -- Copy attached zImage to tftp folder (assume /tftpboot) -- extract default rootfs to NFS folder (assume /nfsroot) -- COPY attached imx51_fb_test to ~/unit_test folder. -- Power on the board -- After redboot is boot up, use following command to boot up linux kernel    load -r -b 0x100000 zImage    exec -c "noinitrd console=ttymxc0 root=/dev/nfsroot rootfstype=nfsroot nfsroot=10.192.225.221:/nfsroot/rootfs rw ip=dhcp" -- Once the linux kernel launched, run following commands to test smartlcd panel.    cd /unit_tests    ./imx51_fb_test 4.2 How to use source code -- Current release code is based on L2.6.31_09.12.00_SDK_source.tar.gz. Extract the file to your working folder. -- Entering the working folder and type "./install", select a folder to install ltib. (such as .../ltib) -- Entering ltib folder and type "./ltib" to build Linux platform.  If you are not familiar with this setp, please refer to doc "i.MX_3Stack_SDK_UserGuide.pdf" for detail. -- Entering folder ".../ltib/rpm/BUILD/linux", copy "Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch" from release package to current folder    Run command "patch -p1 < Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch" -- When complete, run command "make ARCH=arm menuconfig", and you can refer to attached sample.config for detail.    * enable    Device Drivers ----> Graphics support ----> [*]   Asynchronous Panels                                            ----> [*] GiantPlus 240x320 Panel                                             * disable    Device Drivers ----> Graphics support ----> [ ]   Synchronous Panel Framebuffer                                         ----> Multimedia support    ----> [ ]   Video For Linux                                             -- Run command "make ARCH=arm" to build kernel.  4.3 How to do SMARTLCD driver test -- After Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch applied, there will be an folder "IMX51_TEST" under linux. -- Go to that folder, and run "make ARCH=arm", imx51_fb_test will be created. -- Copy imx51_fb_test to rootfs/unit_test. and run. 5. History N/A 6. Known Issue -- V4L2 not working yet.

Question: When working with v1.6.0.55 using the standard profile for i.MX35 the tool fails most of the time when transferring the target root file system, on v1.6.0.42 it works just fine. The tags on the internal git don’t clearly mention a tool version, but a BSP. Wwhat are the differences between v1.6.0.55 and v1.6.0.42? Or to which tag(or commit) they correspond on git? Answer: 1.6.042 commit by looking at "Apps/MfgTool.exe/docs/changelog.txt": 1ca2a16df736ac51979a67423fef6a09bed6b7e2 And 1.6.055: "06a4f9190e34297b7273fc4bb4a92737e5bc837f"

Question: How do I add the opencore amrnb plugin to be the default for amrnb for use with playbin2? With a .3gp file to play and audio amrnb encoded, amr plugins do not work ( i.e. are not even part of the build and when configured to build, they do not even build ). Opencore had been added and got it to build and install with our ltib BSP and it plays the audio from the .3gp file in question fine ( but with an explicit pipeline ). But, the opencore amrnb plugin is not selected by gstreamer playbin2 when it does a typefind on the amrnb audio type. Answer: There are three options: 1. Fix the aiurdemux to allow correct demuxing 2. Lower the aiurdemux rank 3. Remove the /usr/lib/gstreamer-0.10/libmfw_gst_aiur_demux.so Obviously, 3 is a ugly hack but it can be just enough for customer. If option 1 or is selected, patches may be required from MM team. On this system, the aiurdemux does not have any issue, and audio playback works as expected. These are the VPU firmware and GST-FSL versions on YOCTO: VPU Version: firmware 1.4.50; libvpu: 5.3.2 MFW_GST_VPU_DECODER_PLUGIN 3.0.8 build on Sep 30 2013 16:36:27. where in LTIB: VPU Version: firmware 1.4.48; libvpu: 5.3.2 MFW_GST_VPU_DECODER_PLUGIN 2.0.3 build on Jul 23 2013 11:20:21. So the next moved would be to try upgrading versions on LTIB if they want to use this system; in case switching to Yocto is viable, then the upgrade is already done.

Questions: 1.  Are there any hardware limitations (such as in the Host Controller IP block itself, how this IP block was implemented or in the DMA engine) to how many device endpoints the i.MX53 can handle on Host2 or Host3?  The Reference Manual notes that the OTG controller supports up to 8 endpoints but does not provide information on the Host Controller. 2.  Do any of the device validation tests for verifying the i.MX53 design (or USB cert tests) test compatibility/performance with multiple devices and multiple endpoints? 3.  What are the maximum number of endpoints Freescale has tested with? Problem Background: During extensive testing the customer observes 100% CPU utilization with only 6 endpoints (can be a combination of multi-endpoint devices or single-endpoint devices - see below for test configuration details) using our latest Linux reference BSP (2.6.35 Kernel).  They have tested with the Adeneo WEC7 BSP and the open source Linux kernel based on 3.11 for the QSB and have observed similar performance limitations. This has been tested with multiple packet sizes and device/endpoint configurations and no impact has been shown in varying these parameters. The customer did note that they are only receiving/processing a single interrupt at the 1ms boundary regardless of the number of devices/endpoints.  Processing this interrupt takes approximately 23us for one device and an additional 17us for each additional device endpoint after the first that is processed. The customer hardware configuration for their testing looks something like this: On the customer's board: [i.MX53 Host2/Host3] -> [SMSC 3315 USB High Speed ULPI PHY] -> [SMSC LAN9514 On-board 4-port USB 2.0 HS Hub] External: [SMSC LAN9514 Port #1] -> [SMSC USB2415 4-Port USB 2.0 HS Hub] -> Medical device w/ endpoints #1-4 [SMSC LAN9514 Port #2] -> [SMSC USB2415 4-Port USB 2.0 HS Hub] -> Medical device w/ endpoints #5-8 [SMSC LAN9514 Port #3] ->  Medical device w/ endpoint #9 [SMSC LAN9514 Port #4] ->  Medical device w/ endpoint #10 Answer: Hosts do not have endpoints. Only devices have endpoints. EHCI compliance hosts, like all i.MX devices, use a linked list of queues (for bulk/control transport). Each queue has a queuehead that represents a corresponding endpoint and has the endpoint's capabilities. On the queue are transfer descriptors that have the information of which data is to be moved to/from the endpoint of the device. All of this is in main memory and read/written under DMA.  There is no limit on how many devices/endpoints a host can service, other than the amount of available main memory (DRAM). The CPU has to build the linked lists, but this is  normally not taking much bandwidth. My guess at this time is that there may be a problem in the USB driver, or the application that is using the driver, or a problem with data alignment. For efficient operation, data must be aligned on 32-bit boundaries. Buffers are best aligned on 64-byte boundaries.

Q: Does anyone have the Lauterbach script files for connecting to the mx53?  Also,  does anyone know of a converter to convert RealView scripts to Lauterbach? A: Please see below attach.cmm and load_simbols.cmm for i.MX53. attach.cmm ; ; Script to attach to a running system, halt the CPU, ; and display the ASM code ; screen.on ; Debugger Reset winpage.reset area.reset WINPOS 0. 26. 75. 8. 0. 0. W000 area print "resetting ICD..." System.Down Break.Delete MAP.RESet TASK.RESet sYmbol.RESet Data.PROLOG.RESet Data.EPILOG.RESet sYmbol.AutoLoad.CHECK OFF      ; disable dynamic autoloader sYmbol.AutoLoad.RESet          ; reset autoloader list MMU.RESet ; setup of ICD JTAG print "initializing JTAG..." SYStem.CPU CORTEXA8 SYStem.MultiCore IRPOST 0x0 SYStem.MultiCore IRPRE 0x0 SYStem.MultiCore DRPOST 0x0 SYStem.MultiCore DRPRE 0x0 SYStem.MultiCore DAPIRPOST 0x09 SYStem.MultiCore DAPIRPRE 0x0 SYStem.MultiCore DAPDRPOST 0x02 SYStem.MultiCore DAPDRPRE 0x0 SYStem.MultiCore MEMORYACCESSPORT 0 SYStem.MultiCore DEBUGACCESSPORT 1 SYStem.MultiCore COREBASE APB:0xC0008000 SYStem.Option DACR ON          ; give Debugger global write permissions TrOnchip.Set DABORT OFF        ; used by Linux OS for page miss! TrOnchip.Set PABORT OFF        ; used by Linux OS for page miss! TrOnchip.Set UNDEF OFF         ; let UNDEF be handled by Linux OS SYStem.Option MMU ON           ; enable space ids to virtual addresses SYStem.JtagClock 20.0MHz SETUP.IMASKASM ON              ; lock interrupts while single stepping ; Use on-chip breakpoints Break.SELect PROGRAM ONCHIP Break.SELect READ ONCHIP Break.SELect WRITE ONCHIP Break.SELect ALPHA ONCHIP Break.SELect BETA ONCHIP Break.SELect CHARLY ONCHIP Break.SELect DELTA ONCHIP Break.SELect ECHO ONCHIP SYStem.Option EnReset OFF SYS.m attach ; wait until reset is complete wait 2.s if run()     Break ; Open a Code Window -- we like to see something WINPOS 0. 0. 75. 20. Data.List enddo load.symbols.cmm ; ; Script to load the Linux kernel symbols into the debugger ; print "loading Linux kernel symbols..." &linuxpath="S:\git\kernel\linux-2.6-imx-0" &kbuildpath="build" sYmbol.SourcePATH.SET &linuxpath Data.LOAD.Elf &linuxpath\&kbuildpath\imx5\vmlinux /StripPART 3 /gnu /nocode ; Map the virtual kernel symbols to physical addresses ; to give the debugger access to it before CPU MMU is ; initialized print "setting system MMU..." MMU.FORMAT Linux swapper_pg_dir 0xc0000000--0xc1ffffff 0x70000000 MMU.Create 0xc0000000--0xc1ffffff 0x70000000 ; map kernel pages at RAM start MMU.COMMON 0xc0000000--0xffffffff            ; common area for kernel and processes ;MMU.TableWalk OFF   ; debugger uses a table walk to decode virtual addresses MMU.ON             ; switch on debugger(!) address translation ; Initialize Mutitasking Support print "initializing multitask support..." TASK.CONFIG ../linux       ; loads Linux awareness (linux.t32) MENU.ReProgram ../linux    ; loads Linux menu (linux.men) HELP.FILTER.Add rtoslinux  ; add linux awareness manual to help filter enddo This document was generated from the following discussion: Lauterbach CMM scripts for mx53

Q: MX53 u-boot doc to enable the splash screen and went through Re: MX53 u-boot Splash Screen support but I can't seem to get the splash working on the VGA output.  A: FSL do not have solution / recommendations for VGA splash screen under U-boot. Only LVDS is supported. Typically, the Uboot bootloader does not interact with any display interface and does not have a splash screen displaying capability. To add this feature to Uboot on i.MX5 platform, the IPU driver should be included into the Uboot code. Looks like we do not have ready to use solution for the LCD. As an example for LCD configuring it makes sense to use LCD settings from Linux driver. Another approach - to use Linux (Penguin) logo (assuming Linux is booted quickly after U-boot) - at least, Linux supports more display drivers and its logo using is specified. follow up question is since the Tux the penguin logo is only 80x80 is it possible to make a larger image for the Linux start up logo? yes, you should configure kernel for the new image on make menuconfig That doesn’t help this H/W guy, but I think this may - https://community.freescale.com/thread/304300    look for  “#To change the splash screen of linux kernel (small penguine on top left corner)..“