embWiSe Technologies (acronym for Embedded Wireless Systems Engineering), provides complete embedded WiFi drivers for different WiFi chipsets. embWiSe is pleased to be part of the Freescale's i.MX community and is fully committed to provide its WiFi driver support on all of the i.MX platforms. embWiSe's WiFi driver software solution mitigates engineering leadtime and time-to-market issues and reduces TCO for device designers. embWiSe has design-ins in several Mobile,CE and other connected devices across the world - including smartphones,featurephones,printers,DSCs and handheld devices for different applications and verticals. Specifically, embWiSe offeres SDIO-WiFi + Bluetooth drivers on WinCE6.0, WEC7 and WEC2013 Operating Systems on i.MX51,i.MX53 and i.MX6 platforms. The WiFi driver is integrated with the native SDIO stack and security supplicants of WEC7 and WEC2013. embWiSe also provides HCI Bluetooth driver over SDIO and UART interfaces, integrated with the native BT stack. Additionally, embWiSe offers SDIO-WiFi drivers on other embedded OS platforms including ThreadX,Nucleus Plus,QNX,uC/OS and uITRON. embWiSe also provides value-added engineering services to integrate,test and validate the WiFi drivers on custom hardware platform. For more details, visit http://www.embwise.com or contact [email protected] for more specific information.

    Gigabit Ethernet should be one of most beautiful features in our imx6 platform which will bring more colorful dreams to many customers. But recently,many people responsed that there were great performance gaps between using Android and Linux. Now let me give an exploration here.     Same hardware, same kernel, different performance,why?     In linux, its data throughput can reach 400Mbps.In JB, it can only get to 200Mbps.     From the below info, we can see it should be related with frames dropping.      root@android:/ # busybox ifconfig eth0      eth0      Link encap:Ethernet  HWaddr 00:04:9F:02:6C:E1                inet addr:192.168.0.100  Bcast:192.168.0.255  Mask:255.255.255.0                inet6 addr: fe80::204:9fff:fe02:6ce1/64 Scope:Link                UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1                RX packets:7382672 errors:71828 dropped:789 overruns:71828 frame:71828                TX packets:4147006 errors:0 dropped:0 overruns:0 carrier:0                collisions:0 txqueuelen:1000                RX bytes:2568845018 (2.3 GiB)  TX bytes:284789020 (271.5 MiB)      In TCP stack, there are three buffers involved in iperf test case:tcp_mem; tcp_rmem; tcp_wmem.      All of them are described by three variables which will influence a lot for iperf test result.      In linux,I got a snapshot for them:      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_mem      18240      24320     36480      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_rmem      4096       87380     778240      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_wmem      4096       16384     778240      In Android,I also got them to compare to:      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_mem      9285      12380     18570      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_rmem      4096       87380     396160      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_wmem      4096       16384     396160      The tcp_mem varibles define how the TCP stack should behave in kernel memory management.The first value tells the kernel the low threshold. The second value tells the kernel at which point to start pressuing memory usage down. The third one tells the kernel how many memory pages it may use maximally. If it is reached,TCP streams and packets start geting dropped until to a safe level.      In tcp_rmem, the first value defines the minimum receive buffer for each TCP connection and this buffer is always allocated to a TCP socket.The second one defines the default receive buffer size. The third one specifies the maximum receive buffer that can be allocated for a TCP socket.      In tcp_wmem, three varibles also be given to describle the TCP send buffer for each TCP socket.      We can check how these values come from in kernel code.There is an algorithm in kernel_imx/net/ipv4/sysctl_net_ipv4.c +450.     limit = nr_free_buffer_pages() / 8;     limit = max(limit, 128UL);     sysctl_tcp_mem[0] = limit / 4 * 3;     sysctl_tcp_mem[1] = limit;     sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 2;     /* Set per-socket limits to no more than 1/128 the pressure threshold */     limit = ((unsigned long)sysctl_tcp_mem[1]) << (PAGE_SHIFT - 7);     max_wshare = min(4UL*1024*1024, limit);     max_rshare = min(6UL*1024*1024, limit);     sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;     sysctl_tcp_wmem[1] = 16*1024;     sysctl_tcp_wmem[2] = max(64*1024, max_wshare);     sysctl_tcp_rmem[0] = SK_MEM_QUANTUM;     sysctl_tcp_rmem[1] = 87380;     sysctl_tcp_rmem[2] = max(87380, max_rshare);      From the above algorithm, we can see tcp_mem,tcp_wmem[2],tcp_rmem[2] all related with nr_free_buffer_pages() which stands for amount of free RAM allocatable within ZONE_DMA and ZONE_NORMAL.      So here, we can find the root cause of performance gap between Android and Linux. There is big gaps in free RAM while running different OS. In fact, in android, Google has introduced one mechanism to tune these values through propertity. Now we are using default AOSP's values, you can refer to them in device/fsl/imx6/etc/init.rc.For wifi and Ethernet, they are both using net.tcp.buffersize.wifi. # Define TCP buffer sizes for various networks #   ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax,     setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208     setprop net.tcp.buffersize.wifi    524288,1048576,2097152,262144,524288,1048576     setprop net.tcp.buffersize.lte     524288,1048576,2097152,262144,524288,1048576     setprop net.tcp.buffersize.umts    4094,87380,110208,4096,16384,110208     setprop net.tcp.buffersize.hspa    4094,87380,262144,4096,16384,262144     setprop net.tcp.buffersize.hsupa   4094,87380,262144,4096,16384,262144     setprop net.tcp.buffersize.hsdpa   4094,87380,262144,4096,16384,262144     setprop net.tcp.buffersize.hspap   4094,87380,1220608,4096,16384,1220608     setprop net.tcp.buffersize.edge    4093,26280,35040,4096,16384,35040     setprop net.tcp.buffersize.gprs    4092,8760,11680,4096,8760,11680     setprop net.tcp.buffersize.evdo    4094,87380,262144,4096,16384,262144 I tried to change the above values but unfortunately got no obvious improvement.Hi,why???? so another topic,how tcp_mem and tcp_rmem cowork in kernel? In android, we only have way to tuning tcp_rmem or tcp_wmem settings but not tc_mem. Take "iperf -c" for example, tcp_rmem will be filled up according to the frequency of Gigabit ethernet clock. And then it will be repacked acoording to the size of tcp_mem.If tcp_mem is smaller, more times will be triggered and if it has exceeds the max value dropping frames will be triggered. Then retransport will be launched in TCP. At last, performance will downgrade. It is just like go surfing using Gigabit but with a rubbish notebook. You still can't enjoy good performance of Gigabit ethernet. Why kernel calculate tcp_mem like this in ipv4? Maybe they consider the balance between single high-bandwidth and multiple connections. You can imagine if we change the tcp_mem to use a solid big value, it may cause the board deny connections because of a lack of memory allocation in tcp init. Here I will give out several method to improve our android ethernet performance. Enlarge your memory size in board design phase.      I have double checked it by testing in our SabreAuto board whose memory is 2G whose download speed can reach to 270 Mbps about 50Mbps over Sabresd. Try to use older version android, if you can use ICS, you can abandon JB4.3. Compared with newer android version, old version will take less memory and there will leave more free memory to use. Using ICS, we can reach 380 Mbps downloading while in JB4.3, it can only get to 210 Mbps. If you are using sabresd's Gigabit ethernet for a very important case, you can balance it if you can throw other memory eaters like GPU. I have checked it if we disable GPU, the performance can reached to 340 Mbps in JB4.3 with about 50% improvement. Change tcp_mem algorithm to enlarge its max value threshold. Like you can change  "sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 2" to "sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 3" above. You can see there won't be framedropping any more. Or you can also refer to How To: Network / TCP / UDP Tuning to hard code it. But like its author said in it, it is not recommended for those support multiple users or multiple connections. for it maybe cause the board to deny connections because of a lack of memory allocation. Tune tcp_rmem and tcp_wmem through the following patches in android. you will get bidirectional 320Mbps. But if you use ifconfig tool to set static ip you will not get these parameters set. For AOSP's framework only support DHCP now. For this case, you can manually echo these parameters in console before doing test.                Gerrit Code Review                Gerrit Code Review Change kernel's scheduler policy config.      Disable CONFIG_FAIR_GROUP_SCHED and only enable CONFIG_RT_GROUP_SCHED will contribute some enhancement.      With the above changes, I have tested on Sabresd RevC1 using android4.3GA, the bidirection speed can both reach 390~400Mbps.

