i.MX Processors Knowledge Base

Discussions

The i.MX 6 D/Q L3.035_1.0.3 patch release is now available on www.freescale.com · Files available # Name Description 1 L3.0.35_1.0.3_TEMP_PFD_PATCH This patch release is based on the i.MX 6Dual/6Quad Linux 12.09.01 release. The purpose of this patch release is update thermal sensor calibration routine and correct the PFD workflow in U-Boot. More details in the release notes.

This work is the result of my daughter's idea, she finished it with my guidance. Cradle-1 Palmsize mini-HPC World's first full function heterogeneous mini-HPC, this is what it looks like: 1 Architecture Overall: CPU+GPU heterogeneous, 4 nodes, connected by a 100M Ethernet switcher; Nodes： FreeScale I.MX6 Quad core mini-pc, with 4 ARM Cortex-A9 cores and 1 Vivante GC2000 GPU 2 Software OS: Ubuntu 11.10 linaro OpenCL driver: Vivante GC2000 OpenCL driver Compiler: C/C++: gcc 4.6.1, Fortan90/95: gfortran 4.6.1, MPI Parallel Computing: MPICH2 1.4-1 NFS network file system: nfs-kernel-server 1.2.4 SSH security: openssh 1:5.8 3 Hardware The hardware of all nodes are the same, only the software configurations are slightly different. One of them was assigned as the master node, the others are slave nodes. They were TV sticks originally, with android 4.0 installed. The node's hardware specification is: CPU: 4 1.2G Cortex-A9 cores GPU: 1 Vivante GC2000 GPU RAM: 1G DDR ROM: 8G SD NIC: usb2.0 100M Ethernet Adapter (this NIC is not the TV stick's component, we added it) WIFI: 150M Display Interface: HDMI Network Switcher: 5 port 100M Ethernet Switcher 4 Network Each node has one USB2.0 NIC and one WIFI interface, the WIFI is used as the backup connection for NIC connection. Network configurations are: IP Address assignment: (baby1 - baby4 are the four computing nodes) baby1: 100M NIC 192.168.10.1 WIFI 192.168.0.111 baby2: 100M NIC 192.168.10.2 WIFI 192.168.0.112 baby3: 100M NIC 192.168.10.3 WIFI 192.168.0.113 baby4: 100M NIC 192.168.10.4 WIFI 192.168.0.114 5 Performance Cradle-1 has 16 1.2G ARM Cortex-A9 cores and 4 Vivante GC2000 GPU cores, the total computing power of these 20 computing devices is more than 100GFLOPS, more powerful than an ordinary desktop. The whole machine is only a little bigger than a palm, and the total power consumption is less than 15 watts. The overall architecture of Cradle-1 is almost the same as Chinese Tianhe-1A or the Titan in the oak ridge lab. they used the same set of software, LINUX+OPENCL+OPENMPI. Cradle-1 supports C/C++, Fortran90/95. And almost all kinds of parallel computing algorithms can run on it, the only difference is the scale. We coded a MPI parallel computing program for large matrix multiplication with 4 processes, each process had 5 threads, four threads for the four CPU cores, and one thread for GPU computing. 6 Appearance Front Back Top Left Right One node, it has three interfaces, the right is HDMI interface, upper-left is the wireless adapter for keyboard and mouse, down-left is the power connection. One node is running Ubuntu 11.10. Coded a simple OpenCL program to display OpenCL driver information On a notebook, using remote desktop access function to obtan the node baby1's desktop. This is the sign in desktop of baby1 node. Baby 1 has X11VNC server installed. sign in baby1, open a terminal Ran a MPI testing program, ensuring that all babies (baby1 - baby4) were working Any comments? please mail to audrey.tao@hotmail.com

