This patch is for i.MX6 ESPI controller slave mode (SPI timing mode 0 and 3) support. Hardware prepare:   Connect two i.MX6 Sabresd boards, remove U14 SPI nor device, connect two boards like:          MISO --- MISO          MOSI --- MOSI          SS     --- SS          CLK   --- CLK          GND  ---  GND Software prepare: 1>Apply patch spi_slave_2013_10_12.patch on 3.0.35_4.1.0 Linux BSP release.     Note two board all need choose CONFIG_IMX6_SDP_MISCSPI, CONFIG_SPI_SPIDEV of kernel Symbol: IMX6_SDP_MISCSPI [=y]                                                                                                              Location:   |     -> Device Drivers                                                                                                                      |       -> Misc devices (MISC_DEVICES [=y]) Symbol: SPI_SPIDEV [=y]  Location:                                                                                                                                            |     -> Device Drivers                           |       -> SPI support (SPI [=y])    Spi master board choose CONFIG_SPI_IMX_VER_2_3 Symbol: SPI_IMX_VER_2_3 [=y] Location:                                                                                                                                           |     -> Device Drivers                                                                                                                                 |       -> SPI support (SPI [=y])                                                                                                                       |         -> Choose IMX SPI work mode (<choice> [=y])    Spi slave board choose CONFIG_SPI_IMX_VER_2_3_SLAVE. Symbol: SPI_IMX_VER_2_3_SLAVE [=y] Location:                                                                                                                                           |     -> Device Drivers                                                                                                                                 |       -> SPI support (SPI [=y])                                                                                                                       |         -> Choose IMX SPI work mode (<choice> [=y]) 2>Compile test application  mxc_spi_test1.c to generate mxc_spi_test. 3> Test steps : First  spi slave board input cmd mxc-spi-test –D 0 –b 32 –L 32 Then spi master board input cmd mxc-spi-test –D 0 –b 32 –L 32           This tool will write its buffer ( the content is same in two side ) to the  other board  through  SPI bus , then read data from the other board , and compare with its write buffer.

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.

ERR005723           PCIe: PCIe does not support L2 Power Down   Description: When PCIe works as Root Complex, it can exit L2 mode only through reset. Since PCIe doesn't have a dedicated reset control bit, it cannot exit L2 mode.   Projected Impact: PCIe does not support L2 Power Down   Workarounds: The PCIe can be put in PDDQ mode to save on PCIe PHY power and wakeup only by the OOB (Out of Band) wakeup signal (since wakeup by a beacon from link partner is not supported) driven from the link partner (End Point). This signal could be used as a GPIO interrupt to exit this mode. The limitation of this workaround is that the link partner cannot be put into L2.   Proposed Solution:                 No fix scheduled   Linux BSP Status:                 No software workaround available   SW workaround used to fix ERR005723 in Linux BSP Why the original workarounds can’t be implemented in Linux BSP * PCIe controller doesn’t have the reset mechanism that can be used when re-insmod the PCIe driver without power down/up PCIe module. * During the PCie driver rmmod/insmod operations, the PCIe CLKs would be turned off/on. IC can’t guarantee that the PCIe PHY can work well and re-establish the PCIe link properly. One SIMPLE SW workaround for this errata imx: pcie: toggle bit18 of grp1 fix pcie can't exit L2 issue.   Set bit18 of gpr1 before enter into supend, and clean it after resume, can fix the following errata. Errata ERR005723_PCIe PCIe does not support L2 Power Down. About the details, please refer to the attached patch. "0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch"   The conception of the other SW workaround (System warm-reset) The procedures of the original suspend/resume. Suspend User suspend command echo mem > /sys/power/state All driver call suspend function SRPG,  ARM save all state to memory Enter Stop mode and Power down ARM   Resume:   GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Recovery ARM status from memory Call all devices resume function.   Because PCIe only reset by system reset, we need change above follow. Resume:   GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Warm Reset system, memory context will be kept. But all peripheral status lost. ROM code running Jump to SRPG point again. Recovery ARM status from memory Call all devices resume function. Resume function call init to initialize it.  And recover to the status saved before.   Impact: Can’t support usb remote wake up, which required 4ms responsive Longer latency, warm reset need some ms.  The recovery of the device status needs some more ms.   Risk:   Current BSP have not tested above follow Device driver have not supported this follow yet. Need additional work to enable \debug\test it.     Modules enabled in this workaround now: * UART * ENET * PCIe   Tests procedure. HW: one i.MX6Q SD boards, and one INTEL pciex1 1000M CT network card.   SW(The images used by me are attached):   * Apply the attached patches(kernel and uboot) to the kernel/uboot source codes, re-build, get the images. Kernel is based on imx_3.0.35_4.0 release, uboot , is based on imx_v2009.08 # build out SD/MMC and USB driver to make DRAM hibernate work     # build pcie in.   *procedure of the suspend/resume tests;     # unload ep's driver --> suspend/resume --> reload ep's driver.   NOTE: Please make sure that the command line contains “no_console_suspend” The command used to enable the console input wake up after login the consol: echo enabled > /sys/devices/platform/imx-uart.0/tty/ttymxc0/power/wakeup   Log when the INTEL CT 1G network card is used: -------------------------------log--------------------------------------------   PM: Syncing filesystems ... done.                                             start suspend Freezing user space processes ... (elapsed 0.01 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. add wake up source irq 101 add wake up source irq 99 add wake up source irq 103 add wake up source irq 51 add wake up source irq 58 PM: suspend of devices complete after 15.482 msecs PM: late suspend of devices complete after 0.823 msecs Disabling non-boot CPUs ... CPU1: shutdown CPU2: shutdown CPU3: shutdown IMX PCIe imx_pcie_pltfm_suspend entering. IMX PCIe imx_pcie_pltfm_suspend exit.          suspended     U-Boot 2009.08-00679-g6ec6783 (May 20 2013 - 14:50:20)     resume   CPU: Freescale i.MX6 family TO1.2 at 792 MHz src 0x92eac8 resume 0x92eac8 jump to resume IMX PCIe imx_pcie_pltfm_resume entering. IMX PCIe imx_pcie_pltfm_resume pcie start re-link. IMX PCIe port imx_pcie_pltfm_resume: re-link up. Enabling non-boot CPUs ... CPU1: Booted secondary processor Calibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU1 is up CPU2: Booted secondary processor Calibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU2 is up CPU3: Booted secondary processor Calibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU3 is up PM: early resume of devices complete after 0.974 msecs remove wake up source irq 58 imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) imx-ipuv3 imx-ipuv3.1: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) remove wake up source irq 51 remove wake up source irq 103 remove wake up source irq 101 remove wake up source irq 99 PM: resume of devices complete after 54.174 msecs Restarting tasks ... done. PHY: 1:01 - Link is Up - 100/Full                            resume is ok, reload ep’s driver num is 61 e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2 e1000e: Copyright(c) 1999 - 2011 Intel Corporation. e1000e 0000:01:00.0: Disabling ASPM L0s e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI-X interrupts.  Falling back to MSI interrupts. e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI interrupts.  Falling back to legacy interrupts. e1000e 0000:01:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b e1000e 0000:01:00.0: eth1: Intel(R) PRO/1000 Network Connection e1000e 0000:01:00.0: eth1: MAC: 3, PHY: 8, PBA No: E42641-005 e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: seq=0 ttl=64 time=3.126 ms 64 bytes from 192.168.0.1: seq=1 ttl=64 time=0.244 ms 64 bytes from 192.168.0.1: seq=2 ttl=64 time=0.232 ms 64 bytes from 192.168.0.1: seq=3 ttl=64 time=0.206 ms 64 bytes from 192.168.0.1: seq=4 ttl=64 time=0.222 ms 64 bytes from 192.168.0.1: seq=5 ttl=64 time=0.207 ms 64 bytes from 192.168.0.1: seq=6 ttl=64 time=0.250 ms 64 bytes from 192.168.0.1: seq=7 ttl=64 time=0.209 ms 64 bytes from 192.168.0.1: seq=8 ttl=64 time=0.154 ms 64 bytes from 192.168.0.1: seq=9 ttl=64 time=0.211 ms   --- 192.168.0.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.154/0.506/3.126 ms PM: Syncing filesystems ... done.                                   ep’s functions are ok, re-do the suspend/resume tests Freezing user space processes ... (elapsed 0.01 seconds) done. -------------------------------end-------------------------------------------- Original Attachment has been moved to: 0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch.zip Original Attachment has been moved to: uboot_patch_image.zip Original Attachment has been moved to: kernel_patch_image.zip

