i.MXプロセッサナレッジベース

ディスカッション

Hi, I have a custom board with lcd of 18bit rgb color, and 240x320 resolution. OS is Android. DDMS command of Android SDK captured screen, and ddm_screenscapture-2014-07-08.png outputed. The gralloc library supported 240x320 for DDMS ? LCD display is work (20140708.jpg). logcat I/imx5x.gralloc( 2207): id = DISP3 BG I/imx5x.gralloc( 2207): xres = 240 px I/imx5x.gralloc( 2207): yres = 320 px I/imx5x.gralloc( 2207): xres_virtual = 256 px I/imx5x.gralloc( 2207): yres_virtual = 1152 px I/imx5x.gralloc( 2207): bpp = 16 I/imx5x.gralloc( 2207): r = 11:5 I/imx5x.gralloc( 2207): g = 5:6 I/imx5x.gralloc( 2207): b = 0:5 I/imx5x.gralloc( 2207): width = 38 mm (160.421051 dpi) I/imx5x.gralloc( 2207): height = 51 mm (159.372543 dpi) I/imx5x.gralloc( 2207): refresh rate = 59.71 Hz I/FslOverlay( 2207): /dev/graphics/fb0 fb_var: bits_per_pixel 16,xres 240,yres 320,xres_virtual 256,yres_virtual 1152 Best Regards, Masaki Hayakawa.

