Q: What is i.Mx6 ECSPI max frequency? https://community.freescale.com/message/338305 But in the RM we clearly state 60 MHz is the default config while Boot from SPI. I cannot measure it because I have no board where I can boot from SPI Nor. Also if I look at clocking, PLL  is 480MHz divided by 8 is fixed thus we get 60 MHz. Next divider can be either 1, thus ECSPI_CLK_ROOT  = 60MHz or 2, thus ECSPI_CLK_ROOT = 30 MHz. A: From i.MX6 Datasheet (IMX6DQCEC, Rev. 2.3, 07/2013), Table 52 (ECSPI Master Mode Timing Parameters) : ECSPIx_SCLK Cycle Time–Read • Slow group                                        55 ns • Fast group                                        40 ns         ECSPIx_SCLK Cycle Time–Write          15 ns So, only for writing we can get ~60 MHz.

Q: Q&A: Where to find IBIS Models on the web? A: In the first figure (FSL driving 100 ohm), the processor is DC coupled to a transmission line and terminated at the far end with a 100-ohm resistor. The results look pretty normal for this. In the other figure, the processor is dc coupled to a transmission line, then ac coupled to another transmission line segment (0.1u) with 50-ohm resistors to ground, and then drives the inputs of an HCSL clock buffer. The results are pretty un remarkable. The top red signal in the trace is one of the IMX6 clock outputs, the first green signal is the other clock output, and the last green signal (from top to bottom that is) is the differential signal seen by the clock buffer. The customer is concerned about the asymmetrical drive of the processor. It looks like LVDS clock outputs do not like to be AC coupled. This simulation resembles the way the clock is handled in the Smart Device schematics where the clock is AC coupled to the reference clock inputs on the PCIE connector. The ibis files were downloaded from the web (21x21_imx6q, consumer variant). So a few updates: I had the customer download the latest duallite IBIS models. Previously they were apparently using the quad/dual models. They are going to update HyperLynx and are going to run a simulation and let me know if they still see the same issue. He said he's using "linesim". Meanwhile he noticed a different problem with the duallite/solo IBIS models. Although the datasheet says LVDDR3 (1.35V) is supported, there is no model for DDR3_L either as input or output. The same model existed in the quad/dual models. Do you know why this option is not in the duallite IBIS models? Thanks! A ctm of mine would like to get the IBIS model with LVDDR3 support on the i.MX6 DL. For mx6-duallite IBIS models for DDR3L memory (1.35V). It'd be great if the models matched the quad version. Please find the new updated IBIS file in website. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6DL&nodeId=018rH3ZrDRB24A&fpsp=1&tab=Design_Tools_Tab

It is suggested to create a layer when creating or modifying any metadata file (recipe, configuration file or class). The main reason is simple: modularity. Follow these steps 1. To have access to Yocto scripts, setup the enviroment from the BASE folder fsl-community-bsp $ . setup-environment build 2. Move to the place you want to create your layer and choose a name (e.g. `fsl-custom`) sources $ yocto-layer create fsl-custom # Answer the questions. Make sure the priority is set correctly (higher numbers, # higher priorities). Set the priority equal to the lowest already present, except # when you have introduce a new recipe with the same name as other and want to shadow # the original one. 3. Add any metadata content. Suggestion: Version the layer with Git and upload your local git repo to a server 4. Edit and add the layer to the `build/conf/bblayers.conf` file 5. To verify that your layer is *seen* by BitBake, run the following command under the build folder build $ bitbake-layers show-layers This document was generated from the following discussion: i.MX Yocto Proyect: How can I create a new Layer?

