This is the procedure and patch to set up Ubuntu 13.10 64bit Linux Host PC and building i.MX28 L2.6.35_1.1.0_130130. It has been tested to build GNOME profile and with FSL Standard MM codec. A) Basic Requirement: Set up the Linux Host PC using ubuntu-13.10-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 $ sudo apt-get install libc6-dev-i386 $ sudo apt-get install u-boot-tools $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd $ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so   /usr/lib/librt.so C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L2.6.35_1.1.0_130130_source.tar.gz $ ./L2.6.35_1.1.0_130130_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L2.6.35_1.1.0_130130 could be installed and compiled on Ubuntu 13.10 64bit OS $ cd ~/ltib $ git apply 0001_make_L2.6.35_1.1.0_130130_compile_on_ubuntu_13.10_64bit_OS.patch What the patch is doing: a) The patch modifies the following files: dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/elftosb/elftosb.spec dist/lfs-5.1/lkc/lkc.spec dist/lfs-5.1/mux_server/mux_server.spec dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory: pkgs/elftosb-2.6.35.3-1385779630.patch pkgs/elftosb-2.6.35.3-1385779630.patch.md5 pkgs/lkc-1.4-lib.patch pkgs/lkc-1.4-lib.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L2.6.35_1.1.0_130130_docs/doc/mx28/Setting_Up_LTIB_Host_on_Ubuntu_9_04.pdf https://community.freescale.com/docs/DOC-93394 https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation elftosb compilation issue fixed by added -lm to LIBS in the elftosb-2.6.35.3-1.1.0/makefile.rules NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

This is the procedure and patch to set up Ubuntu 12.04 64bit Linux Host PC and building i.MX28 L2.6.35_1.1.0_130130.  It has been tested to build GNOME profile and with FSL Standard MM codec. A) Basic Requirement: Set up the Linux Host PC using ubuntu-12.04.3-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install ia32-libs libc6-dev-i386 lib32z1 $ sudo apt-get install uboot-mkimage $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L2.6.35_1.1.0_130130_source.tar.gz $ ./L2.6.35_1.1.0_130130_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L2.6.35_1.1.0 could be installed and compiled on Ubuntu 12.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L2.6.35_1.1.0_130130_compile_on_ubuntu_12.04_64bit_OS.patch a) The patch modifies the following files:    dist/lfs-5.1/base_libs/base_libs.spec    dist/lfs-5.1/lkc/lkc.spec    dist/lfs-5.1/mux_server/mux_server.spec    dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory:    pkgs/lkc-1.4-lib.patch    pkgs/lkc-1.4-lib.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L2.6.35_1.1.0_130130_docs/doc/mx28/Setting_Up_LTIB_Host_on_Ubuntu_9_04.pdf https://community.freescale.com/docs/DOC-93394 https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

This is the procedure and patch to set up Ubuntu 12.04 64bit Linux Host PC and building i.MX6x L3.0.35_4.1.0.  It has been tested to build GNOME profile and with FSL Standard MM Codec for i.MX6Q SDB board. A) Basic Requirement: Set up the Linux Host PC using ubuntu-12.04.3-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install ia32-libs libc6-dev-i386 lib32z1 $ sudo apt-get install uboot-mkimage $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L3.0.35_4.1.0_130816_source.tar.gz $ ./L3.0.35_4.1.0_130816_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L3.0.35_4.1.0 could be installed and compiled on Ubuntu 12.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L3.0.35_4.1.0_compile_on_Ubuntu_12.04_64bit_OS.patch The patch modifies the following files: dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/ncurses/ncurses.spec E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L3.0.35_4.1.0_130816_docs/doc/mx6/Setting_Up_LTIB_host.pdf https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

This is a hardware design checklist for i.MX28. Please go through this checklist and check your design before requesting a schematics review. Arthur