Booting Linux Directly from SD/MMC Card You can create a self-bootable SD or MMC card with Linux. This tutorial describes how to create a complete Linux system (bootloader + Linux kernel + root file system) that boots from SD/MMC card. This is very useful for people willing to demonstrate several Linux images that can be self-contained in SD/MMC cards. Flashing RedBoot on MMC using ATK To boot Linux from a SD card, the first thing to do is to program the bootloader to the card. For this, click on the link below: I.MX35 PDK Board Flashing SDCard Flashing RedBoot on MMC using DD You can also use dd on any linux system to load redboot: $ sudo dd if=./Desktop/mx35_3stack_redboot_mmc.bin of=/dev/sdd bs=512 skip=2 seek=2 Configuring Kernel to Boot From SD/MMC Creating a Linux bootable MMC/SD Card. Execute LTIB: $ ./ltib -c Choose configure the kernel: [*] Configure the kernel Change image generation to NFS: Target Image Generation Options ---> (X) NFS only Compile Linux kernel with built-in support to MMC/SD and ext3: Follow that sequence: Device Drivers ---> <*> MMC/SD card support ---> <*> UniFi SDIO glue for Freescale MMC/SDIO <*> Freescale i.MX Secure Digital Host Controller Interface support File systems ---> <*> Ext3 journalling file system support After the compilation copy the file ~/ltib/rootfs/boot/zImage to tftpboot directory: $ cp ~/ltib/rootfs/boot/zImage /tftpboot Creating RedBoot Kernel Partition Create RedBoot partitions and copy Linux kernel to it: Turn MMC active: RedBoot> factive MMC Initialize flash partitions: RedBoot> fis init RedBoot> fis list ... Read from 0x07ee0000-0x07eff000 at 0x00060000: . Name FLASH addr Mem addr Length Entry point RedBoot 0x00000000 0x00000000 0x00040000 0x00000000 FIS directory 0x00060000 0x00060000 0x0001F000 0x00000000 RedBoot config 0x0007F000 0x0007F000 0x00001000 0x00000000 Load kernel to RAM: RedBoot> load -r -b 0x100000 /tftpboot/zImage Using default protocol (TFTP) Raw file loaded 0x00100000-0x002c31b7, assumed entry at 0x00100000 Create a kernel partition with content of kernel image loaded to RAM: RedBoot> fis create -f 0x200000 kernel RedBoot> fis list ... Read from 0x07ee0000-0x07eff000 at 0x00060000: . Name FLASH addr Mem addr Length Entry point RedBoot 0x00000000 0x00000000 0x00040000 0x00000000 FIS directory 0x00060000 0x00060000 0x0001F000 0x00000000 RedBoot config 0x0007F000 0x0007F000 0x00001000 0x00000000 kernel 0x00200000 0x00100000 0x001E0000 0x00100000 If you reset your board you need to see: Booting from [SD card, CSD Version 1.0] If instead you see this message: Booting from [unknown version card ] This means your card is not support, please replace it with other card. Creating the Root File System After storing the kernel image in the SD card, remove the card from the target board and insert it in your computer (running Linux). In this example, Linux detected the SD card as /dev/sdb. Now we need to create two partitions. The first partition will not be used, this is just reserved to RedBoot and kernel. The second partition will be used to store Linux Root File System. # fdisk /dev/sdb Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel Building a new DOS disklabel with disk identifier 0x526c22da. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) Command (m for help): p Disk /dev/sdb: 1023 MB, 1023934464 bytes 32 heads, 62 sectors/track, 1008 cylinders Units = cylinders of 1984 * 512 = 1015808 bytes Disk identifier: 0x526c22da Device Boot Start End Blocks Id System Create the first partition with 8 MB; it already contains RedBoot and the kernel, as we stored previously: Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-1008, default 1): Using default value 1 Last cylinder, +cylinders or +size{K,M,G} (1-1008, default 1008): +8M Now, create the second partition using all remaining space on SD card: Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 2 First cylinder (10-1008, default 10): Using default value 10 Last cylinder, +cylinders or +size{K,M,G} (10-1008, default 1008): Using default value 1008 Command (m for help): p Disk /dev/sdb: 1023 MB, 1023934464 bytes 32 heads, 62 sectors/track, 1008 cylinders Units = cylinders of 1984 * 512 = 1015808 bytes Disk identifier: 0x526c22da Device Boot Start End Blocks Id System /dev/sdb1 1 9 8897 83 Linux /dev/sdb2 10 1008 991008 83 Linux Command (m for help): w Now format the second partition as EXT3: # mkfs.ext3 /dev/sdb2 Remove the SD card from your computer and insert again. Probably your Linux distribution will dectect it and will mount automatically. On Ubuntu 8.10 it was mounted on /dev/media: # mount ... /dev/sdb2 on /media/disk type ext3 (rw,nosuid,nodev,uhelper=hal) If your Linux didn't mount it, then you can mount it manually: # mkdir -p /media/disk # mount /dev/sdb2 -t ext3 /media/disk Enter in your LTIB directory and copy the rootfs content to SD card: # cd /home/alan/ltib-imx35/rootfs/ # cp -a * /media/disk/ Verify if it was copied correctly: # ls -l /media/disk/ total 80 drwxr-xr-x 2 root root 4096 2009-03-12 09:55 bin drwxr-xr-x 2 root root 4096 2009-03-12 09:53 boot drwxr-xr-x 2 root root 4096 2009-03-12 09:55 dev drwxr-xr-x 6 root root 4096 2009-03-12 14:41 etc drwxr-xr-x 3 root root 4096 2009-03-12 09:53 home drwxr-xr-x 4 root root 4096 2009-03-12 09:55 lib lrwxrwxrwx 1 root root 11 2009-03-12 14:47 linuxrc -> bin/busybox drwx------ 2 root root 16384 2009-03-12 14:37 lost+found drwxr-xr-x 7 root root 4096 2009-03-12 09:53 mnt drwxr-xr-x 2 root root 4096 2009-03-12 09:53 opt drwxr-xr-x 2 root root 4096 2009-03-12 09:53 proc drwxr-xr-x 2 root root 4096 2009-03-12 10:10 root drwxr-xr-x 2 root root 4096 2009-03-12 09:55 sbin drwxr-xr-x 2 root root 4096 2009-03-12 09:53 sys drwxrwxrwt 3 root root 4096 2009-03-12 09:53 tmp drwxr-xr-x 2 root root 4096 2009-03-12 09:55 unit_tests drwxr-xr-x 9 root root 4096 2009-03-12 09:55 usr drwxr-xr-x 11 root root 4096 2009-03-12 09:55 var root@urubu:~/ltib-imx25/rootfs# Now umount the SD card: # umount /media/disk Configuring RedBoot to Load Kernel and Rootfs from SD/MMC Card Remove the SD card from your computer and place again in the board. Configure RedBoot to load the kernel from SD/MMC card and set up the kernel command parameter "root" to load the root file system from second SD/MMC card partition (/dev/mmcblk0p2) RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> fis load kernel >> exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/mmcblk0p2 init=/linuxrc ip=none" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.244.254 Local IP address: 10.29.244.135 Local IP address mask: 255.255.0.0 Default server IP address: 10.29.240.182 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false Set FEC network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Default network device: lan92xx_eth0 Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00060000: . ... Erase from 0x00060000-0x00080000: . ... Program from 0x07ee0000-0x07f00000 at 0x00060000: . Now just reset the board and it will boot directly from SD/MMC card.

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.

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

