Most engineers should incorporate the following fundamental methodology when designing and bringing up a new board design: 1. Review the schematics and layout to ensure proper connectivity of all devices 2. Once the board returns from the manufacturer, measure and document all of the voltage rails of each IC on the board (especially the SoC and DRAM) 3. Ensure JTAG debugger connectivity (due to the complexity of systems today, every new board design should have some “hooks” to allow JTAG connectivity, even if these are simply test points) 4. Bring up and ensure proper DRAM functionality; it is imperative the first three steps are precisely accomplished – often times, DRAM instability or non functionality is due to improper connection (including not being connected to the voltage net) or poor layout. Once these four steps are completed, the board can then proceed to a more broad based checkout of other peripherals using some type of compiled test code executed from DRAM. More often than not, the end user’s board will differ from Freescale reference design boards either in how the DRAMs are connected or simply by using a different DRAM vendor.  As such, tools were created to aid in the development of DRAM initialization scripts.  The resulting script, though targeted for the RealView development system (aka include files), can be easily ported to another debugger’s command syntax or to assembly code for use in boot loaders.  These tools are Excel spread sheet based and include a “How To Use” tab, making the tool usage relatively self-explanatory.  Each tool is unique to a specific i.MX processor and to the DRAM technology used with each processor.  This attached files are tools available for the following i.MX SoCs:

Wi-Fi Android IMX53 QSB enable WIFI android How to Support New WiFi Card in Android How to enable PCIe WiFi into i.MX6 Android Release? WiFi.zip

Video Tips for video in host side Testing Image Sensor and Display Testing on i.MX31 PDK Gstreamer in the iMX board The i.MX family has a big set of plugins that enable a lot of formats. It has some hardware acceleration, but each board has some peculiarities. I.MX27ADS Board I.MX51EVK Board I.MX53QSB Board How to create an application to play Audio+Video using gstreamer TV Out - Configuring I.MX27ADS TV Out AlphaBlending AlphaBlending is used to exibhit two images on display, one of these is transparent image. Normally you use a solid background image and a transparent (alpha) image on foreground. i.MX31PDK AlphaBlending DirectFB i.MX31PDK DirectFB How to get a screenshot from framebuffer display? i.MX31PDK Screenshot Theora Creating a Theora Encoder Example

on Host: libx11-dev libpng-dev libjpeg-dev libxext-dev x11proto-xext-dev qt3-dev-tools-embedded libxtst-dev On Target (i.MX device) alsa-utils libpng tslib