Prerequisites: The build is verified on prebuilt rootfs(based on LTIB) which can be downloaded from freescale.com or built from Yocto fsl-image-gui These steps are performed on the host: 1. Download the git respository for qt5: $ git clone git://gitorious.org/qt/qt5.git qt5     cd qt5     Let us consider this as <QTDir> 2. Create a build directory to install for the qt5 packages. This directory can be  in any loctation. For example,  $ mkdir /opt/qt5 sudo chown -R <username> /opt/qt5 Let us consider the the installdir as /opt/qt5 3. Enter the Qt5 directory and run the perl init-repository script to download all the source code for    Qt5. To download all the source code will take about an hour. $ perl init-repository 4. Download the attached linux-imx5-g++.tar.gz and copy to  qtbase/mkspecs/devices. Will try to get updstreamed. 5. From the following path $ gedit qtbase/mkspecs/devices/linux-imx5-g++/qmake.conf   6. At the top of the qmake.conf, there is a configure line. Copy and paste the configure line into a text file located    in your build build directory. Edit the configure line to find your toolchain and filesystem. Also make sure to    include the options -no-pch, -no-opengl, -opengl es2, Here is an example of    a configure line.     $ cd <QTDir>     $ cd qtbase     $  ./configure -v -opensource -confirm-license -no-pch -opengl es2 -make libs -device imx5 \     -nomake examples -nomake demos \ -device-option CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-fsl-linux-gnueabi- \ -sysroot <rootfs> -no-gcc-sysroot \ -prefix <installdir> 7. Make the textfile that has the configure line and executable and run it. When the configure summary is shown make sure the Qt5    has openGL ES 2.0 support. Do build       $make     $make install    When Qt5 has finished building, Qt5 will be installed in two places:            1. <location of rootfs>/<installdir>            2. <HOST Machine>/<install dir> This is good because now all the libraries and binaries for Qt5 are installed on the host and the target filesystem. Therefore, the target already has all the libraries and  binaries needed to run Qt5. 8. Also need to build qtjsbackend and qtdeclarative.     $ cd <location to Qt5 git>     $ cd qtjsbackend     $ ../qtbase/bin/qmake -r     $ make && make install        $ $ cd <location to Qt5 git>     $ cd qtdeclarative     $ ../qtbase/bin/qmake -r     $ make && make install 9. Run Qt apps on target     - Boot the target either with NFS or SD Image     - Ensure that folder <installdir> is copied on target file system at “/usr/local”.     - Launch application using     $ cd /usr/local/qt5/examples/opengl/hellogl_es2     $ ./hellogl_es2 -platform eglfs

