According to iMX6DQRM chapter 46 (On-Chip OTP Controller), the UID field is located at offsets 0x410 and 0x420 from the base address of the OCOTP.  That is: OTP Bank0 Word1 - contains the first word of the UID OTP Bank0 Word2 - contains the second word of the UID. md.l 21bc410 021bc410: d72d7372 d72d7372 d72d7372 d72d7372    rs-.rs-.rs-.rs-. 021bc420: 906709d4 906709d4 906709d4 906709d4 ..g...g...g...g. Comparing to the read information under Linux shell: cat /proc/cpuinfo ......... Serial : 906709d4d72d7372 The value is identical from uboot and linux kernel reading back.

Host : Ubuntu 11.10 Part 1. Installation of QNX 6.50 and QNX 6.50 SP1        1.1 Create an account and activate the created account that will be assigned an 30-days evaluation serial numberin then on www.qnx.com, and download qnxsdp-6.5.0-201007091524-linux.bin, qnxsdp-6.5.0SP1-201206271006-linux.bin;        1.2 Execute "sudo apt-get install ia32-libs"        1.3 Execute "sudo -E /your/path/qnxsdp-6.5.0-201007091524-linux.bin", follow the guides as prompted, enter the received evaluation serial number, then the installation of QNX 6.50 will be done;        1.4 Logout, and re-login, so far typing "qconfig" will return the following messages:         --------------------------------------------------------------------------------------------------------------------- alanz@alanz-VirtualBox:~$ qconfig QNX Installations   Installation Name: QNX Software Development Platform 6.5.0             Version: 6.5.0      Base Directory: /opt/qnx650            QNX_HOST: /opt/qnx650/host/linux/x86          QNX_TARGET: /opt/qnx650/target/qnx6         ---------------------------------------------------------------------------------------------------------------------        1.5 Execute "sudo chmod a+rw /etc/qnx/license/licenses"        1.6 Execute "sudo -E /your/path/qnxsdp-6.5.0SP1-201206271006-linux.bin"        1.7 Logout, and re-login, so far typing "qconfig" will return the following messages:         --------------------------------------------------------------------------------------------------------------------- alanz@alanz-VirtualBox:~$ qconfig QNX Installations   Installation Name: QNX Software Development Platform 6.5.0             Version: 6.5.0      Base Directory: /opt/qnx650            QNX_HOST: /opt/qnx650/host/linux/x86          QNX_TARGET: /opt/qnx650/target/qnx6 Additional Packages    Package Name: QNX Software Development Platform         Version: 6.5.0SP1            Base: QNX SDP 6.5.0    Installation Path: /opt/qnx650         ---------------------------------------------------------------------------------------------------------------------        1.8 Download bsp-nto650-freescale-mx6q-sabrelite-trunk-201301161142.zip, and unzip it; Part 2. Build i.MX6Q SabreLite QNX BSP        2.1 Edit a envsetup.sh as following:         --------------------------------------------------------------------------------------------------------------------- #!/bin/bash export QNX_HOST=/opt/qnx650/host/linux/x86 export QNX_JAVAHOME=/opt/qnx650/_jvm export QNX_TARGET=/opt/qnx650/target/qnx6 export QNX_CONFIGURATION=/etc/qnx export ARCH=arm export CPULIST=arm export VARIANTLIST=v7 export MAKEFLAGS=-I/opt/qnx650/target/qnx6/usr/include export PATH=$PATH:/opt/qnx650/host/linux/x86/usr/bin export QCONFIG=/opt/qnx650/target/qnx6/usr/include/qconfig.mk export BSP_ROOT_DIR=/home/alanz/Downloads/QNX_Software/i.MX6Q_SabreLite4QNX         ---------------------------------------------------------------------------------------------------------------------        Note: BSP_ROOT_DIR is the BSP unzip directory.        2.2 Execute "make clean", then "make". The generated file will be under images/ifs-mx6q-sabrelite.raw Part 3. Running i.MX6Q SabreLite QNX BSP        3.1 Copy images/ifs-mx6q-sabrelite.raw to SD;        3.2 Modify u-boot environment as following:         --------------------------------------------------------------------------------------------------------------------- setenv loadaddr '0x10800000' setenv bootcmd_sd 'mmc dev 0; fatload mmc 0:1 ${loadaddr} ifs-mx6q-sabrelite.raw; go ${loadaddr}' setenv bootcmd 'run bootcmd_sd' saveenv boot         ---------------------------------------------------------------------------------------------------------------------        3.3 Connect i.MX6Q SabreLite w/ serial and ethernet, turn on, type "qconn" and "ifconfig" in the serial shell. Part 4. Debug w/ QNX Momentics IDE        4.1 Type "qde" to activate Momentics IDE        4.2 On the top-right corner, there exist several icons named in "xxx perspective" to switch the main window according to current selected "perspective" context. Click "QNX System Information Perspective" to create a target to conect and debug as following depicted.        4.3 Switch to "C/C++ perspective" to create QNX C/C++ project as following depicted.        4.4 Switch to "Debug perspective" to perform "Debug Configuration" as following depicted.        Then it can debug program on target i.MX6Q SabreLite board.