Q: Some background; this instrument has one display connected to the LVDS output of the i.MX6Solo and the SVGA monitor is using the IPU port with an external Analog Devices ADV7125 DAC to actually drive the monitor (or projector).  From Tektronix: We got our kernel logo to show up on an external SVGA monitor as well as on the internal LVDS display so we now at least know that the hardware is functional. However, when our application starts running and writing to the fb0 (background) and fb1 (foreground/overlay) frame buffers, the external monitor (fb2 frame buffer) doesn't get updated. We need to know how to get the same data going to the external monitor as goes to the internal LVDS display.  the external monitor is 800x600 and the internal is 800x480 so we'd further like those 480 lines to show up centered in the 600 line monitor. We are also hoping that this can be down without having to write/DMA all of the data twice. The answer given is SR #1122663812 was "If the customer is using Linux, fb2 should also be drawed by their application."  This was considered in adequate and Tek replied: I would like to know if they are saying that the IPU absolutely cannot automatically do what we want and if not, why not?  I would like to have some detailed information to at least convince us that they've looked into this and it really isn't possible. A: In our Linux BSP we don't support such feature. And in android BSP it was already supported. The customer must draw the fb2 by their application, ipu doesn't have the feature that combining the fb0 and overlay fb1, then resize it to fb2 automatically. The customer application can drawing their UI into a memory, then use v4l2 output to draw this buffer to both fb0 and fb2, in this case, resizing will be implemented in V4l2 output driver with IPU hardware. And if the customer needs overlay on fb2, they must combine the two layer into memory with IPU task first, then using V4l2 output to render it to display fb2. For how to use IPU task, the customer can reference to BSP unit test code: imx-test-1.1.0\test\mxc_ipudev_test The summary: for dual display case, the fb0 and fb2 are just two framebuffer memory, they must be filled before rendering to display, on iMX6S/DL, only the fb0 has the hardware overlay (fb1); if the customer wants to show same contents on two displays in Linux, their application must draw the two framebuffers, but we had some hardware method to improve the performace, using GPU or IPU task. In Android, the application will not draw frame buffer directly, it will use Android surface flinger middleware to draw, so this feature was implemnted in surface flinger; but in Linux, there is no such middleware, and application draws the framebuffer directly, so the application should handle it. This document was generated from the following discussion: i.MX6Solo LDB/LVDS & LCD Ports Active Simultaneously