Question: An alignement trap in Linux had been seen in an unaligned access of the WEIM (to an external FPGA) Alignment trap: testFPGA (1027) PC=0x000086dc Instr=0xe1d330b0 Address=0x08000001 FSR 0x011 The issue can be reproduced with the platform SDK EIM parallel Nor Test on the Sabre AI - When I access WEIM_BASE_ADDR +1 I get an exception. EIM test start: Flash size: 0x 2000000 Flash erase... . Oops, data abort occurred! Registers at point of exception: cpsr = nZCvqeAift Supervisor (0x60000113) r0 = 0x00000000    r8 =  0x00000000 r1 = 0x00000000    r9 =  0x00000000 r2 = 0x00000001    r10 = 0x00000000 r3 = 0x08000001    r11 = 0x10409770 r4 = 0xdeadfeed    r12 = 0x00000001 r5 = 0x10002458    sp =  0x10409734 r6 = 0x00000000    lr =  0x1000ef9c r7 = 0x00000094    pc =  0x1000bfd0 dfsr = 0x00000001 dfar = 0x08000001 Access type: read Fault status: 0x1 Is adress alligned access mandatory for EIM or AXI HW? or is it possible to support unaligned access? Answer: EIM should support unaligned access. Also ARM architecture supports unaligned access to data and address buses but only if the MMU co-processor is setup for that. Try checking cp15 sctlr[1]. Linux discourage the access to unaligned memory and some times that makes a bus error resulting in a kernel panic. So the drivers and the setup architecture files should support unaligned memory access. ARM Information Center /linux/Documentation/unaligned-memory-access.txt The EIM device is a AXI slave which should support unaligned access. Reference Manual and there's a sub-chapter in the EIM call AXI(Master) Bus cycles support. In that chapter there's a table AXI to Memory Burst Splits Number in that table states the increment burst access to a aligned or unaligned address. I expect those are for the EIM and not refer only to the AXI bus. At any case is not state clear if unaligned access should work only in burst mode (which doesn't make any sense to me) or if the RM information is incorrect. Also in the same chapter in signals not supported never list the alignment signals so unaligned access is supported. Link with some generic ARM information about that. http://forums.arm.com/index.php?/topic/8862-axi-narrowunaligned-read-transfers/ AXI4 - Aligned & unaligned address - ARM Community

Question: The i.MX6 documentation gives several different values for the maximum frequency of the IPU’s HSP_CLK clock. What are the correct HSP_CLK maximum frequency values for the i.MX6 Dual/Quad and Solo/DualLite? Can HSP_CLK run at 270 MHz on both the DQ and SDL CPUs, but it’s not clear from the documentation if this is permitted. Maximum HSP_CLK frequencies listed in the reference manual (DQ😞 264 MHz (Table 9-2 (IPU IP Parametric Table), Table 9-5 (IPU Clock Sources)) 266 MHz (Table 18-3 (System Clock Frequency Values)) Maximum HSP_CLK frequencies listed in the reference manual (SDL😞 270 MHz (Table 9-2 (IPU IP Parametric Table), Table 9-5 (IPU Clock Sources), Table 18-3 (System Clock Frequency Values)) Answer: Referring to Figure 18-2, IPU1_HSP_CLK_ROOT may be selected to have 1 of 4 sources. These sources are highlighted in yellow on the northwest corner of the page and the previous paragraph states these are max values. Possible sources are 540, 528, 396, and 480 MHz. The 480 MHz is divided by 4 before the selector, so winds up being 120 MHz. Per the diagram, these are all divided by 2 for IPU1_HSP_CLK_ROOT. The result is 270, 264, 198, and 60 MHz choices. Therefore, the max for IPU1_HSP_CLK_ROOT is 270 MHz for DQ. MX6D/Q and MX6S/DL are different with respect to max HSP_CLK frequency. MX6D/Q = 264 MHz max MX6S/DL = 270 MHz max

This patch made the display no interrupt from uboot to kernel to Android. The IPU and related hardware display interface will only be initialized once in Uboot, the kernel code will skip the IPU initialization.   1. Description     1) Support HDMI, LVDS and LCD output in UBoot.     2) Support UBoot logo keep from uboot to kernel to Android.     3) For HDMI, both 720P and 1080P mode were supported.     4) For LVDS, 1024x768 and 1080P dual channel panels were supported.     5) The logo file is a 32 bpp bmp file. 2. File List -- kernel_imx\0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch -- kernel_imx\0002-Bug-fix-for-uboot-logo-keep-patch.patch    Kernel patch to support the logo keep feature. -- uboot-imx\0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch    Uboot patch to support the logo display. -- logo.bmp    Example 32bpp logo file. -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - Android JB4.2.2_1.1.0-GA UBoot and kernel. 4. How to use -- Copy the two patch files to Android kernel_imx and uboot-imx folder and apply them.     $ cd ~/myandroid/kernel_imx/     $ git apply ./0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch     $ cd ~/myandroid/bootable/bootloader/uboot-imx/     $ git apply ./0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch     $ git apply ./0002-Bug-fix-for-uboot-logo-keep-patch.patch   -- Build the new uboot image:     $ cd ~/myandroid/bootable/bootloader/uboot-imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make mx6q_sabresd_android_config     $ make   -- Before build new UBoot image, the display type can be selected from file uboot-imx\include\configs\mx6q_sabresd.h // Select one of the output mode #define IPU_OUTPUT_MODE_HDMI //#define IPU_OUTPUT_MODE_LVDS //#define IPU_OUTPUT_MODE_LCD   -- Build the new kernel image:     $ cd ~/myandroid/kernel_imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make imx6_android_defconfig     $ make uImage   -- Before "make uImage", make menuconfig can be used to select the display type.                 System Type  --->                    Freescale MXC Implementations  --->                       MX6 clk setting for smooth UI transtion from bootloader to kernel  --->                           Select Display Interface                              ( )  Smooth UI transtion on LCD, IPU1, DI0                              ( )  Smooth UI transtion on LVDS, IPU1, DI1                              (X)  Smooth UI transtion on HDMI, IPU2, DI0   -- Uboot parameters for video mode    1080P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=148500000"      720P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=74250000"      1024x768 LVDS:       "video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666,bpp=32 fb0base=0x27b00000 fbmem=28M"      800x480 LCD:       "video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB565,bpp=32 fb0base=0x27b00000 fbmem=28M" -- dd the logo.bmp to SD card address 0x100000 and skip the 54 bytes bmp file header.    sudo dd if=logo.bmp of=/dev/sdc bs=1 seek=1048576 skip=54 5. Note     1) The logo.bmp file should be 32bpp or 16bpp, and it should be synced with video mode parameters "bpp=xx",          and uboot config file mx6q_sabresd.h (#define DISPLAY_BPP  xx).       2) The IPU number and DI number are hard coded in kernel file "board-mx6q_sabresd.c". static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {   .ipu_id = 1,   .disp_id = 0, }; static struct fsl_mxc_lcd_platform_data lcdif_data = {   .ipu_id = 0,   .disp_id = 0,   .default_ifmt = IPU_PIX_FMT_RGB565, }; static struct fsl_mxc_ldb_platform_data ldb_data = {   .ipu_id = 0,   .disp_id = 1,   .ext_ref = 1,   .mode = LDB_SEP1,   .sec_ipu_id = 0,   .sec_disp_id = 0, };       3) The IPU number and DI number are defined by Macro in Uboot file "include\configs\mx6q_sabresd.h" #define IPU_NUM   2  // 1 for IPU1, 2 for IPU2. #define DI_NUM   0  // 0 for DI0, 1 for DI1.       4) The display type used in uboot and kernel must be same, same type, same IPU number, same DI port and        same resolution.     [2015-06-29 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-06-29.zip Fix some LVDS issues for iMX6DL. Also given an example for LVDS0 with DI0. New Uboot patches:      0002-Updated-lvds-clock-source-to-pll2_pfd0.-Same-as-kern.patch      0003-Add-support-for-iMX6DL.patch   New kernel patches      0003-Skip-lvds-re-initialization-for-logo-keep.patch      0004-Add-examlpe-for-LVDS0-logo-keep.patch     [2015-08-07 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-08-07.zip Added the new Uboot patch 0004-Correct-the-sequence-to-set-LDB-clock.patch It can correct the LVDS clock set sequence whch is a known issue that caused no LVDS display sometimes.   [2015-09-18 Update]: JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip Added the patch for Android JB4.3_GA1.1.1 release. Updated clock usecount, after blank the display, the related clock can be gated off correctly. Support LVDS clock from PLL5.   [2015-12-21 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2015-12-21.zip. Verified on iMX6DL/Q SabreSD board. It supports LCD and LVDS panels, HDMI patch will be released later.   [2016-01-04 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2016-01-04.zip. Added HDMI display support. Now it supports LCD, LVDS and HDMI displays. Fixed the video playback issue for boot up.   [2016-05-18 Update]: 0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch An issue was founded, when dual channel 4 lanes LVDS panel was used, in uboot there will be no LVDS TX3 signa on one LVDS port, the attach "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip, for other BSP, please port it manually.   [2016-08-29 Update]: 0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch On some iMX6 chip, after reset the IPU in SRC Control Register, enable IPU at once will cause system hang up, to avoid such issue, software needs wait for IPU reset done by polling the SRC register. The attach "0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip + "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch", for other BSP, please port it manually.   [2017-01-06 Update] Added patch for L4.1.15_GA1.2.0 BSP and Android M6.0.1_GA2.1.0 BSP. Files: L4.1.15_GA1.2.0_uboot_logo_keep_patch_2017-01-06.zip; M6.0.1_2.1.0_uboot_logo_keep_patch_2017-01-06.zip