Debugging with JTAG JTAG was created to test populated circuit boards after manufacture. Nowadays, JTAG is primarilly used to access sub-blocks of integrated circuits and useful mechanism for debugging embedded systems. When used as a debugging tool, an in-circuit emulator - which in turn uses JTAG as the transport mechanism - enables a programmer to access an on-chip debug module which is integrated into the CPU, via the JTAG interface. The debug module enables the programmer to debug the software of an embedded system. Besides debugging, the second purpose of the JTAG interface is allowing device programmer hardware to transfer data into internal non-volatile device memory. Some device programmers serve a double purpose for programming as well as debugging the device. [Source: http://en.wikipedia.org] All Boards Hardware Software i.MX27 ADS Board Installing OpenOCD and GDB All Boards Debugging Android All Boards How To Understand JTAG BSDL

JTAG Hardware and Software There are many opened and proprietary JTAG solutions. Here are some of them: Proprietary IAR Systems In-Circuit Debugging Probes Macraigor usb2Demon Segger - Jlink Free and Open Source Software GDB OpenOCD Open Hardware Turtelizer

Freescale LTIB provides only the low level FlexCAN driver, so you can add Canutils and Libsocketcan developed by Pengutronix to have some more functions available on user space and some test and monitoring applications. Adding Flexcan driver support on Kernel On kernel menuconfig, add the following items: [*] Networking support  --->     <*>  CAN bus subsystem support  --->         <*>  Raw CAN Protocol (raw access with CAN-ID filtering)         <*>  Broadcast Manager CAN Protocol (with content filtering)     CAN Device Drivers  --->         <*> Virtual Local CAN Interface (vcan)         [*] CAN devices debugging messages         <*> Freescale FlexCAN Adding Canutils and Libsocketcan Packages on LTIB Download the libsocketcan-0.0.8.tar.bz2 and canutils-4.0.6.tar.bz2 source codes from the links below and save them on your PC at /opt/freescale/pkgs http://www.pengutronix.de/software/libsocketcan/download/libsocketcan-0.0.8.tar.bz2 http://www.pengutronix.de/software/socket-can/download/canutils/v4.0/canutils-4.0.6.tar.bz2 On LTIB directory, create the spec file folders: cd <ltib directory>/dist/lfs-5.1 mkdir canutils mkdir libsocketcan Download the following spec files, unpack them on their respective folders: Can_specs.tar.gz ( attached below ) Now, on ltib directory, unpack, build and deploy them: cd <ltib directory> ./ltib -p libsocketcan.spec -f ./ltib -p canutils.spec -f Testing the FlexCAN network To test the Flexcan network, first set the bitrate and after enable the can port: canconfig can0 bitrate 125000 ifconfig can0 up                                         Now it's possible to test the network connecting two boards: On board 1: cansend can0 -i0x100 11 22 33 44 On board 2: canecho can0 -v Board 2 will show the data coming from board 1.

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

Connectivity - Using a Bluetooth Dongle Network Connection A simple way to set up a network connection using a Bluetooth dongle is using the Personal Area Networking (PAN) profile. Load the following modules on i.MX platform: # modprobe ehci-hcd # modprobe hci_usb # modprobe bnep Set hci0 up: # hciconfig hci0 up Check if the hci0 is set by typing: root@freescale ~$ hciconfig hci0:  Type: USB         BD Address: 00:1E:58:3F:4D:09 ACL MTU: 384:8 SCO MTU: 64:8         UP RUNNING PSCAN ISCAN         RX bytes:4813491 acl:53228 sco:0 events:208901 errors:0         TX bytes:156025160 acl:410140 sco:0 commands:83 errors:0 root@freescale ~$ hciconfig hci0 piscan Start the Bluetooth service: root@freescale ~$ /etc/rc.d/init.d/bluetooth start Start the pand service as Pan User (PANU): root@freescale ~$ pand -s -r PANU On Host (PC), load bnep module: $ modprobe bnep Start the pand service as Group Ad-hoc Network (GN): $ sudo pand --connect 00:1E:58:3F:4D:09 --service GN -n The target address (in this case 00:1E:58:3F:4D:09) can be found using hciconfig command on target A BNEP0 network should be created on host (PC) and target (i.MX): Configure BNEP0 IP on PC: $ sudo ifconfig bnep0 192.168.0.11 Configure BNEP0 IP on i.MX: $ ifconfig bnep0 192.168.0.10 Now the PAN network is set. You can test using ping: root@freescale ~$ ping 192.168.0.11 PING 192.168.0.11 (192.168.0.11): 56 data bytes 64 bytes from 192.168.0.11: icmp_seq=0 ttl=64 time=12.305 ms 64 bytes from 192.168.0.11: icmp_seq=1 ttl=64 time=27.782 ms 64 bytes from 192.168.0.11: icmp_seq=2 ttl=64 time=16.701 ms 64 bytes from 192.168.0.11: icmp_seq=3 ttl=64 time=36.732 ms 192.168.0.11 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 12.305/23.380/36.732/9.551 ms

All Boards Creating App MP3 OpenEmbedded

OpenGL OpenGL is the premier environment for developing portable, interactive 2D and 3D graphics applications. Since its introduction in 1992, OpenGL has become the industry's most widely used and supported 2D and 3D graphics application programming interface (API), bringing thousands of applications to a wide variety of computer platforms. OpenGL fosters innovation and speeds application development by incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions. Developers can leverage the power of OpenGL across all popular desktop and workstation platforms, ensuring wide application deployment. Source: http://www.opengl.org/about/overview/ On i.MX processors, OpenGL takes the advantage of GPU (Graphics Processing Unit) block to improve 3D performance. Installing and running Demos Get more information on how to install and run demos using OpenGL on i.MX31 on this application note: AN3723 - Using OpenGL Applications on the i.MX31 ADS Board - http://www.freescale.com/files/dsp/doc/app_note/AN3723.pdf?fsrch=1 Develop a simple OpenGL ES 2.0 application under Linux This tutorial shows how to develop a simple OpenGL ES 2.0 application with LTIB and an i.MX51 EVK board. This tutorial can be adapted to i.MX53 that share the same 3D GPU core (Z430) and API (OpenGL ES 2.0).

If Android device has Internet access, it can download and install TTS library automatically. However, sometimes in a developer environment, Internet may not be available. Download TTS library from Eyes-Free project, [1] Unzip all files into VFAT partition (of SDCard). It will create two directories: daiane@b19406:/media$ sudo ls disk-3/ -l total 231552 drwx------ 6 daiane root      4096 2010-05-24 15:46 espeak-data drwx------ 2 daiane root      4096 2010-05-24 15:46 svox daiane@b19406:/media$ mount /dev/sdd5 on /media/disk-1 type ext3 (rw,nosuid,nodev,uhelper=hal) /dev/sdd2 on /media/system type ext3 (rw,nosuid,nodev,uhelper=hal) /dev/sdd6 on /media/disk-2 type ext3 (rw,nosuid,nodev,uhelper=hal) /dev/sdd1 on /media/disk-3 type vfat (rw,nosuid,nodev,uhelper=hal,shortname=mixed,uid=1001,utf8,umask=077,flush) /dev/sdd4 on /media/recovery type ext3 (rw,nosuid,nodev,uhelper=hal)

Instead to use gst-launch to play your audio/video media you can create an application do to that. This application was tested in iMX27ADS but should to work on iMX27PDK First execute LTIB (./ltib -c) and select these packages: all gstreamer plugin, alsa-utils and libmad. Create your file code (i.e.: playvideo.c): #include <gst/gst.h> #include <glib.h> #include <string.h> static GstElement *source, *demuxer, *vdqueue, *adqueue, *vdsink, *adsink, *decvd, *decad; void on_pad_added (GstElement *element, GstPad *pad) {         g_debug ("Signal: pad-added");         GstCaps *caps;         GstStructure *str;         caps = gst_pad_get_caps (pad);         g_assert (caps != NULL);         str = gst_caps_get_structure (caps, 0);         g_assert (str != NULL);         if (g_strrstr (gst_structure_get_name (str), "video")) {                 g_debug ("Linking video pad to dec_vd");                 // Link it actually                 GstPad *targetsink = gst_element_get_pad (decvd, "sink");                 g_assert (targetsink != NULL);                 gst_pad_link (pad, targetsink);                 gst_object_unref (targetsink);         }         if (g_strrstr (gst_structure_get_name (str), "audio")) {                 g_debug ("Linking audio pad to dec_ad");                 // Link it actually                 GstPad *targetsink = gst_element_get_pad (decad, "sink");                 g_assert (targetsink != NULL);                 gst_pad_link (pad, targetsink);                 gst_object_unref (targetsink);         }         gst_caps_unref (caps); } static gboolean bus_call (GstBus    *bus,           GstMessage *msg,           gpointer    data) {   GMainLoop *loop = (GMainLoop *) data;   switch (GST_MESSAGE_TYPE (msg)) {     case GST_MESSAGE_EOS:       g_print ("End of stream\n");       g_main_loop_quit (loop);       break;     case GST_MESSAGE_ERROR: {       gchar  *debug;       GError *error;       gst_message_parse_error (msg, &error, &debug);       g_free (debug);       g_printerr ("Error: %s\n", error->message);       g_error_free (error);       g_main_loop_quit (loop);       break;     }     default:       break;   }   return TRUE; } int main (int  argc,       char *argv[]) {   GMainLoop *loop;   GstElement *pipeline;   GstBus *bus;   /* Initialisation */   gst_init (&argc, &argv);   loop = g_main_loop_new (NULL, FALSE);   /* Check input arguments */   if (argc != 2) {     g_printerr ("Usage: %s <Video H264 filename>\n", argv[0]);     return -1;   }   /* Create gstreamer elements */   pipeline      = gst_pipeline_new ("media-player");   source        = gst_element_factory_make ("filesrc","file-source");   demuxer      = gst_element_factory_make ("mfw_mp4demuxer","avi-demuxer");   decvd        = gst_element_factory_make ("mfw_vpudecoder", "video-decoder");   decad        = gst_element_factory_make ("mad", "mp3-decoder");   vdsink        = gst_element_factory_make ("mfw_v4lsink",    "video-sink");   vdqueue      = gst_element_factory_make ("queue",            "video-queue");   adqueue      = gst_element_factory_make ("queue",            "audio-queue");   adsink        = gst_element_factory_make ("fakesink",        "audio-sink");   g_object_set (decvd, "codec-type", "std_avc", NULL);   if (!pipeline || !source || !demuxer || !decvd || !decad || !vdsink || !vdqueue || !adqueue || !adsink) {     g_printerr ("One element could not be created. Exiting.\n");     return -1;   }   /* Set up the pipeline */   /* we set the input filename to the source element */   g_object_set (G_OBJECT (source), "location", argv[1], NULL);   /* we add a message handler */   bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));   gst_bus_add_watch (bus, bus_call, loop);   gst_object_unref (bus);   /* we add all elements into the pipeline */   /* file-source | ogg-demuxer | vorbis-decoder | converter | alsa-output */   gst_bin_add_many (GST_BIN (pipeline),                     source, demuxer, decvd, decad, adqueue, vdqueue, vdsink, adsink,  NULL);   /* we link the elements together */   /* file-source -> ogg-demuxer ~> vorbis-decoder -> converter -> alsa-output */   gst_element_link (source, demuxer);   gst_element_link (decvd, vdqueue);   gst_element_link (vdqueue, vdsink);   //gst_element_link (decad, adqueue);   gst_element_link (adqueue, adsink);   g_signal_connect (demuxer, "pad-added", G_CALLBACK (on_pad_added), NULL);   /* note that the demuxer will be linked to the decoder dynamically.     The reason is that Ogg may contain various streams (for example     audio and video). The source pad(s) will be created at run time,     by the demuxer when it detects the amount and nature of streams.     Therefore we connect a callback function which will be executed     when the "pad-added" is emitted.*/   /* Set the pipeline to "playing" state*/   g_print ("Now playing: %s\n", argv[1]);   gst_element_set_state (pipeline, GST_STATE_PLAYING);   /* Iterate */   g_print ("Running...\n");   g_main_loop_run (loop);   /* Out of the main loop, clean up nicely */   g_print ("Returned, stopping playback\n");   gst_element_set_state (pipeline, GST_STATE_NULL);   g_print ("Deleting pipeline\n");   gst_object_unref (GST_OBJECT (pipeline));   return 0; } Create a directory inside your ltib directory to compile your source code: $ mkdir ~/your-ltib-dir/rpm/BUILD/gst Enter on LTIB shell mode: $ ./ltib -m shell Entering ltib shell mode, type 'exit' to quit LTIB> Enter in your application dir: LTIB> cd rpm/BUILD/gst/ Compile your application: LTIB> gcc -Wall $(pkg-config --cflags --libs gstreamer-0.10) playvideo.c -o playvideo If everything worked file you will get a "playvideo" arm binary: LTIB> file playvideo playvideo: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped Now just copy it to ~/your-ltib-dir/rootfs/home. Start your board using this rootfs and execute: root@freescale ~$ cd /home/ root@freescale /home$ ./playvideo your-file-h264-mp3.avi Now playing: your-file-h264-mp3.avi Running...

First execute LTIB (./ltib -c) and select these packages: all gstreamer plugin, alsa-utils and libmad. Create your file code (i.e.: playmp3.c): #include <gst/gst.h> #include <glib.h> static gboolean   bus_call (GstBus    *bus,             GstMessage *msg,             gpointer    data) {   GMainLoop *loop = (GMainLoop *) data;   switch (GST_MESSAGE_TYPE (msg)) {           case GST_MESSAGE_EOS:               g_print ("End of stream\n");               g_main_loop_quit (loop);               break;           case GST_MESSAGE_ERROR: {               gchar  *debug;               GError *error;               gst_message_parse_error (msg, &error, &debug);               g_free (debug);               g_printerr ("Error: %s\n", error->message);               g_error_free (error);               g_main_loop_quit (loop);               break;         }         default:           break;     }     return TRUE; } int main (int  argc,               char *argv[]) {       GMainLoop *loop;       GstElement *pipeline, *source, *decoder, *conv, *resample, *sink;       GstBus *bus;       /* Initialisation */       gst_init (&argc, &argv);       loop = g_main_loop_new (NULL, FALSE);       /* Check input arguments */       if (argc != 2) {           g_printerr ("Usage: %s <MP3 filename>\n", argv[0]);           return -1;       }         /* Create gstreamer elements */       pipeline = gst_pipeline_new ("audio-player");       source  = gst_element_factory_make ("filesrc",      "file-source");       decoder  = gst_element_factory_make ("mad",      "mp3-decoder");       conv    = gst_element_factory_make ("audioconvert",  "converter");       resample = gst_element_factory_make ("audioresample", "audio-resample");       sink    = gst_element_factory_make ("autoaudiosink", "audio-output");       if (!pipeline || !source || !decoder || !conv || !resample || !sink) {           g_printerr ("One element could not be created. Exiting.\n");           return -1;       }       /* Set up the pipeline */       /* we set the input filename to the source element */       g_object_set (G_OBJECT (source), "location", argv[1], NULL);         /* we add a message handler */         bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));         gst_bus_add_watch (bus, bus_call, loop);         gst_object_unref (bus);         /* we add all elements into the pipeline */         /* file-source | mp3-decoder | converter | resample | alsa-output */         gst_bin_add_many (GST_BIN (pipeline),                                                       source, decoder, conv, resample, sink, NULL);           /* we link the elements together */           /* file-source -> mp3-decoder -> converter -> resample -> alsa-output */           gst_element_link_many (source, decoder, conv, sink, NULL);         /* Set the pipeline to "playing" state*/         g_print ("Now playing: %s\n", argv[1]);         gst_element_set_state (pipeline, GST_STATE_PLAYING);         /* Iterate */       g_print ("Running...\n");       g_main_loop_run (loop);         /* Out of the main loop, clean up nicely */         g_print ("Returned, stopping playback\n");       gst_element_set_state (pipeline, GST_STATE_NULL);       g_print ("Deleting pipeline\n");       gst_object_unref (GST_OBJECT (pipeline));           return 0; } Create a directory inside your ltib directory to compile your source code: $ mkdir ~/your-ltib-dir/rpm/BUILD/gst Enter on LTIB shell mode: $ ./ltib -m shell Entering ltib shell mode, type 'exit' to quit LTIB> Enter in your application dir: LTIB> cd rpm/BUILD/gst/ Compile your application: LTIB> gcc -Wall $(pkg-config --cflags --libs gstreamer-0.10) playmp3.c -o playmp3 If everything worked file you will get a "playmp3" arm binary: LTIB> file playmp3 playmp3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped Now just copy it to ~/your-ltib-dir/rootfs/home. Start your board using this rootfs and execute: root@freescale ~$ cd /home/ root@freescale /home$ ./playmp3 your-file.mp3 Now playing: your-file.mp3 Running...

Ramdisk is unnecessary thing for some embedded systems, but it's required for Android . You can develop an Android system with no ramdisk (initrd/initramfs), just follow these steps: 1) Remove RAMDISK support from kernel: General setup  --->             [ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support Create a single rootfs: cd myandroid/out/target/product/imx51_BBG mkdir rootfs sudo cp -a system rootfs/ sudo cp -a root/* rootfs/ sudo cp -a recovery rootfs/ Since you are using a single filesystem, then comment out these lines from rootfs/init.rc: #mount ext3 /dev/block/mmcblk0p2 /system #mount ext3 /dev/block/mmcblk0p2 /system ro remount #mount ext3 /dev/block/mmcblk0p5 /data nosuid nodev #mount ext3 /dev/block/mmcblk0p6 /cache nosuid nodev Create just one partition into your MMC or Flash memory: Partition 1: 200MB+ as EXT3 will be used as system(rootfs). Remember to skip 4MB to save kernel. It is a good idea to create a second partition (VFAT) to mount as /data to save user files. Mount that "system" partition and copy all content of rootfs: sudo mount /dev/sdb1 -t ext3 /mnt sudo cp -a .../target/product/imx51_BBG/rootfs/* /mnt sudo umount /mnt Now just setup your bootloader parameter correctly (i.e. MMC Partition 1): setenv bootargs_base 'setenv bootargs root=/dev/mmcblk0p1 rootfstype=ext3 console=ttymxc0,115200 noinitrd'

logcat Logcat is the most powerful debug tool for Android. Logcat is to Android what the dmesg is to kernel. It shows messages logs from system and applications. logcat can be used directly on board console or via adb. $ logcat directly on board console. It gives the complete log message list and waits for any new log message. $ logcat & board console. It gives log list and run in background. Any new log message will be displayed. # adb logcat Using adb you can get log messages through Ethernet or USB connection. $ logcat -d > logcat.txt it sends log messages to logcat.txt file and exits. $ logcat *:W it filters expression displays all log messages with priority level "warning" and higher, on all tags * * http://developer.android.com/guide/developing/debugging/debugging-log.html

The getevent function shows kernel events like press button events, touchscreen events, sensor events (like accelerometers or magnetometers). bash-3.2# getevent -h Usage: getevent [-t] [-n] [-s switchmask] [-S] [-v [mask]] [-p] [-q] [-c count] [-r] [device]       -t: show time stamps       -n: don't print newlines       -s: print switch states for given bits       -S: print all switch states       -v: verbosity mask (errs=1, dev=2, name=4, info=8, vers=16, pos. events=32)       -p: show possible events (errs, dev, name, pos. events)       -q: quiet (clear verbosity mask)       -c: print given number of events then exit       -r: print rate events are received Bellow an example of all events on some board bash-3.2# getevent -p add device 1: /dev/input/event2   name:    "mxc_ts"   events:       SYN (0000): 0000  0001  0003       KEY (0001): 014a       ABS (0003): 0000  value 0, min 0, max 0, fuzz 0 flat 0                         0001  value 0, min 0, max 0, fuzz 0 flat 0                         0018  value 0, min 0, max 0, fuzz 0 flat 0 could not get driver version for /dev/input/mouse0, Not a typewriter add device 2: /dev/input/event1   name:    "mxc_power_key"   events:     SYN (0000): 0000  0001     KEY (0001): 003e add device 3: /dev/input/event0   name:    "mxckpd"   events:     SYN (0000): 0000  0001     KEY (0001): 0002  0003  0004  0005  003b  003c  003d  003e                       0066  0067  0069  006a  006c  008b  009e  0161 could not get driver version for /dev/input/mice, Not a typewriter For example, some touchscreen event. Any touchscreen press-up or press-down will return a vector of values related with the event (please, see include/linux/input.h for detail) bash-3.2# getevent /dev/input/event2 0003 0000 0000020e 0003 0001 0000014a 0003 0018 00000037 0001 014a 00000001 0000 0000 00000000 0003 0000 00000209 0003 0001 00000147

ADB ADB is a tool for Android debugging. With ADB, you can install applications from you PC, copy files to/from your device, access console. You can access your device using an USB Cable, or through network (using an IP address). You can take ADB from SDK [1] or inside <my_android>/out/host/linux-x86/bin/adb I cannot see my device First checkpoint must be for ADBD. It´s the ADB daemon, and if it´s not running on your device, you will not be able to access it. Install and configure any USB driver [2] [3] Double check connection (USB cable, ethernet) Double check if debugging is on Double check if USB config is right (see how on User Guide) Tips and Tricks Turning on Remember to turn debugging mode on: Settings->Applications->Development->USB debugging No Permission When you get "no permissions" from ADB, you need to start server with your root user: $ sudo /usr/share/android-sdk-linux_86/tools/adb devices List of devices attached ????????????    no permissions $ sudo /usr/share/android-sdk-linux_86/tools/adb shell error: insufficient permissions for device $ sudo /usr/share/android-sdk-linux_86/tools/adb kill-server $ sudo /usr/share/android-sdk-linux_86/tools/adb start-server * daemon not running. starting it now * * daemon started successfully * $ sudo /usr/share/android-sdk-linux_86/tools/adb devices List of devices attached 0123456789ABCDEF    device $ sudo /usr/share/android-sdk-linux_86/tools/adb shell # ls dev etc

Structures to be modified The main table that needs to be modified is in C:\WINCE600\PLATFORM\COMMON\SRC\SOC\COMMON_FSL_V2_PDK1_9\NAND\INC\NANDTYPES.h. Add the Nand specific information to the following structure. typedef struct _NandChipInfo { FlashInfo fi; //@<<info> FlashInfo structure BYTE NANDCode[NANDID_LENGTH];//@<<info> NAND full ID BYTE NumBlockCycles; //@<<info> flash erase address cycle BYTE ChipAddrCycleNum; //@<<info> flash access address cycle BYTE DataWidth; //@<<info> 8/16 bits data width BYTE BBMarkNum; //@<<info> MAX_MARK_NUM = 4 BYTE BBMarkPage[MAX_MARK_NUM];//@<<info> MAX_MARK_NUM = 4 BYTE StatusBusyBit; //@<<info> interleave mode support BYTE StatusErrorBit; //@<<info> interleave mode support WORD SpareDataLength; //@<<info> spare area size BYTE CmdReadStatus; //@<<command> read status BYTE CmdRead1; //@<<command> read first 256 bytes data BYTE CmdRead2; //@<<command> read last 256 bytes data BYTE CmdReadId; //@<<command> read device ID BYTE CmdReset; //@<<command> reset nand flash BYTE CmdWrite1; //@<<command> sequence data input BYTE CmdWrite2; //@<<command> page program BYTE CmdErase1; //@<<command> block erase BYTE CmdErase2; //@<<command> block erase NANDTiming timings; //@<<info> NAND timing parameters }NandChipInfo, *pNandChipInfo; All information from NANDCode to CmdErase2, can be obtained from the Nand Datasheet. The structure FlashInfo, is filled in with data obtained from the Nand Analysis sheet. Please check this link to see how to create this spreadsheet from Nand Datasheets. typedef struct _FlashInfo { FLASH_TYPE flashType; DWORD dwNumBlocks; DWORD dwBytesPerBlock; WORD wSectorsPerBlock; WORD wDataBytesPerSector; }FlashInfo, *PFlashInfo; In the similar way the Nand timings calculated from the spreadsheet are add into this structure. typedef struct _NANDTiming { BYTE DataSetup; BYTE DataHold; BYTE AddressSetup; BYTE DataSample; }NANDTiming, *PNANDTiming; Remember to do a clean sysgen and build.

This page describes how to determine the NAND timing parameters for use in the NAND driver. This is independent of any OS that may be used. Analyzing NAND Datasheets  We use a spreadsheet to capture and analyze NAND features. That spreadsheet is [attached to this wiki page|Adding support for a new NAND with i.MX28– Nand Analysis^nand_analysis_template.xls]. We analyze a NAND as described below. We must have the NAND datasheet to do the analysis. Copy the *analysis spreadsheet* to a new filename with the exact part number(s) of the NAND(s) being analyzed. Fill in sheet 1 ("Cover Page") of the analysis spreadsheet. Work on sheet 3 next: Fundamental Features. Other tables. If the NAND is one of a family listed together in a data sheet, then analyze the whole family with one spreadsheet. You can use the "Similar to" rows for the additional members of the family. Add more rows if needed. Most NANDs have an asyncrhronous interface, so there is not a simple clock frequency involved. Instead, there are various setup times, hold times, and output delays that imply limits on the I/O rate to/from the NAND. The spreadsheet compares the NAND's timing specifications to see if sums of the setup, hold, and output times are shorter than the minimim read-cycle or write-cycle times. The spreadsheet is specifically intended for use with the Nand controller in STMP378x/i.MX233/i.mx28 chips, so the spreadsheet performs the timing calculations with the goal of deriving the timing parameters *TSU*, *TDS*, and *TDH* for those CPUs. If the TDS and/or TDH quantities {color:#ff0000}turn red{color} after all the timings have been computed, then the computed TDS and/or TDH are too short for the specified cycle-time of the NAND. In that case:           You will have to increase one or both of them in the software. Write a note somewhere in the analysis spreadsheet about the values that you choose, but don't mess up the automatic computations. Record how the flash denotes factory-marked bad-blocks. (Some use the first page of a block, some use the last page,, etc.) Compare it to this [current superset of bad-block marking methods [http://wiki.freescale.net/display/PSGSW/Storage+Media%2C+Flash+Bad+Block+Marks] used to detect any flash factory bad block. Example Analysis Examples of NAND datasheets and analyses can be found on the [Hynix NAND Page | http://wiki.freescale.net/display/PSGSW/Hynix+NAND+Flash+Documents].