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.

i.MX6UL Hardware design checklist v0.1

Dumping the pipeline elements into a image file # On target, run the pipeline $ export GST_DEBUG_DUMP_DOT_DIR=<folder where dot files are created> $ gst-launch playbin2 uri=file://${avi} $ # Move the .dot files to a host machine (scp, etc) # On Host dot <dot file> -Tpng -o out.png # dot command is part the the graphviz package Querying which elements are being used on a gst-launch command GST_DEBUG=GST_ELEMENT_FACTORY:3 gst-launch playbin2 uri=file://`pwd`/<media file> Interrupting a gst-launch process running in the background kill -INT $PID # where $PID is the process ID Using only SW codecs # Backup and remove $ find /usr/lib/gstreamer-0.10 -name "libmfw*" | grep -v sink | xargs tar cvf /libmfw_gst.tar $ find /usr/lib/gstreamer-0.10 -name "libmfw*" | grep -v sink | xargs rm # Run your pipeline. This time SW codecs are used $ gst-launch playbin2 uri=file://`pwd`/media_file # To 'install' FSL plugins again, just untar the file $ cd / && tar xvf libmfw_gst.tar && cd - # then run your pipeline. This time HW codecs are used $ gst-launch playbin2 uri=file://`pwd`/media_file

Using a RAW NAND is more difficult compared to eMMC, but for lower capacity it is still cheaper. Even with the ONFI (Open NAND Flash Interface) you can face initialization issue you can find by measure performance. I will take example of a non-well supported flash, I have installed on my evaluation board (SABRE AI). I wanted to do a simple performance test, to check roughly the MB/s I can expected with this NAND. One of a simplest test is to use the dd command: root@imx6qdlsolo:~# time dd if=/dev/mtd4 of=/dev/null 851968+0 records in 851968+0 records out 436207616 bytes (436 MB, 416 MiB) copied, 131.8884 s, 3.3 MB/s ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ As my RAW was supposed to work in EDO Mode 5, I could expect more than 20MB/s. To check what was wrong, read you kernel startup log: Booting Linux on physical CPU 0x0 Linux version 4.1.15-2.0.0+gb63f3f5 (bamboo@yb6) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Fri Sep 16 15:02:15 CDT 2016 CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: Freescale i.MX6 DualLite/Solo SABRE Automotive Board [...] Amd/Fujitsu Extended Query Table at 0x0040 Amd/Fujitsu Extended Query version 1.3. number of CFI chips: 1 nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xdc nand: Macronix MX30LF4G18AC nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 gpmi-nand 112000.gpmi-nand: mode:5 ,failed in set feature. Bad block table found at page 262080, version 0x01 Bad block table found at page 262016, version 0x01 nand_read_bbt: bad block at 0x00000a7e0000 nand_read_bbt: bad block at 0x00000dc80000 4 cmdlinepart partitions found on MTD device gpmi-nand Creating 4 MTD partitions on "gpmi-nand":‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ On line 13 you can read "mode:5, failed in set feature", meaning you are not in mode 5... so you have the "relaxed" timing you have at boot. After debuging your code (I have just remove the NAND back reading security check), you can redo the test: root@imx6qdlsolo:~# time dd if=/dev/mtd4 of=/dev/null 851968+0 records in 851968+0 records out 436207616 bytes (436 MB, 416 MiB) copied, 32.9721 s, 13.2 MB/s‍‍‍‍‍‍‍‍‍‍‍‍ So you multiplied the performances by 4! Anyway, you have a better tool to measure your NAND performance, it is mtd_speedtest, but you have to rebuild your kernel. In Yocto, reconfigure your kernel (on your PC of couse!): bitbake virtual/kernel -c menuconfig‍‍‍ Choose in the menu "Device Drivers" -> "Memory Technology Device (MTD) support" -> "MTD tests support", even it it not recommended! bitbake virtual/kernel -f -c compile bitbake virtual/kernel -f -c build bitbake virtual/kernel -f -c deploy‍‍‍‍‍‍‍‍‍ Then reflash you board (kernel + rootfs as tests are .ko files): Then you can do more accurate performance test: insmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko dev=2 ================================================= mtd_speedtest: MTD device: 2 mtd_speedtest: MTD device size 16777216, eraseblock size 131072, page size 2048, count of eraseblocks 128, pages per eraseblock 64, OOB size 64 mtd_test: scanning for bad eraseblocks mtd_test: scanned 128 eraseblocks, 0 are bad mtd_speedtest: testing eraseblock write speed mtd_speedtest: eraseblock write speed is 4537 KiB/s mtd_speedtest: testing eraseblock read speed mtd_speedtest: eraseblock read speed is 16384 KiB/s mtd_speedtest: testing page write speed mtd_speedtest: page write speed is 4250 KiB/s mtd_speedtest: testing page read speed mtd_speedtest: page read speed is 15784 KiB/s mtd_speedtest: testing 2 page write speed mtd_speedtest: 2 page write speed is 4426 KiB/s mtd_speedtest: testing 2 page read speed mtd_speedtest: 2 page read speed is 16047 KiB/s mtd_speedtest: Testing erase speed mtd_speedtest: erase speed is 244537 KiB/s mtd_speedtest: Testing 2x multi-block erase speed mtd_speedtest: 2x multi-block erase speed is 252061 KiB/s mtd_speedtest: Testing 4x multi-block erase speed mtd_speedtest: 4x multi-block erase speed is 256000 KiB/s mtd_speedtest: Testing 8x multi-block erase speed mtd_speedtest: 8x multi-block erase speed is 260063 KiB/s mtd_speedtest: Testing 16x multi-block erase speed mtd_speedtest: 16x multi-block erase speed is 260063 KiB/s mtd_speedtest: Testing 32x multi-block erase speed mtd_speedtest: 32x multi-block erase speed is 256000 KiB/s mtd_speedtest: Testing 64x multi-block erase speed mtd_speedtest: 64x multi-block erase speed is 260063 KiB/s mtd_speedtest: finished =================================================‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You can now achieve almost 16MB/s, better than the dd test. Of course you cannot achieve more than 20MB/s, but you are not that far, and the NAND driver need optimizations. To redo the test: rmmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko insmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko dev=2 To check your NAND is in EDO mode 5, you can check your clock tree: /unit_tests/dump-clocks.sh clock          parent   flags    en_cnt pre_cnt      rate [...] gpmi_bch_apb   ---      00000005   0       0       198000000 gpmi_bch       ---      00000005   0       0       198000000 gpmi_io        ---      00000005   0       0        99000000 gpmi_apb       ---      00000005   0       0       198000000‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The IO are clocked now at 99MHz, thus you can read at 49.5MHz (20ns in EDO mode 5 definition).

    Some customer will use NAND flash as the storage device, also in auto application field,  the fast boot is also necessary,  so how to make the read speed faster is a question. FSL provide some patches for fast boot, they’re also suitable for NAND fast boot. These patch mainly enable the MMU and SDMA in uboot, some part of the patches is special for MMC.        0001-Merge-from-12.0.4-fastboot.patch     0002-Add-fsclmmcdma-code.patch    Some NAND flash support the EDO feature, according to the device feature mode, the NAND flash can be set different clock frequency.  Here will describe how to calculate the NAND working clock.    The NAND clock is divider from the GPMI source clock, can be program in setup_gpmi_nand().  The  divider was configured in register GPMI_TIMING0, the NAND clock can get from the following:           NANDCLK=GPMICLK/(DATA_HOLD+DATA_SETUP)    NAND Clock will affect the speed a lot, for the NAND chipsets which support the EDO, the nand speed will be set automatically. For those doesn’t support EDO NAND chip, the usr should take care those setting manually. There is also a patch for enable EDO mode and set NAND clock automatically.               0008-NAND-configure-as-EDO-mode-5.patch     Besides above, there are two other patches to improve the speed about 30%, 0009-For-nand-page-align-read-include-read-offset-and-siz.patch enabled the cache read(Note: please make sure the NAND chipset support cache read), it will reduce the unnecessary command transfer between the CPU and NAND, 0010-If-possible-directly-use-user-buffer-as-BCH-nand-buf.patch remove some unnecessary memcpy.

