“Hardware Development Guide for i.MX 6SoloX …” does not provide any recommendations regarding configuring JTAG tools, assuming ARM DSTREAM  / DS-5 using. Nevertheless, it is possible to apply ARM RealView tools with i.MX6 SoloX. Chapter 7 (Configuring JTAG Tools) of  “Hardware Development Guide for i.MX 6Quad, 6Dual, 6DualLite, 6Solo Families…” contains base considerations, that may be used for i.MX6 SoloX too. http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf Some addition details  are provided below.   Both A9 core and M4 core have their own DAP, all the resources in its platform will be accessed through its own DAP. JTAG Chain Configuration: − SJC, IR Length = 5, same as i.MX 6Solo; − SDMA, IR Length = 5, same as i.MX 6Solo; − DAP for A9, IR Length = 4, same as i.MX 6Solo; − DAP for M4, IR Length = 4, new in i.MX 6SoloX. It is needed to use the recent RVICE firmware, which may be found in ARM DS5 Community Edition. http://ds.arm.com/ds-5-community-edition/ After installation, please run “Debug Hardware Update” option of the DS5 and select the firmware file for “Install Firware Update” menu. In my case : c:\Program Files\DS-5 v5.21.0\sw\debughw\firmware\ARM-RVI-4.23.0-35-base.rvi   Finally, RealView configuration looks as below. Coresight base address Cortex-A9_0 is 0x82150000. The Cortex-A9 always boots as the primary core and is responsible for launching the Cortex-M4.

Two year ago we have developed a 16 bit ETM adaptor to connect our PowerTrace II module with our AUTOFOCUS II preprocessor : TRACE32® Chip Support and Configurations for IMX6QUAD This adaptor is connected on the EDGE connector of the SABRE Automotive Industry board from Freescale and provide a MICTOR 38 connector compatible with 16 bit maximum ETM size. This is the maximum ETM size supported by iMX6. The maximum Trace clock frequency riched is 132 Mhz, which provide enough bandwidth to trace a full ANDROID running on Quad Core iMX6 !!! and it works perfectly. with Lauterbach tools you can debug completely Linux kernel and driver and full ANDROID support using our dalvik awareness that show you the complete call stack from low level system linux call to high level JAVA code. this adaptor is already in use on several customer from us, with perfect result. TRACE32 can now display all the code executed by the iMX6 Quad for each core, with no limitation on time recording. Linux task switch timing, profiling function, MIPS information, Detailed Tree function etc ... more detail here : TRACE32® Trace-based Profiling here below a small example of what you can see : here below the board, and schematic. in case you want the full schematic for this adaptor, please contact me, i can then provide it for free ... if you buy some Lauterbach tools 😉 Jean-Pierre Paradiso Sales Manager http://www.lauterbach.com/frames.html?tutorials.html PS : we are also developping a new ETM adapter compatible with our partner DAVE (DAVE Embedded Systems ) that develop very nice eval board on iMX6 called AXEL EVB will be available soon through the official DAVE  distributor in France : Cynetis

This patch release is target for LPDDR2 ( dual channels in interleave mode ) support on i.MX6DL platform. Two patches are prepared to modify u-boot and kernel in order to have correct DRAM init sequence, 400MHz & 24MHz frequency switching and suspend/resume support. The patches are not fully verified. It is provided as reference for customer to enable their i.MX6DL board with LPDDR2. Customization and Testing is needed by customer. We need to remind some points here: MMDC_MDCFG3LP in 24MHz need to increase the margin ( 0x40222 -> 0x80555 ) in order to pass the OS frequency switch stress test. We are identifying the reason but this workaround is working fine and included to the patch. Code changes in kernel is prepared so that it is compatible to DDR3. In other words, the DDR type will be detected and a correct handling will be done for LPDDR2 and DDR3. In LPDDR2 system, we can't put SDQ pin into LPM during suspend. Otherwise, the system cannot resume. Dual channels in fix mapping mode is not recommended to use.

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