The latest i.MX28 BSP provided by Freescale (10.12) is based on a 2.6.35 kernel. If you want to use the latest and greatest kernel version from kernel.org, follow the steps below. 1. Get the mainline kernel: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git(this is only done once) git checkout -b yourlocalbranch origin/master 2. Export the toolchain PATH=/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/:$PATH export PATH export CROSS_COMPILE=arm-none-linux-gnueabi- export ARCH=arm 3. Build the kernel make mxs_defconfig make uImage sudo cp arch/arm/boot/uImage /tftpboot (In this example /tftpboot is the directory used to send files via TFTP) 4. Kernel command line: On U-boot change the following parameter of the kernel command line: console=ttyAM0,115200 to console=ttyAMA0,115200 5. On LTIB You can still use LTIB to provide the root file system. ./ltib -c Target System Configuration Options ----> Unselect [] boot up with tty and login If this option is selected the serial port will fail to open as it still uses ttyAM0 instead of ttyAMA0. 6. Boot the kernel via TFTP and mount the rootfs via NFS.

Splash Screen on U-boot for i.MX25 PDK Having a bitmap on the LCD a few seconds after boot is a requirement on several embedded systems, u-Boot supports this feature. However, currently, the code provided on Freescale's BSP only implements support for the LCD controller on Linux. This page provides instructions to add support for the LCDC on the u-boot. 1 - Install Freescale i.MX25 BSP, SDK 1.7 It is available on www.freescale.com. If needed follow the getting started section instructions. 2 - Update u-boot source After installing the BSP and running LTIB for the first time, it's time to update u-boot: - Download u-Boot patch and spec file. - Replace the file "u-boot.spec.in" located at <ltib_path>/config/platform/imx by the one downloaded - Copy the "u-boot-2009.08-1273860148.patch" downloaded to /opt/freescale/pkgs 3 - Extract and rebuild u-boot - To extract the source and aply the patch run: <Ltib_path>$ ./ltib -p u-boot -m prep - Now Build:     <Ltib_path>$ ./ltib -p u-boot -m scbuild    After completing this step an u-Boot binary (u-boot.bin) will be saved at <ltib_path>/rpm/BUILD/u-boot-2009.08 4 - Program the SD card Program a SD card with the new u-Boot binary and a bitmap image to be displayed. Insert the SD and run:      $sudo dd if=<ltib_path>/rpm/BUILD/u-boot-2009.08/u-boot.bin of=/dev/mmcblk0 bs=512 "/dev/mmcblk0" should replaced according to your host, use "dmesg" after inserting the SD to find out where is the SD on your host. Unmount it before issuing the dd command. $sudo dd if="your_image".bmp of=/dev/mmcblk0 bs=512 seek=608 Argument seek 608, skips the first 608 blocks of the SD (608x512) where the uboot is stored. If you need to relocate the image, update also the environment variable "splashimage_mmc_init_block", see step 6. 5 - Boot Boot the image from the SD. Personality Board settings:   12345678 SW22 -> 00000000 SW21 -> 11000000    Debug Board settings: SW5,6,7,8,9,10 -> OFF      12345678 SW4 -> 10000001 Turn on the board and stop at u-boot prompt: MX25 U-Boot > 6 - u-Boot environment variables Update u-Boot environment variables for the splash screen to work: The address in memory to load the splash screen from: MX25 U-Boot > setenv splashimage 0x80800000 The SD device on the board: MX25 U-Boot > setenv splashimage_mmc_dev 0 The block on the SD where the bitmap is stored, this must match the block on step 4. MX25 U-Boot > setenv splashimage_mmc_init_block 0x260  The amount in blocks to be read from the SD card, this depends on the bitmap size, i.e. for a 308278 bytes bitmap, 0x2B5 blocks are enough on a 512 bytes per block SD, (308278 / 512). MX25 U-Boot > setenv splashimage_mmc_blkcnt 0x2b5 The SD card block size in bytes: MX25 U-Boot > setenv splashimage_mmc_blksize 512 Save the environment variables: MX25 U-Boot > saveenv Now reboot the board and you should see the splash screen on the LCD. 7 - Booting Linux When Linux takes control of the board it initializes the LCD controller and Framebuffer again. To maintain the splash screen on the LCD you can replace the Linux Logo with the figure used for the splash screen, the side effect is a blink when Linux takes over the LCDC. To achieve this, create a new image in Gimp and save it as ".ppm". Copy it to Linux "logo" folder <ltib_path>/rpm/BUILD/linux-2.6.31/drivers/video/logo Run: $ ppmquant -mapfile clut_vga16.ppm "my_image.ppm" | pnmnoraw > logo_linux_vga16.ppm where: logo_linux_vga16.ppm is the current logo being used by Linux. Recompile the kernel and boot it.