LTIB does not support X11 acceleration, since the packages are too old. Ubuntu 11.10 prebuilt image part of i.MX6 BSP has Xorg version 1.10.4. Yocto 1.4 has Xorg version 1.11.4. This document is based on Yocto 1.4.1 yocto and Freescale BSP 3.5.7 Alpha release. Few simple steps to enable 1.14.0. 1. Let us consider your Yocto directory is $(rootfs_builder) 2. Edit vi sources/meta-fsl-arm/conf/machine/include/imx-base.inc PREFERRED_VERSION_xserver-xorg_mx6 = "2:1.14.0" 3.Edit vi sources/meta-fsl-bsp-release/imx/meta-fsl-arm/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_3.5.7-1.0.0.bb SRC_URI = "${FSL_MIRROR}/xserver-xorg-video-imx-viv-${PV}.tar.gz \ file://Makefile-fix-cross-compile.patch \ file://0001-add-compat.h.patch" 4. Copy the attached Makefile-fix-cross-compile.patch into sources/meta-fsl-bsp-release/imx/meta-fsl-arm/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/. 5. In the build directory, delete the tmp directory. Otherwise there will be build errors (I did not found easy way) 6. bitbake fsl-image-x11 7. Now the image is ready to flash. 8. Boot the board with the newly built image. 9. Check the Xorg version log in /var/log/Xorg.0.log. It will be 1.14.0. 10. Before executing any of the X11-EGL application, export VIV_DESKTOP=0 to the terminal. You can see the application running. There are some known issues related to performance in 3.5.7 Alpha release.

Q: Some background; this instrument has one display connected to the LVDS output of the i.MX6Solo and the SVGA monitor is using the IPU port with an external Analog Devices ADV7125 DAC to actually drive the monitor (or projector). From Tektronix: We got our kernel logo to show up on an external SVGA monitor as well as on the internal LVDS display so we now at least know that the hardware is functional. However, when our application starts running and writing to the fb0 (background) and fb1 (foreground/overlay) frame buffers, the external monitor (fb2 frame buffer) doesn't get updated. We need to know how to get the same data going to the external monitor as goes to the internal LVDS display. the external monitor is 800x600 and the internal is 800x480 so we'd further like those 480 lines to show up centered in the 600 line monitor. We are also hoping that this can be down without having to write/DMA all of the data twice. The answer given is SR #1122663812 was "If the customer is using Linux, fb2 should also be drawed by their application." This was considered in adequate and Tek replied: I would like to know if they are saying that the IPU absolutely cannot automatically do what we want and if not, why not? I would like to have some detailed information to at least convince us that they've looked into this and it really isn't possible. A: In our Linux BSP we don't support such feature. And in android BSP it was already supported. The customer must draw the fb2 by their application, ipu doesn't have the feature that combining the fb0 and overlay fb1, then resize it to fb2 automatically. The customer application can drawing their UI into a memory, then use v4l2 output to draw this buffer to both fb0 and fb2, in this case, resizing will be implemented in V4l2 output driver with IPU hardware. And if the customer needs overlay on fb2, they must combine the two layer into memory with IPU task first, then using V4l2 output to render it to display fb2. For how to use IPU task, the customer can reference to BSP unit test code: imx-test-1.1.0\test\mxc_ipudev_test The summary: for dual display case, the fb0 and fb2 are just two framebuffer memory, they must be filled before rendering to display, on iMX6S/DL, only the fb0 has the hardware overlay (fb1); if the customer wants to show same contents on two displays in Linux, their application must draw the two framebuffers, but we had some hardware method to improve the performace, using GPU or IPU task. In Android, the application will not draw frame buffer directly, it will use Android surface flinger middleware to draw, so this feature was implemnted in surface flinger; but in Linux, there is no such middleware, and application draws the framebuffer directly, so the application should handle it. This document was generated from the following discussion: i.MX6Solo LDB/LVDS & LCD Ports Active Simultaneously