Overview The purpose of this document is to provide the patches to fix display mess issue in TextView based on MX6 Android R13.4-GA and R13.4.1 ICS release. Please note these patches are only validated basically for dedicated issues. If you find any side effect with these patches, please add the comments into this document. Issue Description Software: R13.4-GA or R13.4.1 Android releases Hardware: i.MX6Dual/Quad SabreSD board or i.MX6DualLite SabreSD board. Test steps: Install testviewtest.apk Run this APK and key in the text, you will see the text display mess after key in more texts. You can also get the issue descriptions from https://community.freescale.com/thread/303194 Patches You can get the patches from attached textview_fix.zip. For R13.4-GA, please apply the following patches: kernel_imx, unzip Kernel/r13.4-ga/kernel-patch-r13.4-ga-gpu4.6.9p10.tar.gz and apply the patches. device/fsl-proprietary/gpu-viv: unzip gpu_lib/gpu-viv-lib-4.6.9p10-font-libGAL-crash-fix.tar.gz and replace lib folder. For R13.4.1, please apply the following patches: kernel_imx, Apply the patch Kernel/r13.4.1/0001-upgrade-gpu-4.6.9p10-kernel-driver_r13.4.1.patc device/fsl-proprietary/gpu-viv: unzip gpu_lib/gpu-viv-lib-4.6.9p10-font-libGAL-crash-fix.tar.gz and replace lib folder.

This document is a simple guide on one of the ways in which 3D models can be loaded and displayed using OpenGL.   Requirements - Blender (open source) or a similar program that allows to export 3D models in the .obj format. We’ll be using Blender to export the .obj file with the essential information to draw the 3D model, without information on textures, for example. https://www.blender.org/   - i.MX6 Linux BSP image with X11 support – For this document we’ll use the L3.10.31 BSP, which is compiled using Yocto 1.6.You may use a newer BSP. We’ll use the fsl-image-gui. You may use a Qt5 image with X11 from newer BSPs. - GCC Toolchain -You may either cross compile on a Host or compile on the same board by providing the necessary libraries and toolchain. On the L3.10.31 you need to manually add GCC to your baked image. In newer releases this may not necessary. For adding the GCC package to a Yocto image and compiling within the board itself please add the following line to the conf/local.conf file inside your build directory. IMAGE_INSTALL_append += " gcc libgcc" If you wish to cross compile from your host and then run on your board you first will need to extract the toolchain from the BSP, which can be done by following the instructions of the next document: https://community.nxp.com/docs/DOC-95122  - FreeGLUT – FreeGLUT is an open source alternative to the OpenGL Utility Toolkit (GLUT), a window system independent toolkit for writing OpenGL programs. It implements a simple windowing application programming interface (API) for OpenGL. This is not necessary for drawing the model on the window but foes allow for functions such as rotating it. You may install it on your host with the following command: $ sudo apt-get install freeglut3-dev For additional information and downloads of FreeGLUT please refer to the projects website: http://freeglut.sourceforge.net/   - i.MX6D/Q/DL/S/SX GPU Demo Framework SDK – We’ll use the GPU Test examples which are available at the following link. Source code for this document implementation is attached but for more examples of OpenGL ES please refer to this SDK. (Please note that you may need to login in order to download this file) https://www.nxp.com/webapp/Download?colCode=FSL_GPU_SDK_2.3&appType=license&location=null&fpsp=1&WT_TYPE=Software%20Development%20Kits&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&fileExt=.zip&Parent_nodeId=1337637154535695831062&Parent_pageType=product   - i.MX6Q Board – For this example we will be using the i.MX6Q SABRE Board, but you may run OpenGL ES on any i.MX6Q board provided that you provide the necessary packages to support OpenGL ES.   Brief introduction to OpenGL ES? OpenGL is a software interface to hardware accelerated graphics. The API of this interface consists of about 150 distinct commands that allow you to specify objects and perform operations on them in order to produce interactive three-dimensional applications. OpenGL ES is the OpenGL implementation for Embedded Systems. Somei.MX6 Processors like the i.MX6Q possess a Vivante GPU module that runs on OpenGL ES. When using OpenGL or OpenGL ES all 3D objects are descripted as a series of triangles. This is important to mention as it will make the instructions we will need for describing our model make more sense.   Step 1 - Exporting a model as .obj You may import a 3D model from other sources or make your own simple 3D model in blender. For this example we’ll make a simple 3D NXP logo and export it. Once you have your model ready, select the object in objet mode with a right click. Once selected select File > Export > Wavefront (.obj) You may now select where and with what name to export the object file. On the left panel you will have the export options. It’s important to leave all options unchecked except for: Write Normals Include UVs Triangulate Faces (You may change the scale of your model and it won’t negatively affect the process)     The .obj model may be opened with a text editor and we’ll see that it basically describes the object as a series of parameters that may include vertex data, free-form curve/surface attributes, elements, free-form curve/surface body statements, connectivity between free-form surfaces, grouping and display/render attribute information. For our example we’ll be using a simple file that just contains: - List of geometric vertices, with (x,y,z) coordinates v 0.292475 0.017345 -0.152653 - List of vertex normals in (x,y,z) form vn 0.0000 1.0000 -0.0000 - Polygonal face element f 3//1 113//1 4//1   Step 2- Converting .obj to OpenGL compatible information We’ll be using the following program that allows to convert from .obj format to a format compatible with OpenGL as the conversion from one format to the other is not part of the scope of this document. https://fr.jeffprod.com/obj-to-opengl.php This program does more than just changing the format on the file and do perform some operations to translate the parameters of the .obj file to the following OpenGL ES information: static GLfloat v_triangles[] static GLfloat vt_triangles[] static GLfloat vn_triangles[] We’ll be using these variables and also the number of triangles which for this example is 1440. This can be found at the end of the file on the following line which effectively draws the complete triangle array: glDrawArrays(GL_TRIANGLES, 0, 1440);   Step 3 – Loading the model arrays to the .C program. You will need to copy the three GLfloat arrays to your OpenGL ES .C code. (You may alternatively use an include to have it more neatly organized but this is outside the scope of this document) In our example we’ll copy them inside void render (). Inside this function we’ll find the Draw Array instruction in which we must specify the number of triangles in our array. You may just replace your model information AND also change the number of triangles, otherwise you will receive an error when running the program.   glDrawArrays(GL_TRIANGLES,0,1440); We are using a simple rotation using glRotate and incrementing the value of rotation with each flush of the screen.     glRotatef(rlogo, 2.0f, 1.0f, 1.0f); The variable rlogo gets increased each time the screen is drawn. Depending on your model you may need to change the view in order to be able to see your model. This example uses a very small model so we have a viewpoint just 1.25 units away from the screen (Z axis). Depending on your model you may need to be further away in order to see the model on the screen. glTranslatef(0.0f, 0.0f, -1.25f);    Step 4- Compiling the OpenGL example For this simple example we will be using the examples from the GPU  as base an add the information of the model we have just exported. We’ll use the two attached files for this: Makefile.x11 – A make file with the dependencies and attributes necessary to compile our C file. NXPlogo.c – C file with the information of the model and instructions on to draw it on the screen. You can compile using the following commands to first clean in case you built before and then compiling the code. make –f Makefile.x11 clean make Makefile.x11 Once the program has compiled you can run it from the command prompt by using: export DISPLAY=:0.0 ./NXPlogo The result will be as follows, where the 3D model is rotating,     Additional Resources 2D and 3D Graphics in NXP Devices http://www.nxp.com/files/training/doc/dwf/DWF13_AMF_CON_T1025.pdf   i.MX6D/Q/DL/S/SX GPU Demo Framework SDK – Which provides the source code for the demo in which this example was built upon and also contains good documentation for those interested in OpenGL ES. https://www.nxp.com/webapp/Download?colCode=FSL_GPU_SDK_2.3&appType=license&location=null&fpsp=1&WT_TYPE=Software%20Development%20Kits&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&fileExt=.zip&Parent_nodeId=1337637154535695831062&Parent_pageType=product    OpenGL Redbook – Which is the most comprehensive book documenting and explaining the OpenGL API. http://www.opengl-redbook.com/

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-341473 