Instruction On Linux OS, we have two major audio system API to play/record audio pcm, alsa-lib and pulseaudio. Pulseaudio is in Freescale Ubuntu root fs release, while alsa-lib is used by default in LTIB release. This article is to tell how to configure alsa-lib by configuration file. Architecture Alsa-lib has a set of standard API which allows application to develop easily. At the same time, it provides a scalable mechanism to fulfill its features, including resample, channels remix, sound mixing from different applications, and so on. As above figure describes, alsa plugin provide fundamental function, and the whole pipeline makes customization possible. Alsa-lib API pretend to be an alsa device and provide a name for caller to open. What kind of plugin the name represents for is decided by configuration. For example, pcm.card0 {    type hw    card 0 } card0 is the fake alsa device name, with type hw, which represents for the first real alsa device. pcm.plug {     @args [ SLAVE ]     @args.SLAVE {         type string     }     type plug     slave.pcm $SLAVE } plug is the fake alsa device name, with type plug, which represents for audio conversion processor. In addition, it's also receive arguments from application that make it more flexible. When we call snd_pcm_open(.., "plug:card0",..); in the application, we create a pipeline which will first convert the source pcm to sound card 0 capable pcm if necessary in "plug" plugin, then play it to sound card 0 in "card0" plugin.  "slave.pcm" is the key to link different plugins. The number of arguments could be more than one, with definition pcm.xxx {     @args [ arg1 arg2 arg3 ]     @args.arg1 { type string }     @args.arg2 { type string }     @args.arg3 { type string }     ... } The argument could also have default value, please refer to /usr/share/alsa/alsa.conf. To pass the arguments, use snd_pcm_open(.., "xxx:arg1,arg2,arg3",..); From the name, we can always follow the pipeline to the last plugin, which type might be hw(to alsa driver), file(to file), or others (pulse, bluetooth...) to network, protocol stack and so on. The Configuration Files In configuration file, we mainly define the fake alsa device name. The root configuration file is /usr/share/alsa/alsa.conf, which will load additional configuration files which might overwrite previous name definition in the previously loaded file. The load sequence is: 1. /usr/share/alsa/alsa.conf 2. /usr/share/alsa/alsa.conf.d/* 3. /etc/asound.conf for administrator 4. $(HOME)/.asoundrc for certain user In practice, alsa applications (e.g. aplay or speaker-test) are always using "default" as the fake device name, so that the most important thing to customize your own pipeline is to overwirte "default". For example, pcm.dmix_44100{     type dmix     ipc_key 5678293     ipc_key_add_uid yes     slave{         pcm "hw:0,0"         period_time 10000         format S16_LE         rate 44100     } } pcm.!default{     type plug     route_policy "average"     slave.pcm "tee:dmix_44100,/home/wayne/a.pcm" } The "!" in "pcm.!default" means forcing overwrite. The pipeline defined above is as following figure: The next example is the "default" definition on ubuntu root fs. pcm.!default {     type pulse     hint {         show on         description "Playback/recording through the PulseAudio sound server"     } } The only alsa plugin is "pulse", and the pipeline is as following: Additional Resources There are a lot of alsa plugins developed, with various configuration parameters, I won't list them in detail. Please refer to .asoundrc - ALSA wiki for more details.

1) nfs I burn the uboot to board by mfgtool, then starting the kernel by nfs, when the board boot up, I set a) ipaddr and b)serverip, then I set the c)"setenv nfsroot /home/usuario/fsl-release-bsp/buildimx6q/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui/1.0-r0/rootfs", this is sample, you need choose correct folder for yours, this is for imx6q, d) set the mdt file,then run the netboot. 2) program uboot to the qspi, then boot from SD card 3) change the mfgtool to program uboot, kernel to the qspi attched the ucl2.xml setenv bootcmd 'run bootargsset; sf probe; sf read ${loadaddr} 0xA00000 0x600000; sf read ${fdt_addr} 0x800000 0x10000; bootz ${loadaddr} - ${fdt_addr}'

Overview: This document is written for Freescale customers who have Freescale AC3 release packages (excluded package). (If you did not have the AC3 release package, you can disregard this document.) Freescale OMX Player in Android release supports audio track selection when playing files with multiple audio tracks. However, most customers don't use this enhanced API to select the audio track even if current audio codec is not supported. To avoid a soundless output when partial audio track can be played, this document provides the method to select the available audio track automatically to play. The patch in this document is not included in our current release because it did not match with our track selection rule - play the first track. If you have any idea with this issue, feel free to add comments into this document. Issue description: Software: R13.4-GA or R13.4.1 Android releases Hardware: MX6Dual/Quad SabreSD board Test source: 1.mkv Test Step: 1. Lunch Gallery from main menu. 2. Play the video And you can see the watch the video without any sound Root Reason: The file has 2 audio track DTS & AC3: audio track 1 is DTS and track 2 is AC3. OMX Player will choose the first audio track to play as default audio track, which is DTS audio. However, the software only supports the AC3 audio codec, so it could not set up audio decoder for DTS track. If we choose to play the AC3 track, sounds could be heard. How to fix: The audio track index is set in GMPlayer::LoadParser(). You can get audio format to check whether it is supported by decoder. Please see the patch audio_track_slection.diff