Gamma correction Displays usually presents a nonlinear bright response. For example, a frame buffer value of 100 will almost never give half the brightness of a value of 200. Historically, this is due to the physics of CRT monitors, but newer display technologies emulate the behavior. This is not only for compatibility, but for solid reasons based in the science of human visual perception. A first-order approximation to the non-linearity of a CRT is: L = ν ^ γ where L is the radiance (light intensity) from the display, ν is the voltage applied to the CRT gun (normally proportional to the digital value in the frame buffer), and γ (Greek letter “gamma”) is a constant particular to the monitor; it's the unknown parameter that makes it all work. It usually ranges from about 2.0 to about 2.5. One useful fact is that the gamma curve is linear in log-log space (i.e. logL as a function of logν), and γ is just the slope of that line. Example of gamma correction The dotted line indicates a linear transfer function (γ=1), the framebuffer gamma; the solid line shows how a typical CRT behaves; the dashed line represents the inverse function, the corrected gamma. How to correct gamma on i.MX using DP (Display Processor)? Gamma correction can be performed by IC (Image Converter) or DP (Display Processor) sub-blocks inside IPU. Current Linux kernel (3.10) provided by Freescale has an IOCTL that changes the related gamma parameters registers DP_GAMMA_C_SYNC<i> and DP_GAMMA_S_SYNC<i> on Display Processor block. The steps below shows how to change the gamma using user space applications: 1 - Declare a variable as mxcfb_gamma: struct mxcfb_gamma fb_gamma; 2 - Enable the gama correction: fb_gamma.enable = 1; 3 - Set the constk and slopek values, where i = 0 to 15 and x and y are respectively the new constk and slopek constant values: fb_gamma.constk[i] = x; fb_gamma.slopek[i] = y; 4 - Open the framebuffer device and call MXCFB_SET_GAMMA: fd_fb = open("/dev/fb0", O_RDWR, 0) ioctl(fd_fb, MXCFB_SET_GAMMA, &fb_gamma) Running the code above will immediately change the gamma value.