Overview i.MX28EVK Setup Build Yocto Project image Create a SDCARD from the Linux Host Boot i.MX28EVK Create file system on USB Create Mount Point and Mount the USB device Create 250 MB File Create Exports File Restart NFS Server Ubuntu Linux Host Setup Create Mount Directory Mount i.MX28EVK Exported Directory Access the NFS mounted directory Overview This document describes the steps for configuring a NFS Server running on an i.MX Application Processor - in this case the evaluation board i.MX28 EVK. Once the NFS server is running, an Ubuntu 12.04 Linux host is then configured to NFS mount the i.MX28EVK exported directory. The Ethernet interface is used for the connection transport. A block diagram of the connection setup is shown below: An Ethernet switch provided the Ethernet connection between the Linux Host and the i.MX28EVK. A thumb drive was connected to the USB port on the i.MX28EVK which was used for the exported directory. i.MX28EVK Setup Build Yocto Project image Use core-image-minimal and add packages to conf/local.conf to support NFS MACHINE=imx28evk source setup-environment mx28-evk echo "CORE_IMAGE_EXTRA_INSTALL += \"bash kernel-modules nfs-utils\" " >> conf/local.conf bitbake core-image-minimal When bitbake finishes the images are found in tmp/deploy/images/imx28evk Create a SDCARD from the Linux Host sudo dd if=/tmp/deploy/images/imx28evk/core-image-minimal-imx28evk.sdcard of=/dev/sdc bs=4M && sync Boot i.MX28EVK Insert the SDCARD into slot 0 on the bottom side of the i.MX28EVK and connect the serial console. Power-on and push the POWER button on the lower conner to turn on. The Login credentials are User Name: root      There is no password configured by default. Create file system on USB The USB drive had one partition which was formatted with vfat file system: mkfs.vfat /dev/sdb1 Create Mount Point and Mount the USB device mkdir /mnt/usb mount /dev/sdb1 /mnt/usb Create 250 MB File dd if=/dev/zero of=/mnt/usb/file1.txt bs=512K count=500 Create Exports File echo "/mnt/usb *(rw,sync,no_root_squash,no_subtree_check)" > /etc/exports Restart NFS Server /etc/init.d/nfsserver stop /etc/init.d/nfsserver start Ubuntu Linux Host Setup Create Mount Directory sudo mkdir /mnt/remote Mount i.MX28EVK Exported Directory sudo mount -t nfs 10.85.1.10:/mnt/usb /mnt/remote Access the NFS mounted directory ls /mnt/remote