Q: i.Mx53 and a kernel based on our latest Linux BSP (Kernel Version 2.6.35) – They do see problems when mounting SATA Disk which is used for their rootfs. Has anyone seen this before? I am just wondering if the upcoming release might address and fix this? From the MCU i MX Product Update Call_May 2013.ppt presentation i.MX53  external release June 30 th 2013, freescale.com •       There will be patches/features for i.MX53 including Yocto for this kernel  L2.6.35 BSP release •       Validation testing Where can I check which patches / features are in this release? Is there already a Release Note? this is the kernel for the legacy release: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain The main proposal for the next legacy release is not upgrade kernel, is only make a yocto release. And if you take meta-fsl-arm on master you will find everything from legacy release. I upstreamed every change I made internaly A: Rootwait is in the command line. Please note they can boot with Kernel version 3.2 - but customer requires 2.6.35 Kernel for other reasons. Please find attached the log files I received. A text bootlog (note sometimes booting works) but it is not stable and reliable on 2.6.35 - same HW seems stable on 3.2 Kernel Regarding to the failed messages contained in customer's log, it's a random issue. SATA driver reports that there is an " SError: { DevExch }" on the PHY connection. It seems that the SATA PHY connection is not stable enough. Can you make a double check on the cable connection and the power supply? You can disable the following configuration when build the 2.6.35 kernel image config SATA_AHCI_FSL_NO_HOTPLUG_MODE         bool "Freescale i.MX SATA AHCI NO HOTPLUG mode"         depends on SATA_AHCI_PLATFORM != n         default n         help           In order to decrease the pwr consumption, release the CLK resources such as usb_phy1_clk, when there is no SATA device adaptored into the AHCI SATA port. The HOTPLUG feature can't be enabled in this situation. Please disable this option if the HOTPLUG is mandatory required.           If unsure, say N. ============================ BTW, I just verified the RFS on SATA on i.MX53 LOCO. It's ok. Here is the log: Starting kernel ... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.35.3-01275-ge6b3f3b (r65037@shlinux1) (gcc version 4.7.3 20121001 (prerelease) (crosstool-NG hg+-946d6d133a90) ) #52 PREEMPT Tue Jul 30 11:27:17 CST 2013 CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7d CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Freescale MX53 LOCO Board Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 250880 Kernel command line: noinitrd console=ttymxc0,115200 root=/dev/sda1 rootwait rw ... mxc_rtc mxc_rtc.0: setting system clock to 1970-01-01 00:00:01 UTC (1) Waiting for root device /dev/sda1... ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-8: SanDisk SSD P4 32GB, SSD 8.00, max UDMA/133 ata1.00: 62533296 sectors, multi 1: LBA48 ata1.00: configured for UDMA/133 ata1: EH complete scsi 0:0:0:0: Direct-Access     ATA      SanDisk SSD P4 3 SSD  PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk VFS: Mounted root (ext2 filesystem) on device 8:1. Is there a possibility to tweak timing parameters? Maybe that could help to get it more robust? Are there other parameters we can try to play with and could explain failing Sata RFS on some i.Mx53 boards? I got more info from customers and also "hints" to other forum entries realted to that problem. http://lists.debian.org/debian-arm/2012/03/msg00059.html http://debian.2.n7.nabble.com/Linux-2-6-35-3-Kernel-for-ARM-and-SATA-problems-td1664800.html """ Linux version 2.6.35.3-mx53qsb (mike@ubuntu) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #3 PREEMPT Sat Mar 17 15:34:48 PDT 2012 CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Freescale MX53 LOCO Board ... ata1: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 28 ... ata1: SATA link down (SStatus 1 SControl 300) ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen t4 ata1: irq_stat 0x00000040, connection status changed ata1: SError: { DevExch } ata1: hard resetting link ata1: SATA link down (SStatus 1 SControl 300) ata1: EH complete """ http://www.raspberrypi.org/phpBB3/viewtopic.php?f=9&t=4256&start=175 As mentioned custoemr sees simlar problems with our test image. Maybe one way to check, can you provide me our u-boot and uImae you did the test with? Customer confirmed their HW is compatible with MX53 LOCO Board so I would like to make sure they use correct SW and use what you tested. A bit strange is also that this Problem shows never up on a 3.2 based kernel. However the end customer requires to stay on 2.6.35 for other reasons. - kernel 3.2 which is able to initialize always. - protocol logs for good and bad case trans -p uImage.mx5.35 File keyword is ngbl7927a Data transfer to Austin Transcend repository started.   File size is 2.94 MB. Transfer Method:  Serial with no encryption. File 'uImage.mx5.35' (size 2.94 MB) transcended. Retrieve the file with the keyword:  ngbl7927a TransWeb URL:  http://transweb.freescale.net/index.cgi?go=KEYWORD&KEYWORD=ngbl7927a This file will be deleted in three working days. Local Deletion Time:  Thu Aug 15 23:51:16 2013 CST Greenwich Mean Time:  Fri Aug 16 04:51:16 2013 GMT I know that i.MX53 SATA doesn't have the adjust-window like the adjust window contained by i.MX6Q SATA. As I know that we didn‘t release 3.2 kernel version BSP, right? Regarding to the experience of ”http://debian.2.n7.nabble.com/Linux-2-6-35-3-Kernel-for-ARM-and-SATA-problems-td1664800.html”, it seems that the updates of the SATA stack of Linux level up the timing-compatibility of SATA. Derived from the URL listed above. ”I did trace the problems I having to the ahci code in the kernel not properly handling an ahci CONINIT event generated by my WD5000BEVT drive.  Seems this drive has extra SATA features implemented so that it can be used in hot-plug arrays and these features aren't recognized by the kernel driver so it just seems to shut down the drive and ignore it.  The other SATA drive that I do have working with the kernel doesn't implement the extra features so the kernel is happy.  Presumably these problems were fixed in later kernels and the patches didn't make it into Freescales 2.6.35.3 branch. On the other hand, the kernel might be fine and the firmware in the drive isn't conforming to the ahci specs, but I think that wold cause problems with the drive on other systems. ” This document was generated from the following discussion: i.MX53 Sata rootfs problem