Tel Aviv, December 2013   Variscite announces the support of Yocto over its iMX6 System-on-Modules   Variscite, a leading manufacturer of embedded solutions and System-on-Modules and Freescale’s Connected Partner, is pleased to announce the support of Yocto v4.1 Dora release over all Variscite’s iMX6 embedded products. Variscite develops, produces and manufactures a powerful range of System-on-Modules (SoM) and Single-Board-Computers (SBC), consistently setting market benchmarks in terms of speed and innovation. Today Variscite’s cost sensitive high performance portfolio serves over a thousand c ustomers in over 50 countries worldwide. The Yocto project was announced in 2010 to enable the creation of Linux distributions for embedded software that are independent of the underlying architecture of the embedded software itself. Variscite’s support of Yocto over its iMX6 solutions aligns with the company’s strategy to provide its customers with a complete set of leading embedded software and hardware solution, reducing development risk, cost and time-to-market. Variscite’s Yocto v4.1 Dora release supports iMX6 Solo, Dual Lite, Dual and Quad processors with a variety of speed grades, memory sizes and interfaces. More information can be found in: http://www.variwiki.com/index.php?title=Yocto_V4.1_Dora#Supported_hardware_and_features   About Variscite:   In less than a decade Variscite has taken a leading position in the System-on-Modules (SoM) design and manufacturing market. A trusted provider of development and consulting services for a variety of embedded platforms, Variscite transforms clients’ visions into successful products. Learn more about Variscite by visiting: www.variscite.com or contacting: Variscite Sales, [email protected] , +972-9-9562910

The attached patches slow-down the DDR's clock (from 528000000Hz to 396000000Hz) on i.MX6Q Sabre SDB-P boards. These were tested on Android JB4.2.2_1.0.0 and Linux L3.0.35_4.1.0. To verify patches were correctly applied, one the serial console one should see the following TWO bold lines Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [POR ] Boot Device: MMC I2C:   ready DRAM:   1 GB MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3 *** Warning - bad CRC or MMC, using default environment mx6q pll1: 792MHz mx6q pll2: 528MHz mx6q pll3: 480MHz mx6q pll8: 50MHz ipg clock     : 49500000Hz ipg per clock : 49500000Hz uart clock    : 80000000Hz cspi clock    : 60000000Hz ahb clock     : 99000000Hz axi clock   : 198000000Hz emi_slow clock: 99000000Hz ddr clock     : 396000000Hz usdhc1 clock  : 198000000Hz usdhc2 clock  : 198000000Hz usdhc3 clock  : 198000000Hz usdhc4 clock  : 198000000Hz nfc clock     : 24000000Hz In:    serial Out:   serial Err:   serial Found PFUZE100! deviceid=10,revid=10 Net:   got MAC address from IIM: 00:04:9f:02:67:46 FEC0 [PRIME] Hit any key to stop autoboot:  0 kernel   @ 10808000 (4709060) ramdisk  @ 11800000 (183100) kernel cmdline:     use boot.img command line:     console=ttymxc0,115200 init=/init video=mxcfb0:dev=ldb,bpp=32 video=mxcfb1:off video=mxcfb2:off fbmem=10M fb0base=0x27b00000 vmalloc=400M androidboot.console=ttymxc0 androidboot.hardware=freescale Starting kernel ... Uncompressing Linux... done, booting the kernel. . . . sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655ms Set periph_clk's parent to pll2_pfd_400! arm_max_freq=1.2GHz . . .

Question: What is the correct path for the buffer generated by the GPU and sent to the display? When referring to Linux Manual Chapter 5 "Image Processing Unit (IPU) Drivers" and sect.37.5.68 "Current Buffer Register 0". i.MX6DQ Reference Manual (rev.1  4/2013) and further on text and associated with buffer events interrupts. A lot of printouts in the mxc_ipuv3_fb.c file have been added and in other files located in the drivers/video/mxc/ directory and still unable to capture the interrupt generated by the IPU. An open GL buffer (using the GLES and EGL) is generated with the frame buffer mechanism to a monitor connected to the HDMI output on the evaluation board. Direct it to /dev/fb0. The following functions are used to create EGL context fbGetDisplayByIndex(0) fbCreateWindow(…); Everything works and openGL on the monitor can be seen. To measure how long it takes for the data to be sent to the display/monitor after the buffer is ready in the GPU, can it be done in the IPU if where it is performed is known? Where is the exact location where the interrupt can be captured. The ltib on the Ubuntu 12.04 OS (the alsa-utils package was also installed using some patch)) is installed. Answer: GPU EGL swapbuffer is asyncronous. It means when you call swapbuffer it will not be displayed immediately. If will just flush the command buffer and when the GPU completes the frame, it will be displayed to the scree, To make sure the frame is complete, use glFinish after eglswapbuffer. Also please try with simple program rather using GPU driver to measure time to display on the screen. Swapbufferinterval will work when FB_MULTI_BUFFER = 2. By default it will be 1.