First upload the U-Boot firmware using Network (Transferring file over network) or Serial (Transferring file over serial) This is a common serial transfer output: => loady ## Ready for binary (ymodem) download to 0xa0800000 at 115200 bps... CCmode, 1359(SOH)/0(STX)/0(CAN) packets, 9 retries ## Total Size = 0x0002a388 = 172936 Bytes Unprotect the bootloader flash area: protect off C0000000 C003FFFF Erase the flash blocks: erase C0000000 C003FFFF Copy from RAM to Flash: If firmware has been thansfered over serial: cp.b A0800000 C0000000 2a388 If firmware has been transfered over tftp: cp.b 100000 C0000000 2a388 Installing U-Boot using BDI3000 You can use a BDI2000/3000 to write to the S71WS256 pSRAM: Get this config file. Thanks to the folks at Ultimate Solutions for being such a nice people and writing an almost ready file! Edit the [FLASH] section to this: [FLASH] CHIPTYPE S29M32X16 CHIPSIZE 0x2000000 BUSWIDTH 16 FILE /home/lsantos/work/i.mx27/u-boot/u-boot-v2/uboot.bin ; change to you path FORMAT BIN 0xC0000000 ERASE 0xC0000000 ERASE 0xC0008000 ERASE 0xC0018000 ERASE 0xC0010000 ERASE 0xC0020000 Don't forget to edit the [HOST] section to your machine's IP address. Telnet to the BDI - CONFIG: loading configuration file passed - CONFIG: loading register definition passed - TARGET: processing reset request - TARGET: BDI asserts TRST and RESET - TARGET: BDI removes TRST - TARGET: Bypass check 0x00000001 => 0x00000002 - TARGET: JTAG exists check passed - Core#0: ID code is 0x07926121 - TARGET: All ICEBreaker access checks passed - TARGET: BDI removes RESET - TARGET: BDI waits for RESET inactive - TARGET: resetting target passed - TARGET: processing target startup .... - TARGET: processing target startup passed Erase the first 128 KiB ADS>erase Erasing flash at 0xc0000000 Erasing flash at 0xc0008000 Erasing flash at 0xc0018000 Erasing flash at 0xc0010000 Erasing flash at 0xc0020000 Erasing flash passed Write the flash ADS>prog Programming /home/lsantos/work/i.mx27/u-boot/u-boot-v2/uboot.bin , please wait .... Programming flash passed Check everything went really well ADS>verify Verifying /home/lsantos/work/i.mx27/u-boot/u-boot-v2/uboot.bin , please wait .... Verifying target memory passed Now you can unplug the BDI and reset the board U-Boot 2.0.0-rc9-00136-gbf725a2-dirty (Jun 17 2009 - 15:45:23) Board: Freescale i.MX27 ADS cfi_probe: cfi_flash base: 0xc0000000 size: 0x02000000 chip id: [2,882,1,01d] mpll: 265999329 Hz spll: 239999725 Hz arm: 177332886 Hz perclk1: 8866644 Hz perclk2: 17733288 Hz perclk3: 44333221 Hz perclk4: 17733288 Hz clkin26: 26000000 Hz ahb: 44333221 Hz ipg: 22166610 Hz Malloc space: 0xa7b00000 -> 0xa7f00000 (size 4 MB) Stack space : 0xa7af8000 -> 0xa7b00000 (size 32 kB) envfs: wrong magic on /dev/env0 no valid environment found on /dev/env0. Using default environment running /env/bin/init... Hit any key to stop autoboot: 2 type update_kernel [<imagename>] to update kernel into flash type udate_root [<imagename>] to update rootfs into flash uboot:/ Of course, this setup works with Redboot, just change the FILE entry at the [FLASH] section or use the prog command: ADS>prog 0xc0000000 /home/lsantos/work/i.mx27/redboot/build/install/bin/redboot.bin BIN Programming /home/lsantos/work/i.mx27/redboot/build/install/bin/redboot.bin , please wait .... Programming flash passed ADS>verify Verifying /home/lsantos/work/i.mx27/redboot/build/install/bin/redboot.bin , please wait .... Verifying target memory passed Rebooting ++... Read from 0x07ee0000-0x07f00000 at 0xc1fe0000: . ... Read from 0x07ed3000-0x07ed4000 at 0xc1fff000: . **Warning** FLASH configuration checksum error or invalid key Use 'fconfig -i' to [re]initialize database PMIC ID: 0x0000009b [Rev: 3.3] Ethernet FEC MAC address: is not set Board Type: ADS Clock input: 26 MHz Booting from [NOR flash] PHY ID 22 @ 1 FEC: [ HALF_DUPLEX ] [ disconnected ] [ 10M bps ]: Ethernet eth0: MAC address 00:04:9f:00:af:7a Can't get BOOTP info for device! RedBoot(tm) bootstrap and debug environment [ROMRAM] Non-certified release, version FSL 200749 - built 19:37:28, Jun 17 2009 Platform: MX27 ADS/EVB (Freescale i.MX27 based) PASS 2.1 [x32 SDR] Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. RAM: 0x00000000-0x07f00000, [0x00025260-0x07ed1000] available FLASH: 0xc0000000 - 0xc2000000, 256 blocks of 0x00020000 bytes each. RedBoot>

