Q: To do a triple display demo based on imx6 SDP. The 3 channel are 1 lvds & 1hdmi & 1 lcd  and the OS is Android JB4.3. The dual display works and those 2 screens can all display the Android desktop. The setting as below. setenv bootargs console=ttymxc0,115200 init=/init rw video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb1:dev=lcd,CLAAWVGA,if=RGB565 video=mxcfb2:off video=mxcfb3:dev=hdmi,1920x1080M60,if=RGB24 fbmem=10M fb0base=0x27b00000 vmalloc=400M androidboot.console=ttymxc0 androidboot.hardware=freescale static struct ipuv3_fb_platform_data sabresd_fb_data[] = {         { /*fb0*/         .disp_dev = "lcd",         .interface_pix_fmt = IPU_PIX_FMT_RGB565,         .mode_str = "CLAA-WVGA",         .default_bpp = 16,         .int_clk = true,         .late_init = false,         }, {         .disp_dev = "ldb",         .interface_pix_fmt = IPU_PIX_FMT_RGB666,         .mode_str = "LDB-XGA",         .default_bpp = 16,         .int_clk = false,         .late_init = false,             }, {         .disp_dev = "ldb",         .interface_pix_fmt = IPU_PIX_FMT_RGB666,         .mode_str = "LDB-XGA",         .default_bpp = 16,         .int_clk = false,         .late_init = false,         }, {         .disp_dev = "hdmi",         .interface_pix_fmt = IPU_PIX_FMT_RGB24,         .mode_str = "1920x1080M60",         .default_bpp = 16,         .int_clk = true,         .late_init = false,             }, }; static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {         .ipu_id = 1,          .disp_id = 1, }; 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 = 1,         .sec_disp_id = 0, }; A: Android BSP doesn't support triple display, and so the change in kernel would not make the 3rd display work.

Hi all, Cortex-M4 for i.MX6SoloX that is new to i.MX6SX customers. They concerns GPIO ISRs response time are not real time and hugh latency while Android/Linux is running on Cortex-A9 in i.MX6SoloX. I shared my test steps, report and image for your reference. Best regards, Carl

Connectivity - Using a Bluetooth Dongle Network Connection A simple way to set up a network connection using a Bluetooth dongle is using the Personal Area Networking (PAN) profile. Load the following modules on i.MX platform: # modprobe ehci-hcd # modprobe hci_usb # modprobe bnep Set hci0 up: # hciconfig hci0 up Check if the hci0 is set by typing: root@freescale ~$ hciconfig hci0:  Type: USB         BD Address: 00:1E:58:3F:4D:09 ACL MTU: 384:8 SCO MTU: 64:8         UP RUNNING PSCAN ISCAN         RX bytes:4813491 acl:53228 sco:0 events:208901 errors:0         TX bytes:156025160 acl:410140 sco:0 commands:83 errors:0 root@freescale ~$ hciconfig hci0 piscan Start the Bluetooth service: root@freescale ~$ /etc/rc.d/init.d/bluetooth start Start the pand service as Pan User (PANU): root@freescale ~$ pand -s -r PANU On Host (PC), load bnep module: $ modprobe bnep Start the pand service as Group Ad-hoc Network (GN): $ sudo pand --connect 00:1E:58:3F:4D:09 --service GN -n The target address (in this case 00:1E:58:3F:4D:09) can be found using hciconfig command on target A BNEP0 network should be created on host (PC) and target (i.MX): Configure BNEP0 IP on PC: $ sudo ifconfig bnep0 192.168.0.11 Configure BNEP0 IP on i.MX: $ ifconfig bnep0 192.168.0.10 Now the PAN network is set. You can test using ping: root@freescale ~$ ping 192.168.0.11 PING 192.168.0.11 (192.168.0.11): 56 data bytes 64 bytes from 192.168.0.11: icmp_seq=0 ttl=64 time=12.305 ms 64 bytes from 192.168.0.11: icmp_seq=1 ttl=64 time=27.782 ms 64 bytes from 192.168.0.11: icmp_seq=2 ttl=64 time=16.701 ms 64 bytes from 192.168.0.11: icmp_seq=3 ttl=64 time=36.732 ms 192.168.0.11 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 12.305/23.380/36.732/9.551 ms

This guide is created for introducing how to do DDR3 calibration for mass production. Please read carefully and understand clearly before following it. To be update!

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