In an earlier topic (Linux fast boot on i.MX6 Sabresd board.) about Linux fast boot on i.MX6 SabreSD board, the demo showed an application startup procedure including u-boot boot, Linux kernel boot, rootfs mount, demo application load and run. Additionally, this demo shows a live video on a LVDS screen from board CSI camera. Its total boot up time is about 1.x seconds. Now, based on Linux fast boot, we integrate it with another demo application: surround view, this demo shows 4 different live videos on LVDS screen from 4 UDP data sockets. In this demo video is drawn by GPU to screen, that means the frame buffers decode by video decoder directly pass to GPU, which is not same as previous demo. The encode video format is also MJPEG in this demo. This demo creates 4 different threads every thread handle one UDP socket, receive buffer, push this buffer to video decoder, get frame buffer from video decoder, pass this buffer to GPU, start GPU render, command GPU draw the render buffer to the screen; this thread needs to occupy one ARM processor to show every video smoothly. So we need a i.MX 6DQ board in this demo. Hardware: i.MX 6DQ SabreSD board Software: 12.09 GA BSP Difference with previous fast boot demo: U-boot difference with previous fast boot demo. 1: Add logo show. (For remove CSI2, V4L2, Capture modules ) Kernel different with previous fast boot demo. 1: Add SMP support. 2: Add Network support. (IPV4, PHY, network driver(FEC)) 3: Remove CSI2, V4L2, Capture. (Remove this need in U-boot procedure Freescale logo show on the screen! ) 4: Add GPU support in kernel. Rootfs difference with previous fast boot demo: 1: Keep rc.s firstly run, while in previous fast boot demo, demo is the firstly running program on rootfs. 2: Get rid of almost all service in rc.conf just keep “mount /proc and /sys” service. Network performance on this demo Software : The default network receive buffer is about 128KB. This default size is too small for this demo; the demo application can't fetch receive buffer in time while kernel network stack will discard some UDP packets if we don't enlarge it. We enlarge this receive buffer through command in inittab before demo running. Hardware: i.MX6 DQ TOI less than 1.2 version has some Ethernet mac layer issue, this issue will also cause some UDP packets lost. So please ensure the SabreSD board i.MX6 DQ chip TOI version is equal 1.2 or more. Attached are some files for your reference. Below patches assume this SabreSD board boot from SD3 and default display port is LVDS1. 1: U-boot and kernel patches based on 12.09. 2: Demo application based on 12.09 vpu test program and vpu test program running configure file. 3: Rootfs startup scripts.

In January 2013, Adeneo Embedded launched 2 dedicated blogs. These blogs are both run by Adeneo Embedded Windows and Linux experts, multiple time MVP awarded. The goal is to provide the windows and linux communities with specific up-to-date information as well as the latest announcements concerning these two companies. Click here to visit our Windows dedicated blog Click here to visit our Linux dedicated blog Follow, comment and subscribe ! Ce document a été généré à partir de la discussion suivante : Adeneo Embedded experts launch 2 dedicated blogs !