ATK (Advanced Toolkit) ATK is a Windows tool for programming the flash memory of i.MX boards. It can be downloaded here. Using ATK This section will describe the procedure to erase the flash memory and program the bootloader. 1. Assemble the PDK using the CPU board, the Personality board, and the Debug board. 2. Connect a USB cable between the PC and the i.MX25 PDK Personality board. 3. Some hardware configurations (switches) must be set for booting from UART/USB:   On the debug board:   Switch SW5 -> Off   Switch SW6 -> Off   Switch SW7 -> Off   Switch SW8 -> Off   Switch SW9 -> On   Switch SW10 -> On   On the personality board:   Switch SW21 -> 11000000   Switch SW22 -> 00000000 {{Note|On SW5 thourgh SW10, "1" means the keys selected towards the edge of the board.} 4. Run ATK (1.6 or above) going to Start -> Programs -> AdvancedToolKit -> AdvancedToolKit   Set the options:   i.MX CPU -> i.MX25_TO1.1   Device memory -> DDR2;   Custom Initial File -> (keep it unmarked)   Communication Channel -> USB 5. Power up the i.MX25 PDK 6. Click on "Next" 7. Click on Flash Tools to erase, program or dump the the flash memory and click GO. NAND Flash Erasing 1. Configure the Dip Switch of Personality Board:                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      Switch 1 2 3 4 5 6 7 8 SW1 OFF OFF OFF OFF N/A N/A N/A N/A SW2 ON OFF OFF ON ON OFF OFF OFF 2. Choose NAND model K9LAG08U8M 3. Continue the steps Remember to select the checkbutton BBT (Back Block Table) Commands to flash kernel and rootfs fis init -f load -r -b 0x100000 zImage -h <host IP address> fis create -f 0x300000 kernel load -r -b 0x100000 rootfs.jffs2 -h <host IP address> fis create -f 0x800000 root fis load kernel exec -c "noinitrd console=ttymxc0 115200 root=/dev/mtdblock2 rw ip=dhcp rootfstype=jffs2" Command to create rootfs.jffs2 mkfs.jffs2 -r rootfs -e 0x80000 -s 0x1000 -n -o rootfs.jffs2

You can boot from SPI NOR Flash using the following procedure:      1 - Download ATK Release 1.7. The version ATK 1.7 can be downloaded here. 2 - Unzip file iMX_AdvancedToolKit_R170.zip into "C:\Program Files\freescale\AdvancedToolKit-STD\image\".      3 - Open the file "C:\Program Files\freescale\AdvancedToolKit-STD\config\ADSToolkit.cfg" and add the following lines: [MX25_TO11] MMC/SD::image\mx25_mmc.bin:0x(unknown) NAND::image\mx25_nand.bin:0x(unknown) SPI::image\mx25_spi.bin:0x(unknown) [MX31]   4 - Set the SPI Boot Config on MX25PDK:   SW22: no influence SW21[1-8]: 11110010 BT_MEM_CTL[0:1] = 11 (Expansion) BT_MEM_TYPE[0:1] = 11 (Serial ROM via SPI) BT_PAGE_SIZE[0:1] = no influence BT_BUS_WIDTH[0:1] = 10 (3-Address SPI (24-bit) Note: BT_BUS_WIDTH[0]=1, BT_BUS_WIDTH[1]=0 On Debug Board the red switches: (SW5-SW10) = 000011 (0=off) Boot Config Switches (SW21, SW22) on Personality Board have no influence.   5 - Connect USB or Serial cable between Host PC and PDK and execute ATK   6 - Select USB/UART serial boot on MX25PDK and power on the board   7 - Configure ATK as following: Device = i.MX25_TO1.1 device memory initial = DDR2 Communication channel: COMn (select the COM port on your PC) or Communication channel: USB If you choose COM (serial UART connection) you MUST disconnect USB cable from OTG connector on i.MX25 PDK.   8 - Configure ATK "Flash Tool" as following: Tick "Program" Tick "Read Back Check" Flash Model = SPI Address = 0x0 Image = mx25_3stack_redboot_TO1_1.bin (same file as for NAND boot). Same should be applicable to U-boot.   Note: SPI NOR Boot requires internal boot mode. On Debug Card all red switches must be off (SW5-SW10) = 000000 (0=off). Note: if booting from SPI NOR, Redboot needs approx 2 seconds before it shows messages on the console.

In Chinese Twitter: Sino Weibo, one famous distributor mentioned “i.MX28 is the best choice in ARM9 core-based processor, no ‘one of’”. With high integration of analog module and digital module, i.MX28 is attracting more and more engineers in various applications. Despite its advantage, there are some mistakes one may commit or issues they may meet. The note records a number of issues/mistakes. Each case in the note comes from a real story. I hope the note will help you in your development work. And It is definitely welcomed for everyone to add your own content to the note.The more you share, the more you get.

The imx_bootlets package in LTIB contains the code that will be the first code loaded and executed by ROM when booting a build of the Linux BSP. It is responsible for initializing some of the low level peripherals such as the integrated power supply and the DRAM controller as well as a few other initialization tasks. The default configuration of the bootlet code for the latest i.MX233 and i.MX28x release (SDK 10.05 and SDK 10.12 respectively) support a hardware configuration that has both a LiIon battery configuration (as shown in the reference schematics for these platforms as shown on freescale.com). For other configurations though such as a VDD5V connection only or a DCDC_BATT/Battery connection only, some additional changes are recommended.

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:

Some i.MX25 customers reported an issue for the GPT timer, when using 120MHz (240MHz UPLL divided 2) clock source as the GPT per_clk, the timer will not be increased all the time in free-run mode. If using 66.5MHz IPG clock and 133MHz PER clock as the clock source, there are no such issue. There are 4 test cases in the attached test code. Case 0: in CCM_MCR, set bit 5 as 0 for 133MHz HCLK as the gpt_per_clk source;  in GPT_CR bit[8:6], set 0b001 ipg_clk (66.5MHz). There is no issue, the GPT counter is fixed at 4 between old_cnt and new_cnt. Case 1: in CCM_MCR, set bit 5 as 0 for 133MHz HCLK as the gpt_per_clk source;  in GPT_CR bit[8:6], set 0b010 ipg_clk_highfreq (133MHz). There is no issue, the GPT counter is fixed at 8 between old_cnt and new_cnt. Case 2: in CCM_MCR, set bit 5 as 1 for 240MHz UPLL divided by 2 as the gpt_per_clk source;  in GPT_CR bit[8:6], set 0b001 ipg_clk (60MHz). There is no issue, the GPT counter is fixed at 4 between old_cnt and new_cnt. Case 3: in CCM_MCR, set bit 5 as 0 for 240MHz UPLL divided by 2 as the gpt_per_clk source;  in GPT_CR bit[8:6], set 0b010 ipg_clk_highfreq (120MHz). There is issue, the GPT counter is not a fixed value between old_cnt and new_cnt, and sometimes it will be negative. Count 9874: 4 old_cnt: 0x188849dc new_cnt: 0x188849e0 Count 9877: 12 old_cnt: 0x18918400 new_cnt: 0x1891840c Count 9915: 4 old_cnt: 0x189aea90 new_cnt: 0x189aea94 Count 9937: -12 old_cnt: 0x18a42458 new_cnt: 0x18a4244c Count 9967: 4 old_cnt: 0x18adb17c new_cnt: 0x18adb180 In fact, it is not an issue, when using UPLL as the GPT clock source, the maxim frequency should be 60MHz. That's why all other three test case is OK and it only failed on this case.

A new release of the manufacturing tool is was recently made available, "imx-3.10.53_1.1.0_ga-mfg-tools". It can be found in the software download sections for the iMX6 family. However, it can be used to program an iMX28 in a Win7 64-bit host by adding a few files. The steps to do so are listed below and can be checked against the script in ucl2.xml.   Download the attached "28.vbs" file and place it into where the manufacturing tool was installed, typically in  <install_dir>\mfgtools\   Replace <install_dir>\mfgtools\Profiles\Linux\OS Firmware\ucl2.xml with the attached ucl2.xml.    Copy the attached files "updater_ivt.sb" and "fdisk-u.input" into <install_dir>\mfgtools\Profiles\Linux\OS Firmware\firmware Copy your iMX28 image file into <install_dir>\mfgtools\Profiles\Linux\OS Firmware\files.  The file should be renamed to "linux.sb" to conform with the ucl2.xml script. Copy your "rootfs.tar.bz2" file into <install_dir>\mfgtools\Profiles\Linux\OS Firmware\files To launch the manufacturing tool, double click on "28.vbs". Issue: After MfgTool has finished and the progress bars have turned green, clock on the Stop button or the program will start another cycle.

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

Question: How to enable HAB on the MX28, following the recommendations of AN4555 to get the "get_hab_status()" function working, but has run into an issue. Question #1 They believe they have all the HAB components worked out that are inputs to the efltosb tool as they are able to successfully run U-boot to the interactive prompt.  However, at the point where they:     - call the rvt_report_status() function, their board says "### ERROR ### Please RESET the board ###".      - call the rvt_entry(), their board prints some garbage characters on the screen and then hangs. This suggests that there is something wrong with the clock that in turn affects the baudrate on the serial console causing the above behavior. Question #2 Is there a concept of a "Bound Signature" in HABv4 as there is in HABv3? Any chance the addresses for the rvt_ calls are incorrect? Can you provide the u-boot source? Either Bound signature verification or UID is never mentioned in the HABv4 Application Note. So I suppose it is not supported. We have made assumptions about the RVT function pointer offsets.  The HAB 4 API does not explicitly say the offsets but uses a rvt_base::function_name notation.  We have assumed that function pointers are placed in order, at every word offset beyond the RVT header.  We have confirmed the RVT header exists at the latest address in the reference manual based on a memory dump but we cannot be certain the function offsets we have setup are correct. As far as source code, we modeled our changes for our mx28 board off of the hab.c and hab.h files available from the mainline u-boot for the mx6 architecture. This is basically the same code get_hab_status code that is written in the AN4555 document.  We did HAB API function pointer addresses to match the updated RVT base address and assumed offsets. Answer: Here are the first 3 instructions from report_status(), could your customer check the instructions from the address which they called is correct? <report_status>: :   b087b570        addlt   fp, r7, r0, ror r5 :   1c0e1c05        stcne   12, cr1, [lr], {5} :   22182433        andscs  r2, r8, #855638016      ; 0x33000000

Introduction EMV stands for Europay, MasterCard and VISA, and is a global standard for inter-operation of integrated circuit cards (ICC) and ICC reader terminals (like point of sale (POS) terminals, automated teller machines (ATMs)) for authenticating credit and debit payment cards transactions. Any IC card reader must be certified to be EMV compliant. The EMV standard defines the interaction at the physical, electrical, data and application levels between the IC cards and IC card terminal. For the contact smartcards it is based on standard ISO/IEC 7816. Some of the i.MX embeds a Subscriber Identification Module (SIM) which was designed to facilitate the communication to a mobile phone SIM card. It could be used to communicate indirectly with a banking smartcard due to the listed limitations in regards to the EMV requirements. Electrical Limitations The POS terminal must support 1.8V, 3.3V, and 5V smartcards. Depending on the i.MX, 1.8V or 3.3V could be supported but not both, and 5V is definitely out of the range of the I/O supplies. => a level adapter component is required between the i.MX and the smartcard. Protocol Limitations The communication between the IC card and the reader is asynchronous (almost a UART), but based on a common clock for synchronous operation. The ISO7816 standard defines the following: 1 ETU = F / D * 1 / f ETU is Elementary Time Unit, which is somehow the nominal time to transmit a bit (0 or 1). F or Fi is the clock rate conversion integer. D or Di is the baud rate adjustment integer. f is the frequency of the communication clock used between the controller and the smartcard. Below is a partial list of what the controller must support to pass the EMV certification, and the known limitations of the SIM controller: - baud rate at x1 (Fi/Di=372/1) => default speed for all smart cards =>  supported. - baud rate at x2 (Fi/Di=372/2 = 186/1) => a higher speed for some smart cards => not supported. - baud rate at x4 (Fi/Di=372/4 93/1) => a higher speed for some smart cards => not supported. - message length of 12ETU => specified for T=0 type smart card => supported. - error of -0.2ETU on message length of 12ETU => 11.8ETU smart card => not supported. - message length of 11ETU => specified for T=1 type smart card => supported. - error of -0.2ETU on message length of 11ETU => 10.8ETU smart card => not supported. Conclusion For these reasons, the i.MX SIM controller does not allow to pass the EMV certification without the usage of an external controller that must care of all these missing features. The SIM can still be used to communicate with that external controller such Atmel AT83C26, NXP TDA8023, Terridian, or On Semi. Freescale does not have driver neither reference design to support that configuration. This company has the expertise to work with EMV certification for the i.MX258 + a companion smartcard controller: http://www.alcineo.com

i.MX27 and i.MX31 Issues When Interfacing Micron's 78nm mDDRs Micron is discontinuing some "-75" mDDR parts (133MHz) popular on i.MX27 and i.MX31 designs, newer "-6" are being used to replace the EOL devices. However, loss of data issues may be experienced when i.MX mDDR controller is used to interface with newer Micron's mDDR. On some cases, the bootloader works, memory tests on RedBoot pass. However, Linux hangs when booting. Here are the DDR Controller configuration changes that may be used to avoid the issue: (This configuration is not proven to work on every design, but has been validated on at least 3 different boards.) ESDRAMC Configuration Registers Set ESDCFG0/1 to 0x0079D72F 0xD800_1004 = 0x79D72F Drive Strength Control Registers Use "Normal". i.MX27 Default. Enhanced MDDR Delay Line Configuration Debug Register Set the ESDCDLYx to 0x002C0000 0xD800_1020 = 0x2C0000 0xD800_1024 = 0x2C0000 0xD800_1028 = 0x2C0000 0xD800_102C = 0x2C0000

This is the procedure and patch to set up Ubuntu 12.04 64bit Linux Host PC and building i.MX28 L2.6.35_1.1.0_130130.  It has been tested to build GNOME profile and with FSL Standard MM codec. A) Basic Requirement: Set up the Linux Host PC using ubuntu-12.04.3-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install ia32-libs libc6-dev-i386 lib32z1 $ sudo apt-get install uboot-mkimage $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L2.6.35_1.1.0_130130_source.tar.gz $ ./L2.6.35_1.1.0_130130_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L2.6.35_1.1.0 could be installed and compiled on Ubuntu 12.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L2.6.35_1.1.0_130130_compile_on_ubuntu_12.04_64bit_OS.patch a) The patch modifies the following files:    dist/lfs-5.1/base_libs/base_libs.spec    dist/lfs-5.1/lkc/lkc.spec    dist/lfs-5.1/mux_server/mux_server.spec    dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory:    pkgs/lkc-1.4-lib.patch    pkgs/lkc-1.4-lib.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L2.6.35_1.1.0_130130_docs/doc/mx28/Setting_Up_LTIB_Host_on_Ubuntu_9_04.pdf https://community.freescale.com/docs/DOC-93394 https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

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.