The Android O8.1.0_2.0.0 GA (4.14.98 kernel) is now available on IMX software landing page. Overview -> i.MX BSP Updates and Releases -> Android -> Android O8.1.0_2.0.0   Files available:   # Name Description 1 android_o8.1.0_2.0.0-GA_docs.zip Android O8.1.0_2.0.0  Documentation 2 imx-o8.1.0_2.0.0-ga.tar.gz i.MX Android Automotive proprietary source code for Android O8.1.0_2.0.0 3 android_o8.1.0_2.0.0-ga_image_8qmek.tar.gz Prebuilt images with NXP extended features for the i.MX8QMax and 8QXPlus MEK   Supported boards: i.MX 8QuadMax MEK i.MX 8QuadXPlus MEK   Features and Known issues For features and known issues, please consult the Release Notes in detail.  ============================================================= The Android O8.1.0_2.1.0_AUTO GA (4.14.98 kernel) is now available on IMX software landing page. Overview -> i.MX BSP Updates and Releases -> Android AUTO-> Android O8.1.0_2.1.0_AUTO   Files available:   # Name Description 1 android_o8.1.0_2.1.0-auto-GA_docs.zip Android O8.1.0_2.1.0_AUTO Documentation 2 imx-o8.1.0_2.1.0-auto-ga.tar.gz i.MX Android Automotive proprietary source code for Android O8.1.0_2.1.0_AUTO 3 android_o8.1.0_2.1.0-auto-ga_image_8qmek.tar.gz Prebuilt images with NXP extended features with the EVS function enabled in the Cortex-M4 CPU core for the i.MX 8QuadMax/8QuadXPlus MEK 4 android_o8.1.0_2.1.0-auto-ga_image_8qmek2.tar.gz Prebuilt images with NXP extended features for the i.MX8QMax and 8QXPlus MEK, without the EVS in M4 Core. Supported boards: i.MX 8QuadMax MEK i.MX 8QuadXPlus MEK   Features and Known issues For features and known issues, please consult the Release Notes in detail. 

Features 1.75" x 2.5" CPU board 4" x 4" Expansion board Board Support Package i.MXL LiteKit drivers: Serial Ethernet I2C (audio, LEDs and Switches) Framebuffer/Video and Touchscreen SD/MMC Audio i.MX21 LiteKit drivers: Serial Ethernet I2C (LEDs and Switches) Framebuffer/Video and Touchscreen SD/MMC Audio USB host GX-Linux baseline distribution GNU X-Tools from Microcross For more information, [click here.]

After bitbake meta-toolchain the script to install the toolchain package is located under $ ls tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.4.1.sh    tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.4.1.sh In order to install it: $ source poky-eglibc-x86_64-arm-toolchain-1.4.1.sh     [sudo] password for daiane:     Enter target directory for SDK (default: /opt/poky/1.4.1):     You are about to install the SDK to "/opt/poky/1.4.1". Proceed[Y/n]?y     Extracting SDK...done     Setting it up...done     SDK has been successfully set up and is ready to be used. Hello World $ source /opt/poky/1.4.1/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi $ cd ~/test/ $ arm-poky-linux-gnueabi-gcc helloworld.c $ ls a.out                                                 helloworld.c                           $ ./a.out -bash: ./a.out: cannot execute binary file $ file a.out a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped Kernel $ source /opt/poky/1.4.1/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi $ cd linux-2.6-imx $ git checkout remotes/origin/imx_3.0.35 $ export ARCH=arm $ export CROSS_COMPILE=$TARGET_PREFIX $ unset LDFLAGS $ make imx6_defconfig $ make uImage Make sure to have mkimage available on bin patch (if using mkimage from u-boot export its patch) Or, download the ubuntu pachage: sudo apt-get install uboot-mkimage UPDATE You may find the following error:   OBJCOPY arch/arm/boot/zImage   Kernel: arch/arm/boot/zImage is ready multiple (or no) load addresses: This is incompatible with uImages Specify LOADADDR on the commandline to build an uImage make[1]: *** [arch/arm/boot/uImage] Error 1 make: *** [uImage] Error 2 This is regarding a missing LOADADDR for mkimage to use to generate uImage with the right offset to be placed in the right LOADADDR. The address value is dependent on your hardware! And it is different depending on imx6 variations. So please be aware regarding what is your right value. If the machine you are using is supported in yocto project/meta-fsl-arm, for example, you can find the value related with your board in the file conf/machine/include/imx-base.inc or online here meta-fsl-arm - Layer containing Freescale ARM hardware support metadata It is the same value used in variable UBOOT_ENTRYPOINT. For example as of this writing for the Freescale SABRE-SD board looking in conf/machine/include/imx-base.inc UBOOT_ENTRYPOINT_mx6  = "0x10008000" Thus the build command would be: $ make uImage LOADADDR=0x10008000 So, as a quick reference table, I point here the 3 most wanted make command lines: imx28evk: $ make LOADADDR=0x40008000 imx53qsb: $ make LOADADDR=0x70008000 imx6qsabresd: $ make LOADADDR=0x10008000 Update 2 Suggested by cmcqueen1975 Building an autotools-based package. E.g. $ source /opt/poky/1.4.1/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi $ ./configure ${CONFIGURE_FLAGS} $ make $ make install the CONFIGURE_FLAGS is the variable depending on your very-own project. Go to Yocto Training - HOME Go to Task #7 - Create the toolchain