Q: How to get the CSI BT656 without HSYNC/VSYNC working. The problem, is that all implemented driver in the BSP are using the external HSYNC/VSYNC synchronization signal. The SW designer is actually struggling to find the right way to generate the end of field active interrupt (end of frame). > mxc_v4l2_still.out I get an: > ERROR: v4l2 capture: mxc_v4l_read timeout counter 0 > > When using mxc_v4l2_capture.out or mxc_v4l2_tvin.out I get an: > ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0 > To help him implementing the driver, I need to get some insight on the IPUx_CSIn_CCIR_CODE_1/2/3 as it seems that the bit description 21 to 19 (CSI_STRT_FLD0_ACTV) is not described (same for all the multiple bit field in this register. Maybe it should match the ITU656, but here as well the driver examples does not match the bit description of the ITU standard. So my questions: IS it really possible to implement the BT656 with SAV / EAV and without external HSYNC/VSYNC? If yes, is it possible to review the IPUx_CSIn_CCIR_CODE_1/2/3 fields and communicate which parameter should be provided here? i.MX6Q A:      For no VSYNC and HSYNC case, in the sensor driver such as "linux-3.0.35\drivers\media\video\mxc\capture\adv7180.c", function ioctl_g_ifparm(), you should set p->u.bt656.bt_sync_correct to 0;      p->u.bt656.bt_sync_correct = 1; // It means external VSYNC and HSYNC will be used for SYNC.      p->u.bt656.bt_sync_correct = 0; // No external VSYNC and HSYNC, embedded EAV and SAV will be used for SYNC.      In iMX6 BSP, the CCIR related code is ready in "linux-3.0.35\drivers\mxc\ipu3\ipu_capture.c", function ipu_csi_init_interface(), no code modification was needed, that code was verified work.      For BT656 mode, your sensor driver such as adv7180, should also report correct parameters in function function ioctl_g_ifparm().      p->u.bt656.clock_curr = 0;  // This will tell linux-3.0.35\drivers\media\video\mxc\capture\mxc_v4l2_capture.c to use "IPU_CSI_CLK_MODE_CCIR656_INTERLACED" in function mxc_v4l2_s_param().      The current iMX6 BSP mxc_v4l2_capture.c driver doesn't support BT656 progressive mode, it only supports BT656 interlace mode. To support BT656 progressive mode, the customer should modify the code in mxc_v4l2_s_param(), let csi_param.clk_mode = IPU_CSI_CLK_MODE_CCIR656_PROGRESSIVE. This is exactly what they are doing, but still it doesn’t work. Actually, they see the code being executed following the right steps in the ipu_csi_init_interface() going through PAL 720x625 configuration. But still, they get the timeout! else if (cfg_param.clk_mode == IPU_CSI_CLK_MODE_CCIR656_INTERLACED) {       if (width == 720 && height == 625) {         /* PAL case */         /*         Field0BlankEnd = 0x6, Field0BlankStart = 0x2,         Field0ActiveEnd = 0x4, Field0ActiveStart = 0           */         ipu_csi_write(ipu, csi, 0x40596, CSI_CCIR_CODE_1);         /*         Field1BlankEnd = 0x7, Field1BlankStart = 0x3,         Field1ActiveEnd = 0x5, Field1ActiveStart = 0x1           */         ipu_csi_write(ipu, csi, 0xD07DF, CSI_CCIR_CODE_2);         ipu_csi_write(ipu, csi, 0xFF0000, CSI_CCIR_CODE_3); So, I believe the parameters are wrong. What could be missing. Can you review the driver? For me it looks like the adv example, except the bt_sync_correct=0, which is what we want. You can suggest the customer to capture the CSI data bus to check if there is correct output from sensor, such as EAV/SAV. For the "timeout" error, it always means there is no correct data on CSI data bus. This document was generated from the following discussion: CSI BT656

$ ~/dylan/sources$ find -name *image*.bb ./meta-fsl-demos/recipes-fsl/images/fsl-image-gui-sdk.bb ./meta-fsl-demos/recipes-fsl/images/fsl-image-test.bb ./meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb ./meta-fsl-demos/recipes-qt/images/qt-in-use-image.bb ./meta-fsl-demos/recipes-qt/images/qte-in-use-image.bb ./meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb ./meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-image.bb ./meta-openembedded/meta-oe/recipes-support/imagemagick/imagemagick_6.7.5.bb ./meta-openembedded/meta-oe/recipes-multimedia/libsdl-image/libsdl-image_1.2.12.bb ./poky/meta-hob/recipes-core/images/hob-image.bb ./poky/meta-skeleton/recipes-multilib/images/core-image-multilib-example.bb ./poky/meta/recipes-devtools/mkelfimage/mkelfimage_svn.bb ./poky/meta/recipes-sato/images/core-image-sato-dev.bb ./poky/meta/recipes-sato/images/core-image-sato.bb ./poky/meta/recipes-sato/images/core-image-sato-sdk.bb ./poky/meta/recipes-qt/images/qt4e-demo-image.bb ./poky/meta/recipes-core/images/core-image-minimal.bb ./poky/meta/recipes-core/images/core-image-base.bb ./poky/meta/recipes-core/images/core-image-minimal-dev.bb ./poky/meta/recipes-core/images/core-image-minimal-initramfs.bb ./poky/meta/recipes-core/images/build-appliance-image.bb ./poky/meta/recipes-core/images/core-image-minimal-mtdutils.bb ./poky/meta/recipes-extended/images/core-image-lsb-sdk.bb ./poky/meta/recipes-extended/images/core-image-basic.bb ./poky/meta/recipes-extended/images/core-image-lsb-dev.bb ./poky/meta/recipes-extended/images/core-image-lsb.bb ./poky/meta/recipes-graphics/images/core-image-directfb.bb ./poky/meta/recipes-graphics/images/core-image-x11.bb ./poky/meta/recipes-graphics/images/core-image-clutter.bb ./poky/meta/recipes-graphics/xcb/xcb-util-image_0.3.9.bb ./poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2013.01.01.bb ./poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb ./poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.03.bb ./poky/meta/recipes-rt/images/core-image-rt-sdk.bb ./poky/meta/recipes-rt/images/core-image-rt.bb Those are all available images. And note that, available images from poky and meta-fsl-arm only. As you may imagine, several other layers can be included, and any new layer can provide new images. If you look line by line, you can see that some of that files are not images, for example u-boot-mkimage_2011.06.bb but you got the message. Yocto Project (and meta-fsl-demos) provides some "pre baked" images. In my point of view, those images are not to be used on your product. They are examples and quick starting points. When you desire a pie, you can go to supermarket and buy a frozen chocolate pie. But when you´re developing a pie to be the Apple Salted Caramel with Dark Chocolate Cinnamon Topping you need to decide every piece of this pie. What is the base, which type of apple to use. How much salt on caramel. This is your product, your pie, not a frozen standard pie. I know the analogy is kind of dumb. But it´s important to understand that the "pre baked" images provided by Yocto Project, or meta-fsl-demos are not supposed to become a product image! You can (and maybe should) base your image on some of those images, but they are not good enough to your product. I highly recommend you to have your own image file. The pre-baked images I´m used with are core-image-minimal I use to image name I use it when/for Formal description core-image-minimal testing machine support; uboot support/upgrade; kernel support/upgrade A small image just capable of allowing a device to boot. core-image-base when I need to add something like ssh/dropbear or evtest or usb utils. I always configure this on local.conf to add the desired package. A console-only image that fully supports the target device hardware. core-image-x11 when I need to test X11 accelerated by GPU, or I need to have X11 for any test. A very basic X11 image with a terminal core-image-direcftb when I debug directfb GPU support An image that uses DirectFB instead of X11. core-image-weston when I debug Wayland GPU support A very basic Wayland image with a terminal fsl-image-test when I need to test VPU with and without gstreamer. - fsl-image-gui when I need to have QT, or I want to build everything altogether. Although I´ve been preferring the smaller images instead. - meta-toolchain To have the crosscompiler installed on my machine to manually build u-boot and kernel, when I´m changing it Meta package for building a installable toolchain All those images DO NOT include -dev packages or native build. If you want it you MUST configure your local.conf. Although, you can find special images that provides the header files or the native compiler. The images with -dev sufix include the header files (and development files) from all packages. For example: core-image-minimal-dev ( A small image just capable of allowing a device to boot and is suitable for development work. ) The images with -sdk sufix include the native build tools. For example core-image-sato-sdk ( Image with Sato support that includes everything within core-image-sato plus meta-toolchain, development headers and libraries to form a standalone SDK. ) *all formal description was copied from poky source code (poky - Poky Build Tool and Metadata) Please, go back to Yocto Training - HOME

I.MX6 CoreBoard Computer On Module • Processor Freescale i.MX 6Quad, 1GHz • RAM 1GB DDR3 SDRAM 64-bit • ROM 4GB NAND Flash    UP to 16GB • ROM 2M SPI Nor Flash • Power supply Single 5V • Size 40mm SO-DIMM • Temp.-Range     0 to + 95C (Consumer)               -20 to + 105C (Extended Consumer)               -40 to +105C (Industrial)               -40 to + 125C (Automotive) Key Features • 10/100Mbps Ethernet • One High Speed USB 2.0 ports • Full HD LCD controller, 24bpp • OpenGL ES 2.0 and OpenVG 1.1        hardware accelerators • Multi-format HD 1080p60 video decoder and 1080p30 encoder hardware engine • Two Camera Interfaces • NEON MPE coprocessor — SIMD Media Processing Architecture — dual, single-precision floating point execute pipeline • Unified 1MB L2 cache • Several interfaces: 5x UART, 2x SDIO, 1x SSI/AC97/I2S, 3x I2C, 2xCSPI • 3.3V I/O • 2x Controller Area Network (FlexCAN) • PCIe 2.0 (1-lane) LVDS Option only: • Dual LVDS display port • SATA OS Support • Linux • Android

Hi, the document "how to create ubuntu hardfloat rootfs for imx6d/q" was shared by Junping Mao. https://community.freescale.com/docs/DOC-95387 Here, i build the OpenCV based on the ubuntu hardfloat rootfs for i.MX6Q sabre board. Details about building instruction pls refer to the attachment. Thanks! 

Hi, The document "How to create ubuntu hardfloat rootfs for imx6d/q" was shared by Junping Mao. https://community.freescale.com/docs/DOC-95185 However, some modification need to be made to build imx-tests on this rootfs. Attached please find the guide for building imx-tests on hf-ubuntu rootfs for imx6d/q. Any problems, pls feel free to let me know. Regards, Alvin zheng

LTIB does not support X11 acceleration, since the packages are too old. Ubuntu 11.10 prebuilt image part of i.MX6 BSP has Xorg version 1.10.4. Yocto 1.4 has Xorg version 1.11.4. This document is based on Yocto 1.4.1 yocto and Freescale BSP 3.5.7 Alpha release. Few simple steps to enable 1.14.0. 1. Let us consider your Yocto directory is  $(rootfs_builder) 2. Edit vi sources/meta-fsl-arm/conf/machine/include/imx-base.inc      PREFERRED_VERSION_xserver-xorg_mx6 = "2:1.14.0" 3.Edit vi sources/meta-fsl-bsp-release/imx/meta-fsl-arm/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_3.5.7-1.0.0.bb      SRC_URI = "${FSL_MIRROR}/xserver-xorg-video-imx-viv-${PV}.tar.gz \            file://Makefile-fix-cross-compile.patch \                    file://0001-add-compat.h.patch" 4. Copy the attached Makefile-fix-cross-compile.patch into sources/meta-fsl-bsp-release/imx/meta-fsl-arm/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/. 5. In the build directory, delete the tmp directory. Otherwise there will be build errors (I did not found easy way) 6. bitbake fsl-image-x11 7. Now the image is ready to flash. 8. Boot the board with the newly built image. 9. Check the Xorg version log in /var/log/Xorg.0.log. It will be 1.14.0. 10. Before executing any of the X11-EGL application, export VIV_DESKTOP=0 to the terminal. You can see the application running. There are some known issues related to performance in 3.5.7 Alpha release.

The instructions is based on building wayland-weston on Ubuntu prebuilt image. The same can be applied to other build systems as well. PREREQUISITIES The following is the software environment required: - Ubuntu Oneiric (11.10) distribution. (Download Pre-built Ubuntu demo image from www.freescale.com/imx6) - Wayland/Weston : Wayland dependencies are listed in http://wayland.freedesktop.org/building.html. - 0001-DRM-condition.patch and 0002-Enable-weston-for-Vivante-GPU.patches for Weston. WAYLAND VERSION This release is based on Wayland 1.1.0 version. BUILDING The steps are based on wayland building from http://wayland.freedesktop.org/building.html. Download wayland-1.1.0.tar.xz from http://wayland.freedesktop.org/releases.html    3. Setting up the environment. This need to be performed on the target $export WLD=/usr $export LD_LIBRARY_PATH=$WLD/lib $export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/ $export ACLOCAL="aclocal -I $WLD/share/aclocal"        Also, create the 'share/aclocal' directory.                $mkdir -p $WLD/share/aclocal       Let us consider, extracting the package to /opt $cd /opt $tar xvvf wayland-1.1.0.tar.xz $cd wayland-1.1.0 $ ./configure --prefix=$WLD --disable-documentation $ make $ make install   4. Setting up GPU-VIV graphics drivers The GPU-VIV graphics drivers are available as part of BSP release. Get the gpu-viv-wl-bin-mx6q-{VER}.tar.gz for 4.0.0 release gpu-viv-wl-bin-mx6q-3.0.35-4.0.0.tar.gz from the BSP-Source/pkgs Extract to the target $ROOTFS The prebuilt root file system (rootfs) may come with prebuilt GPU driver. By default, it may set to EGL framebuffer. To enable Wayland/Weston support, make EGL and GAL point to correct binaries as shown below: $ ls –l $(ROOTFS)/usr/lib/libEGL.so* libEGL.so -> libEGL-wl.so libEGL.so.1 -> libEGL-wl.so $ ls –l $(ROOTFS)/usr/lib/libGAL.so                            libGAL.so -> libGAL-wl.so   5. Build the libxkbcommon as in http://wayland.freedesktop.org/building.html 6. We will need Cairo stack as Weston clients depend on Cairo for rendering. Please build Cairo as described in http://wayland.freedesktop.org/building.html, but note that, for now, we do not enable gl backend for Cairo, so the '--enable-gl --enable-xcb' flags must not be used when building. 7. Building Weston     Now add the following environment settings in the terminal window. (Note the "`"- backtick - character). export WLD=/usr export LD_LIBRARY_PATH=$WLD/lib export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/ export ACLOCAL="aclocal -I $WLD/share/aclocal" export LD_LIBRARY_PATH="/usr/lib" export LDFLAGS="-lwayland-server -lwayland-client -lwayland-server -lwayland-cursor -lpixman-1" export COMPOSITOR_LIBS="-lGLESv2 -lEGL -lGAL -lwayland-server -lxkbcommon -lpixman-1" export COMPOSITOR_CFLAGS="-I $WLD/include -I $WLD/include/pixman-1 -L$SDK_DIR/drivers -DLINUX=1 -DEGL_API_FB -DEGL_API_WL" export CLIENT_CFLAGS="-I $WLD/include -I $WLD/include/cairo -I $WLD/include/pixman-1" export CLIENT_LIBS="-lGLESv2 -lEGL -lwayland-client -lwayland-cursor -lxkbcommon" export SIMPLE_EGL_CLIENT_CFLAGS="-DLINUX=1 -DEGL_API_FB -DEGL_API_WL -I $WLD/include" export SIMPLE_EGL_CLIENT_LIBS="-lGLESv2 -lEGL -lwayland-client -lwayland-cursor" export IMAGE_LIBS="-lwayland-cursor" export WESTON_INFO_LIBS="-lwayland-client" Apply the two patches 0001-DRM-condition.patch and 0002-Enable-weston-for-Vivante-GPU.patch. Build the Weston. $cd /opt $tar xvvf weston-1.1.1.tar.xz $ cd weston-1.1.1     $ ./configure --prefix=$WLD \         --disable-setuid-install \         --disable-x11-compositor --disable-drm-compositor \         --disable-rpi-compositor --disable-wayland-compositor \         --disable-weston-launch --disable-libunwind \         --disable-xwayland-test \ WESTON_NATIVE_BACKEND="fbdev-backend.so" $ make $ make install RUNNING Also, Weston must be run as root. copy weston.ini and weston-desktop-shell.ini to /root/.config/ . In terminal window, export LD_LIBRARY_PATH="/usr/lib" export XDG_RUNTIME_DIR=/tmp Execute 'src/weston'. You should see a blue screen fading in. In a different terminal, enter 'clients/simple-shm &'. You should see a scrolling color pattern. You can then enter 'clients/simple-egl &' to see a 3D client  action.

Continental Yocto Training Author:           Leonardo Sandoval Material: PDF Tutorial: i.MX Yocto Project: Freescale Yocto Project Tutorial Provided Virtual Machine Wandboard Dual Wandboard - Freescale i.MX6 ARM Cortex-A9 Opensource Community Development Board - BLOG Tasks: Task 1: Build and Boot your board in N-steps     1.    Create a new folder ($ mkdir conti-fsl-community-bsp)     2.    Follow all N-steps (from the tutorial, page 2) EXCEPT the baking     3.     Baking has been done for you, so assume that the bake is done!     4.    Flash:         conti-fsl-community-bsp $ cd         $ cd fsl-community-bsp/build         build $ dd if=tmp/deploy/images/core-image-minimal-wandboard-dual.sdcard of=/dev/sdb bs=1M         build $ sync # NEVER FORGET THIS STEP, You have been warned!     5.    Boot         Task 2:    Folders     1. Tree structure & size         fsl-comunity-bsp $ tree -d -L 2         fsl-comunity-bsp $ du -h --max-depth=2 Task 3:    Architecture Task 4:    Metadata Task 5:    Config files         build $ cat conf/local.conf         build $ cat conf/bblayer.conf Task 6:     Layers build $ bitbake-layers show-layers sources $ cat meta-fsl-arm/conf/layer.conf Task 7:    Adding an existing layer     1. Clone the repo sources $ git clone https://github.com/lsandoval/meta-fsl-test.git     2. Add the layer to build/bblayers.conf sources $ cd ../build build $ vi conf/bblayers.conf     3. Browse the new layer files     4. Compile the kernel build $ bitbake -f -c compile linux-wandboard build $ bitbake -c deploy linux-wandboard     5. Flash    build $ sudo mkdir /media/boot         build $ sudo mount /dev/sdb1 /media/boot         build $ cp tmp/deploy/images/uImage /media/boot         build $ sudo umount /media/boot     6. Boot Task 8: (Optional) Check the core-image-minimal-test image, bake and flash it. Run the 'helloworld' app Task 9: Q&A

i.MX6 4.0.0 BSP release doesn't support ASRC_P2P function. This patch provides the reference codes to enable ASRC_P2P function for SSI. It can convert input sample rate to 44.1K_16bit/44.1K_24bit and 48K_16bit/48K_24bit. You can modify the configurations in the Board file. By the way, the SSI controler works at slave mode. Known limitations for the patch: -- The SDMA doesn't support SSI Dual FIFO when using ASRC_P2P function. -- From the waveform, the converted 24bit data have some abnormal data(values between 0 and 1) , but can't hear any abnormal sound from headphone. One suggestion is given under https://community.freescale.com/docs/DOC-95340

When using SSI Slave Mode for ASRC_P2P function (https://community.freescale.com/docs/DOC-95342), the waveform of the converted 24bit data is abnormal(have some values between 0 and 1). When using SSI Master Mode, these abnormal data disappear. This patch shows how to enable SSI Master Mode based on ASRC_P2P patches. Because SSI Master Mode uses fixed data width for LRCLK(32bits for each L or R), and the SSI Dual FIFO Mode is not supported for ASRC_P2P, the converted 16bit data is not well supported in this patch. Suggestions: If you want to convert the audio data to 16bit, you can use SSI Slave Mode; if you want to convert the audio data to 24bit, you can use SSI Master Mode.

Add MIPI DSI support in uboot, the mipi panel is hx8369.

Support SSI Master function based on 0001_SSI_ASRC_P2P.patch

Add SSI_ASRC_P2P support for imx6 based on Kernel 3.0.35.

One of the most important features of Yocto is its ability to handle sublayers. To understand the sublayers please Yocto Project Development Manual Start creating meta-custom folder, then create the other folders. For example: meta-daiane/ ├── conf │   └── layer.conf ├── README ├── recipes-core │   └── helloworld │       ├── helloworld │       │   └── hello_world.c │       └── helloworld_0.0.bb └── recipes-daiane     └── images         └── dai-image-hello.bb It´s possible to create recipes-kernel and place there your defconfig, or create a bbappend to apply your patches to kernel, or even create a recipes-multimedia and place there custom application for gstreamer, for example. Here, the custom application example is a helloworld application. One important tip: Yocto see recipes name as PACKAGENAME_VERSION.bb, It means, yocto uses "_" (underline) to separate the package name from package version on a recipe file name. So, if you call your helloworld application as hello_world_1.0.bb Yocto will think your application is called "hello" and the version is something around "world_1.0" Please, be careful. LAYER.CONF This is the file that gives new layer live. Find the content of mine layer.conf below: # We have a conf and classes directory, add to BBPATH BBPATH .= ":${LAYERDIR}" # We have a packages directory, add to BBFILES BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \             ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "daiane" BBFILE_PATTERN_daiane := "^${LAYERDIR}/" BBFILE_PRIORITY_daiane = "4" As soon as the new custom layer is created, it MUST include it to  conf/bblayers.conf file. Please see the example: LCONF_VERSION = "6" BBPATH = "${TOPDIR}" BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}" BBFILES ?= "" BBLAYERS = " \   ${BSPDIR}/sources/poky/meta \   ${BSPDIR}/sources/poky/meta-yocto \   \   ${BSPDIR}/sources/meta-openembedded/meta-oe \   \   ${BSPDIR}/sources/meta-fsl-arm \   ${BSPDIR}/sources/meta-fsl-arm-extra \   ${BSPDIR}/sources/meta-fsl-demos \   \   ${BSPDIR}/sources/meta-daiane \ " Please, find the tarball with sample meta layer attached to this document. It includes one image that will install the Hello World application: $ bitbake dai-image-hello When the content of image tar ball is extracted, hello_world was installed and it was for ARM: $ find -name hello* ./usr/bin/hello_world $ file ./usr/bin/hello_world ./usr/bin/hello_world: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped Go to Yocto Training - HOME Go to Task #9 - How to add bad/ugly

Overview As you know, R13.4.1 doesn't support Bluetooth. These attached patches enable Bluetooth for R13.4.1. Before applying the patches for MX6 SabreSD, please rework SabreSD. Refer to How to enable BT on board imx6q_sabresd RevC. Hardware i.MX6Dual/Quad or i.MX6DualLite SabreSD board Software i.MX6DQ/MX6DL Android ICS R13.4 or R13.4.1 Release