When boot from battery, then plug in 5V cable, the actual charging current can't reach the preset charging current. It is because the HEADROOM_ADJ is not correctly set. Please use attached mx28_chargingcurrent_limit_bootfrombattery.patch. Grace

Video Streaming over Ethernet This section shows how to stream a video over Ethernet using UDP and RTP. Be sure to have the newest gst-plugin-good installed to ensure the best streaming quality. Define the environment variable HOST with the ip address of the receiver machine (that one that will show the video). $ export HOST=XX.XX.XX.XX Do you know how to get caps? i.MX 27 Video GST Caps H264 (MX->PC) in i.MX27: gst-launch-0.10 -v mfw_v4lsrc capture-width=640 capture-height=480 ! mfw_vpuencoder width=640 height=480  /     codec-type=std_avc ! rtph264pay ! udpsink host=$HOST port=5000 in PC: gst-launch-0.10 -v --gst-debug=2 udpsrc port=5000 /   caps ="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, /   profile-level-id=(string)42001e, sprop-parameter-sets=(string)Z0IAHqaAoD2Q, payload=(int)96, /   ssrc=(guint)3296222373, clock-base=(guint)2921390826, seqnum-base=(guint)35161" ! /   rtph264depay  ! ffdec_h264 ! autovideosink MPEG4 (MX->PC) in i.MX27 gst-launch-0.10 -v mfw_v4lsrc capture-width=352 capture-height=288 ! mfw_vpuencoder width=352 height=255 bitrate=64 codec-type=std_mpeg4 ! rtpmp4vpay send-config=true / ! udpsink host=10.29.244.32 port=5000 Set send-config to true to send configuration with the video. Ensures better deconding PC gst-launch-0.10 -v --gst-debug=2 udpsrc port=5000 caps ="application/x-rtp, media=(string)video, clock-rate=(int)90000, / encoding-name=(string)MP4V-ES, profile-level-id=(string)2, config=(string)000001b002000001b59113000001000000012000c888800f50b042414103, / payload=(int)96, ssrc=(guint)4006671474, clock-base=(guint)3714140954, seqnum-base=(guint)29742" / ! rtpmp4vdepay ! ffdec_mpeg4 ! autovideosink MPEG4 (MX->MX) Sender gst-launch-0.10 -v mfw_v4lsrc capture-width=640 capture-height=480 ! mfw_vpuencoder width=640 height=480  codec-type=std_mpeg4 ! rtpmp4vpay send-config=true ! udpsink host=$HOST port=5000 Receiver gst-launch-0.10 -v udpsrc port=5000 caps= "application/x-rtp, media=(string)video, clock-rate=(int)90000, / encoding-name=(string)MP4V-ES, profile-level-id=(string)4, config=(string)000001b004000001b59113000001000000012000c888800f514043c14103, / payload=(int)96, ssrc=(guint)907905085, clock-base=(guint)2029414707, seqnum-base=(guint)22207" ! rtpmp4vdepay ! / mfw_vpudecoder codec-type= std_mpeg4 min_latency=true ! mfw_v4lsink sync=false   Setting min_latency true gives the better latency for the streaming H264 (MX->MX) Sender gst-launch-0.10 -v mfw_v4lsrc capture-width=640 capture-height=480 ! mfw_vpuencoder width=640 height=480  codec-type=std_avc ! rtph264pay ! udpsink host=10.29.240.51 port=5000 Receiver gst-launch-0.10 -v udpsrc port=5000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000" ! rtph264depay ! mfw_vpudecodr codec-type=std_avc ! mfw_v4lsink sync=false