Following docs(English or Chinese version) are also can be referred as a hand on guide. Freescale i.MX6 DRAM Port Application Guide-DDR3  飞思卡尔i.MX6平台DRAM接口高阶应用指导-DDR3篇    Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid  Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.MX6DQSDL DDR3 Script Aid  Please find i.MX6SX DDR3 Script Aid through below link. i.MX6SX DDR3 Script Aid  Please find i.MX6SL LPDDR2 Script Aid through below link. i.MX6SL LPDDR2 Script Aid  Please find i.MX6UL DDR3 Script Aid through below link.. https://community.nxp.com/docs/DOC-329899  Please find i.MX6UL LPDDR2 Script Aid through below link. i.MX6UL_LPDDR2_Script_Aid  Please find i.MX6ULL DDR3 Script Aid through below link. i.MX6ULL_DDR3_Script_Aid 

                For the SPI NOR booting on fuse steps. 1.      Please boot your PCB on uboot and type below command for fuse boot setting. MX6Q SABRESD-MFG U-Boot > imxotp blow --force 5 0x0a000030 MX6Q SABRESD-MFG U-Boot > imxotp read 5 Reading fuse at index: 0x5 Fuse at (index: 0x5) value: 0xA000030 MX6Q SABRESD-MFG U-Boot > imxotp read 6 Reading fuse at index: 0x6 Fuse at (index: 0x6) value: 0x0 MX6Q SABRESD-MFG U-Boot > imxotp blow --force 6 0x10 Current fuse at (index: 0x6) value: 0x0 Blowing fuse at index: 0x6, value: 0x10 Reloading shadow registers... Operation succeeded fuse at (index: 0x6) value: 0x10 MX6Q SABRESD-MFG U-Boot > imxotp read 6 Reading fuse at index: 0x6 Fuse at (index: 0x6) value: 0x10 MX6Q SABRESD-MFG U-Boot > 2.      Set the boot mode for 00 as Boot from fuses 3.      You could see the SPI clock on scope after re power on.

►How to Modify U-boot configure for change memory size to 512M •Only need change the u-boot memsize configure.      #define PHYS_SDRAM_1_SIZE                                                         (1u * 512 * 1024 * 1024) ► Use the performance tool Antutu test system in 512M and in 1024M.      * The statistic of Memory free after each test.     * The improve test is reduce GPU reserve physical memory size from 192M to 128M ► System boot-up reserve. (Static)     ► DMA allocate page and mem page.(Dynamic) ► Use for page alloc  < 292392K ► Browser speed     * The Browse speed in 512M is nearly with in 1024M ► Conclusion:   It is acceptable for this performance when use 512M physical memory.

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

Issue Description When WM8960 is working as master mode and target sample rate is 44100Hz or 48000Hz, it's found no sound can be heard on some i.MX boards. Impact Software Baseline: Linux 4.1.15_2.0.0 release or previous versions. Impact Hardware Platform: MCIMX6UL-EVKB, MCIMX6ULL-EVK and MX7SABRE boards which have WM8960 as Audio Codec. Root Cause When WM8960 is working as master mode, if input MCLK is 12.288MHz and configure "PLLPRESCALE =2 and SYSCLKDIV[1:0] =1", wrong BCLK and LRCLK output maybe got on some boards. And then it causes no sound output. Solutions After change the WM8960 PLL setting from “PLLPRESCALE =2 and SYSCLKDIV[1:0] =1” to “PLLPRESCALE =1 and SYSCLKDIV[1:0] =2”, the failure parts can work normally. See attached patch. The formal patch is also included into the releases starting from L4.1.15_2.0.1. See http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-bsp/recipes-kernel/linux/files?id=imx_4.1.15_2.0.1

Recently I published this i.MX Dev Blog post about the Gateworks plugin gst-variable-rtsp-server support for i.MX 6. Now, you can check how to use it on i.MX 8 SoCs as well. 1. Preparing the image In order to use gst-variable-rtsp-server plugin, prepare your machine and distro: Add the following line to conf/local.conf: IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server gst-variable-rtsp-server" Download the attached patch and apply it by doing: $ cd <yocto_path>/sources/meta-fsl-bsp-release/ $ git am ~/Download/0001-Add-RTSP-support-for-i.MX-8-L4.14.78_ga1.0.0-or-olde.patch Note: This patch is not necessary for L4.14.98_ga2.0.0 BSP! Then, build the image with bitbake and deploy it to the SD card. 2. Video Test Source Example Server $ gst-variable-rtsp-server -p 9001 -u "videotestsrc ! v4l2h264enc ! rtph264pay name=pay0 pt=96" Client 2. Camera Example Server $ gst-variable-rtsp-server -p 9001 -u "v4l2src device=/dev/video0 ! video/x-raw,width=640,height=480 ! v4l2h264enc ! rtph264pay name=pay0 pt=96" Client In order to use VLC or other application as the client, just enter the URL as shown in the image below:

