i.MX Processors Knowledge Base

Discussions

In order to get USB cameras (web cams) working on i.MX 51 EVK board running Ubuntu, a few steps must be followed, and they are: Enable USB Camera's drivers on Kernel Test it using Gstreamer or another compatible software (as Cheese) Kernel Driver USB cameras (web cameras) on Linux work over GSPCA driver, to enable this driver you need to go to: ./ltib -c [*] Configure the kernel Device Drivers --> Multimedia Devices --> [*] Video Capture Adapters --> [*] V4L USB Devices --> <*> USB Video Class (UVC) [*] UVC input events device support <*> GSPCA Based WebCams --> From this point, you need to choose your specific driver. If you don't know, you can select all of those options as a built-in module "<*>" that will work. GSPCA Drivers USB Camera Detection Connect your USB camera to the USB Host port on i.MX 51 EVK board and then type "dmesg", and also check if there is a video0 device using: ubuntu@ubuntu-desktop:~$ ls /dev/video0 /dev/video0 USB Camera Detection Gstreamer Command Line In order to test your USB camera using Gstreamer plugin, use the following command line to perform it: ubuntu@ubuntu-desktop:~$ gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink and the results: Hi there !!! EOF !

It is often not easy to use company network to flash application, due to network security (proxy, etc...). We will see in this tutorial, how to flash a Linux application in a SD card with ONLY a SD card reader and simple standard Linux commands. SD card Memory Map A Linux application is divided in 3 parts: the bootloader the Linux Kernel the Linux Rootfs We will flash sequentially these 3 parts Flashing U-boot With the SD card Reader, we will flash the yellow part. In the [...]/ltib/rootfs/boot/ folder $ sudo dd if=u-boot.bin of=/dev/sdb bs=512 skip=2 seek=2 && sudo sync Flashing Linux Kernel With the SD card reader, we will flash the green part. Keep in mind that 1MB=1048576B -> Kernel Offset. $ sudo dd if=uImage of=/dev/sdb bs=1048576 seek=1 && sudo sync Configure U-boot variables To launch the Kernel, you need to configure U-boot. Plug the serial cable on the EVK: 115kbps, 8 bits, 1 stop and no parity EVK switches must be configured as below: 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 Put the SD card in the EVK (bottom slot) and launch the app. In the hyperterminal type: BBG U-Boot > printenv To print environnement variables Modify the bootcmd: BBG U-Boot > setenv bootcmd_mmc 'run bootargs_base bootargs_mmc;mmc read 0 ${loadaddr} 0x800 0x1800;bootm' "0x1800" is the size of the kernel. Must be bigger than uImage Kernel file (0x1800x512Byte=3MB) If you want to use the WVGA as display screen (kernel need to be configured with CLAA support), for LTIB1007 and after (before it was 'wvga' option): Script for LTIB1007's u-boot on i.MX51 EVK (copy/paste in the hyperterminal): setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc read 0 ${loadaddr} 800 1800 ; bootm' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw init=/init' setenv bootargs_base' setenv bootargs console=ttymxc0,115200 di1_primary console=tty1' setenv bootcmd 'run bootcmd_mmc' saveenv Script for LTIB1007's u-boot on i.MX53 EVK (copy/paste in the hyperterminal): setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc read 0 ${loadaddr} 800 1800 ; bootm' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw init=/init' setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 di0_primary console=tty1' setenv bootcmd 'run bootcmd_mmc' saveenv You must have the following printenv: BBG U-Boot > printenv bootdelay=3 baudrate=115200 loadaddr=0x90800000 netdev=eth0 ethprime=FEC0 uboot_addr=0xa0000000 uboot=u-boot.bin kernel=uImage bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serveri p}:${nfsroot},v3,tcp bootcmd_net=run bootargs_base bootargs_nfs; tftpboot ${loadaddr} ${kernel}; boot m load_uboot=tftpboot ${loadaddr} ${uboot} ethact=FEC0 bootargs=console=ttymxc0,115200 di1_primary root=/dev/mmcblk0p1 rootwait rw init =/init bootcmd_mmc=run bootargs_base bootargs_mmc; mmc read 0 ${loadaddr} 800 1800 ; bo otm bootargs_mmc=setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw init=/i nit bootargs_base=setenv bootargs console=ttymxc0,115200 di1_primary bootcmd=run bootcmd_mmc stdin=serial stdout=serial stderr=serial</br> Environment size: 748/131068 bytes BBG U-Boot > Create ext3 partition With the SD card reader, create an ext3 partition. You can use gparted, a graphical partition manager tool. Launch gparted: $ sudo gparted Create a new ext3 partition, with 20MB of offset: Copying Linux To copy rootfs folder generated by LTIB, type in the shell: $ sudo cp -r /[…]/ltib/rootfs/* /media/FreescaleSD/ && sudo sync Test application Put the SD in the slot slot and launch the application. Password is root.

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

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

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.