Here are two patches to support BT656 and BT1120 output for i.MX6 ipuv3. With this patch, the i.MX6 can support the CVBS output on TV encoder. It is useful for a TV box. "L3.0.35_1.1.0_GA_bt656_output_patch.zip" is the patch for Freescale L3.0.35_1.1.0_GA_iMX6DQ BSP. "r13.4.1_bt656_output_patch.zip" is the patch for Freescale Android R13.4.1 BSP. 1. Features supported: 1) Support BT656(8 bits) and BT1120 (16 bits)interlaced output on display port. 2) Support both RGB and YUV frame buffer for BT656/BT1120 output. 3) Support PAL and NTSC mode. 4) Support on the fly switch between PAL and NTSC mode. 5) Support CVBS output based on adv7391 TV encoder. 2. Hardware link between iMX6 and adv7391 TV encoder chip. IPU1_DI0_DISP_CLK connected to adv7391 CLKIN pin. IPU1_DISP0_DAT_23~DISP0_DAT_16 connected to adv7391 P7~P0 pins. IPU1_DI0_PIN2 connected to adv7391 HSYNC pin. (option) IPU1_DI0_PIN4 connected to adv7391 VSYNC pin. (option) - Android R13.4.1 kernel. 3. How to use -- Copy the two patch files to kernel folder. $ git apply ./0001-Support-BT656-and-BT1120-output-for-iMX6-ipuv3.patch $ git apply ./0002-Support-adv739x-TV-encoder-for-BT656-output.patch -- Select them in kernel config and build the new kernel image: Device Drivers ---> Graphics support ---> [*] MXC BT656 and BT1120 output [*] ADV7390/7391 TV Output Encoder -- Uboot parameters for video mode Output BT656 NTSC data to display port with UVYV frame buffer mode: "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=UYVY16" Output BT656 NTSC data to display port with RGB565 frame buffer mode: "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB565" Output BT656 PAL data to display port with RGB24 frame buffer mode: "video=mxcfb0:dev=bt656,BT656-PAL,if=BT656,fbpix=RGB24" Output CVBS NTSC signal on adv7391 with UYVY frame buffer mode: "video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16" Output CVBS PAL signal on adv7391 with RGB565 frame buffer mode: "video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565" -- Switch between PAL and NTSC $ echo D:720x480i-60 > /sys/class/graphics/fb0/mode $ echo D:720x576i-50 > /sys/class/graphics/fb0/mode 4. Note 1) For 8 bits BT656 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_16", it can also be any other continued display data pins, for example if "DISP0_DAT_7~DISP0_DAT_0" are used, the macro "BT656_IF_DI_MSB" in "kernel_imx/drivers/mxc/ipu3/ipu_disp.c" should be changed from "23" to "7". 2) For 16 bits BT1120 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_8", it can also be any other continued display data pins, the macro "BT656_IF_DI_MSB" should be modified if the hardware pins are changed. 3) When bt656 interface is the second display for each IPU,1-layer-fb (it can be checked with command "$ cat /sys/class/graphics/fbx/fsl_disp_propperty"), the frame buffer can only be YUV format. In this case, the IPU DC channel was used for BT656 display, it has no CSC function, so RGB frame buffer was not supported. 2013-08-09 updated: The new release package "L3.0.35_1.1.0_GA_bt656_output_patch_2013-08-09.zip" had fixed the BT656 dual display issue on iMX6S/DL. Removed the old release package. 2013-09-04 updated: The new release package "r13.4.1_bt656_output_patch_2013-09-04.zip" had fixed the BT656 dual display issue on iMX6S/DL. For default, the dual display was tested with HDMI + CVBS, HDMI is the main display and adv739x CVBS output is the second display. For iMX6DQ which has two IPUs, please assign dual display to two IPUs, for example adv739x is on IPU1 DI0, it is fixed, because hardware pins used for it is fixed. Then we can assign HDMI or LVDS to another IPU (IPU2). For iMX6S/DL which has only one IPU, since adv739x had used IPU1 DI0, another display should be IPU1 DI1. 2013-09-30 updated: Added patch for L3.0.35_4.1.0_GA BSP, the file is "L3.0.35_4.1.0_GA_bt656_output_patch_2013-09-30.zip". 2014-07-21 updated: Added patch for L3.10.17_1.0.0_GA BSP, the file is "L3.10.17_1.0.0_GA_bt656_output_patch_2014-07-21.zip". 2015-01-26 updated: Updated the IPU microcode for 1080i50 and 1080i60 BT1120 output, the parameters "N" for command BMA is a 8 bits parameters, so its max value is 255, but for 1080i50 and 1080i60 output, it needs more blank data in each line, the "N" will be bigger than 255, the updated IPU microcode can fix this limitation. The updated file is "IPU_Microcode_Update_for_BT1120_1080i_20150126.zip". You can update the macro "DC_MCODE_BT656_xxx" and function _ipu_dc_setup_bt656_interlaced() to the old patch if you used BT1120 mode to support 1080i display. The verified 1080i display mode is: { /* 1080I60 Interlaced output */ "BT1120-1080I60", 30, 1920, 1080, 13468, 20, 3, 20, 2, 280, 1, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_INTERLACED, FB_MODE_IS_DETAILED,}, { /* 1080I50 Interlaced output */ "BT1120-1080I50", 25, 1920, 1080, 13468, 20, 3, 20, 2, 720, 1, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_INTERLACED, FB_MODE_IS_DETAILED,}, 2016-01-28 updated: Updated IPU microcode to align with BT656.4 specification for NTSC output. For other BSP version with NTSC format support, please reference to ipu_disp_update.c for the final microcode. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160128.zip"., Details, please reference to the readme.txt file in the package. 2016-06-24 update: Added BT656 and BT1120 progressive mode support. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160624.zip". Details, please reference to the readme.txt file in the package. The patch for 3.14.52 GA1.1.0 BSP will be released in next week. 2016-06-27 update: Add BT656 and BT1120 display patch for 3.14.52 BSP. File "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27.zip", details, please reference to the readme.txt in the package. 2017-03-10 update: Fixed a hard coding DC macro issue for progressive mode. Added patch "0008-Fixed-a-hard-coding-DC-macro-issue-for-progressive-m.patch" in L3.0.35_4.1.0_GA_bt656_output_patch_2017-03-10.zip. The code in patch "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27" is correct.

Starting from $52, the VAR-SOM-MX6 sets the bar for unparalleled design flexibility. The VAR-SOM-MX6 ensures scalable and simplified development, while also extending the product lifecycle. Thanks to four CPU core assembly options, customers can apply a single System on Module in a broad range of applications to achieve short time-to-market for their current innovations, while still accommodating potential R&D directions and marketing opportunities. VAR-SOM-MX6 CPU: Freescale iMX6 Key features include: Freescale i.MX6 1.2GHz Quad / Dual / Single core Cortex-A9 2GB DDR3, 1GB SLC NAND Flash Full HD 1080p video encoding/decoding capability Vivante GPU providing 2D/3D acceleration Simultaneous multiple display support Gigabit Ethernet TI WiLink™ 6.0 single-chip connectivity solution (Wi-Fi, Bluetooth®) PCI-Express 2.0, S-ATA 3.0 Camera interface USB 2.0: Host, OTG Audio In/Out Dual CAN Bus This versatile solution's -40 to 85°C temperature range and Dual CAN support is ideal for industrial applications, while 1080p video and graphics accelerations make it equally suitable for intensive multimedia applications. The impressive scalability of the VAR-SOM-MX6 satisfies the needs of the most demanding future application requirements whether faster processing power, enhanced algorithms or improved graphics and video performance to name just a few. The VAR-SOM-MX6 is an all-round solution with broad connectivity and sophisticated video and acceleration graphic capabilities, delivering a range of middle to high end assembly options all from the same product. For more details, please see VAR-SOM-MX6 CPU: Freescale iMX6

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.