With Qt5  you will find the addition of new technologies that will make your development much easier. Qtquick2 SceneGraph Qml Qt5 is backwards compatible,  that means you can run your Qt 4.8 applications, But that doesn't mean they will have the best performance, sometimes it is better to do a porting to use the newest features. Qt5, has two options to paint components into the screen. Painting in Qt 5 is primarily done either with: The imperative QPainter API Qt’s declarative UI language, QML, and its scene graph back-end. QPainter As this document mentions  Qt5GraphicsOverview | Qt Wiki | Qt Project  The Qpainter engine uses software to paint, and is used when drawing Qimages or Qwidgets. Its  advantage over OpenGL is the high quality when antialiasing is enabled, and a complete feature set. The Qpainter can use an OpenGL engine, but as the document mentions it is more suceptible to state changes. And has to be used carefully. QML & Scene Graph. All visual QML items are rendered using the scene graph, a low-level, high-performance rendering stack, closely tied to OpenGL. Qt Quick 2 makes use of a dedicated scene graph based on OpenGL ES 2.0 or OpenGL 2.0 for its rendering. Using a scene graph for graphics rather than the traditional imperative painting systems (QPainter and similar), means the scene to be rendered can be retained between frames and the complete set of primitives to render is known before rendering starts. This opens up for a number of optimizations, such as batch rendering to minimize state changes and discarding obscured primitives. The QML scene graph is a new back-end for QML in Qt 5, and is based on OpenGL. It generally improves the performance of QML significantly over the QPainter-based back-end used in Qt 4. It achieves better performance in a number of ways: The scene graph uses OpenGL directly instead of going though a QPainter which could be using either the raster or OpenGL paint engine. This means that all the resources, like geometry, textures and shaders can be stored in a format suitable for OpenGL rather than using classes such as QPainterPath, QPixmap, QBrush, or QPen, which the QPainter would need to translate into OpenGL primitives and possibly cache. QML, being a declarative language, defines how the end result should look like, but it doesn’t define how and in which order each individual element is drawn. The drawing can therefore be reordered to reduce the number of state changes, or merged to reduce the number of draw calls. The scene graph uses a separate render thread, and synchronizes the animations with the vertical retrace on platforms where this can be supported. The render thread allows the preparation of the next frame to be done at the same time the current frame is being rendered. This has a positive effect also on single-core systems, since the render thread might block on OpenGL commands. The synchronization with the vertical retrace improves the perceived smoothness of the animations. We have tested on i.MX6 Both options, having the best results using QML Qtquick2 elements. When we tried using QtPainter via Widgets we face the problem that if not using a windowing system like X11 or Wayland the painter wont work well and will only show the QtGLWidget. With QML scene graph we are able to have an OpenGL element and a Qt element on the same environment, and there is an easy way to communicate one with the other and share variables.  Please look at the example results here: I.MX6 scene graph Qt5 - YouTube And the great advantage, the sceneGraph is all accelerated via OpenGL.

For default Android JB4.3 GA1.1.0 BSP, iMX6SL EVK board doesn't support BlueTooth, attached is the patch for the BSP to support AR3002 bluetooth.   The hardware information can be found at: https://community.freescale.com/docs/DOC-95016   iMX6SL_EVK_BlueTooth_Patch_for_JB4.3_1.1.0.tar.gz: these are the patch files. iMX6SL_EVK_BlueTooth_Support_for_JB4.3_1.1.0.tar.gz: these are the patched source code files. Please select one of above to use.

Tested on imx28 EVK Rev. D. When plug-in or plug-out cable on eth0 port, eth1 port (and vice versa) will also be reset and the communication will be interrupted. Reason: Both Ethernet PHYs on EVK board share the same GPIO as their reset pin, in software the function name is mx28evk_enet_gpio_init. So any call to pdata->init() in fec.c will reset both PHY at the same time. In order to avoid such problem, you have to use 2 individual GPIO for the PHY reset.