Question: To connect an FPGA to the i.MX6Q over LVDS.,to connect the 2 LVDS channels in split mode. The datasheet indicates the driver output max skew due to different propagation time of rising and falling edge. For the sake of the design of their FPGA interface, it would be also interesting to get the skew between the 2 LVDSn_CLK (of the 2 channels) as well as the intrachannel- skew. Answer: Backend database are checked. We can provide the result in the view of design. Since we do not check inter-channel skew in production, the following may not be guaranteed.  At the core boundary, we found that, timing skews between every data and clock are within 30ps. Path from core boundary to PAD are matched by analog layout, should produce some skew well below 30ps also. As the result, I think, all LVDS signal can be considered as one single group, and skew in datasheet can apply to any signal.

This is a workaround—this page needs to be updated to add instructions for multi-touch support. Based on Freescale BSP 11.05. The LVDS panel (MCIMX-LVDS1) has a serial multi-touch controller, eGalax. As a workaround to have it supported on directly on Qt, we can force the driver to behave as a single touch. To do this: 1 - Edit the file ltib/rpm/BUILD/linux-2.6.35.3/drivers/input/touchscreen/egalax_ts.c adding the following line: + #define FORCE_SINGLE_POINTER_SUPPORT 1 2 - Compile the kernel ./ltib -m scbuild -p kernel 3 - Copy the new kernel to Card/Memory and boot it. 4 - Start your Qt app: $ Xfbdev -screen 1024x768 -mouse tslib,,device=/dev/input/event0  & $ export DISPLAY=:0.0 $ ./yourQTapp Note: You can read the touch events with "evtest" $ evtest  /dev/input/event0 or tslib apps: $ export TSLIB_TSDEVICE=/dev/input/event0 $ ts_print

Q: How to program i.MX6 eFUSE? A: what about using the mfg tool? In the end only the supplies, USB OTG and the boot mode pins need to be connected. The customers Idea was to have all devices (i.MX6 eFUSE, Flash, PFUZE, etc) pre- programmed before mounting on the board. I presented the flows we support (MFG Tool, Platform SDK) for eFUSE programming last Friday when I was at the customer. KITPF0100SKTEVBE Product Summary Page MfgTools is the most convenient way to burn eFuse. Or the customer can burn the fuse on their jig/socket board by the u-boot: How to Fuse in U-Boot U-Boot contains a tool, imxotp, which is used for fusing. U-Boot > imxotp imxotp - One-Time Programable sub-system Usage: imxotp imxotp read <index> - read fuse at 'index' imxotp blow [--force] <index> <value> - blow fuse at 'index' with hex value 'value' Tips: 'addr' to 'index': convert 'index' from 'address' index = (addr - otp_base) / 0x10 eg, addr is 0x021bc410, otp_base is 0x021bc400, the index = 1 '--force' must be present in order to blow the fuse. Command will abort if '--force' is missing. index = (addr - otp_base) / 0x10, where the addr is the address of the fuse you want to operate, the otp_base is the base address of the fuse block. 'value' should correspond to fuse settings according to the fuse map and desired fuse configuration. ---------------------------------- FIrst of all thanks for your reply. However both flow assumes the i.MX6 is already soldered on the board. Please note the specific request was if it is possible (and we can support a programming house) to pre program the efuses BEFORE they are soldered on the PCB thus on a standard programmer. Take an FLASH programmer as an example.

Hi, this is a smart server called Duckbill in a thumb-drive format based on the i.MX283. It's a really low cost solution usable with or without casing. It is intended to be set up as a small home-server for automation purposes. It comes with Debian Linux as operation system but without any specific user programs.  The stick can be operated either at a USB power adaptor or at a USB port of your router.  Since Duckbill runs Linux you are totally free in software development. The internal connectors can be used as UART, SPI, I2C, ADC or GPIO. So it's up to everyone to develop his own expansion board. 1. Duckbill without casing (top) 2. Duckbill without casing (bottom) 3. Duckbill with casing 4. Duckbill for development purposes 5. Duckbill with integrated EnOcean module If you want to know more about this product: http://www.i2se.com/homeautomation.html

This document describes the i.MX 8MQ EVK HDMI output and mini-SAS connectors features on Linux and Android use cases, covering the supported daughter-board, the process to change Device Tree (DTS) files or Boot Images, and enable these different display options on the board.