JAVA on i.MX Sun Microsystems has pre-built versions of Java Virtual Machine for ARM Processors. It's possible to download them at: http://java.sun.com/javase/downloads/embedded.jsp All pre-built software mentioned on site above are distributed as evaluation software. For more information about use and license, please contact Sun Microsystems i.MX31 PDK will be used as an example to describe installation, compilation and execution procedures. It can be easily done for other i.MX platforms Installing Sun Java on i.MX For i.MX31, i.MX35, download the following version: Usage Headful Binary Version Non-Graphical Applications ARMv6 Linux - Headless (Early Access) EABI, glibc 2.5, Hard Float (VFP), Little Endian Graphical Applications ARMv6 Linux - Headful (Early Access) EABI, glibc 2.5, Hard Float (VFP), Little Endian For i.MX21, i.MX25, i.MX27, download the following version: Usage Headful Binary Version Non-Graphical Applications ARMv5 Linux - Headless (Early Access) EABI, glibc 2.5, Soft Float, Little Endian Graphical Applications ARMv5 Linux - Headful (Early Access) EABI, glibc 2.5, Soft Float, Little Endian On following example, a graphical application will be compiled, the headful version will be used. This example uses X11 as graphical server. On LTIB, select X11 and also the package libXtst and libXi. Extract the downloaded package (in this case "ejre-1_6_0_10-ea-b39-linux-armv6-vfp-eabi-min-eval-30_jul_2009.tar.gz") tar xzvf ejre-1_6_0_10-ea-b39-linux-armv6-vfp-eabi-min-eval-30_jul_2009.tar.gz Create a new folder on <LTIB Directory>/rootfs/ called ejre1.6.0_10 cd rootfs sudo mkdir ejre1.6.0_10 Copy all files and folders located inside the extracted package to <LTIB Directory>/rootfs/ejre1.6.0_10/ cd rootfs/ejre1.6.0_10 cp -a ../../ejre1.6.0_10/* . Include the bin folder to the PATH: export PATH=$PATH:/ejre1.6.0_10/bin/ In this example the X11 will be used as graphical server. Add the display environment variable: export DISPLAY=:0 Running a simple program Compiling and testing on Host PC Let's first compile and test a simple program on Host Machine (PC). Create a file called Example1.java and add the following code: import java.awt.*;   public class Example1 extends java.applet.Applet {    public void init()    {         add(new Button("One"));         add(new Button("Two"));    }     public Dimension preferredSize()    {         return new Dimension(480, 640);    }        public static void main(String [] args)    {         Frame f = new Frame("Example 1");          Example1 ex = new Example1();          ex.init();          f.add("Center", ex);                  f.pack();         f.show();    } } On terminal, compile the source code using ecj: $ ecj Example1.java ecj Java Compiler is needed to compile this example. To install ecj on Debian based OS, install the packages: sudo apt-get install ecj ecj-gcj libecj-java libecj-java-gcj Now it's possible to test the compiled program. Just type on host: $ java Example1 The following window will be shown: Running on i.MX Copy the file Example1.class to <LTIB Directory>/rootfs/home cp Example1.class rootfs/home On i.MX Linux, start Xfbdev in background: $ Xfbdev & Run Example1: $ java Example1 The following screen will be shown on LCD:

Setting up the clocks for PCIe is a bit tricky, especially for bare-metal or if not using the Linux BSP. The ENET PLL (PLL6) 100 MHz (SATA) PFD output MUST be enabled in order to access the registers in the PCIe IP block. (To enable this clock, set CCM_ANALOG_PLL_ENET[ENABLE_100M (bit 20)].) This is not well documented in the RM, but follow these steps to insure reliable performance.

The LTC®3676 is a complete power management solution for i.MX6, ARM Cortex processor systems. The LTC3676 features eight independent resistor-programmable voltage rails, with dynamic control and sequencing, in compact QFN and LQFP packages. These rails supply power to the processor core, SDRAM, system memory, PC cards, always on real-time clock (RTC), and a variety of other functions. Quad I 2 C Adjustable High Efficiency Step-Down DC/DC Converters: 2.5A, 2.5A, 1.5A, 1.5A Triple 300mA LDO Regulators (2 Adjustable) DDR Power Solution with VTT and VTTR Reference Pushbutton On/Off Control with System Reset Independent Enable Pin-Strap and I2C Sequencing Programmable Autonomous Power-Down Control Power Good and Reset Functions Dynamic Voltage Scaling Selectable 2.25MHz or 1.12MHz Switching Frequency Always Alive 25mA LDO Regulator 10μA Standby Current 40-Pin 6mm × 6mm × 0.75mm QFN and 48-Pin 7mm × 7mm LQFP Packages Contact Linear Technology for further details (please note that this is a pre-release product; however, data sheets and ES samples are available from Linear Technology) http://www.linear.com/product/LTC3676 or Gerard Velcelean at [email protected] or Steve Knoth at [email protected]

Linphone is an internet phone or Voice Over IP phone (VoIP). With Linphone you can communicate freely with people over the internet, with voice, video, and text instant messaging. Linphone makes use of the SIP protocol, an open standard for internet telephony. You can use Linphone with any SIP VoIP operator, including our free SIP audio/video service. Linphone is free software (or open-source), you can download and redistribute it freely. Linphone is available for desktop computers: Linux, Windows, Mac OSX, and for mobile phones: Android, iPhone, Blackberry. Linphone-android is a good example to show the integration of Java code based on Android SDK with native CODEC, network protocols. Not like XBMC-Android that is almost total c++/c project. Perform the following steps to build a linphone-android project: 1. git clone git://git.linphone.org/linphone-android.git --recursive 2. sudo apt-get install autoconf automake libtool pkg-config 3. "cd" to the root of "git clone" : cd /home/user/linphne-android // wherver git'ed linphone-android is 4. export PATH=/home/user/android-ndk:$PATH //wherever your android-ndk, android-sdk tools, and platform-tools, and ANT are stored in.             For example on my PC.      export PATH=/home/alanz/android-ndk-r8d:/home/alanz/android-sdk-linux/tools:/home/alanz/android-sdk-linux/platform-     tools:/home/alanz/bin/apache-ant-1.8.4/bin:$PATH             Note: PATH contains the ndk, sdk, and ant. 5. Make sure the network is working, then execute "./prepare_sources.sh" at the linphone-android root 6. Then, execute "/home/alanz/android-ndk-r8d/ndk-build", it will take a while to be finished 7. Modify Makefile as following example, modify it accordingly.      NDK_PATH=/home/alanz/android-ndk-r8d      SDK_PATH=/home/alanz/android-sdk-linux/tools      SDK_PLATFORM_TOOLS_PATH=/home/alanz/android-sdk-linux/platform-tools      .....................      generate-libs:           $(NDK_PATH)/ndk-build ....... (remove -j$(NUMCPUS) by the end of this command line) 8. execute "make", after finish, the apk file can be found under bin/ subdirectory.