Hello! Here's some CODE!!! #include <iostream> #include <stdio.h> #include <assert.h> #include <string.h> #include <fcntl.h> #include <malloc.h> #include <math.h> #include <stdlib.h> //#define EGL_USE_GLES2 #include <GLES2/gl2.h> #include <EGL/egl.h> #include <GLES2/gl2ext.h> #include <EGL/eglext.h> #include <termios.h> #include <unistd.h> #include <fcntl.h> #ifdef EGL_USE_X11 #include <X11/X.h> #include <X11/Xlib.h> #endif EGLDisplay egldisplay; EGLConfig eglconfig; EGLSurface eglsurface; EGLContext eglcontext; EGLNativeWindowType eglNativeWindow; EGLNativeDisplayType eglNativeDisplayType; EGLNativeDisplayType fsl_getNativeDisplay() {   EGLNativeDisplayType eglNativeDisplayType = NULL; #if (defined EGL_USE_X11)   eglNativeDisplayType = XOpenDisplay(NULL);   assert(eglNativeDisplayType != NULL); #elif (defined EGL_API_FB)   eglNativeDisplayType = fbGetDisplayByIndex(0); //Pass the argument as required to show the framebuffer #else   display = EGL_DEFAULT_DISPLAY; #endif   return eglNativeDisplayType; } EGLNativeWindowType fsl_createwindow(EGLDisplay egldisplay, EGLNativeDisplayType eglNativeDisplayType) {   EGLNativeWindowType native_window = (EGLNativeWindowType)0; #if (defined EGL_USE_X11)   Window window, rootwindow;   int screen = DefaultScreen(eglNativeDisplayType);   rootwindow = RootWindow(eglNativeDisplayType,screen);   window = XCreateSimpleWindow(eglNativeDisplayType, rootwindow, 0, 0, 400, 533, 0, 0, WhitePixel (eglNativeDisplayType, screen));   XMapWindow(eglNativeDisplayType, window);   native_window = window; #else   const char *vendor = eglQueryString(egldisplay, EGL_VENDOR);   if (strstr(vendor, "Imagination Technologies"))   native_window = (EGLNativeWindowType)0;   else if (strstr(vendor, "AMD"))   native_window = (EGLNativeWindowType)  open("/dev/fb0", O_RDWR);   else if (strstr(vendor, "Vivante")) //NEEDS FIX - functs don't exist on other platforms   { #if (defined EGL_API_FB)   native_window = fbCreateWindow(eglNativeDisplayType, 0, 0, 0, 0); #endif   }   else   {   printf("Unknown vendor [%s]\n", vendor);   return 0;   } #endif   return native_window; } void fsl_destroywindow(EGLNativeWindowType eglNativeWindowType, EGLNativeDisplayType eglNativeDisplayType) {   (void) eglNativeWindowType; #if (defined EGL_USE_X11)   //close x display   XCloseDisplay(eglNativeDisplayType); #endif } void GLInit (void) {   static const EGLint s_configAttribs[] =   {   EGL_RED_SIZE, 5,   EGL_GREEN_SIZE, 6,   EGL_BLUE_SIZE, 5,   EGL_ALPHA_SIZE, 0,   EGL_SAMPLES, 0,   EGL_NONE   };   EGLint numconfigs;   printf("1");   eglNativeDisplayType = fsl_getNativeDisplay();   printf("2");   egldisplay = eglGetDisplay(eglNativeDisplayType);   printf("3");   eglInitialize(egldisplay, NULL, NULL);   printf("4");   assert(eglGetError() == EGL_SUCCESS);   printf("5");   eglBindAPI(EGL_OPENGL_ES_API);   printf("6");   eglChooseConfig(egldisplay, s_configAttribs, &eglconfig, 1, &numconfigs);   assert(eglGetError() == EGL_SUCCESS);   assert(numconfigs == 1);   printf("7");   eglNativeWindow = fsl_createwindow(egldisplay, eglNativeDisplayType);   assert(eglNativeWindow);   printf("8");   eglsurface = eglCreateWindowSurface(egldisplay, eglconfig, eglNativeWindow, NULL);   assert(eglGetError() == EGL_SUCCESS);   printf("9");   EGLint ContextAttribList[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };   eglcontext = eglCreateContext( egldisplay, eglconfig, EGL_NO_CONTEXT, ContextAttribList );   assert(eglGetError() == EGL_SUCCESS);   printf("10");   eglMakeCurrent(egldisplay, eglsurface, eglsurface, eglcontext);   assert(eglGetError() == EGL_SUCCESS); } void GLEnd (void) {   printf("Cleaning up...\n");   eglMakeCurrent(egldisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);   assert(eglGetError() == EGL_SUCCESS);   eglDestroyContext(egldisplay, eglcontext);   eglDestroySurface(egldisplay, eglsurface);   fsl_destroywindow(eglNativeWindow, eglNativeDisplayType);   eglTerminate(egldisplay);   assert(eglGetError() == EGL_SUCCESS);   eglReleaseThread(); } int main (int argc, char **argv) {   GLInit();   for( int i = 0; i < 100000; ++i)   {   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);     // Clear The Screen And The Depth Buffer   glClearColor (.0f, .0f, 1.0f, 1.0f);   eglSwapBuffers (egldisplay, eglsurface);   }   GLEnd(); } Above code is stitched together from samples from GPU SDK. I've built an image using Yocto (dylan branch) and build the meta-toolchain-qt (and qte). Successfully managed to build above code ONLY FOR X11. Issues i am facing: 1) if build for X11 and run app on the board, window shows, but it stays white, when it should be BLUE...doesn't update no matter what color i glClear to. 2) when compiling with FB, fbCreateWindow and etc don't get recognized, i.e. undefined reference to `fbCreateWindow' .... WHAT header contains these functions???? 3) if even the basic samples don't work, how the hell is anybody supposed to build a GL application on this board?? --- more rhetorical than a real question, just frustrated here... what did i do wrong? 4) please show me a working tutorial or some code on how to get this EGL context initialized...i'm running at wit's end here...

1. Description     1) Support HDMI interlaced display mode, the followed format had been verified.         CEA format 5: 1920x1080i @60Hz         CEA format 6&7: 720(1440)x480i @60Hz         CEA format 20: 1920x1080i @50Hz         CEA format 21&22: 720(1440)x576i @50Hz     2) Support LCD interface for interlaced display mode, 1920x1080i @50Hz(CEA format 20)        had been verified. 2. File List -- 0001-IPUv3-support-interlaced-display-mode.patch    Patch to support interlaced display output for iMX6 ipuv3. -- 0002-iMX6-HDMI-support-interlaced-display-mode.patch    Patch to support interlaced display mode for iMX6 HDMI driver. -- 0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch    Patch to support interlaced display mode for iMX6 LCD interface driver.    -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - L3.0.35_4.1.0_GA_iMX6DQ kernel. 4. How to use -- Copy the patch files to kernel folder.     $ cd ~/ltib/rpm/BUILD/linux-3.0.35/     $ git apply ./0001-IPUv3-support-interlaced-display-mode.patch     $ git apply ./0002-iMX6-HDMI-support-interlaced-display-mode.patch     $ git apply ./0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch -- Build the new kernel image:     $ cd ~/ltib/rpm/BUILD/linux-3.0.35     $ export CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi-     $ export ARCH=arm     $ make imx6_defconfig     $ make uImage -- Uboot parameters for video mode    Output 1080i50 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1920x1080Mi@25,if=RGB24,bpp=32"    Output 1080i60 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1920x1080Mi@30,if=RGB24,bpp=32"    Output 576i50 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1440x576Mi@25,if=RGB24,bpp=32"    Output 480i60 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1440x480Mi@30,if=RGB24,bpp=32"    Output 1080i50 display mode on LCD interface:       "video=mxcfb0:dev=lcd,LCD-1080I50,if=RGB565,bpp=32"       -- Switch HDMI interlaced mode    $ echo S:1920x1080i-50 > /sys/class/graphics/fb0/mode    $ echo S:1920x1080i-60 > /sys/class/graphics/fb0/mode    $ echo S:1440x480i-50 > /sys/class/graphics/fb0/mode    $ echo S:1440x576i-60 > /sys/class/graphics/fb0/mode 5. Know issue     1) When the interlaced display and another display work on same IPU,        blank and unblank the interlaced display will get the followed IPU        warning, but the display still works due to IPU can revover from the error.     imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_5 = 0x00800000     imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00080000 2015-05-13 update: Replace the fourth patch to make interlace display mode follow CEA-861-specification The patch "0004-IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch" was fine tuned for CEA-861-D specification on interlaced mode display. Please use this patch to replace the old 0004 patch. 2016-05-20 Update: For 3.0.35 BSP, add patch 0005-IPU-update-interlaced-video-mode-parameters-to-align.patch      Align the interlaced video mode parameters to progressive mode. 0006-IPU-update-IDMAC-setting-for-interlaced-display-mode.patch      Udate the IDMAC setting for interlaced display mode, output odd field data from memory first, it aligns with IPU DI timing, odd field first. For 3.14.52 BSP, created the new patch L3.14.52_1.1.0_GA_HDMI_Interlaced_Mode_Patch_2016_05_20.zip.