These days I supported a customer to enable LVDS in function. The data format between external LVDS in chip and i.MX6 CSI is RGB565, with HSYNC and VSYNC signals available. So we take gated mode configuration for i.MX6 CSI. Customer environment:  i.MX6 D  + Linux LTIB 4.0.0 BSP By default,  RGB565 gated mode is not supported by Linux LTIB 4.0.0 V4L2 capture driver, here is a summary for what we need to change for the driver to support RGB565 gated mode. Please apply the attached patch "0001-ENGR00262270-IPU3-Basic-16-bit-generic-data-support.patch". By this patch, IPU_PIX_FMT_GENERIC_16 can be supported by ipu3 driver. For V4L2 capture setup, file linux-3.0.35/drivers/media/video/mxc/capture/mxc_v4l2_capture.c,  function mxc_v4l2_s_fmt(), add code segment like this:                  switch(f->fmt.pix.pixelformat) {                  ............................................................................                  case V4L2_PIX_FMT_SGRBG8:                           size = f->fmt.pix.width * f->fmt.pix.height * 2;                           bytesperline = f->fmt.pix.width * 2;                           break;                  default:                           break;                  }                  Also for file linux-3.0.35/drivers/media/video/mxc/capture/ipu_csi_enc.c,  function csi_enc_setup(), please add code segment:                  else if (cam->v2f.fmt.pix.pixelformat == V4L2_PIX_FMT_SGRBG8)                            pixel_fmt = IPU_PIX_FMT_GENERIC_16;           By the modifications above, IPU_PIX_FMT_GENERIC_16 can be set for the CSI IDMAC channel. For sensor driver, please set pixel format to IPU_PIX_FMT_GENERIC_16 Don't forget to set GATED MODE and data with to 16 bits for CSI param in file linux-3.0.35/drivers/media/video/capture/mxc_v4l2_capture.c, function mxc_v4l2_s_param                 csi_param.clk_mode = IPU_CSI_CLK_MODE_GATED_CLK;                 csi_param.data_width = IPU_CSI_DATA_WIDTH_16; Please ensure CSI->MEM IDMAC channel should be choosed      The key point is that for CSI RGB565 gated mode support, the pixel format for IDMAC channel should be set to GENERIC 16, and for CSI port configuration, the pixel format is BAYER mode.