This document explains how to bring-up u-boot & Linux via JTAG This procedure has been tested on: i.MX6 Solo X Sabre SD i.MX6UL EVK Prerequistes: Get the latest BSP for your board. This procedure was tested with L4.1.15. Build the 'core-image-minimal' image to bring-up your board (Detailed steps here) Optional- Build a meta-toolchain for your device 1.- Set board to boot from Serial dowloader mode or set it to boot from the SD card and remove the sd card We basically want the board to stall in boot ROM to attach to the target. 2.- Connect JTAG probe and turn on the board The device should stall trying to establish a connection to download an image, this will allow us to attach to the target. 3.- Load Device Configuration Data In 'normal' boot sequence the boot ROM takes care of reading the DCD and configuring the device accordingly, but in this case we are skipping this sequence and we need to configure the device manually. The script used by Lauterbach to parse and configure the device is called dcd_interpreter.cmm and can be found here. Search for the package for your specific device. The DCD configuration for your board should be on your u-boot directory: yocto_build_dir/tmp/work/<your board>imx6ulevk/u-boot-imx/<u-boot_version>2016.03-r0/git under board/freescale/<name of your board>mx6ul_14x14_evk/imximage.cfg This file (imximage.cfg) contains all the data to bring up DRAM among other early configuration options. 4.- Load U-boot If an SREC file of U-boot is not present build it (meta-toolchain installed required) the SREC file contains all the information required by the probe to load it and makes this process easier. To build the SREC simply type: make <your board defconfig>mx6ul_14x14_evk_defconfig  (all supported boards are found under u-boot_dir/configs) make If you cannot build an SREC or do not want to, you can use the u-boot.imx (located under yocto_build_dir/tmp/deploy/images/<your board name>/) or u-boot.bin files but you will need to figure out the start address and load address for these files, this can be done by examining the IVT on u-boot.imx (here is a useful document explaining the structure of the IVT). Let U-boot run and you should see its output on the console I will try to boot from several sources but it will fail and show you the prompt. 5.- Create RAMDisk After building the core-image-minimal you will have all the required files under yocto_build_dir/tmp/deploy/images/<your board name>/ You will need: zImage.bin - zImage--<Linux Version>--<your board>.bin Device tree blob - zImage--<Linux Version>--<your board>.dtb Root file system - core-image-minimal-<your board>.rootfs.ext4 We need to create a RAMDisk out of the root file system we now have, these are the steps to do so: Compress current Root file system using gzip: gzip core-image-minimal-<your board>.rootfs.ext4 If you want to keep the original file use: gzip -c core-image-minimal-<your board>.rootfs.ext4 > core-image-minimal-<your board>.rootfs.ext4.gz Create RAMDisk using mkimage: mkimage -A arm -O linux -T ramdisk -C gzip -n core-image-minimal -d core-image-minimal-<your board>.rootfs.ext4.gz core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot Output: Image Name: core-image-minimal Created: Tue May 23 11:28:55 2017 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3017939 Bytes = 2947.21 kB = 2.88 MB Load Address: 00000000 Entry Point: 00000000 Here are some details on mkimage usage Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) mkimage -V ==> print version information and exit 6.- Modify U-boot's environment variables Now we need to modify U-boot's bootargs as follows: setenv bootargs console=${console},${baudrate} root=/dev/ram rw We need to find out the addresses where u-boot will expect the zImage, the device tree and the initial RAMDisk, we can do it as follows: => printenv fdt_addr fdt_addr=0x83000000 => printenv initrd_addr initrd_addr=0x83800000 => printenv loadaddr loadaddr=0x80800000 Where: fdt_addr -> Device tree blob load address initrd_addr -> RAMDisk load address loadaddr -> zImage load address 7.- Load zImage, DTB and RAMDisk Now we know where to load our zImage, device tree blob and RAMDisk, on Lauterbach this can be achieved by running the following commands: Stop the target and execute: data.load.binary zImage.bin 0x80800000 data.load.binary Your_device.dtb 0x83000000 data.load.binary core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot 0x83800000 Let the device run again and deattach from the device in lauterbach this is achieved by: go SYStem.mode.NoDebug start the boot process on u-boot as follows: bootz ${loadaddr} ${initrd_addr} ${fdt_addr} You should now see the Linux kernel boot process on your terminal: After the kernel boots you should see its prompt on your terminal: Since we are running out of RAM there is no way for us to save u-boot's environment variables, but you can modify the source and compile u-boot with the new bootargs, by doing so you can create a Load script that loads all the binaries hits go and the boot process will continue automatically. One way to achieve this is to modify the configuration file under U-boot_dir/include/configs/<your board>.h find the mfgtool_args and modify accordingly. The images attached to this thread have been modified as mentioned.