Question: How to enable HAB on the MX28, following the recommendations of AN4555 to get the "get_hab_status()" function working, but has run into an issue. Question #1 They believe they have all the HAB components worked out that are inputs to the efltosb tool as they are able to successfully run U-boot to the interactive prompt.  However, at the point where they:     - call the rvt_report_status() function, their board says "### ERROR ### Please RESET the board ###".      - call the rvt_entry(), their board prints some garbage characters on the screen and then hangs. This suggests that there is something wrong with the clock that in turn affects the baudrate on the serial console causing the above behavior. Question #2 Is there a concept of a "Bound Signature" in HABv4 as there is in HABv3? Any chance the addresses for the rvt_ calls are incorrect? Can you provide the u-boot source? Either Bound signature verification or UID is never mentioned in the HABv4 Application Note. So I suppose it is not supported. We have made assumptions about the RVT function pointer offsets.  The HAB 4 API does not explicitly say the offsets but uses a rvt_base::function_name notation.  We have assumed that function pointers are placed in order, at every word offset beyond the RVT header.  We have confirmed the RVT header exists at the latest address in the reference manual based on a memory dump but we cannot be certain the function offsets we have setup are correct. As far as source code, we modeled our changes for our mx28 board off of the hab.c and hab.h files available from the mainline u-boot for the mx6 architecture. This is basically the same code get_hab_status code that is written in the AN4555 document.  We did HAB API function pointer addresses to match the updated RVT base address and assumed offsets. Answer: Here are the first 3 instructions from report_status(), could your customer check the instructions from the address which they called is correct? <report_status>: :   b087b570        addlt   fp, r7, r0, ror r5 :   1c0e1c05        stcne   12, cr1, [lr], {5} :   22182433        andscs  r2, r8, #855638016      ; 0x33000000

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343273 

Whenever possible is always better to avoid Virtual Machines when compiling Android as the building process might take several hours to even a day or two depending on the resources available to the Virtual Machine. Sometimes, however, a VM is the only option available and here are some useful considerations when using a VM as a host for Android builds. This document addresses some of the requirements for the Kit-Kat Freescale Android BSP although some may also apply to the general Android releases. It’s recommended to use Ubuntu 12.04 64-bits as Host OS. As for HDD space, which is often a limited resource when using VM, Google states that at least 30GB of disk space in order to build the Android Tree. In practice, however, it’s recommended to allocate at least 100GB to the VM HDD if possible, as additional packages and larger images can quickly deplete disk space. Installing Java (not VM specific) It’s recommended (albeit not mandatory) to uninstall any version of Java other than the recommended for the specific Android release for which we will build. In the case of Kit-Kat this is Java 6. Another option is to just switch the java alternatives to the ones we want to use for Android. There is a document with the exact instructions on how to install the required JKD on the following link. How to install Sun's JDK in Ubuntu for Android build Starting KitKat, however, it’s also necessary to install javap (Java Class File Dissasembler) so please also add these steps when following this document. $ sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk1.6.0_45/bin/javac 1 $ sudo update-alternatives --config javac Memory considerations when using a Virtual Machine Using a Virtual Machine slows down the image building considerably. Besides that memory system is often also an issue. Having insufficient RAM especially on the linking part of the image build may cause a number of issues that are difficult to troubleshoot. In these cases it’s good to take a look at the resource monitor to see if indeed the RAM was depleted. One way to make up for the limited RAM is using a bigger swap. Google recommends at least 16GB of RAM/swap so it’s not uncommon to create a 10GB swap when working in VM, to do this please use the following commands. $ sudo fallocate -l 10g /mnt/10GB.swap $ sudo chmod 600 /mnt/10GB.swap $ sudo mkswap /mnt/10GB.swap $ sudo swapon /mnt/10GB.swap This will helps with the memory requirements but won’t speed up the build process. Building time with VM, as previously stated, will take several hours or even a couple of days depending on computing power.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-344336 

