Flashing Kernel and Root File System using RedBoot Creating an image A kernel image and a root file system can be created using All Boards LTIB or compiling the kernel and setting the correct set of files. Create a root file system image from a set of files converting the files to a jffs2 file system. For this, install the package mtd-tools. In Ubuntu type apt-get install mtd-tools For making an root file system for flash, use the jffs2 file system like: mkfs.jffs2 -r rootfs/ -e 0x20000 -n -p -o rootfs.jffs2 Where rootfs/ is the original set of file for the file system and rootfs.jffs2 is the output image file. Flashing Some connections errors can be avoided by All Boards Configuring RedBoot. The process below uses TFTP to copy the files between host and target. See All Boards TFTP for detail in configurations. Copy the kernel image and the root file system image to the TFTP dir. For example, in  LTIB dir, type sudo cp ./rootfs/boot/zImage /tftpboot sudo cp rootfs.jffs2 /tftpboot/ Where /tftpboot is the dir configured for TFTP The next steps are performed in a Minicom session, and happens on the board. Formatting the flash: fis init Flashing kernel Load kernel image (zImage) using the command below. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/zImage -h 10.29.244.99 The address 0x100000 is used as a temporary location Create the kernel at the right address (0x200000, for IMX31PDK) fis create -f 0x200000 kernel Flashing root file system Load root file system image (rootfs.jffs2) to the temporary address. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/rootfs.jffs2 -h 10.29.244.99 Create the root file system in the right address (0x600000, for IMX31PDK. fis create -f 0x600000 root Testing You can now load your kernel in the flash by typing: fis load kernel To know if the root file system written in the flash was correctly saved, execute the NFS file system and mount the flash. For load the the root file system by NFS, type: 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" Wait the system go up, then mount the flash at /mnt. Reminde that the flash has a jffs2 file system. mount -t jffs2 /dev/mtdblock2 /mnt ls /mnt List the /mnt contents. The output must be the right file system. Modifying the initial script Reset the board and press CTRL-C. Type fc to modify the configurations and insert the initialization script. RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> fis load kernel >> exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 ip=none" >> 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> Remember to save the configuration in the flash by typing y Reset the system. To certify that the board is loading the system from flash, remove the ethernet cable.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-344896 

MX6X_3.14.28_Uboot_V1-20150917.doc

To copy the screen (framebuffer) execute on i.MX 31 PDK terminal: dd if=/dev/fb0 of=screen.raw bs=1280 count=480 Where: the value 1280 means 640 * 2 bytes (16bpp) and the value 480 is equal the screen width. Copy this raw file to your Linux host and execute it to convert to png image: fbgrab -f screen.raw -w 480 -h 640 -b 16 screen.png To install fbgrab on Debian/Ubuntu execute: apt-get install fbgrab

Download Linux kernel 2.6.29: $ wget -c http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2 Extract this: $ tar jxvf linux-2.6.29.tar.bz2 Apply the patches: $ cd linux-2.6.29 Edit the file drivers/net/cs89x0.c adding: #include <mach/hardware.h> Export CROSS_COMPILE environmet: $ export PATH="$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/" $ export CROSS_COMPILE=arm-none-linux-gnueabi- Unselect all no essentials features: $ make ARCH=arm allnoconfig Start the configuration menu: $ make ARCH=arm menuconfig Change/Select the kernel options below. Select the MXC/iMX platform and iMX31ADS board: System Type ->             ARM system type -> (X) Freescale MXC/iMX-based             Freescale MXC Implementations  ->                            MXC/iMX Base Type -> (X) MX3-based                            MX3 Options  -> [*] Support MX31ADS platforms (NEW) Select ARM EABI standard to compile the kernel: Kernel Features  --->           [*] Use the ARM EABI to compile the kernel Add support to Linux Binary Format ELF: Userspace binary formats ->              [*] Kernel support for ELF binaries Add support to Network (TCP/IP): [*] Networking support  ->          Networking options  ->                          [*] Packet socket                          [*] Unix domain sockets                          [*] PF_KEY sockets                          [*] TCP/IP networking                                   [*] IP: kernel level autoconfiguration                                   [*]     IP: DHCP support Select network driver (CS89x0), serial driver and unselect VGA console: Device Drivers  ->                      [*] Network device support  --->                                      [*]   Ethernet (10 or 100Mbit)  --->                                             [*]   CS89x0 support                      Character devices  ->                              Serial drivers  --->                                       [*] IMX serial port support                                       [*]   Console on IMX serial port                      Graphics support  ->                             Console display driver support  --->                                        [ ] VGA text console Add support to NFS and support to use it as root file system: File systems  ->                            [*] Network File Systems (NEW)  ->                                        [*]   NFS client support                                        [*]     Root file system on NFS Compile the kernel: $ make ARCH=arm Copy the created zImage to tftp directory: $ cp arch/arm/boot/zImage /tftpboot/ Configure your RedBoot to boots with this kernel: load -r -b 0x100000 /tftpboot/zImage exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.240.191:/tftpboot/rootfs ip=dhcp"

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

Computer On Module • Processor i.MX25, 400 MHz • RAM 64/128 MB mDDR • ROM up to 2 GB NAND Flash • Power supply Single 3.0V to 5.5V • Size 42.2mm SO-DIMM200 • Temp.-Range -40°C..85°C Key Features • 10/100Mbps Ethernet • High-Speed USB 2.0 OTG • Full-Speed USB 2.0 Host • LCD controller • Still-picture camera interface • Several peripheral interfaces: UART, SD-CARD, I2C, PWM, 1-wire, Keypad, Digital Audio (AC97/I2S), Configurable serial peripheral interface, 4 wire Touchscreen, CAN OS Support • Windows Embedded CE 6.0 • Linux 2.6.35 Application：POS, handheld terminals, building security, anti-theft devices for e-commerce, smart meters and access control For more information, please see Attachment We can provide a complete solution

I have imx53 quick sort board i downloaded u-boot-mx53.bin and uImage to loade that into the board and dowloaded rootfs.ext2.gz in the L2.6.35_11.09.01_ERimages and i did partitions on 1GB memory card and loaded that u-boot-mx53.bin,uImage images on to the 500mb of NTFS filesystem and loaded and rootfs.ext2.gz on to the othe 500mb of ext4 file system the i inserted memorycard in to the board but u-boot logs are not comming what will be the solution

i.MX 35 PDK board has 256 MB of RAM, due to a bug in Redboot bootloader compiled for the board effectively there is only 128 MB available. This procedure fixes this bug to be able to use 256 MB of RAM. Redboot supporting 256 MB of RAM 1. Download the attached Redboot256.bin file. 2. Flash the new redboot image instead of the old one using one of the methods: All Boards Updating RedBoot Through RedBoot

Use case: iMX8QXP system can be a video input source to another system.   Hardware Pins： LCDIF_D00 ~ LCDIF_D07 LCDIF_CLK LCDIF_VSYNC LCDIF_HSYNC LCDIF_EN   Reference patch： It is based on L5.4.70_2.3.0 GA BSP.  File: L5.4.70_2.3.0-iMX8QXP-LCDIF-add-YUV422-8-bits-output.patch Customer can change the timing parameters in file "panel-lcdif-yuv422.c" as needed, the default timing is a 1280x720 P30 mode: static const struct display_timing yuv422_lcd_timing = {     .pixelclock = { 74250000, 74250000, 74250000 },     .hactive = { 1280, 1280, 1280 },     .hfront_porch = { 220, 220, 220 },     .hback_porch = { 110, 110, 110 },     .hsync_len = { 40, 40, 40 },     .vactive = { 720, 720, 720 },     .vfront_porch = { 20, 20, 20 },     .vback_porch = { 5, 5, 5 },     .vsync_len = { 5, 5, 5 },     .flags = DISPLAY_FLAGS_DE_HIGH, };   Test application: drm_test_yuv.zip: it can set framebuffer to UYVY mode, in this case, no CSC is needed, the data in framebuffer memory will be same as output on display data interface. drm_test_rgb.zip: it can set framebuffer to RGBA mode, in this case, RGB to YUV CSC is needed, application can draw RGB data into framebuffer as normal, the LCDIF will convert it to YUV422 format on the fly, then output the YUV data to display interface.    

The i.MX21 Application Development System (MCIMX21ADSE) is a development tool which is designed to run software applications designed for the i.MX21 processor. Features   i.MX21 Processor   Two clock-source crystals, 32.768 KHz and 26 MHz   Power connector for +5.0-volts in from an external, regulated power supply, an in-line fuse, and a power on/off switch.   Voltage regulators that step down the 5.0-volt input to Vcc (3.0-volts), 2.5-volts, 1.8-volts, and 1.5-volts.   Multi-ICE debug support   Two 8M × 16-bit Burst Flash memory devices, configured as one 32MB, 32-bit device   Two 16M × 16-bit SDRAM devices, configured as one 64MB, 32-bit device   High speed expansion connectors for optional add on cards   Two-board system: modular CPU board plugs into Base board; Base board has connections for LCD display panel and keypad and TV encoder card   Memory mapped expansion I/O   Configuration and user definable DIP switches   SD/MMC memory card connector   Two RS232 transceivers and DB9 connectors (one configured for DCE and one for DTE operation) supporting on-chip UART ports   External UART with RS232 transceiver and DB9 connector   IrDA transceiver that conforms to Specification 1.4 of the Infra-red Data Association   USB OTG (On The Go) interface transceiver and USB mini AB connector   Separate LCD panel assembly with a ribbon cable that connects to the Base board and interfaces directly with the M9328MX21ADS   Touch panel controller for use with the LCD   Separate Keypad unit with 36 push button keys   Separate CMOS Image Sensor Card   Audio CODEC includes an 11.28MHz crystal oscillator, a 3.5mm audio input jack, a 3.5mm microphone jack, and a 3.5mm headphone jack   Cirrus Logic CS8900A Ethernet controller, with RJ-45 connector for connecting to a system hub   Two 32 × 3-pin DIN expansion connectors with most i.MX21 I/O signals   Variable resistor for emulation of a battery voltage level   NAND Flash card (Plugs into CPU)   LED indicators for power, external bus activity, Ethernet activity, and two LEDs for user defined status indiction   Universal power supply with 5.0-volt output @ 2.4A   USB cable   RS232 serial cable   Two RJ-45 Ethernet cables, network and crossover

Random Number Generator - RNGA Download rng-tools: http://downloads.sourceforge.net/sourceforge/gkernel/rng-tools-2.tar.gz This tool tests the link between a random number generator hardware and the kernel's PRNG (pseudo-random number generator). ./ltib -m shell LTIB> cd rpm/BUILD/ LTIB> cp ~/hwrandom/rng-tools-2.tar.gz . LTIB> tar zxvf rng-tools-2.tar.gz LTIB> cd rng-tools-2 LTIB> ./configure --host=arm-linux LTIB> make LTIB> sudo cp rngtest /tftpboot/ltib/home/ Restart your board and execute this command in the board's console: $ cat /dev/hwrng | /home/rngtest -c 1000

Copy Redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND or MMC flash media for Redboot. In this case, NAND is beeing used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate Copy redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND, or MMC flash media for Redboot. In this case, NAND is being used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate

The KTV Demo is a common user case for KTV OEM. In this charpter, we will see what it is and how to use it. HW Platform imx6qp-sabresd SW Platform 3.14.52_1.0.0-ga, fb backend Display Connection LVDS0 XGA 1024*768 RGB666                          - IPU1 DI0 HDMI Display1920*1080@60                              - IPU0 DI1 HDMI Display1920*1080@56 via sii902x            - IPU0 DI0 LVDS1 XGA 1024*768 RGB666                          - IPU1 DI1 User case The demo has following output: Display # UI Video Stream Output Resolution DISP0-LVDS0 3D Cube@60fps 1920x1080@24fps (overlay) XGA(1024x768,RGB666) DISP1-HDMI 3D Cube@60fps 720p@20fps (overlay) 1080P@60(1920x1080,RGB24) DISP2-SII902X 3D Cube@60fps N/A 1080P@56(1920x1080,RGB24) DISP3-LVDS1 N/A 720p@20fps XGA(1024x768,RGB666) The DISP0 and DISP1 has overlay framebufffer, so output UI to bottom framebuffer and output video stream to overlay framebuffer. Run Demo The customer can refer to following script: #!/bin/sh echo "KTV demo start!" # Set environment variables export FB_FRAMEBUFFER_0=/dev/fb0 export FB_FRAMEBUFFER_1=/dev/fb2 export FB_FRAMEBUFFER_2=/dev/fb4 export FB_FRAMEBUFFER_3=/dev/fb5 # Run cube on DISP0,DISP1, DISP3 echo 0 > /sys/class/graphics/fb0/blank ./cube display=0 & sleep 1 echo 0 > /sys/class/graphics/fb2/blank ./cube display=1 & sleep 1 echo 0 > /sys/class/graphics/fb4/blank ./cube display=2 & echo "Open DISP0(LVDS0)" gst-launch-1.0 playbin \   uri=file:///home/root/ktv_demo/1080p_24fps.mp4 \   video-sink="imxv4l2sink device=/dev/video17" & sleep 3 echo "Open DISP1(HDMI)" gst-launch-1.0 playbin \   uri=file:///home/root/ktv_demo/720p_20fps.mp4 \   video-sink="imxv4l2sink device=/dev/video19" & #sleep 3 echo "Open DISP3(LVDS1)" gst-launch-1.0 playbin \   uri=file:///home/root/ktv_demo/720p_20fps.mp4 \   video-sink="imxv4l2sink device=/dev/video21" & sleep 3 The demo image can be downloaded at: \\10.193.102.186\public_share\ZhengTao\KTV Demo​ VPU frequency The vpu can run at 352MHz or  266MHz. We run it at 352MHz in this demo. The customer can configure the VPU frequcency from Linux kernel Kconfig options. Performance Utilization: 33% Overall Bus Load: 71% For 1080p@24fps, the real fps can only up to 13.319fps. The GPU may influence VPU performance.

Question: To eliminate the need for pull-ups AND  pull-downs on the gpio boot override pins to save board space, does anyone know when in the boot rom that the GPIO pins are sampled and whether the internal Pull Downs are already enabled? Is this true for all the GPIO override pins? To just be able to provide an external Pull-up to specify boot options and NOT both pull-up and pull-down option. Can this be done? Answer: The pull-ups and pull-downs are active while POR_B is low (as defined in the datasheet). The pins are sampled on the 2 nd rising edge of RTC_XTALO before the rising edge of POR_B. As a caution, on-chip pull-up/downs are very weak and are primarily intended for controlling the pin (keeping it from logically wiggling) if the pin is not connected at all. If a pin is connected out to a trace, relaying on the on-chip PU/PD alone could be a little risky. Since the PU/PD is weak, it's possible to have noise coupled onto the pin. [Similar to Brett's comment above].

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343777 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-344485 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-345629 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-342654 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343715