Introduction This is a brief guide showing how to integrate the driver for the WF111 module to the i.MX6 BSP Release. In this case the WF111 driver is available on a repository and it’s in accordance with the Yocto Project, which allows to easily customize a linux distribution for your board. Requirements WF111 Documentation – Silicon Labs have made a great job of documenting the steps to add the WF111 driver to a Linux distribution and have created Application Note 996 (link below), which we will use as reference. http://www.silabs.com/documents/login/application-notes/AN996.pdf WF111 Driver - We will also be using the Yocto layer included on the following repository: https://github.com/engicam-stable/meta-engicam i.MX6 3.14.52 BSP Release – In out scenario the WF111 layer that will be imported includes a driver that it’s compatible with Linux Kernel 2.6.24 up to 4.1., which it’s important to keep in mind.   Installing the 3.14.52 BSP Release First, setup the 3.14.52 BSP as described on the i.MX Yocto Project User’s Guide.   Adding the WF111 Driver Layer Clone the WF111 Driver Layer to your sources folder inside the BSP Release directory. Since the 3.14.52 BSP Release is based on Fido we will clone the Fido branch of the driver repository. $ cd <BSP_RELEASE_DIR>/sources $ git clone https://github.com/engicam-stable/meta-engicam -b fido‍‍  Once the layer is cloned you would need to add the new later editing the bblayers.conf file located the following path: <BSP_RELEASE_DIR>/<BUILD_DIR>/conf/bblayers.conf By adding the following line to add the new layer.   BBLAYERS += " ${BSPDIR}/sources/meta-engicam "‍   This should make the wf111-driver available through bitbake since bitbake will now look into this layer for all available recipes. You can then add the driver to your image by adding the following line to the <BUILD_DIR>/conf/local.conf   IMAGE_INSTALL_append += "wf111-driver"‍ Or you may create a new image recipe that includes the wf111-driver package. However, there are certain kernel options that must be enabled for the driver to work.   Creating an append to configure the kernel options Before we can bake an image with the WF111 driver we would need to edit the kernel options as mentioned on Silabs AN996. The following kernel options must be enabled:   CONFIG_WIRELESS_EXT CONFIG_MODULES CONFIG_FW_LOADER We would need to add the CONFIG_WIRELESS_EXT as the other two options are enabled on the BSP by default.   This involves adding an addendum to the kernel recipe to change its configuration. You may either add this append to any layer. The best way to handle it would be using a new layer for all your customization. You can find how to create a new layer on the following document: https://community.nxp.com/docs/DOC-331917 We’ll use a new layer called meta-newlayer for this example. It’s important that this layer has a high priority so the changes from the bbappend are not overridden. The following alternative was suggested by Chris Hossack on the following thread: https://community.nxp.com/thread/376369 First, run the menuconfig tool on the bitbake environment: bitbake linux-imx -c menuconfig Enable the necessary options: Networking Support > Wireless > cfg80211 wireless extensions compatibility   Save the configuration and exit. Then run the following bitbake command, which will create a config fragment file that contains the changed made to the default kernel options. bitbake linux-imx -c diffconfig We’ll make an append file that adds the required options.  Content of the config fragment:   CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211_WEXT=y CONFIG_LIB80211=y CONFIG_LIB80211_CRYPT_WEP=y CONFIG_LIB80211_CRYPT_CCMP=y CONFIG_LIB80211_CRYPT_TKIP=y # CONFIG_LIB80211_DEBUG is not set CONFIG_HOSTAP=y # CONFIG_HOSTAP_FIRMWARE is not set‍‍‍‍‍‍‍‍‍‍‍‍‍    Since we are appending the kernel layer we need to add the addendum on the same path as that of the original kernel recipe but within our layer and create the append file there. Also add the WF111.cfg file to the linux-imx directory:   We would need to copy (and you may rename it as well) to the folder where are will be creating the append recipe for the kernel. Copy:  <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg To: <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg You can do so suing the following command: cp <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg‍ (Please note that the file was renamed for ease, but you may use any name for the config fragment)   We need to create the bbappend file on the following path (as it must be the same relative path as the original recipe it is appending) <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx_3.14.52.bbappend   The linux-imx_3.14.52.bbappend file would contain the following:   SRC_URI += "file://WF111.cfg"  do_configure_append() {          #this is run from         #./tmp/work/<MACHINE>-poky-linux-gnueabi/linux-imx/3.14.52-r0/git          cat ../*.cfg >> ${B}/.config  }‍‍‍‍‍‍    After creating this recipe you should be able to bake any image from the BSP and see the driver there. I tested with the core-minimal-image and found that the files were indeed added to /lib/firmware. $ bitbake core-image-minimal ‍‍‍

On imx8qm there are two DPUs(display process unit) and one ISI(image subsystem interface), ISI has 5 inputs and two of them are from DPU0 and DPU1.   This document demonstrates on how to loopback DPU1 outputs to ISI. Note that only mipi dsi0 of dpu0 and lvds1 of dpu1 can be loopbacked to isi.   Platform:                            imx8qm b0 mek OS:                                    yocto 4.14.78 ga hardware connection:        imx8qm lvds1 ====> it6263 cable =====> hdmi display.   1st: isi has 8 pipelines which can be assigned to any of the 5 inputs, this doc takes the 5th pipeline to sink the dpu1 input. So you will need to configure the isi_4( start from 0) source in the dts and write a simple v4l2 subdev for capture testing, the default isi_4 device will be /dev/video4.   2st: configure both framegen0 of dpu1 and lvds1's link to pixellink 3.   3st: write a v4l2 userspace program to capture from /dev/video4 device, take this vulkan-capture as an example. Note that Vulkan-capture is rendered by vulkan api, you can also take opengl es for rendering.   See the atttachments for details.   ======================================== 2019/11/12 update patches. ======================================== 2019/12/19 add patch. Support connect real display to DC1-LVDS1   Note: for ISI loopback,  it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6]  o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4]   For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4] 