When boot from battery, then plug in 5V cable, the actual charging current can't reach the preset charging current. It is because the HEADROOM_ADJ is not correctly set. Please use attached mx28_chargingcurrent_limit_bootfrombattery.patch. Grace

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"

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].

One of the important features that differentiates Xenomai from other real-time Linux extensions is its ability to offer hard real-time support to user-space applications. Ease of use of the user-space programming model should outweigh any gain one could expect from running the application directly from kernel space. User-space applications are memory protected from other processes, thus cannot crash the kernel should something goes wrong. Xenomai also provides generic building blocks for building different RTOS interfaces called skins, These skins imitates the different RTOS APIs thus allowing easy porting of existing applications to Xenomai. Required software 1. The current BSP version for iMX6 from Freescale is 3.0.35 does not fully work with the latest version Xenomai because the accompanying I-pipe patch does not support SMP. To use the latest I-pipe patch, a newer Linux kernel is need. Grab the latest stable kernel:   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git   $ cd ~/linux-stable   $ git branch -a   $ git checkout remotes/origin/linux-3.8.y -b linux-3.8.y   $ git checkout v3.8.1 -v v3.8.1 2. Configure the kernel. Make sure the kernel is built without any errors before patching it with Xenomai.   $ export ARCH=arm   $ export CROSS-COMPILE=arm-fsl-linux-gnueabi- $ make imx_v6_v7_defconfig $ make -j16 uImage 3. Note that this is a device-tree enabled kernel. You'll also need to generate the flattened device tree that U-Boot will pass to the kernel.   $ make imx6q-sabrelite.dtb 4. This step is not needed if your U-Boot supports device-tree kernel. Grab the latest U-Boot: $ git clone git://git.denx.de/u-boot.git $ cd u-boot/ $ make mx6qsabrelite_config $ make -j16 5. The boot script will need to updated to load the device-tree into memory and pass it to the bootm command.   U-Boot > setenv bootcmd 'fatload mmc 1 0x22000000 uImage; fatload mmc   1 0x11000000       imx6q-sabrelite.dtb; bo otm 0x22000000 – 0x11000000' 6. Grab the latest I-pipe patch from Adeos    $ wget http://download.gna.org/adeos/patches/v3.x/arm/ipipe-core-3.8-   arm-1.patch 7. Grab the latest Xenomai    $ wget http://www.xenomai.org/index.php/Xenomai:News#2013-10-           05_Xenomai_2.6.3   $ tar -xvjf xenomai-2.6.3.tar.bz2 Patching the kernel 1. Prepare the target kernel. This is to assume that the Linux kernel and I-pipe patch are located relatively to Xenomai.   $ cd xenomai-2.6.3   $ ./scripts/prepare-kernel.sh --linux=../linux-stable/ --adeos=../linux-stable/ipipe-core-3.8-arm-1.patch –arch=ARM   $ ./configure CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --host=arm-fsl-linux-gnueabi 2. Build and installation   $ make -j8   $ sudo root   $ export PATH=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/:$PATH   $ make DESTDIR=~/BSP/ltib/rootfs install    Testing the installation 1. Verifying the kernel. If everything works, the kernel boot logs should messages like:    I-pipe: head domain Xenomai registered.   Xenomai: hal/arm started.   Xenomai: scheduling class idle registered.   Xenomai: scheduling class rt registered.   Xenomai: real-time nucleus v2.6.2.1 (Day At The Beach) loaded.   Xenomai: debug mode enabled.   Xenomai: starting native API services.   Xenomai: starting POSIX services.   Xenomai: starting RTDM services. 2. Comparison of Xenomai and unpatched Linux kernel real-time performance. We ran a couple benchmarks on a Freescale I.MX6q Sabrelite board to do the comparison. The tests used default configurations and fully stressed the system in order to measure scheduling jitter.                               Linux   Kernel     Zero load     100% loaded     Average latency   (us)     Worst-case   latency (us)     Average latency   (us)     Worst-case   latency (us)     Standard     4.625       41.311     5.120     1849.91   Patched with   Xenomai     4.825       15.568     6.654     16.655 The tests measure the jitter relative to expected time on a periodic task running every 1 millisecond. Data show the Xenomai implementations stand out for having by far the smallest difference between light and full load in the worst case. Stock Linux fare much worse as the timers miss a lot wake ups.

