Currently the default i.MX51 wince release doesn't support high capacity MMC card. Attached was the patch of how to enable high capacity MMC card in i.mx51. Original Attachment has been moved to: High-capacity-MMC-support.zip
In the i.MX51 default WINCE6 release, the eCSPI doesn't support multiple bursts mode and set the wait states. Attached was the document and code for how to enable the multiple bursts mode and how to set the wait states between two burst.
In traditional file system, the WinCE image is a signal file “NK.NB0”/”NK.BIN”. And when using NAND flash for storage, since it can’t support XIP, the total “NK.NB0” need be copied into RAM before running. The EBOOT will do this copy. In this way, there are two main shortages: Long boot time and big size RAM requirement. If the WinCE image is big (Included more features), these issues will be critical. The BINFS can fix those two issues fine. It gave the chance to use 32MB RAM run 64MB WinCE image, this can cost down the final products. In BINFS file system, the final WinCE image will be divided into multi-BIN files, and only the XIPKERNEL BIN (Less than 7 MB) need be copied into RAM by EBOOT. The files in other BIN will work with demand paging mode. These files will be loaded into RAM only when they need run.
Attached is the SDHC DMA read supported patch, it is based on WCE600_MX51_ER_1104, it was verified on iMX51 EVK board. The SDHC DMA read can reduce the NK copy time, in this way it can speed up the WinCE boot.
An i. MX50 customer encountered such kernel bug recently. Android UI has no response, because the suspend work queue is blocked: suspend pm_suspend enter_state suspend_prepare / suspend_finish pm_prepare_console / pm_restore_console vt_move_to_console vt_waitactive vt_event_wait wait_event_interruptible Confimed the same bug can also happen on imx6SL which is running linux 3.0.35. e.g. by echo standby/ mem > /sys/power/state It takes over thousand suspend/resume cycles to reproduce the problem. The bug fix has been merged since linux 3.6: commit a7b12929be6cc55eab2dac3330fa9f5984e12dda
In L2.6.35_11.09.01_ER BSP Uboot, the MMC driver was updated, but there is issue that when you modified some uboot code, the MMC driver has chance to fail to work. The root cause is that mmc->has_init hasn't been initialized. Sometimes the value will be not zero, then mmc driver will be skipped for initialization. Attached is the patch to fix this issue in L2.6.35_11.09.01_ER BSP Uboot.
GStreamer has a simple feature to enable tracing, allowing the developer to do basic debugging. These can be done in two ways: Adding the parameter --gst-debug=LIST to the pipeline (a pipeline is a executed gst-launch command) Prepending the environment variable GST_DEBUG=LIST' LIST is a a comma-separated argument, indicating the GStreamer elements to trace. For example, if one needs to trace the sink element $ GST_DEBUG=*sink*:5 gst-launch playbin2 uri=file:///sample.avi or $ gst-launch playbin2 uri=file:///sample.avi --gst-debug=*sink*:5 Both commands produces the same log. In case want to trace for than one element, so can simple add the <element>:5, for example $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi The number 5 indicates the log category, where 5 is the highest (the most verbose log you can get) and 0 produces no output (5=LOG, 4=DEBUG, 3=INFO, 2=WARN, 1=ERROR). Log can be huge in each pipeline run. One way to filter it is using the grep command. Before grepping, one needs to redirect the standard error to the standard output (GStreamer log goes always to stderr), so $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi 2>&1 | grep <filter string> In case the log needs to be shared, it is important to remove the 'color' of the log, again, one just needs to add the parameter --gst-debug-no-color or prepend the env variable GST_DEBUG_NO_COLOR=1 ----- More shell variables that GStreamer react, can be found here https://developer.gnome.org/gstreamer/0.10/gst-running.html
Freescale's consumer and industrial i.MX 51 applications processors balance the performance, power consumption, connectivity and multimedia capabilities necessary to drive today's latest and greatest products. Freescale's automotive i.MX 51 processors provide what is necessary to steer today's most advanced automotive systems. i.MX51 Family Comparison i.MX Family Comparison Product Information on Freescale.com i.MX512 Applications Processor i.MX513 Applications Processor i.MX514 Applications Processor i.MX515 Applications Processor i.MX516 Applications Processor Evaluation/Development Boards and Systems IMX51EVK Evaluation Kit Bootloader Installing U-Boot on i.MX51EVK Flashing i.MX51EVK Working with mainline U-Boot Add new iMX5x board on LTIB Compiling U-Boot (from Freescale BSP) using LTIB Changing environment variables storage on U-Boot Linux Flashing Linux application only with SD card Reader Multimedia Using USB Camera Installing OpenCV Library (Open Computer Vision - Image Processing) Android Android without RamDisk Installing TTS library manually Running ADB over USB (iMX51 and Ubuntu communication) Ubuntu Using an USB Touchscreen (Karmic) Using Touchscreen (Lucid) Embedded Software and Tools Android OS for i.MX Applications Processors i.MX51 Current Software Updates and Releases Partners / 3rd-Party Development Tools STK5: Starter-Kit 5 (Karo Electronics) Additional Resources Board bring-up and DDR initialization tools Develop a Simple OpenVG Application Under Linux: Tutorial i.MX 51 Android ADB over USB IMX51EVK i.MX51 EVK Board USB Camera i.MX51 EVK Compiling U-boot i.MX 51 EVK U-boot i.MX51 EVK Board Video i.MX51 EVK Board OpenCV i.MX51 EVK Board Flashing i.MX51 Flashing Linux Application Only with SD Card Reader I.MX51EVK Install U-Boot i.MX51 EVK Compiling U-boot i.MX51 EVK U-boot i.MX51 EVK Changing Env IMX51 Ubuntu USB TS i.MX 51 Ubuntu TS Lucid
This table shows how to configure i.MX51 EVK DIP Switches to boot from SD card and how to boot from internal ROM to use ATK: DS1 DS2 DS3 DS4 DS5 DS5 DS7 DS8 DS9 DS10 Boot from SD/MMC Card 0 0 0 0 0 0 1 1 0 0 Boot from i.ROM (ATK) 1 1 0 0 0 0 1 1 0 1
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 ) ...
Installing U-Boot on i.MX51EVK using BDI3000 Unlike older i.MX processor you don't need to select CONFIG_SKIP_LOWLEVEL_INIT because U-Boot lowlevel for i.MX51 doesn't reconfigure RAM memory. It is configured on DCD table. Copy u-boot.bin to /tftpboot because BDI3000 will load it from there. Connect the serial console cable on your i.MX51EVK board and connect to it using minicom. Connect to your BDI3000 through telnet and execute these commands: FSL-iMX51> load 0x97800000 u-boot.bin Loading u-boot.bin , please wait .... Loading program file passed FSL-iMX51> rm pc 0x97800000 FSL-iMX51> go When you execute the last command (“go”) you will see U-Boot starting on serial console.