Changing the storage for U-boot environment variables U-Boot on Freescale BSP has a compiling option that allows you to choose the storage for environment variables. 1 - Extract the u-boot source using LTIB: ./ltib -m prep -p u-boot 2 - The source will be extracted to <ltib path>/rpm/BUILD/u-boot-2009.08 3 - On u-Boot source locate the i.MXEVK config file, <ltib path>/rpm/BUILD/u-boot-2009.08/include/configs/mx51_bbg.h 4 - To change the storage of variables environment to SD card, on this file, comment out CONFIG_FSL_ENV_IN_SF and define CONFIG_FSL_ENV_IN_MMC: //#define CONFIG_FSL_ENV_IN_SF #define CONFIG_FSL_ENV_IN_MMC 5 - Adjust CONFIG_ENV_SECT_SIZE and CONFIG_ENV_OFFSET accordingly. Recall that sd card read block size is 512B. For example: #define CONFIG_ENV_SECT_SIZE (256 * 512) #define CONFIG_ENV_SIZE CONFIG_ENV_SECT_SIZE #if defined(CONFIG_FSL_ENV_IN_MMC) #define CONFIG_ENV_IS_IN_MMC 1 #define CONFIG_ENV_OFFSET (1023 * 512) 6 - Save the file. 7 - Recompile u-boot: ./ltib -m scbuild -p u-boot 8 - Your new compiled u-boot image will be saved at: <ltib path>/rpm/BUILD/u-boot-2009.08/u-boot.bin

This tutorial has been done with an i.MX51 EVK. This example can be easily adapted to i.MX35 or i.MX53 that share the same GPU Core (Z160) and the same API (OpenVG 1.1). This tutorial show you how to do a simple image warp deformation with OpenVG 1.1. Generation of Linux Image with 2D gpu support To support 2D/3D gpu, you need to select gpu driver in LTIB. In LTIB's "package list" select the following packages: [x] amd-gpu-bin-mx51 [x] libz160-bin Build your Linux Image and copy it to your SD card. Building OpenVG simple application Download the application (see attached archive) Untar/unbz2 the application source code. To build the simple OpenVG application, you need to adapt the Makerules file. First you have to indicate where your linux image has been generated withLTIB: ROOTFS = /home/fsl/LTIB_1_7/ltib/rootfs You also need to indicate the compiler path (usualy installed in /opt/freescale/usr/local/....): GNUTOOL_PATH=/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/ After that you have to copy gpu's driver headers files in the include folder of the project. You will find these header in /opt/freescale/pkgs/amd-gpu-bin-mx51-x.x.x.tar.gz archive: extract all the include folders/files in the include folder of the project. Now you can build the application: fsl@fsl-laptop:~/SW/openVG_sample$ make /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc -mfloat-abi=softfp -mfpu=vfp -Wall -O3 -fsigned-char -D_LINUX -I/home/fsl/SW/openVG_sample/include -c warp.c -o warp.o In file included from warp.c:37: roselend_savoie_france_350x350.c:12391:66: warning: trigraph ??) ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:12964:71: warning: trigraph ??/ ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:14518:10: warning: trigraph ??- ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:15118:67: warning: trigraph ??) ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:15327:67: warning: trigraph ??' ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:15795:62: warning: trigraph ??! ignored, use -trigraphs to enable /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc -I/home/fsl/SW/openVG_sample/include -lOpenVG -legl13 -Wl,--library-path=/home/fsl/LTIB_1_7/ltib/rootfs/usr/lib,-rpath-link=/home/fsl/LTIB_1_7/ltib/rootfs/usr/lib -o warp warp.o fsl@fsl-laptop:~/SW/openVG_sample$ Copy the application on your SD card Put the SD card in the i.MX51 and run the gpu drivers $ login:root $ modprobe gpu Run the application $ ./warp Modifying the image A simple way to modify the image, is to use The Gimp. When you want to save your image, choose "C source code format": Then choose the prefix name (here "roselend"): Click on "Save". The "C" file of your image is generated: /* GIMP RGBA C-Source image dump (roselend_savoie_france.c) */ static const struct { guint width; guint height; guint bytes_per_pixel; /* 3:RGB, 4:RGBA */ guint8 pixel_data[350 * 350 * 4 + 1]; } roselend = { 350, 350, 4, "\265\303\357\376\264\304\357\376\262\304\357\376\260\304\356\376\260\303" "\356\376\257\303\356\376\257\302\355\376\257\301\355\376\257\302\355\376" "\257\302\355\377\256\302\356\376\256\302\357\376\256\302\356\377\255\302" "\357\376\254\302\360\376\253\302\357\376\254\302\355\376\255\302\357\376" ...

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.

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"

i.MX 51 EVK Board Bootloader i.MX 51 EVK Board Flashing i.MX 51 EVK U-boot i.MX 51 EVK Compiling U-boot i.MX 51 EVK Changing Env Linux i.MX 51 Flashing Linux Application Only with SD Card Reader Multimedia i.MX 51 EVK Board USB Camera i.MX 51 EVK Board OpenCV Android All Board Android Without Ramdisk All Board install TTS Library Manually i.MX 51 Android ADB over USB Ubuntu i.MX 51 Ubuntu USB TS i.MX 51 Ubuntu TS Lucid

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

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

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

i.MX51 EVK Board USB Camera

i.MX51 Flashing Linux Application Only with SD Card Reader

How to use PMIC RTC intead of i.MX51 RTC

i.MX51 Multimedia Applications Processors

Tracing GStreamer Pipelines

Flash Header for NAND boot on i.MX51 platform

Add New i.MX5x Board on LTIB

i.MX51 WINCE600 High capacity MMC support

I.MX51EVK Install U-Boot

i.MX51 EVK Changing Env

How to enable dual display on i.mx51 eboot with DVI and WVGA

Develop a Simple OpenVG Application Under Linux: Tutorial

i.MX51 WinCE6 NAND Fast Boot with BINFS Support

A Patch to Fix the SDMMC Card in L2.6.35_11.09.01_ER UBoot

How to enable dual display on i.MX51 WinCE6

How to change I2S from Slave to Master mode on IMX51

Q&A: Why does Mfg tool v1 release fail?

i.MX51 EVK

i.MX JTAG hot plug with no reset

sleep indefinitely in wait_event_interruptible(vt_event_waitqueue, vw->done);