Notes: + Run the pipelines in the presented order + The above example streams H263 video. + the gl command is equal to 'gst-launch' (two instead of 'gst-launch'.size() chars ) + Pending work: H264 test cases and other scenarios. Scenario Shell variables and pipelines # Export always these variables on the i.MX export VSALPHA=1 export WIDTH=320 export HEIGHT=240 export SEP=20 # decoded and displayed Uni-directional: from PC to i.MX. PC is streaming 4 H.263 streams and i.MX displays all in the screen. # On i.MX (Target) gl udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8890 ! rtph263depay ! vpudec ! mfw_isink sync=false axis-top=0 axis-left=0 disp-width=$WIDTH disp-height=$HEIGHT & gl udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8891 ! rtph263depay ! vpudec ! mfw_isink sync=false axis-top=0 axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT & gl udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8892 ! rtph263depay ! vpudec ! mfw_isink sync=false axis-top=`expr $HEIGHT + $SEP` axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT & gl udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8893 ! rtph263depay ! vpudec ! mfw_isink sync=false axis-top=`expr $HEIGHT + $SEP` axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT & # On PC (Source) export IP_iMX= # Place the IP address of the i.MX board gst-launch -v videotestsrc ! ffenc_h263 ! rtph263pay ! multiudpsink clients=IP_iMX:8890,IP_iMX:8891,IP_iMX:8892,$IP_iMX:8893 Uni-directional: from PC to i.MX. PC is streaming one H.264 stream and i.MX displays it on the screen # On i.MX (Target) # Make sure you set the caps correctly, specially the sprop-parameter-sets cap. The one show below is just an example and works with the source file sintel_trailer-1080p.mp4 export VSALPHA=1 GST_DEBUG=*:2 gst-launch -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, sprop-parameter-sets=(string)\"Z2QAMqw05gHgCJ+WEAAAAwAQAAADAwDxgxmg\\,aOl4TLIs\", payload=(int)96' port=8890 ! rtph264depay ! vpudec ! mfw_isink sync=false # On PC (Source) gst-launch -v filesrc location=sintel_trailer-1080p.mp4 typefind=true ! qtdemux ! rtph264pay ! multiudpsink clients=10.112.102.168:8890 Bi-directional: PC is streaming 4 H.263 streams to i.MX, iMX displays it and sends the four back to PC # On i.MX export IP_PC= # Place the IP address of the PC host machine gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8890 ! rtph263depay ! vpudec ! tee name=t ! queue ! mfw_isink sync=false axis-top=0 axis-left=0 disp-width=$WIDTH disp-height=$HEIGHT t. ! queue ! vpuenc codec=5 ! rtph263pay ! udpsink host=$IP_PC port=9990 & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8891 ! rtph263depay ! vpudec ! tee name=t ! queue ! mfw_isink sync=false axis-top=0 axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT t. ! queue ! vpuenc codec=5 ! rtph263pay ! udpsink host=$IP_PC port=9991 & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8892 ! rtph263depay ! vpudec ! tee name=t ! queue ! mfw_isink sync=false axis-top=`expr $HEIGHT + $SEP` axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT t. ! queue ! vpuenc codec=5 ! rtph263pay ! udpsink host=$IP_PC port=9992 & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8893 ! rtph263depay ! vpudec ! tee name=t ! queue ! mfw_isink sync=false axis-top=`expr $HEIGHT + $SEP` axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT t. ! queue ! vpuenc codec=5 ! rtph263pay ! udpsink host=$IP_PC port=9993 & # On PC ## Stream received from iMX export IP_iMX= # Place the IP address of the i.MX board gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=9990 ! rtph263depay ! ffdec_h263 ! xvimagesink & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=9991 ! rtph263depay ! ffdec_h263 ! xvimagesink & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=9992 ! rtph263depay ! ffdec_h263 ! xvimagesink & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=9993 ! rtph263depay ! ffdec_h263 ! xvimagesink & ## Stream sent to iMX gl -v videotestsrc ! videoscale ! video/x-raw-yuv,width=\(int\)1408,height=\(int\)1152 !  ffenc_h263 ! rtph263pay ! udpsink host=$IP_iMX port=8890 & gl -v videotestsrc ! videoscale ! video/x-raw-yuv,width=\(int\)1408,height=\(int\)1152 ! ffenc_h263 ! rtph263pay ! udpsink host=$IP_iMX port=8891 & gl -v videotestsrc ! videoscale ! video/x-raw-yuv,width=\(int\)1408,height=\(int\)1152 ! ffenc_h263 ! rtph263pay ! udpsink host=$IP_iMX port=8892 & gl -v videotestsrc ! videoscale ! video/x-raw-yuv,width=\(int\)1408,height=\(int\)1152 ! ffenc_h263 ! rtph263pay ! udpsink host=$IP_iMX port=8893 &

Android Jelly Bean(4.2) locks HDMI rotation by default. You can unlock by the instruction of this commit. -- Author: Jeff Brown <[email protected]> Date:   Wed Oct 17 18:32:34 2012 -0700     Add special mirroring modes for demonstration purposes.     Assume rotation of HDMI display is portait.     $ adb shell setprop persist.demo.hdmirotation portrait     Don't lock rotation while HDMI is plugged in.     $ adb shell setprop persist.demo.hdmirotationlock false     Hide secondary displays from apps but continue mirroring to them.     $ adb shell setprop persist.demo.singledisplay true     Bug: 7326281     Change-Id: I8f9a3b0bc19821a3a01043b0f516806dac82ce53