This is the procedure and patch to set up Ubuntu 13.10 64bit Linux Host PC and building i.MX28 L2.6.35_1.1.0_130130. It has been tested to build GNOME profile and with FSL Standard MM codec. A) Basic Requirement: Set up the Linux Host PC using ubuntu-13.10-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 $ sudo apt-get install libc6-dev-i386 $ sudo apt-get install u-boot-tools $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd $ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so   /usr/lib/librt.so C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L2.6.35_1.1.0_130130_source.tar.gz $ ./L2.6.35_1.1.0_130130_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L2.6.35_1.1.0_130130 could be installed and compiled on Ubuntu 13.10 64bit OS $ cd ~/ltib $ git apply 0001_make_L2.6.35_1.1.0_130130_compile_on_ubuntu_13.10_64bit_OS.patch What the patch is doing: a) The patch modifies the following files: dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/elftosb/elftosb.spec dist/lfs-5.1/lkc/lkc.spec dist/lfs-5.1/mux_server/mux_server.spec dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory: pkgs/elftosb-2.6.35.3-1385779630.patch pkgs/elftosb-2.6.35.3-1385779630.patch.md5 pkgs/lkc-1.4-lib.patch pkgs/lkc-1.4-lib.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L2.6.35_1.1.0_130130_docs/doc/mx28/Setting_Up_LTIB_Host_on_Ubuntu_9_04.pdf https://community.freescale.com/docs/DOC-93394 https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation elftosb compilation issue fixed by added -lm to LIBS in the elftosb-2.6.35.3-1.1.0/makefile.rules NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

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].