When I am planing to develop some features in Uboot, I found it has lots limitation without interrupt. For example, to have camera preview in Uboot. Polling in Uboot results non sync when camera preview and hard to keep code simple and clean. I decided to take some time survey interrupt and it is time to share it.   This patch (shown as attachment) is to enable the interrupt. It also has the sample code to set GPIO interrupt as well. The test below showed Uboot can get the interrupt when pressing Volume up key. Special thanks for Anson Huang for patient discussing with me on this.   irqinfo is the command to enable Volume up interrupt. The log do_irq is print when Uboot got the interrupt.   Original Attachment has been moved to: 0001-Enable-interrupt-on-i.MX6Q-SabreSD.patch.zip

The i.MX 8QXP MEK does not allow the OV5640/LVDS/LCD usage only by changing the device tree anymore. It occurs because the M4 owns the i2c resources, so the A core must use rpmsg to enable virtual drivers. Due to this, if the user changes the device tree, for instance, the *ov5640.dtb, the kernel won't boot, entering in the following loop: [    8.603353] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).      [    8.610025] [drm] No driver support for vblank timestamp query.              [    8.616077] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.2 (ops dpu_) [    8.624978] imx-drm display-subsystem: bound imx-dpu-crtc.0 (ops dpu_crtc_op) [    8.632526] imx-drm display-subsystem: bound imx-dpu-crtc.1 (ops dpu_crtc_op) [    8.639833] imx-drm display-subsystem: failed to bind ldb@562210e0 (ops imx_7 [    8.648428] imx-drm display-subsystem: master bind failed: -517 With the approach provided in this post, it is possible to make this change manually, only by changing the flash.bin at U-boot for a non-m4 one. In order to make the changes to the flash.bin file, it’s needed to obtain the following files: - u-boot.bin from internal u-boot provided by NXP. - scfw_tcm.bin from SCFW porting kit - bl31.bin from ARM Trusted Firmware - SECO firmware container image Disclaimer The described procedures in this document target a GNU/Linux (Ubuntu 20.04 LTS) and it’s focused on iMX8QXP B0 + BSP L4.19.35_1.1.0. Required packages 1 - Install ARM64 ToolChain: 1.1 - Install ARM64 GCC and G++ cross-compilers: # apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu 2 - Install ARM32 GCC6 ToolChain: 2.1 - Download the ARM32 6 Toolchain and install it: $ mkdir ~/gcc_toolchain $ cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ $ cd ~/gcc_toolchain/ $ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 # apt-get update # apt-get install srecord 3 - Download MKimage 3.1 - Create a new directory desired to the packages: $ mkdir flash_build $ cp flash_build 3.1 - Clone the MKimage: $ git clone https://source.codeaurora.org/external/imx/imx-mkimage -b imx_4.19.35_1.1.0 4 - U-boot build 4.1 - Clone the U-boot  $ git clone https://source.codeaurora.org/external/imx/uboot-imx -b imx_v2019.04_4.19.35_1.1.0 $ cd uboot-imx 4.2 - Export the ARM64 ToolChain:  $ export ARCH=arm64 $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- 4.3 - Build it:  $ unset LDFLAGS $ make -j4 imx8qxp_mek_defconfig $ make 4.4 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp spl/u-boot-spl.bin ../imx-mkimage/iMX8QX/ $ cp u-boot-nodtb.bin ../imx-mkimage/iMX8QX/ $ cd ..   5 - ARM Trusted Firmware 5.1 - Clone the imx-atf:  $ git clone https://source.codeaurora.org/external/imx/imx-atf -b imx_4.19.35_1.1.0 $ cd imx-atf 5.2 - Build it:  $ unset LDFLAGS $ make PLAT=imx8qx bl31 5.3 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp build/imx8qx/release/bl31.bin ../imx-mkimage/iMX8QX/ $ cd ..   6 - SCFW 6.1 - Export the ARM32 GCC6 Toolchain:  $ export TOOLS=~/gcc_toolchain/ 6.2 - Download the BSP L4.19.35_1.1.0_SCFW and copy it to the flash_build directory:  $ cp ~/Downloads/imx-scfw-porting-kit-1.2.7.1.tar.gz $ tar xvzf imx-scfw-porting-kit-1.2.7.1.tar.gz $ cd packages/ $ chmod a+x imx-scfw-porting-kit-1.2.7.1.tar.gz $ ./imx-scfw-porting-kit-1.2.7.1.bin 6.3 - Build it to i.MX 8QXP MEK B0:  $ cd imx-scfw-porting-kit-1.2.7.1/src/ $ tar xvzf scfw_export_mx8qx_b0.tar.gz $ cd scfw_export_mx8qx_b0/ $ make qx R=B0 B=mek 6.4 - Copy the binary file to the MKimage/iMX8QX directory:  $ cp build_mx8qx_b0/scfw_tcm.bin ../../../../imx-mkimage/iMX8QX/ $ cp ../../../../ 7 - SECO Firmware Container Image 7.1 - Download the SECO firmware binaries and copy it to the flash_build directory $ cp ~/Downloads/firmware-imx-7.9.bin . $ chmod a+x firmware-imx-7.9.bin 7.2 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp firmware-imx-7.9/firmware/seco/mx8qx-ahab-container.img /imx-mkimage/iMX8QX/ 8 - Build flash.bin 8.1 - In a new terminal, open the imx-mkimage directory: $ cd flash_build/imx-mkimage 8.2 - Build it:  $ make SOC=iMX8QX flash 8.3 - Deploy it to the SDCard:  $ sudo dd if=iMX8QX/flash.bin of=/dev/sdX bs=1k seek=32 && sync Now, you are able to use any non-rpmsg.dtb without kernel errors. Author: Pedro Jardim: [email protected]