When to improve kernel booting using hibernation [1], I found kernel initialized each component [2] took too much time. One solution is to remove unnecessary module to save time. Another approach is to delay those modules until user space up. Then it won’t lost some features just because hopes to gain benefit on booting speed. This is very useful since hibernation’s trigger point is at the late_initcall [3]. Kernel doesn't need do much module initialize since hibernate will restore those module status later. The detailed implementation is in the attached patch. [1]: hibernation is a technique to store system memory content to storage. Then the device can be shutdown and read the content back after power on. [2]: component means subsystem or driver. [3]: Consult kernel/power/hibernate.c, software_resume

This is a tool can generate a DDR3 script easily for i.MX53 and only need input several parameters based on using DDR datasheet and system architecture. Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.Mx6DQSDL DDR3 Script Aid Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid Please find i.Mx6SL LPDDR2 Script Aid through below link. i.Mx6SL LPDDR2 Script Aid Any questions are welcome!

Description about VPU & IPU usage in Android R13.4 GA release for i.MX6DQ

NOTES: Empty cells do not mean there is no bitbake parameter for the corresponding ltib one. This is still work in progress. Both engines are completely different and doing a one-to-one comparison is not actually fair. The following tables compare the two core build tools, ltib for LTIB and bitbake for the Yocto Project (YP, hereafter). For YP, there is another important tool called HOB,  when appropriate, we add comments on the Comment's column. There are two main tables, 'ltib modes versus bitbake' 'ltib options versus bitbake'.          We split in two based how ltib splits its parameter, so the order is the same as the one shown when typing './ltib --help'. LTIB comes in every released BSP, follow the User Guide to install it. The command 'ltib' is a script located on the folder with the same name, so all ltib commands should be run with './' as prefix YP can be seen of a series of layers (folders). To download these, including the Freescale layers, follow this link. The command 'bitbake' must be installed independently, you can either use the package manager of you OS (e.g. sudo apt-get install bitbake on Ubuntu) or download the source code and do the setup manually. Both ways should place the bitbake script into a executable path. ltib modes versus bitbake Mode description ltib command bitbake command Comment Just prep the package ltib -m prep -p <package> bitbake <package> -c patch With bitbake when running the patch task, it executes two lower tasks: fetch and unpack. For example, if one wants a untouched (no yocto patches) kernel, one can try: 'bitbake linux-imx -c unpack' and code unpacked code is placed on tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/<version>/git/ rpmbuild -bc --short-circuit ltib -m scbuild -p <package> bitbake <package> -c compile With bitbake running compile also runs a lower task: configure. rpmbuild -bi --short-circuit ltib -m scinstall -p <package> bitbake <package> -c With ltib the install task executes the %Install section of the package's spec. With bitbake the same task executes all related package's recipe install functions, e.g. do_install. Note: with ltib running a higher task (like scinstall) will not execute lower tasks (like scbuild and prep); this is not the case for bitbake: it runs lower tasks automatically. does an scinstall followed by an install to the rootfs ltib -m scdeploy -p <package> bitbake <package> -c build With bitbake, build is the default task, so one can even omit the -c build parameter, e.g. 'bitbake <package>' generate and merge a patch (requires -p <pkg>) ltib -m patchmerge -p <package> NA This is a pretty nice feature from LTIB, unfortunately with bitbake the command does not exit. For example, to patch the Kernel's recipe, take a look at this procedure. In case you follow all these steps to fix a bug, do not forget to send your patch to the community. lean/uninstall target packages ltib -m clean -p <package> NA With bitbake the 'clean' counterpart does not exit. If one needs to remove a specific package from a build, you may remove it from the image configuration file (e.g. file meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb, remove item on IMAGE_INSTALL variable); if package is inside a package group (e.g. ./meta-fsl-demos/recipes-fsl/packagegroup/packagegroup-fsl.bb) you may remove it there. After this change, bitbake again and the resulting image won't have the package. With HOB, this is much simpler due to its Graphical User Interface. Just type hob on your build directory, select the machine and the base image, then click on the 'Edit Image'. On that window you can easily deselect packages. Once deselection is done, build the image. full cleanup, removes nearly everything ltib -m distclean NA With bitbake the 'distclean' command does not exit. The way to remove all the built, remove the build/tmp folder. Be careful, next time you run bitbake, all tasks for all packages will be executed, in other words, you will start from scratch. list packages (alphanumeric) ltib -m listpkgs non-GUI: bitbake -g fsl-image-gui && cat pn-depends.dot GUI: bitbake -g -u depexp fsl-image-gui A bit more complex non-GUI: bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq list package names and licenses ltib -m listpkgseula NA With HOB, you can see every package name name and its licence. Just type hob, then select the machine and image, and click on the 'Edit Image' button. On the 'All recipes' tab, you get a list of packages with their licenses. list packages in twiki format ltib -m listpkgstw NA list packages in a format for import into spreadsheet ltib -m listpkgscsv NA make a binary release iso image ltib -m release NA make a non-distributable test iso release ltib -m trelease NA configure selected platform (no build) ltib -m config NA There is no way to open a configuration menu with bitbake. Instead, you can use hob. With hob, things are much easier. Just type hob under the build folder and you can select the machine and the image. If the image you want does not fit to the ones already available, you can add packages manually and even store your new tuned image. NOTES: 1. On YP, an image is a similar concept as LTIB's package profile (usually called just profile). There are many predefined images which can be used as starting point, so type 'bitbake <image name>'. 2. In case the kernel needs to be configure, run 'bitbake linux-imx -c menuconfig'. sub-platform selection (no build) ltib -m selectype NA The selectype on LTIB opens two menus: 1. Platform and the Package Profile selection 2. Configuration menu (the same menu as the one shown with -m config). In case one needs to do execute just the first task, just run 'bitbake <image name>'. In case you need to execute both, run hob. enter ltib shell mode (sets up spoofing etc) ltib -m shell bitbake <package name> -c devshell import srpms into ltib (semi-automatic) ltib -m addsrpms ltib options versus bitbake Option Description ltib command bitbake command Comments Root context number (0 is the primary and implicit) ltib --rootn | ltib -R operate on this package only ltib --pkg | ltib -p bitbake <package> With bitbake there is no need to add a '-' parameter, just use the package name without the .bb extension run the interactive configuration and build ltib --configure  | ltib -c NA See the mode -m config for more info run the sub-platform configuration and build ltib --selectype NA See the mode -m selectype for more info configuration file to build from (defaults to .config) ltib --preconfig bitbake <predefined image> With bitbake use any of the predefined images (assuming that these have not been modified), e.g. bitbake core-image-minimal or bitbake fsl-image-gui (it happens to be the smallest and the largest image, in terms of number of packages) profile file.  This is used to select an alternate  set of userspace packages, this is saved and used on later runs of ltib (e.g config/profiles/max.config) ltib --profile use this resource file ltib --rcfile <f> | ltib - r <f> batch mode, assume yes to all questions ltib --batch | ltib -b force rebuilds even if they are up to date ltib --force | ltib -f bitbake --force | bitbake -f For example, to force recompiling the kernel: bitbake linux-imx -c compile -f re-install rpms (but don't force rebuild) ltib --reinstall | ltib -e bitbake <package name> -c install -f remove (erase) rpm ltib --erase | ltib -E turn off install/uninstall dependency checks ltib --nodeps | ltib -n bitbake -b <somepath/somefile.bb> For example, to build just the kernel (no dependencies, just kernel): bitbake -b ../sources/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.0.35.bb NOTE: ALL dependencies should be already be installed, otherwise the command will fail don't force install rpms that have file conflicts ltib --conflicts | ltib -k keep the srpms after the build (deleted by default) ltib --keepsrpms | ltib -s more output ltib --verbose | ltib -v bitbake --verbose | bitbake -v On YP, the log can be too verbose, so one way to handle the amount of log is to store it and then grep it: bitbake linux-imx | tee log; grep -i <your string to seach> < log mostly a dry run (calls to system are just echos) ltib --dry-run | ltib -d bitbake --dry-run | bitbake -n try to continue on package build errors (autobuilds) ltib --continue | ltib -C bitbake --continue | bitbake -k print the application version and quit ltib --version | ltib -V bitbake --version do not redirect any output ltib --noredir | ltib -N run the deploy scripts even if build is up to date ltib --deploy | ltib -D bitbake <image name> -f disabled deployment (even with -p <pkg>) ltib --no-deploy just download the packages only ltib --dlonly bitbake -c fetchall <image name> E.g. bitbake -c fetchall core-image-minimal test that the BSP's packages are available ltib --dltest check against external staging repositories ltib --external leave the sources unpacked (only valid for pkg mode) ltib --leavesrc | ltib -l NA This is the default mode in YP. All source code can be found on tmp/work. In case you want to remove source code after building (as in LTIB), add INHERIT += "rm_work" to your local.conf. NOTE: If your adding changes to a particular package, these will be lost. In case you want to keep source code of a specific package, include this on the RM_WORK_EXCLUDE variable (e.g. RM_WORK_EXCLUDE += "busybox eglibc"). Make the selected root number sticky --sticky Remove root stickiness --no-sticky (re)configure/build/install the host support package set --hostcf use with package listings --enable use if you really want to ignore any locks (careful!) --ignorelock used with -m release to copy additional content --fullbsp used with -m release to copy specical packages into ISO --distmap don't check sudo, work around for broken sudo (fc9) --no-sudo use git for some package's build where use-git-mode is either: internal    Use fsl internal git external   Use fsl external git --use-git-mode use external git for some package's build --external-git help on usage --help | -h --help | -h

Hi all, Most of IoT customers request to enable/demo i.MX EVK with FSL Zigbee solution. In default i.MX Linux/Android BSP, Zigbee function is not enabled. Here we make a lighting demo setup through i.MX6Q SabreSD, KW20 USB dongle and Philips Hue light. KW20 is configured as Zigbee coordinator, connected with USB OTG in i.MX6Q, then i.MX6Q can issue On/Off, brightness and color control commands through KW20 to toggle Philips Hue light directly. Please find the attachment for details. Best regards, Carl

Installation, patching and building the SDK The i.MX 6 Series Platform SDK v1.1.0 does not enable neither the MMU nor L1/L2 Caches (depending on the benchmark you are running, enabling these yield much better numbers), so there is a need to patch the code to enable these. Please download the SDK from the Freescale portal and the patch attached on this document, then follow these instructions: $ tar zxvf imx6_platform_sdk_v1.1.0.tgz $ cd iMX6_Platform_SDK $ patch -p1 < 0001-add-L2-cache-enable-to-mx6-SDK-1.1.0.patch $ export PATH=$PATH:<toolchain_install_path>/bin $ ./tools/build_sdk For more help, please look at the README.pdf and documents inside the doc folder.

Introduction This guide provides a step by step explanation of what is involved in adding a new WiFi driver and making a new WiFi card work well in a custom Android build. (This guide was written for Android 4.1 but should be applicable to previous Android releases and hopefully future releases.) Contents Understand how Android WiFi works Port WiFi driver. Compile a proper wpa_supplicant in your BoardConfig.mk Modify your wifi.c in HAL. Launch wpa_supplicant and dhcpcd services in init.rc. Several debug tips. Understand How Android WiFi Works As the following figure, Android wireless architecture can be divided into three parts: Java Framework(WifiManager, WifiMonitor etc..), HAL(wifi.c,wpa_supplicant,netd) kernel space modules(wireless stack, wifi drivers) Java Framework communicate with wpa_supplicant using native interface (wifi.c). Wpa_supplicant and netd uses wireless extension or nl80211 to control WiFi drivers. Port WiFi driver Usually WiFi driver is provided as a kernel module. There are mainly two types of Android WiFi architecture:nl80211 and wext. With the implementation of nl80211/cfg80211 many wireless drivers in main line kernel  support nl80211 interface instead of wireless extension. For different vendors’ WiFi drivers, writing one Android.mk to add its compile into Android is what you should do. Here take atheros’s AR6kl as an example: ath6kl_module_file :=drivers/net/wireless/ath/ath6kl/ath6kl_sdio.ko $(ATH_ANDROID_SRC_BASE)/$(ath6kl_module_file):$(mod_cleanup) $(TARGET_PREBUILT_KERNEL) $(ACP)         $(MAKE) -C $(ATH_ANDROID_SRC_BASE) O=$(ATH_LINUXPATH) ARCH=arm CROSS_COMPILE=$(ARM_EABI_TOOLCHAIN)/arm-eabi- KLIB=$(ATH_\ LINUXPATH) KLIB_BUILD=$(ATH_LINUXPATH)         $(ACP) -fpt $(ATH_ANDROID_SRC_BASE)/compat/compat.ko $(TARGET_OUT)/lib/modules/         $(ACP) -fpt $(ATH_ANDROID_SRC_BASE)/net/wireless/cfg80211.ko $(TARGET_OUT)/lib/modules/ include $(CLEAR_VARS) LOCAL_MODULE := ath6kl_sdio.ko LOCAL_MODULE_TAGS := optional LOCAL_MODULE_CLASS := ETC LOCAL_MODULE_PATH := $(TARGET_OUT)/lib/modules LOCAL_SRC_FILES := $(ath6kl_module_file) include $(BUILD_PREBUILT) Compile a proper wpa_supplicant in your BoardConfig.mk In Android’s external directory, there are two wpa_supplicant_* projects. For wext-based wifi driver, wpa_supplicant_6 can be used. For nl80211-based WiFi driver, wpa_supplicnat_8 can only be used. But if WiFi vendors supply their own customized wpa_supplicant, it will be much easier to debug the communication between wpa_supplicant and WiFi drivers. No matter which supplicant  you choose, just control their compile in your BoardConfig.mk. Take atheros’s ath6kl as an example: ifeq ($(BOARD_WLAN_VENDOR),ATHEROS) BOARD_WLAN_DEVICE                        := ar6003 BOARD_HAS_ATH_WLAN                      := true WPA_SUPPLICANT_VERSION                  := VER_0_8_ATHEROS WIFI_DRIVER_MODULE_PATH                  := "/system/lib/modules/ath6kl_sdio.ko" WIFI_DRIVER_MODULE_NAME                  := "ath6kl_sdio" WIFI_DRIVER_MODULE_ARG                  := "suspend_mode=3 wow_mode=2 ar6k_clock=26000000 ath6kl_p2p=1" WIFI_DRIVER_P2P_MODULE_ARG              := "suspend_mode=3 wow_mode=2 ar6k_clock=26000000 ath6kl_p2p=1 debug_mask=0x2413" WIFI_SDIO_IF_DRIVER_MODULE_PATH          := "/system/lib/modules/cfg80211.ko" WIFI_SDIO_IF_DRIVER_MODULE_NAME          := "cfg80211" WIFI_SDIO_IF_DRIVER_MODULE_ARG          := "" WIFI_COMPAT_MODULE_PATH                  := "/system/lib/modules/compat.ko" WIFI_COMPAT_MODULE_NAME                  := "compat" WIFI_COMPAT_MODULE_ARG                  := "" endif then you need to provide a proper wpa_supplicant.conf  for your device. wpa_supplicant.conf  is very important because the control socket for android is specified in this file(ctrl_interface=). This file should be copied to /system/etc/wifi. Minimum required config options in wpa_supplicant.conf : There are two different ways in which wpa_supplicant can be configured, one is to use a "private" socket in android namespace, created by socket_local_client_connect() function in wpa_ctrl.c and another is by using a standard UNIX socket. Android private socket ctrl_interface=wlan0 update_config=1 - Unix standard socket ctrl_interface=DIR=/data/system/wpa_supplicant GROUP=wifi update_config=1 Modify your wifi.c in HAL Here what you should do is modifying some codes like wifi_load_driver and wifi_unload_driver. For Broadcom or CSR’s wifi driver, you can directly use the original wifi.c. But for atheros’s ath6kl driver, there are total three  .ko modules to install. So some micro variables and codes need to be changed to adapt it. Launch wpa_supplicant and dhcpcd services in init.rc If you have configured to use android private socket, you should do like this: service wpa_supplicant /system/bin/wpa_supplicant -Dwext -iwlan0 -c / data/misc/wifi /wpa_supplicant.conf socket wpa_wlan0 dgram 660 wifi wifi disabled oneshot or if you have configured to use unix standard socket, you should do like this: service wpa_supplicant /system/bin/wpa_supplicant -Dwext -iwlan0  -c/data/misc/wifi/wpa_supplicant.conf disabled oneshot If WiFi driver is not “wext” but “nl80211”, you should change it to –Dnl80211. For dhcpcd, you should lunch it like the following: service dhcpcd_wlan0 /system/bin/dhcpcd -ABKL     class late_start     disabled oneshot The parameters “-ABKL” can largely enhance wifi connection speed.  About what “ABKL” stand for, you can refer to dhcpcd’s GNU manual. Several debug tips Incorrect permissions will result in wpa_supplicant not being able to create/open the control socket andlibhardware_legacy/wifi/wifi.c won't connect. Since Google modified wpa_supplicant to run as wifi user/group the directory structure and file ownership should belong to wifi user/group (see os_program_init() function in wpa_supplicant/os_unix.c ). Otherwise errors like: E/WifiHW  (  😞 Unable to open connection to supplicant on "/data/system/wpa_supplicant/wlan0": No such file or directory will appear. Also wpa_supplicant.conf should belong to wifi user/group because wpa_supplicant will want to modify this file. How to Enable debug for wpa_supplicant.               By default wpa_supplicant is set to MSG_INFO that doesn't tell much.                    To enable more messages:                 modify common.c and set wpa_debug_level = MSG_DEBUG                 modify common.h and change #define wpa_printf from if ((level) >= MSG_INFO) to if ((level) >= MSG_DEBUG)         3. WiFi driver’s softmac.               For most vendors’ WiFi driver, the mac address is fixed. We should add one softmac rule to let WiFi driver’s mac is unique for each board.

The Linux Kernel is just another recipe for Yocto, so learning to patch it you learn to patch any other package. In the other hand, Yocto **should not** be used for package development, but in those rare cases follow the below steps. It is assumed that you have already build the package you want to patch. 1. Create the patch or patches. In this example we are patching the Linux kernel for [wandboard-dual](http://www.wandboard.org/) machine; in other words, the value of MACHINE on the `build/conf/local.conf` is `MACHINE ??= 'wandboard-dual'`. In case you already have the patches, make sure these can be nicely applied with the commands `git apply --check <PATCH_NAME>`, and jump this step build $ cd tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git build $ # Edit any files you want to change build $ git add <modified file 1> <modified file 2> .. # Select the files you want to commit build $ git commit -s -m '<your commit's title>' # Create the commit build $ git format-patch -1 # Create the patch 2. Create a new layer (see document i.MX Yocto Proyect: How can I create a new Layer?) 3. On the new layer (e.g `meta-fsl-custom`) , create the corresponding subfolders and the `.bbfile` sources $ mkdir -p meta-fsl-custom/recipes-kernel/linux/linux-wandboard-3.0.35/ sources $ cat > meta-fsl-custom/recipes-kernel/linux/linux-wandboard_3.0.35.bbappend FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" SRC_URI += "file://0001-calibrate-Add-printk-example.patch" PRINC := "${@int(PRINC) + 1}" # SEE NOTE BELLOW ^d (The PRINC variable is not needed starting at Yocto 1.6 ([RFC] base.bbclass: Deprecate the PRINC logic - Patchwork)) 4. Move the patch to the new layer sources $ cp \ ../build/tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git/0001-calibrate-Add-printk-example.patch \ meta-fsl-custom/recipes-kernel/linux/linux-wandboard-3.0.35 5. Setup the enviroment and clean previous package's build data (sstate) fsl-community-bsp $ . setup-environment build build $ bitbake -c cleansstate linux-wandboard 6. Compile and Deploy build $ bitbake -f -c compile linux-wandboard build $ bitbake -c deploy linux-wandboard 7. Insert the SD into your Host and copy the `uImage` into the first partition. Do not forget to unmount the partition before removing the card! build $ sudo cp tmp/deploy/images/uImage /media/Boot\ wandbo/ 8. Insert the SD into your board and test your change.

Introduction LVDS display panel driving data flow: Display quality: To get the best display quality for 24bit LVDS display panel in Android, we should use 32bit framebuffer, make IPUv3 display Engine and LDB output 24bit pixels, since RGB component information is aligned from source to destination.  2 stages to enable display: Uboot splash screen and Kernel framebuffer Guidelines Uboot splash screen:    Change should be done in board file, like board/freescale/mx6q_sabresd/mx6q_sabresd.c:    1. Set video mode in struct fb_videomode according to the new 24bit LVDS display panel’s spec(please, refer to the example at the end of this doc).    2. Set up pwm, iomux/display related clock trees in lcd_enable(). Note that these should be aligned with Kernel settings to support smooth UI transition        from Uboot splash screen to Kernel framebuffer.    3. Set the output pixel format of IPUv3 display engine and LDB to IPU_PIX_FMT_RGB24 when calling ipuv3_fb_init().    4. Set pixel clock according to the new 24bit LVDS display panel’s spec when calling ipuv3_fb_init().    5. If dual LDB channels are needed to support tough display video mode(high resolution or high pixel clock frequency), we need to enable both of the two LDB        channels and set LDB to work at split mode. LDB_CTRL register should be set accordingly in lcd_enable(). Kernel framebuffer:    As we may add ‘video=‘  and ‘ldb=’ options in kernel bootup command line, Kernel code is more flexible to handle different LVDS display panels with various display color depth than Uboot code. For detail description of ‘video=’ and ‘ldb=’ option, please refer to MXC Linux BSP release notes and Android User Guide. Some known points are:    1. Add a video mode in struct fb_videomode in drivers/video/mxc/ldb.c according to the new 24bit LVDS display panel’s spec(please, refer to the example at        the end of this doc).    2. Set up pwm backlight/display related iomux in platform code.   3. Set appropriate ‘video=‘ option in kernel bootup command line, for example:        video=mxcfb0:dev=ldb,LDB-NEW,if=RGB24,fbpix=RGB32     4. Set appropriate ‘ldb=‘ option in kernel bootup command line if dual LDB channels are needed to support tough display video mode, for example:        ldb=spl0 (IPUv3 DI0 is used)  or  ldb=spl1 (IPUv3 DI1 is used)    5. Set appropriate ‘fbmem=‘ option in kernel bootup command line to reserve enough memory for framebuffer. For example, if we use 1280x800 LVDS panel        for fb0 and fb0 is in RGB32 pixel format, then ‘fbmem=12M’ should be used, since the formula is:        fbmem= width*height*3(triple buf)*Bytes_per_pixel= 1280*800*3*4B=12MB An Example to Set struct fb_videomode:    Let’s take a look at the timing description quoted from a real 1280x800@60 24bit LVDS panel spec: And, standard linux struct fb_videomode definition in include/linux/fb.h: struct fb_videomode {         const char *name;       /* optional */         u32 refresh;            /* optional */         u32 xres;         u32 yres;         u32 pixclock;         u32 left_margin;         u32 right_margin;         u32 upper_margin;         u32 lower_margin;         u32 hsync_len;         u32 vsync_len;         u32 sync;         u32 vmode;                u32 flag; };    What we need to do is to set every field of struct fb_videomode correctly according to the timing description of LVDS display panel’s spec:     1. name: we can set it to ‘LDB-WXGA’.    2. refresh: though it’s optional, we can set it to typical value, that is, 60(60Hz refresh rate).    3. xres: the active width, that is, 1280.    4. yres: the active height, that is, 800.    5. pixclock: calculate with this formula – pixclock=(10^12)/clk_freq. Here, typically, for this example, pixclock=(10^12)/71100000=14065.    6. left_margin/right_margin/hsync_len:        They are the same to HS Back Porch(HBP)/HS Front Porch(HFP)/HS Width(HW) in the spec. Since the spec only tells us that typically        HBP+HFP+HW=160. We may set left_margin=40, right_margin=40, hsync_len=80.    7. upper_margin/lower_margin/vsync_len:        Similar to horizontal timing, the vertical ones can be set to upper_margin=10, lower_margin=3, vsync_len=10.    8. sync: Since the timing chart tells us that hsync/vsync are active low, so we don’t need to set FB_SYNC_HOR_HIGH_ACT or        FB_SYNC_VERT_HIGH_ACT. Moreover, clock polarity and data polarity are invalid, so we set sync to be zero here.    9. vmode: this is a progressive video mode, so set vmode to FB_VMODE_NONINTERLACED.    10. flag: the video mode is provided by driver, so set flag to FB_MODE_IS_DETAILED.