There are several vulnerabilities been found recently as below: ZIMPERIUM’s report: http://jiveon.jivesoftware.com/mpss/c/7gA/PDcDAA/t.1p4/5z0zjG0pTd2TX1EnZDdFDQ/h3/hAMy2Th8Lsdoz-2BI-2B-2B4FlQpxshE-2Fm9XH3UWXhoYdrt6y4Crt0q1GUsW8pizm7YGWnxGc52SR4U4vCgooHeqoe1S9fu9dc4l1m2ew0Kz-2BSCbA-3D They are reported as CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828 and CVE-2015-3829. Trendmicro’s report:http://blog.trendmicro.com/trendlabs-security-intelligence/trend-micro-discovers-vulnerability-that-renders-android-devices-silent/ All above vulnerabilities are related with stagefright’s stackoverflow, which exist all android version since JellyBean 4.2. The stagefright is the default Multimedia framework in Android’s AOSP source code. To avoid attacking toward stagefright, it is recommended to have patches in this attach, which should be applied to myandroid/frameworks/av. Reference: https://github.com/WhisperSystems/TextSecure/issues/381 This document was generated from the following discussion: Android vulnerability related with stagefright Created by Hui Fang

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

1) rtp linux side: gst-launch mfw_v4lsrc fps-n=30 ! vpuenc codec=6 ! queue ! rtph264pay ! udpsink host=192.168.0.105 port=5000 –v pc side: open the attached H264.sdp file using VLC. Then you can find the picture from camera on mx6 board, pls don’t forget to load camera module 2) Receive Pipeline from Board to PC: gst-launch -v gstrtpbin name=rtpbin udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=96' port=5000 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! queue ! ffdec_h264 ! queue ! autovideosink sync=false udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 sync=false rtpbin.send_rtcp_src_0 ! udpsink port=5005 sync=false async=false Output: Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:send_rtcp_src_0: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:send_rtcp_src: caps = application/x-rtcp /GstPipeline:pipeline0/GstUDPSink:udpsink0.GstPad:sink: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:send_rtcp_src_0.GstProxyPad:proxypad2: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:recv_rtp_sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_sink_0: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_sink_0.GstProxyPad:proxypad1: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:recv_rtp_src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpPtDemux:rtpptdemux0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_src_0_2621786612_96.GstProxyPad:proxypad4: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:src: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstQueue:queue1.GstPad:sink: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstQueue:queue1.GstPad:src: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage.GstPad:sink: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0.GstGhostPad:sink: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:sync_src: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_sink: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_src_-1673180684: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink_rtcp: caps = application/x-rtcp ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... Execution ended after 26282965149 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... /GstPipeline:pipeline0/GstUDPSink:udpsink0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0.GstGhostPad:sink: caps = NULL /GstPipeline:pipeline0/GstQueue:queue1.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstQueue:queue1.GstPad:sink: caps = NULL /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:src: caps = NULL /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_src_0_2621786612_96: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:send_rtcp_src_0: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpPtDemux:rtpptdemux0.GstPad:src_96: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpPtDemux:rtpptdemux0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink_rtcp: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_src_-1673180684: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:src_-1673180684: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:sync_src: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:send_rtcp_src: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:recv_rtp_src: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:recv_rtp_sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_sink_0: caps = NULL /GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps = NULL Setting pipeline to NULL ... Freeing pipeline ...