Here is an example for i.MX28 EVK board to support SPI NOR boot in uboot, kernel and MFGTool.   Attached files are the patches to support SPI NOR flash on i.MX28 EVK bord based on L2.6.35 ER11.09.01 BSP. It was verified on Spansion s25fl256s SPI NOR. "ER11.09.01_uboot_imx28_spi_nor.patch" is the Uboot patch. "ER11.09.01_kernel_imx28_spi_nor.patch" is the kernel patch. "ucl.xml" is the updated MFGTool config file, please update it to "Mfgtools-Rel\Profiles\MX28 Linux Update\OS Firmware\ucl.xml".   The uboot boot paramters for SPI: setenv bootargs_base 'setenv bootargs console=ttyAM0,115200' setenv loadaddr 0x42000000 setenv bootargs_spi 'setenv bootargs ${bootargs} root=/dev/mtdblock2 rootfstype=jffs2 rootwait rw ip=none' setenv bootcmd_spi 'run bootargs_base bootargs_spi;sf probe 2:0; sf read ${loadaddr} 0x100000 0x300000;bootm' setenv bootcmd 'run bootcmd_spi' saveenv   To boot the board from SPI NOR s25fl256s, the 4KB page region of the NOR should be put to top, the last 128KB of the NOR address space. The uboot.sb is about 220KB, it can't be put to 4KB and 64KB combined region. The IMX28 boot ROM can only handle simple page size for boot. All 4KB page region or all 64KB page region are both OK for boot, but combined region can't boot.   For default, the s25fl256s NOR's 128KB 4KB page size region is at the bottom of the NOR, we should update the OTP to set this region to TOP, in Uboot, we run the followed command to burn the OTP: MX28 U-Boot -> sf probe 2:0 MX28 U-Boot -> sf set_config_reg 0x04   To boot the i.MX28 EVK board from SPI2 NOR flash, the BM3~0 should be 0010.   In this example, we only used the JFFS2 file system. To support the UBIFS, there is a known issue, that the UBIFS will use vmalloc to alloc memory, and if SPI driver used the DMA, kernel will halt with error "kernel BUG at arch/arm/mm/dma-mapping.c:409!".   For 11.09.01 BSP, the default MFGTool rootfs "initramfs.cpio.gz" will be bigger than 4MB, but in i.MX28 bootlets code, the BSP only set ramdisk to 4MB, so we need modify this limitation for MFGTool.   Use command "./ltib -p imx-bootlets -m prep" to get the bootlets code, modify "ltib/rpm/BUILD/imx-bootlets-src-11.09.01/linux_prep/core/setup.c", function setup_initrd_tag(), change from "params->u.initrd.size =  0x00400000;" to "params->u.initrd.size =  0x00500000;". Modify "ltib/rpm/BUILD/imx-bootlets-src-11.09.01/updater.bd" and "updater_ivt.bd", change from "load 0.b    > 0x40800000..0x40c00000;" to "load 0.b    > 0x40800000..0x40d00000;".   Now the MFGTool rootfs size can be 5MB.   2013-05-09: Updated hardware rework: On iMX28 EVK board, rework J89 as followed and mount R320,R321,R322 and C178. MX28 U49 Pin1 /CS <-> NOR Pin7 CS# MX28 U49 Pin2  D0 <-> NOR Pin8 SI/IO1 MX28 U49 Pin5 DIO <-> NOR Pin15 SI/IO0 MX28 U49 Pin6 CLK<-> NOR pin 16 SCK. MX28 U49 Pin8 VCC <-> NOR Pin2 VCC                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 MX28 U49 Pin4 GND <-> NOR Pin10 VSS MX28 U49 Pin3 /WP <-> NOR Pin9 WP MX28 U49 Pin7 /Hold <-> NOR Pin pin1 hold   Software reset issue for 32MB SPI NOR: For 32MB SPI NOR, after booted into kernel, the kernel driver will set SPI NOR to 4 bytes address mode, but for iMX28 SPI boot, it can only boot with 3 bytes address mode, if reset the iMX28 board but SPI NOR was not reset, it will fail to reboot. Hardware solution: when iMX28 was reboot, reset the SPI NOR too, the SPI NOR will work in 3 bytes address mode as default. Software solution: In kernel SPI NOR driver, always switch SPI NOR to 3 bytes address mode after each SPI NOR access, and switch to 4 bytes address mode before each access. There is no such issue if the SPI NOR size is less than 32MB.