What is CMA   The Contiguous Memory Allocator (CMA) is a framework, which allows setting up a machine-specific configuration for physically-contiguous memory management. Memory for devices is then allocated according to that configuration. The main role of the framework is not to allocate memory, but to parse and manage memory configurations, as well as to act as an in-between between device drivers and pluggable allocators. It is thus not tied to any memory allocation method or strategy.  Various devices on embedded systems have no scatter-getter and/or IO map support and as such require contiguous blocks of memory to operate. They include devices such as cameras, hardware video decoders and encoders, etc. Such devices often require big memory buffers (a full HD frame is, for instance, more then 2 mega pixels large, i.e. more than 6 MB of memory), which makes mechanisms such as kmalloc() ineffective. Some embedded devices impose additional requirements on the buffers, e.g. they can operate only on buffers allocated in particular location/memory bank (if system has more than one memory bank) or buffers aligned to a particular memory boundary. Development of embedded devices have seen a big rise recently (especially in the V4L area) and many such drivers include their own memory allocation code. Most of them use bootmem-based methods. CMA framework is an attempt to unify contiguous memory allocation mechanisms and provide a simple API for device drivers, while staying as customisable and modular as possible.   Why use it in default release   Most of the i.MX SoC does not have IOMMU for specific IP who requires larger contiguous memory for operations, like VPU/GPU/ISI/CSI. Or they have IOMMU, but performance is not that good. In the default i.MX BSP, we still allocate physical contiguous memory for those IP drivers for DMA transfers. In arm64 kernel, the DMA allocation API would allocate memory in a various way which depends on the device configurations (in dts or gfp flags). The below table shows how the DMA allocation API (w/o IOMMU enabled device) works to find a proper way for pages (by order, coherent pool -> CMA -> Buddy -> SWIOTLB): Allocator (by order) Configurations (w/o IOMMU) Comments Mapping Coherent Pool device dma is not coherent GFP flag is not allow blocking By __alloc_from_pool() Already mapped on boot when coherent pool init in VMALLOC CMA device CMA or system CMA is present GFP flag is allow blocking: __GFP_DIRECT_RECLAIM set By cma_alloc() map_vm_area, mapped in VMALLOC Buddy No CMA (device or system) or GFP not allow blocking By __get_free_pages(), which can only allocate from the DMA/normal zone (lowmem), 32bits address spaces Already mapped in the lowmem area by kernel on boot SWIOTLB No contiguous pages from buddy or return buffer area region > device dma_mask By map_single() Already mapped on boot when SWIOTLB init   Also a diagram shows how it works (DMA allocation path):     By default, kernel uses CMA as a backend of DMA buffers allocation for most of the cases. That's why i.MX BSP use CMA in the default release for GPU/VPU/CSI/ISI or other buffers for DMA transfers.   CMA Pros & Cons   Pros Well designed for large contiguous memory allocation even under memory fragment condition. Pages in CMA can be shared by buddy system, not a reserved pool Can be device specific CMA area, only used by this device and share to system Easy to configure it's start addr and size on runtime w/o re-compile kernel Cons Allocation process slow when migration pages needed Easy to be corrupted by system memory allocation. Customer may meet cma_alloc failure when system is out of memory, which would cause bad user experiences when foreground application wants graphic buffers for rendering and RVC wants buffers for CAR reverse. Potential dead lock when cma_alloc() need to migrate some pages, which is still flushing to storage (Some customers already met deadlock when one page is under writeback path by FUSE file system, and cma_alloc wants to migrate it). This is the initial motivation to write this documentation.   Why get rid of CMA   Read cons statement above. The key point is to reserve memory for critical path of allocation like GPU graphic buffers and camera/VPU preview/recording buffers to keep a good user experience from allocation failure which would cause black screen, preview stuck, etc. Also avoid potential dead lock when CMA and FUSE work together.   How to get rid of CMA   To get rid of CMA, the basic idea is to cut off the CMA way in the DMA allocation, turn to coherent pool (atomic pool). Please not that coherent pool can only be used by DMA allocation API, it's not shared to system buddy.   1. Enable coherent pool Add “coherent_pool=<size>” in command line, Coherent pool is actually allocate from system default CMA, so CMA size > coherent_pool. There's no reference for this size, as it's various from system to system and use cases to use cases: The biggest consumer of DMA is GPU, it's usage can be monitored by gmem_info tool. Monitor the gmem_info under the typical use cases, and settle down the GPU required memory. Checking for 2nd consumer of DMA: ISI/Camera, depends on the V4l2 reqbuf size and numbers Checking VPU, depends on the multimedia frameworks Plus alsa snd, USB, fec usage The size must be verified by test to make sure system stable.   2. DMA allocation hack Hack to arch/arm64/mm/dma-mapping.c, remove the gfpflags_allow_blocking check in the __dma_alloc() function: diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index 7015d3e..ef30b46 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -147,7 +147,7 @@ static void *__dma_alloc(struct device *dev, size_t size, size = PAGE_ALIGN(size); - if (!coherent && !gfpflags_allow_blocking(flags)) { + if (!coherent) { // && !gfpflags_allow_blocking(flags)) { struct page *page = NULL; void *addr = __alloc_from_pool(size, &page, flags);   3. ION allocator In both Android and Yocto release, ION allocator (android staging driver) is used for VPU buffers. And it default goes into the ION CMA heap. This means ION request for contiguous memory is direct to CMA. To avoid CMA, we can use carveout heap instead of CMA heap in ION:   3.1 Android Enable CARVEOUT heap, disable CMA heap: CONFIG_ION=y CONFIG_ION_SYSTEM_HEAP=y -CONFIG_ION_CMA_HEAP=y +CONFIG_ION_CARVEOUT_HEAP=y +CONFIG_ION_CMA_HEAP=n Adjust the carveout reserved heap base address and size in the dts: / {  reserved-memory {  #address-cells = <2>;  #size-cells = <2>;  ranges;    carveout_region: imx_ion@0 {  compatible = "imx-ion-pool";  reg = <0x0 0xf8000000 0 0x8000000>;  };  }; };   3.2 Linux Kernel - refer to attached patch for i.MX8QM. Almost same as Linux, but ION carveout heap driver need to be patched. Gstreamer - apply below patch to make allocate from carveout: yocto/build-8qm/tmp/work/aarch64-mx8-poky-linux/gstreamer1.0-plugins-base/1.14.4.imx-r0/git: diff --git a/gst-libs/gst/allocators/gstionmemory.c b/gst-libs/gst/allocators/gstionmemory.c index 1218c4a..12e403d 100644 --- a/gst-libs/gst/allocators/gstionmemory.c +++ b/gst-libs/gst/allocators/gstionmemory.c @@ -227,7 +227,8 @@ gst_ion_alloc_alloc (GstAllocator * allocator, gsize size,    }    for (gint i=0; i<heapCnt; i++) { -       if (ihd[i].type == ION_HEAP_TYPE_DMA) { +       if (ihd[i].type == ION_HEAP_TYPE_DMA || +             ihd[i].type == ION_HEAP_TYPE_CARVEOUT) {                heap_mask |= 1 << ihd[i].heap_id;          }    }   References "Aarch64 Linux Kernel memory management" "CMA documentation"

Recipes to include Amazon's Alexa Voice Services in your applications. Step 1 : Get iMX Yocto AVS setup environment Review the steps under Chapter 3 of the i.MX_Yocto_Project_User'sGuide.pdf on the L4.X LINUX_DOCS to prepare your host machine. Including at least the following essential Yocto packages $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \   gcc-multilib build-essential chrpath socat libsdl1.2-dev u-boot-tools Install the i.MX NXP AVS repo Create/Move to a directory where you want to install the AVS yocto build enviroment. Let's call this as <yocto_dir> $ cd <yocto_dir> $ repo init -u https://source.codeaurora.org/external/imxsupport/meta-avs-demos -b master -m imx-alexa-sdk-4.9.11.xml Download the AVS BSP build environment: $ repo sync Step 2: Setup yocto for Alexa_SDK image with AVS-SETUP-DEMO script: Run the avs-setup-demo script as follows to setup your environment for the imx7d-pico board: $ MACHINE=imx7d-pico DISTRO=fsl-imx-x11 source avs-setup-demo.sh -b <build_sdk> Where <build_sdk> is the name you will give to your build folder. After acepting the EULA the script will prompt if you want to enable: a Sound Card selection The following Sound Cards are supported on the build: SGTL (In-board Audio Codec for PicoPi) 2-Mic Synaptics/Conexant 2-Mic TechNexion Voice Hat (with DSPConcepts SW) The script will prompt to select the soundcard you will be using: Which Sound Card are you going to use? Sigmatel .............................. 1 Synaptics/Conexant .................... 2 VoiceHat (for DSPConcepts SW) ......... 3 Type the number of your selection and press Enter... Install Alexa SDK Next option is to select if you want to pre-install the AVS SDK software on the image. Do you want to build/include the AVS_SDK package on this image(Y/N)? If you select YES, then your image will contain the AVS SDK ready to use (after authentication). Note this AVS_SDK will not have WakeWord detection support, but it can be added on runtime. If your selection was NO, then you can always manually fetch and build the AVS_SDK on runtime. All the packages dependencies will be already there, so only fetching the AVS_SDK source code and building it is required. Install WiFi support Te WiFi support is optional and requires to get from NXP an additional meta-picopi-wifi layer. Contact NXP to get this layer to be able to support WiFi on your image The image will prompt: Do you want to include WiFi support on this image(Y/N)? Select YES if you already have the complementary meta-avs-demos-wifi layer Finish avs-image configuration At the end you will see a text according with the configuration you select for your image build. Next is an example for a Preinstalled AVS_SDK with Synaptics Sound Card support and WiFi/BT not enabled for PicoPi board. ============================================================ AVS configuration is now ready at conf/local.conf - Sound Card = Synaptics - Alexa SDK 1.7 pre-installed - Wifi supported You are ready to bitbake your AVS demo image now: bitbake avs-image If you want to use QT5DisplayCards, use then: bitbake avs-image-qt5 ============================================================ Step 3: Build the AVS image Go to your <build_sdk> directory and start the build of the avs-image There are 2 options Regular Build: $ cd  <yocto_dir>/<build_sdk>   $ bitbake avs-image With QT5 support included: $ cd  <yocto_dir>/<build_sdk>   $ bitbake avs-image-qt5 The image with QT5 is useful if you want to add some GUI for example to render DisplayCards. Step 4 : Deploying the built images to SD/MMC card to boot on target board. After a build has succesfully completed, the created image resides at <build_sdk>/tmp/deploy/images/imx7d-pico/ In this directory, you will find imx7d-pico-avs--.sdcard image or imx7d-pico-avs-qt5--.sdcard, depending on the build you chose on Step3. To Flash the .sdcard image into the eMMC device of your PicoPi board follow the next steps: Download the bootbomb flasher Follow the instruction on Section 4. Board Reflashing of the Quick Start Guide for AVS kit to setup your board on flashing mode. Copy the built SDCARD file $ sudo dd if=imx7d-pico-avs.sdcard of=/dev/sd<partition> bs=1M && sync $ sync Properly eject the pico-imx7d board: $ sudo eject /dev/sd<partition> NXP Documentation Refer to the Quick Start Quide for AVS SDK to fully setup your PicoPi board with Synaptics 2Mic and PicoPi i.mx7D For a more comprehensive understanding of Yocto, its features and setup; more image build and deployment options and customization, please take a look at the i.MX_Yocto_Project_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document. For a more detailed description of the Linux BSP, u-boot use and configuration, please take a look at the i.MX_Linux_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document.

Even though the Advanced Tool Kit is not a supported tool anymore, it can be used to provision the code and blow fuses of an i.MX device during manufacturing. This is true when the secure boot has been enabled, which means that the code downloaded by the ATK to the target must be signed, as it will be authenticated prior to its execution. Once in secure mode, the Serial Download boot mode (SDP) can only access a restricted range of addresses, which is documented in the DCD section of the reference manual. An attempt to write outside this allowed area will result in an error, and will make the ROM restart the SDP by considering this as an attack. To automatically detect the mode (engineering or secure/production) of the chip, the ATK writes data to a memory location, and by retrieving the response it knows the configuration. The response can be one of two values: 0x56787856 means that the chip is in engineering mode. 0x12343412 means that the chip is in production/secure mode. It should be known that there is a bug that prevents a secure chip from being handled correctly. For instance, to perform the automatic detection mentioned above, the tool writes to 0xFFFF_FFFF for the i.MX25 or even i.MX35. This address is invalid by being outside the allowed address range, so the ROM code aborts the current session, and restarts a new one. The attached DLL library fixes this issue by writing to an appropriate area like the free iRAM space. This will allow use of the ATK for a chip whose secure boot is enabled.

Q: Is there any guidelines document on 3G/4G modem integration with the iMX platforms running Android Lollipop versions ? A: Generally speaking, porting documents on 3G/4G should be provided by manufacture, For different 3G/4G module, porting steps are also distinct.The following steps are for ZTE 3G on android jb 4.2.2,  as a reference: ----Common steps: (1) linux USB driver In linux kernel, we should select GSM module in USB driver path. (2)Communication port for 3G After linux booting normally, you can find some communation port at path /dev/, like ttyUSB0,ttyUSB1,ttyUSB2... These tty ports are for AT commands & data transmitting, but which one is for data , or which one is for AT command, we should have to ask manufacture or get information for them. (3)dial script 3G manufacture will give the script to you, if not, ask for it. (4)Dynamic library(libreference-ril.so) 3G manufacture will give you the library to replace original one in android. (5)Add service for 3G in init.rc file according their documents ---As an example, let us see steps for ZTE 3G(CDMA) ** Replace original file with libreference-ril.so file that ZTE released. **Copy init.gprs-pppd file to system/etc/ppp directory **Modify init..rc like following: service ril-daemon /system/bin/rild -l /system/lib/libreference-ril.so -- -d /dev/ttyUSB2 -u /dev/ttyUSB0 class main socket rild stream 660 root radio socket rild-debug stream 660 radio system socket rild-ppp stream 660 radio system user root group radio cache inet misc audio sdcard_rw log service pppd_gprs /etc/ppp/init.gprs-pppd class main user root group radio cache inet misc disabled oneshot

  “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 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!

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