Here is a quick summary at booting Linux on the i.MX 6 sabre sd platform. This assumes you already have u-boot working on your platform as described here. This implies you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). Get Linux sources We will use git to fetch Linux sources:   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git This should create a linux directory with all the latest sources (after a while). Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l 'v*', and git checkout <the-desired-tag>. Compile Assuming your cross compiler is called e.g. arm-linux-gnueabihf-gcc, you can compile by doing:   $ cd linux   $ export ARCH=arm   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make imx_v6_v7_defconfig   $ make You then need to supply a LOADADDR (as joowonkim pointed out); do:   $ make uImage LOADADDR=0x10008000 This should create a number of files, including arch/arm/boot/uImage and arch/arm/boot/dts/imx6q-sabresd.dtb. Put on SD We need a proper FAT partition on the SD card, from which u-boot will be able to load the kernel and dtb. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout:   +-----+------+--------+-----+----------------   | MBR |  ... | u-boot | ... | FAT partition ...   +-----+------+--------+-----+----------------   0     512    1024           1M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk:   Device    Boot      Start         End      Blocks   Id  System   /dev/sdc1            2048     8054783     4026368    c  W95 FAT32 (LBA) (units: 512B sectors) You can format the FAT partition, mount, copy and unmount with:   $ mkfs.vfat /dev/<your-sd-card-first-partition>   $ mount /dev/<your-sd-card-first-partition> /mnt   $ cp arch/arm/boot/uImage arch/arm/boot/dts/imx6q-sabresd.dtb /mnt/   $ umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or /dev/mmcblk<X>p1. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. Also, be sure to have u-boot on the SD card as explained in this post. Boot! That's it; u-boot already knows how to deal with your kernel by default so you are good to go. Insert the SD card into the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. You should see u-boot messages:   U-Boot 2013.07-rc1-00014-g74771f4 (Jun 21 2013 - 16:27:39) u-boot should load the uImage and dtb from SD card and boot the kernel:   (...)   reading uImage   4215344 bytes read in 449 ms (9 MiB/s)   Booting from mmc ...   reading imx6q-sabresd.dtb   22818 bytes read in 22 ms (1012.7 KiB/s)   ## Booting kernel from Legacy Image at 12000000 ...      Image Name:   Linux-3.10.0-rc6      Image Type:   ARM Linux Kernel Image (uncompressed)      Data Size:    4215280 Bytes = 4 MiB      Load Address: 10008000      Entry Point:  10008000      Verifying Checksum ... OK   ## Flattened Device Tree blob at 11000000      Booting using the fdt blob at 0x11000000      Loading Kernel Image ... OK   OK      Using Device Tree in place at 11000000, end 11008921   Starting kernel ... The kernel should boot:   Booting Linux on physical CPU 0x0   Linux version 3.10.0-rc6 (vstehle@debian) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Fri Jun 21 18:09:26 CEST 2013 By default, the kernel will try to mount a root filesystem from the SD card second partition, as can be read in the default kernel command line:   (...)   Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw ...but we did not prepare a root filesystem partition, so after a number of boot messages the kernel will wait indefinitely:   (...)   mmc1: new SDHC card at address b368   (...)    mmcblk0: p1   (...)   Waiting for root device /dev/mmcblk1p2... We will see in another post how to prepare this root filesystem on the second SD card partition. Enjoy! See also... If you plan to compile Linux often, you might want to use a C compiler cache; see this post. Once you have Linux booting on your platform the next step is to give it a root filesystem. See this post for a Debian root filesystem, this post for a minimal busybox filesystem and this post for generating a root filesystem with buildroot.

This is a tool can generate LPDDR3 script easily for i.MX6SLL.

Gst-entrans.spec GStreamer gst-inspect Tool GStreamer gst-launch Tool i.MX27 Video GST Caps i.MX27 ADS Board Video GST Play i.MX27 ADS Board Video GST Encode Gst-inspect mfw vpuencoder 1109 2.0.2 GStreamer Miscellaneous GStreamer i.MX6 Decoding GStreamer i.MX6 Multi-Display GStreamer i.MX6 Encoding GStreamer i.MX6 Image Display GStreamer i.MX6 Camera Streaming GStreamer i.MX6 Image Capture GStreamer i.MX6 Multi-Overlay GStreamer i.MX6 Pipelines GStreamer ffmpeg GStreamer Streaming GStreamer Transcoding and Scaling Testing GStreamer Tracing GStreamer Pipelines Useful Gstreamer Commands Using a USB Camera with GStreamer