This is a generic script which flashes a Linux System (U-boot, uImage and root filesystem) into a SD card. Steps: 1. Download the script into a Linux system 2. Make the script executable (chmod +x mk_mx_sd) 3. Run it with '-H' to know its usage. 4. Run the script with real parameters, specifying the paths for U-boot, uImage and the root filesystem as seen above 5. Plug the SD into your target, boot the board and change the corresponding U-boot variables $ IMAGE=/data/BSP/L2.6.35_11.09.01_ER/L2.6.35_11.09.01_ER_images_MX5X $ ./mk_mx_sd -d /dev/sdc \ -u $IMAGE/u-boot-mx53-loco.bin \ -k $IMAGE/uImage \ -r $IMAGE/rootfs 6. In case you only want to flash a single binary (like U-boot), just specify the U-boot parameter (-u)

When flashing a Linux System on a SD card using the script mk_mx28_sd on a Ubuntu 12.04 host, one needs to modify it so partitions are created correctly. Just follow these steps on the console: $ cd $SDK/L2.6.35_10.12.01_SDK_scripts $ cat > first_partition_sector.patch << EOF diff -Naur a/mk_mx28_sd b/mk_mx28_sd --- a/mk_mx28_sd 2010-10-06 09:47:42.000000000 -0500 +++ b/mk_mx28_sd 2012-11-30 13:38:34.508199154 -0600 @@ -178,7 +178,7 @@ n p 1 -1 +2048 +32M t b EOF $ patch -p1 < first_partition_sector.patch then, you can run the mk_mx28_sd command again with the device as parameter $ cd $LIB $ export PATH=$PATH:$SDK/L2.6.35_10.12.01_SDK_scripts $ mk_mx28_sd /dev/$SDX

(DEPRECATED. Please check this document for Real Time Streaming) A server can be streaming video and a client, in this case a i.MX6 target, is receiving and decoding it. For example, a server with GStreamer and a web camera connected, can be streaming with the following command: $ # Pipeline 1 $ gst-launch v4l2src ! 'video/x-raw-yuv, format=(fourcc)I420, width=(int)1280, height=(int)800' ! ffenc_mpeg4 ! tcpserversink host=$CLIENT_IP port=$PORT and on the target, the client receives, decodes and display with $ # Pipeline 2 $ gst-launch tcpclientsrc host=$SERVER_IP port=$PORT ! 'video/mpeg, width=(int)1280, height=(int)800, framerate=(fraction)10/1, mpegversion=(int)4, systemstream=(boolean)false' ! vpudec ! mfw_isink The filter caps between the tcpclientsrc and the decoder (vpudec) depend on the sink caps coming from the server encoder (ffenc_mpeg4), so these may change depending on your needs. Running the above pipelines require the environment variables SERVER_IP, CLIENT_IP and PORT. In case you want the i.MX6 to act as a server, just change the video source (either mfw_v4lsrc of v4l2src) and the encoder (vpuenc), so $ # Pipeline 3 $ gst-launch v4l2src ! 'video/x-raw-yuv, format=(fourcc)I420, width=(int)640, height=(int)480, interlaced=(boolean)false, framerate=(fraction)10/1' ! vpuenc ! tcpserversink host=$CLIENT_IP port=$PORT For testing purposes, set SERVER_IP=127.0.0.1, CLIENT_IP=127.0.0.1 and PORT=500, and run pipeline 3 and 2 in two different consoles. Check with 'top' the CPU usage and see that VPU is actually doing most of the work.

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

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

i.MX6 DL/S L3.035_3.0.4 patch release

i.MX6 D/Q L3.0.35_1.0.3 patch release

i.MX6 D/Q L3.035_1.1.3 patch release

Using i.MX6Q to Build a Palm-Sized Heterogeneous Mini-HPC

Surround View Demo With Linux Fast Boot Review

Adeneo Embedded experts launch 2 dedicated blogs !

Patch to Support BT656 and BT1120 Output For i.MX6 BSP

xah

xag

xaf

xaa

uImageMaxPower

VAR-SOM-MX6, $52 i.MX6 System on Module

i.MX25: When Using 120MHz UPLL as Clock Source, GPT Counter Returns Unexpected Results

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

Script to Flash a Linux System into a SD card

i.MX6 Dual/6 Quad Power Consumption Measurement Scripts

Running mk_mx28_sd on Ubuntu 12.04

GStreamer i.MX6 Camera Streaming

Tracing GStreamer Pipelines