To build Android version earlier than Lollipop from source code, you need the Sun's 1.6 SDK to be installed for ubuntu as the link Initializing a Build Environment | Android Developers. You may still cannot get the Sun's JDK  with below instruction: $ sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner" $ sudo apt-get update $ sudo apt-get install sun-java6-jdk    There are below options to help install the Sun's JDK  if you cannot find a valid source through apt-get commands: $ wget --no-cookies --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F" http://download.oracle.com/otn-pub/java/jdk/6u45-b06/jdk-6u45-linux-x64.bin $ chmod u+x jdk-6u45-linux-x64.bin $ ./jdk-6u45-linux-x64.bin $ sudo mv jdk1.6.0_45 /opt $ sudo update-alternatives --install /usr/bin/java java /opt/java/64/jdk1.6.0_45/bin/java 1 $ sudo update-alternatives --install /usr/bin/javac javac /opt/java/64/jdk1.6.0_45/bin/javac 1 $ sudo update-alternatives --install /usr/bin/jar jar /opt/java/64/jdk1.6.0_45/bin/jar 1 # if you have already install some other version of JDK, please export the JAVA_HOME env before your android build every time $ export JAVA_HOME=/opt/jdk1.6.0_45/ #or you can directly link the java binary to the sdk version you need as below: sudo ln -s /opt/java/64/jdk1.6.0_45/bin/jar /bin/jar sudo ln -s/opt/java/64/jdk1.6.0_45/java /bin/java sudo ln -s/opt/java/64/jdk1.6.0_45/javac /bin/javac sudo ln -s/opt/java/64/jdk1.6.0_45/javah /bin/javah sudo ln -s/opt/java/64/jdk1.6.0_45/javadoc /bin/javadoc sudo ln -s/opt/java/64/jdk1.6.0_45/javaws /bin/javaws    To built the Android version Lollipop and Marshmallow from source code, you need the OpenJDK 7 to be installed for ubuntu as the link Initializing a Build Environment | Android Developers. $ sudo apt-get update $ sudo apt-get install openjdk-7-jdk You may have both openjdk7 and SUN JDK 1.6 intalled in your ubuntu to build different Android version. If you have default java SDK to be Sun's JDK 1.6, you can just use below commands to make android build system use the openjdk7 for Lollipop built $ export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/ $ cd myandroid $ . ./build/envsetup.sh           //be sure to resetup the envsetup, and pick the platform to be built $ lunch

Question: The code signing tool(CST) of i.MX6 with "CST -h" command just for viewing help message took about 22 minutes. On other system, it was shorter but still took about 2 minutes. CST version is BLN_CST_MAIN_02.00.00. More test results: 1. Print help message => 4 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --help && date Fri Oct 18 14:10:52 KST 2013 Fri Oct 18 14:15:01 KST 2013 2. Signing 512MB file => 11 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --output "out_system.csf" < "example_system.csf" && date Fri Oct 18 14:15:01 KST 2013 CSF Processed successfully and signed data available in out_system.csf Fri Oct 18 14:25:47 KST 2013 3. Signing 3MB file => 17 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --output "out_kernel.csf" < "example_kernel.csf" && date Fri Oct 18 14:25:47 KST 2013 CSF Processed successfully and signed data available in out_kernel.csf Fri Oct 18 14:42:39 KST 2013 4. Signing 160KB file => 2 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --output "out_uboot.csf" < "example_uboot.csf" && date Fri Oct 18 14:42:39 KST 2013 CSF Processed successfully and signed data available in out_uboot.csf Fri Oct 18 14:45:05 KST 2013 Answer: The slow performance is caused by lack of entropy source and it takes long time to initialize random number generator. Check amount of entropy  "cat /proc/sys/kernel/random/entropy_avail" Tried to install package rng-tools. 1. $sudo apt-get install rng-tools 2. add the following settings in /etc/default/rng-tools HRNGDEVICE=/dev/urandom RNGDOPTIONS=”-W 90% -t 1? 3. sudo /etc/init.d/rng-tools restart 4. cat /proc/sys/kernel/random/entropy_avail After rng-tools starts, entropy increases from less than 100 to more than 1000, then command ./cst -h can run very smoothly.

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"