U-Boot is a bootloader, which supports some i.MX SoCs. Configuring U-Boot LTIB Creating Uimage Uboot U-boot FW Printenv FW Env File Add New i.MX5x Board on LTIB i.MX25 PDK I.MX25 PDK U-boot SplashScreen I.MX25 PDK U-boot SDCard i.MX27 ADS Board Compiling U-Boot for i.MX27ADS i.MX31 ADS Board I.MX31ADS Installing Uboot Blink i.MX31 PDK LEDs Using U-Boot i.MX51 EVK Board i.MX51 EVK U-boot i.MX51 EVK Compiling U-boot i.MX51 EVK Changing Env I.MX51EVK Install U-Boot i.MX53 Board i.MX53 USB Eth NFS i.MX53 ARD Dual LVDS i.MX53 QSB Board Get Started Additional Resources Script to Flash a Linux System into a SD card All Boards U-boot All Boards LTIB Creating Uimage Uboot Configuring U-Boot Running a Script in U-boot Transferring File Over Serial Transferring file over network U-boot.bin

D1 Capture - kernel 2.6.22 diff --exclude CVS -uNr linux-2.6.22/include/asm-arm/arch-mxc/memory.h linux-2.6.22.modified/include/asm-arm/arch-mxc/memory.h --- linux-2.6.22/include/asm-arm/arch-mxc/memory.h 2009-07-16 16:29:45.000000000 -0300 +++ linux-2.6.22.modified/include/asm-arm/arch-mxc/memory.h 2009-07-15 15:38:34.000000000 -0300 @@ -28,6 +28,7 @@ /* Size of contiguous memory for DMA and other h/w blocks */ #define CONSISTENT_DMA_SIZE SZ_16M + /*! * @defgroup Memory_MX27 Memory Map * @ingroup MSL_MX27 @@ -48,7 +49,7 @@ #ifdef CONFIG_DMA_ZONE_SIZE #define MXC_DMA_ZONE_SIZE ((CONFIG_DMA_ZONE_SIZE * SZ_1M) >> PAGE_SHIFT) #else -#define MXC_DMA_ZONE_SIZE ((12 * SZ_1M) >> PAGE_SHIFT) +#define MXC_DMA_ZONE_SIZE ((20 * SZ_1M) >> PAGE_SHIFT) #endif static inline void __arch_adjust_zones(int node, unsigned long *zone_size, diff --exclude CVS -uNr linux-2.6.22/drivers/media/video/mxc/capture/mxc_v4l2_capture.c linux-2.6.22.modified/drivers/media/video/mxc/capture/mxc_v4l2_capture.c --- linux-2.6.22/drivers/media/video/mxc/capture/mxc_v4l2_capture.c 2009-07-16 16:29:43.000000000 -0300 +++ linux-2.6.22.modified/drivers/media/video/mxc/capture/mxc_v4l2_capture.c 2009-07-16 16:08:02.000000000 -0300 @@ -1650,9 +1650,9 @@ /* setup cropping */ cam->crop_bounds.left = 0; - cam->crop_bounds.width = 640; + cam->crop_bounds.width = 800; cam->crop_bounds.top = 0; - cam->crop_bounds.height = 480; + cam->crop_bounds.height = 600; cam->crop_current = cam->crop_defrect = cam->crop_bounds; ipu_csi_set_window_size(cam->crop_current.width, cam->crop_current.height); @@ -1663,7 +1663,7 @@ cam->standard.id = V4L2_STD_UNKNOWN; cam->standard.frameperiod.denominator = 30; cam->standard.frameperiod.numerator = 1; - cam->standard.framelines = 480; + cam->standard.framelines = 600; cam->streamparm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; cam->streamparm.parm.capture.timeperframe = cam->standard.frameperiod; cam->streamparm.parm.capture.capability = V4L2_CAP_TIMEPERFRAME; diff --exclude CVS -uNr linux-2.6.22/drivers/media/video/mxc/capture/ov2640.c linux-2.6.22.modified/drivers/media/video/mxc/capture/ov2640.c --- linux-2.6.22/drivers/media/video/mxc/capture/ov2640.c 2009-07-16 16:29:45.000000000 -0300 +++ linux-2.6.22.modified/drivers/media/video/mxc/capture/ov2640.c 2009-07-16 16:07:03.000000000 -0300 @@ -698,12 +698,12 @@ #endif g_cam->streamparm.parm.capture.capturemode = 1; } else { - out_width = 640; - out_height = 480; + out_width = 800; + out_height = 600; g_cam->crop_bounds.left = 0; - g_cam->crop_bounds.width = 640; + g_cam->crop_bounds.width = 800; g_cam->crop_bounds.top = 0; - g_cam->crop_bounds.height = 480; + g_cam->crop_bounds.height = 600; g_cam->crop_current = g_cam->crop_defrect = g_cam->crop_bounds; #ifdef CONFIG_ARCH_MX3 ipu_csi_set_window_size(g_cam->crop_current.width ,