Wir laden Sie zum i.MX 6 Workshop in Mainz recht herzlich ein. Bei diesem Workshop wird Ihnen der Controller von Freescale im Detail erklärt. Neben der Vorstellung der Entwicklungsumgebungen steht der Gedankenaustausch mit den Referenten und Entwicklern ganz weit oben. Melden Sie sich jetzt an! Zielgerichtet aus der Praxis für die Praxis phyFLEX i.MX 6 Workshop Schulungen sind Investitionen, die sich durch Zeitgewinn und sichere Designs in kürzester Zeit amortisiert haben. Sie sichern vorhandenes Wissen und passen Arbeitsweisen an Weiterentwicklungen des Marktes an. Neue Controller mit erweiterten Fähigkeiten und neuen Hardwareansätzen erfordern erweitertes Wissen. Betriebssysteme und moderne Entwicklungsumgebungen bieten andere Arbeitsweisen, die der Komplexität heutiger Projekte gerecht werden. Ihre Weiterbildung ist uns wichtig. Termine: 07.11.2013 in Mainz Zeit: 9:00 Uhr bis 18:00 Uhr Begrüßung unserer Gäste ab 8:30 Uhr in der Robert-Koch-Straße 37 in 55129 Mainz. Workshopinhalt: Agenda Ab 8:30          Empfang in der Robert-Koch- Str. 37, 55129 Mainz 09:00 – 09:15 Begrüßung der Gäste und Vorstellung der Referenten 09:15 – 10:30 Vorstellung des Prozessors, Herr Rodrigue Simonneau, Freescale 10:30 – 10:45 Kaffeepause 10:45 – 11:45 Vorstellung Hardware (Modul & Carrier Board)                         - der i.MX 6 in unseren Produktfamilien                         - verfügbare Features des phyFLEX-i.MX 6 Moduls                        - Applikationsplatine: Welche Schnittstellen stehen schon im Kit zur Verfügung?                        - Mögliche Bestückungsvarianten des Serienmoduls 11:45 – 12:15 Zeit für Fachgespräche mit den Entwicklern 12:15 – 13:00 Mittagspause 13:00 – 14:00 Führung durch die Produktion 14:00 – 15:00 Digital Imaging mit i.MX 6 - Einführung in die Kameraschnittstellen des i.MX 6 - Konzepte zum Anschluss von Kameramodulen - Überblick über das Software-Interface 15:00 – 16:15 Vorstellung der Linux Entwicklungsumgebung bis hin zum Erarbeiten eines Beispiels                       - LiveDVD mit Eclipse                        - Beispiel-Programm unter Eclipse zur Ansteuerung der GPIO Platine              - Grafik Demos mit OpenGL und Mpeg Decoder               - Benchmark zum Anzeigen der Leistung einzelner Cores 16:15 – 16:45       Zeit für Fachgespräche mit den Entwicklern 16:45 – 17:00     Kaffeepause 17:00 – 18:15        Vorstellung Windows Embedded Compact 7              - Welche neuen Features stehen unter WEC7 zur Verfügung?                - Erste Schritte in WEC7 auf der phyFLEX-i.MX6              - Applikations-Debugging über USB Active Sync               - Verwendung der Remote Tools des Plattform Builders 18:15           Zeit für Fachgespräche mit den Entwicklern Am Tag des Workshops besteht die Möglichkeit ein Phytec i.MX 6 Kit (Linux oder WEC7) käuflich zu erwerben. Geben Sie gleich bei Ihrer Anmeldung an, ob an einem Kauf gernerelles Interesse besteht. Nutzen Sie diese Möglichkeit und melden Sie sich gleich zum i.MX 6 Workshop in Mainz an: Anmeldung Für nähere Fragen und Anmeldung steht Ihnen unser Vertriebsteam gerne zur Seite: Telefon: + 49 (0) 6131/ 9221-32 Unsere Produkte zum i.MX 6 finden Sie hier.

Question: How is mx6 PMIC_ON_REQ under SW control? mx6 PMIC_ON_REQ is hooked up to the PFUZE100's PWRON and Linux and our 3.0.35bsp is used. Mx6 SW control is to drive the PMIC_ON_REQ pin low.  It appears from the documentation that this pin can be controlled by either another imx6 pin OR through SW control. The issue is that the reference manual is not clear on how to do this. While doing an SR search (SR 1-877711457), it does appear the PMIC_ON_REQ is controlled by SW. Answer: In latest RM version, Figure 60-3. Chip on/off state flow diagram and Table 60-3. Power mode transitions in IMX6DQRM.pdf show two ways to make PMIC_ON_REQ go low. I'm sure in latest BSP SW method had been included. It turns out the SNVS module on the mx6s/dl is different from the mx6q/d which is again different from the mx6slx. The bottom line is that the requirements for the SNVS functionality came primarily from the Android market so many of the Linux use cases are not supported. SW control of the PMIC_ON_REQ pin is an example of this. This means that you are correct, there only 2 ways to get PMIC_ON_REQ to power up for the mx6q/d 1 -  a low on the ON/OFF pin greater than the debounce time (750ms) 2 - a wake-up/tamper event. For the mx6s/dl, there are 3 ways to get PMIC_ON_REQ to power up 1 - power-on-reset on the VSNVS  (i.e first applying VSNVS) 2 -  a low on the ON/OFF pin greater than the debounce time (750ms) 3 - a wake-up/tamper event. Note, in my case, where there is an external input that actually wakes up the system, turns on the PMIC and brings up the mx6 there is only 1 way to get PMIC_ON_REQ to go back high 1 - a low on the ON/OFF pin greater than the debounce time (750ms) As it turns out, when the VSNVS_HP section is powered (i.e VDDHIGH is applied), it gates off the wake-up timer.

Question: How do I add the opencore amrnb plugin to be the default for amrnb for use with playbin2? With a .3gp file to play and audio amrnb encoded, amr plugins do not work ( i.e. are not even part of the build and when configured to build, they do not even build ). Opencore had been added and got it to build and install with our ltib BSP and it plays the audio from the .3gp file in question fine ( but with an explicit pipeline ). But, the opencore amrnb plugin is not selected by gstreamer playbin2 when it does a typefind on the amrnb audio type. Answer: There are three options: 1. Fix the aiurdemux to allow correct demuxing 2. Lower the aiurdemux rank 3. Remove the /usr/lib/gstreamer-0.10/libmfw_gst_aiur_demux.so Obviously, 3 is a ugly hack but it can be just enough for customer. If option 1 or is selected, patches may be required from MM team. On this system, the aiurdemux does not have any issue, and audio playback works as expected. These are the VPU firmware and GST-FSL versions on YOCTO: VPU Version: firmware 1.4.50; libvpu: 5.3.2 MFW_GST_VPU_DECODER_PLUGIN 3.0.8 build on Sep 30 2013 16:36:27. where in LTIB: VPU Version: firmware 1.4.48; libvpu: 5.3.2 MFW_GST_VPU_DECODER_PLUGIN 2.0.3 build on Jul 23 2013 11:20:21. So the next moved would be to try upgrading versions on LTIB if they want to use this system; in case switching to Yocto is viable, then the upgrade is already done.

ltib 编译的 解码插件包，官网比较难找到的。

Patch for i.MX6 boards with LPDDR2 using single channel

Kernel provides mtdoops to dump kmsg to MTD device, but MMC card is not a MTD device. We can let user-space program to execute the write operation to dump kmsg into block storage. The sample code is below. kernel space -- #include <linux/kernel.h> #include <linux/module.h> #include <linux/console.h> #include <linux/vmalloc.h> #include <linux/seq_file.h> #include <linux/workqueue.h> #include <linux/sched.h> #include <linux/wait.h> #include <linux/delay.h> #include <linux/interrupt.h> #include <linux/kmsg_dump.h> #include <linux/proc_fs.h> static struct kmsg_dumper dump; static struct proc_dir_entry *my_proc; static int is_panic = 0; static int my_proc_show(struct seq_file *m, void *v) {     seq_printf(m, "%d", is_panic);     return 0; } static int my_proc_open(struct inode *inode, struct file *file) {     return single_open(file, my_proc_show, NULL); } static const struct file_operations my_proc_ops = {     .open        = my_proc_open,     .read        = seq_read,     .llseek        = seq_lseek,     .release    = single_release, }; static void oops_do_dump(struct kmsg_dumper *dumper,         enum kmsg_dump_reason reason, const char *s1, unsigned long l1,         const char *s2, unsigned long l2) {     int i;     printk("### [%s:%d] reason = %d\n", __func__, __LINE__, reason);     is_panic = 1;     for (i = 0;i < 10; i++)         msleep(1000);     printk("### [%s:%d] should be done\n", __func__, __LINE__); } static int __init my_oops_init(void) {     int err;     dump.dump = oops_do_dump;     err = kmsg_dump_register(&dump);     if (err) {         printk(KERN_ERR "oops: registering kmsg dumper failed, error %d\n", err);         return -EINVAL;     }     my_proc = proc_create("dump_tester", 0, NULL, &my_proc_ops);     return 0; } static void __exit my_oops_exit(void) {     printk("### [%s:%d]\n", __func__, __LINE__);     if (my_proc)         remove_proc_entry( "dump_tester", NULL);     kmsg_dump_unregister(&dump); } module_init(my_oops_init); module_exit(my_oops_exit); MODULE_LICENSE("GPL"); User space -- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <fcntl.h> #include <poll.h> #define BUF_LEN 40960 void main(int argc, char **argv) {     char tmp = 'X';     char buf[BUF_LEN];     int fd_src, fd_trg;     int fd = open("/proc/dump_tester", O_RDONLY, 0);     while(1) {         lseek(fd, 0, SEEK_SET);         read(fd, &tmp, 1);         //printf("### [%s:%d] ==> '%c'\n", __FUNCTION__, __LINE__, tmp);         if (tmp == '1') {             fd_src = open("/proc/kmsg", O_RDONLY, 0);             fd_trg = open("/dev/block/mmcblk0p6",  O_RDWR, 0);             memset(buf, 0, BUF_LEN);             write(fd_trg, buf, BUF_LEN);             lseek(fd_trg, 0, SEEK_SET);             read(fd_src, buf, BUF_LEN);             write(fd_trg, buf, BUF_LEN);             close(fd_src);             close(fd_trg);             sleep(1);             printf("### dump panic log into %s\n", "/dev/block/mmcblk0p6");             break;         }         sleep(1);     }     close(fd); }