Question: Did we tested active PCIe components while the Cortex-A9 was in Sleep Mode (suspend to memory)? Answer: It's a known issue that PCIe can't support suspend/resume. And can't be built in kernel image if the system want suspend/resume. I think PCIe will be active while core is in sleep more. Is it different scenario? No, the pcie core is not active, it is in L2 state after suspend, and it can't resume back to L0 state when system resume is called. So, DO NOT let pcie do suspend operation right now. BTW, the tested device: * INTEL x1 1000M CT network card. * INTEL iwl wifi cards. * x1 pcie to usb3.0 card Yes, this patch had been tested on imx_3.0.35_4.0 release, and would be merged into next 3.0.35 release. TO1.2 is used. We tested the Patch against imx_3.0.35_4.0 release

i.MXプロセッサナレッジベース

i.MX Processors Knowledge Base

ディスカッション

142-00207-517_iMX6X_SX-SDCAN_BT.pdf

i.MX JTAG热插拔，无需重置

DDMS for Screen Capture i.MX51

i.MX35 PDK Linux Booting SD

Demonstration Platform

Q&A: i.MX53 Host Controller - Hardware/Firmware limitations for support of multiple Full-Speed EndPoints?

i.MX51 Multimedia Applications Processors

i.MX6 USB Mass Storage Driver Problem

Document to describe how to calculate ESAI Mclk Bitclk LRclk for imx6 sabreauto board based on 3.10.17 linux kernel

Setup Xorg 1.14 for i.MX6

Q&A: Can i.MX6Solo LDB/LVDS & LCD Ports be active simultaneously

Installing U-Boot on i.MX27ADS

Android vulnerability related with stagefright

Tracing GStreamer Pipelines

rtp/udp streaming data transfer

All Boards Transfer Serial RedBoot

All Boards Qtopia on Ubuntu

U-Boot

i.MX27 D1 Capture Kernel 2.6.22

Q&A: PCIe and Sleep Mode

i.MXプロセッサ ナレッジベース

i.MX Processors Knowledge Base

ディスカッション

i.MXプロセッサナレッジベース