Wayland:   Wayland is a display SERVER and COMPOSITION protocol. It is relatively new, as its first release was in 2012. The protocol enables applications to allocate their own off-screen buffers and render their window contents directly, using hardware accelerated libraries like OpenGL ES, or high quality software implementations like Cairo. Wayland is ONLY a display server protocol, not a display server itself. Weston is the reference Wayland protocol implementation.   YOCTO Setup . $ mkdir ~/bin $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config –list $ mkdir fsl-release-bsp $ cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.14.52-1.1.0_ga $ repo sync     you will be able to build Yocto and also have all the recipes to do so, we need to add WAYLAND, then execute the following steps: $ DISTRO=fsl-imx-wayland MACHINE=imx6qsabresd source fsl-setup-release.sh -b build-wayland $ bitbake fsl-image-gui After these steps, you will have a wayland based i.MX6Q image where you will be able to play with all the knowledge we provided here.   Once your image has been properly generated, you will find the Weston source codes in: <YOUR YOCTODIR>/build-wayland/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/weston/1.9.0-r0/weston-1.9.0     Wayland application for extended desktop: This functionality is only supported using the GAL2D blitter, in order to enable a multiple desktop approach, you need to pass the following parameters to your weston command: /etc/init.d/weston stop echo 0 > /sys/class/graphics/fb4/blank weston --tty=1 --use-gal2d=1 --use-gl=0 --device=/dev/fb0,/dev/fb4 &     Xwayland: Wayland is a complete window system in itself, but even so, if we're migrating away from X, it makes sense to have a good backwards compatibility story. With a few changes, the Xorg server can be modified to use wayland input devices for input and forward either the root window or individual top-level windows as wayland surfaces.   DISTRO=fsl-imx-xwayland MACHINE=imx6qsabresd source ./fsl-setup-release.sh -b build-xwayland bitbake fsl-image-gui Once you have the image your Wayland/Weston image will be able to run X11 applications   Excepting X11 applications that use EGL, we don’t support that, if you plan to use EGL apps, please use the Wayland provided functions to create the buffer.   Application for rotation: Weston allows rotating windows with super-key + middle mouse button. As this works for Wayland clients only, you can run Xwayland in weston, run your X application on Xwayland, and rotate the Xwayland display. For another option: Create a file ~/.config/weston.ini with this content: [core] modules=xwayland.so shell=desktop-shell.so idle-time=0 [shell] background-color=0xff002244 locking=false # panel-location=none    [launcher] icon=/usr/share/icons/gnome/24x24/apps/utilities-terminal.png path=/usr/bin/weston-terminal [launcher] icon=/usr/share/icons/hicolor/48x48/apps/firefox.png path=/usr/bin/firefox [output] name=X1 mode=640x800 transform=90 # wanna get mad? use: transform=flipped-270 scale=1 This weston.ini enables a rootless xwayland.so in weston. The [output] section with name=X1 defines weston's appearance as X client. transform=90 rotates the weston display.   the [launcher] sections can be used to create custom panel starters for your X applications. See  /usr/share/doc/weston/examples/weston.ini for more detailed information for further cases, I will attach in the future.

Overview This purpose of this document is to introduce how to support recovery mode for POR reboot event based on MX6 Android R13.4.1. Background If you boot Android R13.4.1 on MX6 SabreSD board, the reboot reason is Watchdog. But if the reboot reason is changed from Watchdog to POR, the recovery mode is failed to enter after factory reset. In R13.4.1, the bit 8 of SRC_GPR10 is used as the persistent bit of recovery mode. This bit is expected to be kept after reboot so that U-boot can use this bit to distinguish what mode should enter. However all SRC registers will be reset on POR sequence according to i.MX6DQRM Section 59.4.1.2.3 IPP_RESET_B (POR). So when the reboot reason is POR, the persistent bit of recovery mode is cleared even if the software set it before reboot. It causes the bootloader won't enter recovery mode after reboot. Software Changes According to i.MX6DQRM, the SNVS_LP General Purpose Register provides a 32 bit read write register, which can be used by any application for retaining 32 bit data during a power-down mode. So to support recovery mode for POR event, the SNVS_LP register can be used to store the persistent bit of recovery mode. The following changes are reqiured to apply (See patches.tar.gz) Apply for Uboot patch bootable/bootloader/uboot-imx/0001-ENGR00235817-mx6-use-SNVS-LPGPR-register-to-store-bo.patch. diff --git a/cpu/arm_cortexa8/mx6/generic.c b/cpu/arm_cortexa8/mx6/generic.c index 257c930..bd47130 100644 --- a/cpu/arm_cortexa8/mx6/generic.c +++ b/cpu/arm_cortexa8/mx6/generic.c @@ -1146,14 +1146,14 @@ int check_and_clean_recovery_flag(void) {   int flag_set = 0;   u32 reg; - reg = readl(SRC_BASE_ADDR + SRC_GPR10); + reg = readl(SNVS_BASE_ADDR + SNVS_LPGPR);   flag_set = !!(reg & ANDROID_RECOVERY_BOOT);   /* clean it in case looping infinite here.... */   if (flag_set) {    reg &= ~ANDROID_RECOVERY_BOOT; -  writel(reg, SRC_BASE_ADDR + SRC_GPR10); +  writel(reg, SNVS_BASE_ADDR + SNVS_LPGPR);   }   return flag_set; @@ -1168,14 +1168,15 @@ int fastboot_check_and_clean_flag(void) {   int flag_set = 0;   u32 reg; - reg = readl(SRC_BASE_ADDR + SRC_GPR10); + + reg = readl(SNVS_BASE_ADDR + SNVS_LPGPR);   flag_set = !!(reg & ANDROID_FASTBOOT_BOOT);   /* clean it in case looping infinite here.... */   if (flag_set) {    reg &= ~ANDROID_FASTBOOT_BOOT; -  writel(reg, SRC_BASE_ADDR + SRC_GPR10); +  writel(reg, SNVS_BASE_ADDR + SNVS_LPGPR);   }   return flag_set; diff --git a/include/asm-arm/arch-mx6/mx6.h b/include/asm-arm/arch-mx6/mx6.h index efb90c2..45381e2 100644 --- a/include/asm-arm/arch-mx6/mx6.h +++ b/include/asm-arm/arch-mx6/mx6.h @@ -732,6 +732,8 @@ #define SRC_GPR9  0x40 #define SRC_GPR10  0x44 +#define SNVS_LPGPR              0x68 + /* Get Board ID */ #define board_is_rev(system_rev, rev) (((system_rev & 0x0F00) == rev) ? 1 : 0) #define chip_is_type(system_rev, rev) \ Apply for kernel patch kernel_imx/0001-ENGR00235817-mx6-use-SNVS-LPGPR-register-to-store-bo.patch diff --git a/arch/arm/mach-mx6/system.c b/arch/arm/mach-mx6/system.c index 6d24f22..61649c5 100644 --- a/arch/arm/mach-mx6/system.c +++ b/arch/arm/mach-mx6/system.c @@ -563,7 +563,7 @@ void mxc_clear_mfgmode(void) #endif #ifdef CONFIG_MXC_REBOOT_ANDROID_CMD -/* This function will set a bit on SRC_GPR10[7-8] bits to enter +/* This function will set a bit on SNVS_LPGPR[7-8] bits to enter   * special boot mode.  These bits will not clear by watchdog reset, so   * it can be checked by bootloader to choose enter different mode.*/ @@ -574,18 +574,18 @@ void do_switch_recovery(void) {   u32 reg; - reg = __raw_readl(SRC_BASE_ADDR + SRC_GPR10); + reg = __raw_readl(MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR);   reg |= ANDROID_RECOVERY_BOOT; - __raw_writel(reg, SRC_BASE_ADDR + SRC_GPR10); + __raw_writel(reg, MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR); } void do_switch_fastboot(void) {   u32 reg; - reg = __raw_readl(SRC_BASE_ADDR + SRC_GPR10); + reg = __raw_readl(MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR);   reg |= ANDROID_FASTBOOT_BOOT; - __raw_writel(reg, SRC_BASE_ADDR + SRC_GPR10); + __raw_writel(reg, MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR); } #endif diff --git a/arch/arm/plat-mxc/include/mach/mx6.h b/arch/arm/plat-mxc/include/mach/mx6.h index 48b04b1..bb22de0 100644 --- a/arch/arm/plat-mxc/include/mach/mx6.h +++ b/arch/arm/plat-mxc/include/mach/mx6.h @@ -302,6 +302,8 @@ #define SRC_GPR9   0x40 #define SRC_GPR10   0x44 +#define SNVS_LPGPR   0x68 + /* GPC offsets */ #define MXC_GPC_CNTR_OFFSET  0x0

Gamma correction Displays usually presents a nonlinear bright response. For example, a frame buffer value of 100 will almost never give half the brightness of a value of 200. Historically, this is due to the physics of CRT monitors, but newer display technologies emulate the behavior. This is not only for compatibility, but for solid reasons based in the science of human visual perception. A first-order approximation to the non-linearity of a CRT is: L = ν ^ γ where L is the radiance (light intensity) from the display, ν is the voltage applied to the CRT gun (normally proportional to the digital value in the frame buffer), and γ (Greek letter “gamma”) is a constant particular to the monitor; it's the unknown parameter that makes it all work. It usually ranges from about 2.0 to about 2.5. One useful fact is that the gamma curve is linear in log-log space (i.e. logL as a function of logν), and γ is just the slope of that line. Example of gamma correction The dotted line indicates a linear transfer function (γ=1), the framebuffer gamma; the solid line shows how a typical CRT behaves; the dashed line represents the inverse function, the corrected gamma. How to correct gamma on i.MX using DP (Display Processor)? Gamma correction can be performed by IC (Image Converter) or DP (Display Processor) sub-blocks inside IPU. Current Linux kernel (3.10) provided by Freescale has an IOCTL that changes the related gamma parameters registers DP_GAMMA_C_SYNC<i> and DP_GAMMA_S_SYNC<i> on Display Processor block. The steps below shows how to change the gamma using user space applications: 1 - Declare a variable as mxcfb_gamma: struct mxcfb_gamma fb_gamma; 2 - Enable the gama correction: fb_gamma.enable = 1; 3 - Set the constk and slopek values, where i = 0 to 15 and x and y are respectively the new constk and slopek constant values: fb_gamma.constk[i] = x; fb_gamma.slopek[i] = y; 4 - Open the framebuffer device and call MXCFB_SET_GAMMA: fd_fb = open("/dev/fb0", O_RDWR, 0) ioctl(fd_fb, MXCFB_SET_GAMMA, &fb_gamma) Running the code above will immediately change the gamma value.

In i.MX8MQ and i.MX8M Mini, the codec used is WM8524, which only supports audio playback. Although 8M Mini does have PDM microphone interface (MICFIL), there is no support for audio record via I2S. This guide will show you how to add audio recording driver in i.MX8MQ/8MM step by step.   Hardware: i.MX8MQ/8MM Evk, I2S output digital microphone OS: Android/Linux Kernel version: 4.14.78 For detailed steps, please see attachment.

Splash Screen on U-boot for i.MX25 PDK Having a bitmap on the LCD a few seconds after boot is a requirement on several embedded systems, u-Boot supports this feature. However, currently, the code provided on Freescale's BSP only implements support for the LCD controller on Linux. This page provides instructions to add support for the LCDC on the u-boot. 1 - Install Freescale i.MX25 BSP, SDK 1.7 It is available on www.freescale.com. If needed follow the getting started section instructions. 2 - Update u-boot source After installing the BSP and running LTIB for the first time, it's time to update u-boot: - Download u-Boot patch and spec file. - Replace the file "u-boot.spec.in" located at <ltib_path>/config/platform/imx by the one downloaded - Copy the "u-boot-2009.08-1273860148.patch" downloaded to /opt/freescale/pkgs 3 - Extract and rebuild u-boot - To extract the source and aply the patch run: <Ltib_path>$ ./ltib -p u-boot -m prep - Now Build:     <Ltib_path>$ ./ltib -p u-boot -m scbuild    After completing this step an u-Boot binary (u-boot.bin) will be saved at <ltib_path>/rpm/BUILD/u-boot-2009.08 4 - Program the SD card Program a SD card with the new u-Boot binary and a bitmap image to be displayed. Insert the SD and run:      $sudo dd if=<ltib_path>/rpm/BUILD/u-boot-2009.08/u-boot.bin of=/dev/mmcblk0 bs=512 "/dev/mmcblk0" should replaced according to your host, use "dmesg" after inserting the SD to find out where is the SD on your host. Unmount it before issuing the dd command. $sudo dd if="your_image".bmp of=/dev/mmcblk0 bs=512 seek=608 Argument seek 608, skips the first 608 blocks of the SD (608x512) where the uboot is stored. If you need to relocate the image, update also the environment variable "splashimage_mmc_init_block", see step 6. 5 - Boot Boot the image from the SD. Personality Board settings:   12345678 SW22 -> 00000000 SW21 -> 11000000    Debug Board settings: SW5,6,7,8,9,10 -> OFF      12345678 SW4 -> 10000001 Turn on the board and stop at u-boot prompt: MX25 U-Boot > 6 - u-Boot environment variables Update u-Boot environment variables for the splash screen to work: The address in memory to load the splash screen from: MX25 U-Boot > setenv splashimage 0x80800000 The SD device on the board: MX25 U-Boot > setenv splashimage_mmc_dev 0 The block on the SD where the bitmap is stored, this must match the block on step 4. MX25 U-Boot > setenv splashimage_mmc_init_block 0x260  The amount in blocks to be read from the SD card, this depends on the bitmap size, i.e. for a 308278 bytes bitmap, 0x2B5 blocks are enough on a 512 bytes per block SD, (308278 / 512). MX25 U-Boot > setenv splashimage_mmc_blkcnt 0x2b5 The SD card block size in bytes: MX25 U-Boot > setenv splashimage_mmc_blksize 512 Save the environment variables: MX25 U-Boot > saveenv Now reboot the board and you should see the splash screen on the LCD. 7 - Booting Linux When Linux takes control of the board it initializes the LCD controller and Framebuffer again. To maintain the splash screen on the LCD you can replace the Linux Logo with the figure used for the splash screen, the side effect is a blink when Linux takes over the LCDC. To achieve this, create a new image in Gimp and save it as ".ppm". Copy it to Linux "logo" folder <ltib_path>/rpm/BUILD/linux-2.6.31/drivers/video/logo Run: $ ppmquant -mapfile clut_vga16.ppm "my_image.ppm" | pnmnoraw > logo_linux_vga16.ppm where: logo_linux_vga16.ppm is the current logo being used by Linux. Recompile the kernel and boot it.

Brief introduction on the aarch64 linux kernel memory mapping layout and basic management stuffs.  Contents include: Kernel's virtual memory layout and mapping after running i.MX8QM/QXP kernel reserved memory layout Kernel memory allocation method and technology (Buddy, cma, ION...) DMA buffer management, SWIOTLB, IOMMU GPU memory management How to customize the memory for different use cases How to avoid using CMA for a better stability and performance

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.

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 ‍‍‍

Question: Using Linux SDK 4.1.0, with CAAM drivers enabled, there is little noticeable difference in the performance of openssd compared to a kernel without the CAAM drivers. Tests were done using openssd. Test image AES-128 8192 byte block (M Bytes/sec) “openssl speed –evp aes-128-cbc” AES-128 8192 byte block (M Bytes/sec) With /dev/crypto “openssl speed –evp aes-128-cbc -engine cryptodev”  Ubuntu 11.04 Image 19.010 N/A Timesys 20.518 N/A SDK 4.1.0 LTIB 22.013 21.984 (errors reported) One can see that with SDK 4.1.0, performance is worse with crypto enabled.  This is probably due to the overhead of a faulty driver or incorrect implementation. The lowest number is for Ubuntu which could be attributed to the Unity GUI. Conclusion:  CAAM driver is not functional or I am using an improper testing procedure. Test Procedure: Board used is iMX6Q Sabre SDP Openssl was used for testing. Two command line commands were used, with and without the cryptodev engine. openssl speed –evp aes-128-cbc openssl speed –evp aes-128-cbc -engine cryptodev Openssl versions used in each build are slightly different: Ubuntu:              openssl 1.0.0e Timesys:              openssl  1.0.1e SDK 4.1.0:            openssl  1.0.1c Three versions of Linux were tested. Default kernel  4.0.0 with Ubuntu rootfs form image tarballs. Timesys kernel and root file system Kernel built with SDK 4.1.0 using LTIB with hardware crypto enabled Both 1 and 2 above did not have CRYPTODEV set in .config which contains the line “# CONFIG_CRYPTO_CRYPTODEV is not set” Option 3 had the line in .config as, “CONFIG_CRYPTO_CRYPTODEV=y” All three builds generate “/proc/crypto”  whose contents are attached.  A partial listing of /proc/crypto lists “caam” as a driver for all encryption methods supported.  Example printout for aes shown below: ame         : cbc(aes) driver       : cbc-aes-caam module       : kernel priority     : 3000 refcnt       : 1 selftest     : passed type         : ablkcipher async        : yes blocksize    : 16 min keysize  : 16 max keysize  : 32 ivsize       : 16 geniv        : eseqiv All three builds have “caam” and “enable_wait_mode=off” in the kernel command line in u-boot. Only option #3 contains both device file in “/dev/crypto” and an entry in “/proc/crypto” root@freescale ~$ cd / root@freescale /$ ls /proc/cr* /proc/crypto root@freescale /$ ls /dev/cr* /dev/crypto root@freescale /$ Test #1—Kernel build 4.1.0 openssl speed test without caam engine root@freescale ~$ openssl speed -evp aes-128-cbc                    Doing aes-128-cbc for 3s on 16 size blocks: 3471184 aes-128-cbc's in 2.94s Doing aes-128-cbc for 3s on 64 size blocks: 986286 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 249743 aes-128-cbc's in 2.93s Doing aes-128-cbc for 3s on 1024 size blocks: 64343 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 7954 aes-128-cbc's in 2.96s OpenSSL 1.0.1c 10 May 2012 built on: Sat Sep 7 18:47:34 PDT 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes     64 bytes    256 bytes 1024 bytes   8192 bytes aes-128-cbc 18890.80k    21040.77k    21820.55k 21962.41k    22013.23k root@freescale ~$ Test #2—Timesys kernel build of openssd without /dev/crypto # openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 3361305 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 924423 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 236623 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 59967 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 7514 aes-128-cbc's in 3.00s OpenSSL 1.0.1e 11 Feb 2013 built on: Thu Sep 5 21:54:37 EDT 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: armv7l-timesys-linux-gnueabi-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/here/workdir/factory/build_armv7l-times ys-linux-gnueabi/toolchain/usr/include -DL_ENDIAN -DTERMIO -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -Os -pipe -Wa,--noexecstack -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes     64 bytes    256 bytes 1024 bytes   8192 bytes aes-128-cbc 17926.96k    19721.02k    20191.83k 20468.74k    20518.23k #  Test #3—Ubuntu rootfs and kernel image root@linaro-ubuntu-desktop:/# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 3030128 aes-128-cbc's in 2.98s Doing aes-128-cbc for 3s on 64 size blocks: 852897 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 220572 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 55534 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 6846 aes-128-cbc's in 2.95s OpenSSL 1.0.0e 6 Sep 2011 built on: Wed Oct 5 01:45:02 UTC 2011 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall The 'numbers' are in 1000s of bytes per second processed. type             16 bytes     64 bytes 256 bytes   1024 bytes   8192 bytes aes-128-cbc 16269.14k    18195.14k    18822.14k 18955.61k    19010.99k root@linaro-ubuntu-desktop:/# Test #4—SDK 4.1.0 openssl speed test with “/dev/crypto” .  Note errors. root@freescale ~$ openssl speed -evp aes-128-cbc -engine cryptodev  invalid engine "cryptodev" 716715216:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(/usr/lib/engines/libcryptodev.so): /usr/lib/eng ines/libcryptodev.so: cannot open shared object file: No such file or directory 716715216:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 716715216:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: 716715216:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=cryptodev 716715216:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(libcryptodev.so): libcryptodev.so: cannot open shared object file: No such file or directory 716715216:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 716715216:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: Doing aes-128-cbc for 3s on 16 size blocks: 3572980 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 966002 aes-128-cbc's in 2.94s Doing aes-128-cbc for 3s on 256 size blocks: 255307 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 62967 aes-128-cbc's in 2.93s Doing aes-128-cbc for 3s on 8192 size blocks: 7890 aes-128-cbc's in 2.94s OpenSSL 1.0.1c 10 May 2012 built on: Sat Sep 7 18:47:34 PDT 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes     64 bytes    256 bytes 1024 bytes   8192 bytes aes-128-cbc 19055.89k    21028.61k    21786.20k 22006.21k    21984.65k root@freescale ~$ Answer: I do not know what is recent state of official Freescale BSP regarding CAAM, but to get OpenSSL working under CAAM support with reasonable acceleration  : https://community.freescale.com/message/318188#318188 The patches was used below : http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.0.35_4.0.0 Direct link to the patches: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.0.0&id=6068d7a77b2101c172fc2f003f90b1febbf99505 http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.0.0&id=b30237c79003223c6e8035d5be183cd4f0b469f9

         In recent months, some I.MX customers hope to compile u-boot-fw-utils in yocto and get fw_printenv & fw_setenv tools.          Although there are u-boot-fw-utils bblayers in Yocto recipes, by default, u-boot-fw-utils is not based on u-boot-imx, but downloaded from the u-boot source website, when using bitbake When u-boot-fw-utils compiles it, it will fail to compile.          For example: # cd  ~/imx-yocto-bsp-5.4.3_1.0.0 # DISTRO=fsl-imx-fb MACHINE=imx6sxsabresd source imx-setup-release.sh -b build_sabresd # bitbake u-boot-fw-utils -c compile          If changing .config to be mx6sxsabresd_optee_defconfig in the top directory of u-boot source code, new errors will occur, like descriptions in the link:          https://community.nxp.com/message/1318081?commentID=1318081#comment-1318081            The root cause is that the u-boot is not u-boot-imx.          If we did the test below, it is easy to validate it.      Compiling u-boot # bitbake u-boot-imx -c compile          After compilation is done, u-boot-imx source code will be released .      Changing u-boot source code of u-boot-fw-utils directory          Replace u-boot source code in u-boot-fw-utils directory with u-boot-imx source code. Then continue to compile u-boot-fw-utils # bitbake u-boot-fw-utils -c compile          We will find it can be compiled successfully. This shows that when u-boot-fw-utils is compiled, the downloaded u-boot source code must be u-boot-imx.          In order to achieve this, we need to add recipes to yocto's u-boot-imx, and we can successfully compile fw_printevn and fw_setenv through the bitbake command. Please follow these steps to add u-boot-fw-utils for i.mx to yocto! copy 2 files in attacments to ~/imx-yocto-bsp-5.4.3_1.0.0/sources/meta-imx/meta-bsp/recipes-bsp/u-boot cd ~/imx-yocto-bsp-5.4.3_1.0.0 run below comands # DISTRO=fsl-imx-fb MACHINE=imx6sxsabresd source imx-setup-release.sh -b build_sabresd # bitbake u-boot-imx-fw-utils -c compile # bitbake u-boot-imx-fw-utils -c install   Then you will get fw_printenv & fw_setenv [Comment]          If i.MX users are using other version of linux BSP, she only need to modify the following content of u-boot-imx-common_2019.04.inc to compile u-boot-fw-utils. …… LIC_FILES_CHKSUM = "file://Licenses/gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263"   UBOOT_SRC ?= "git://source.codeaurora.org/external/imx/uboot-imx.git;protocol=https" SRCBRANCH = "lf-5.4.y_v2019.04" SRC_URI = "${UBOOT_SRC};branch=${SRCBRANCH} \ " SRCREV = "228843cdf5435d4bd69f42a6015f78761ff4cc0d" ……          Then compile it following above steps.          Example for L4.14.98_2.0.0: 1.Copy u-boot-imx-common_2019.04.inc & u-boot-imx-fw-utils_2019.04.bb to ~/imx-release-bsp-4.14.98-2.0.0/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/u-boot/ 2.Rename files name according to u-boot version u-boot-imx-common_2018.03.inc     u-boot-imx-fw-utils_2018.03.bb 3.Modifying u-boot-imx-common_2018.03.inc In the directory, there is u-boot-imx_2018.03.bb file, open it, and find the link of u-boot and check sum, and use lines below to replace those lines in u-boot-imx-common_2018.03.inc In u-boot-imx_2018.03.bb file: …… LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://Licenses/gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263"   UBOOT_SRC ?= "git://source.codeaurora.org/external/imx/uboot-imx.git;protocol=https" SRCBRANCH = "imx_v2018.03_4.14.98_2.0.0_ga" SRC_URI = "${UBOOT_SRC};branch=${SRCBRANCH}" SRCREV = "87a19df5e462f1f63e8a6d2973c7fb9e95284d04" …… Then in u-boot-imx-common_2018.03.inc, there is the same contents as above: Save it and exit. Go back to the top directory of yocto: ~/imx-release-bsp-4.14.98-2.0.0 # cd ~/imx-release-bsp-4.14.98-2.0.0 # DISTRO=fsl-imx-fb MACHINE=imx6sxsabresd source fsl-setup-release.sh -b build_sabresd # bitbake u-boot-imx-fw-utils -c compile # bitbake u-boot-imx-fw-utils -c install          The same method can be used for other Linux BSP versions.       NXP TIC Team Weidong Sun 05/28/2020

Some of Chinese customer couldn’t normally download android source code from google site, here give a way to download android source from Mirror site of Tsinghua University. Preparations 1. Installing Ubuntu16.04.2 LTS Customer can download ubuntu-16.04.2-desktop-amd64.iso from https://www.ubuntu.com/download/desktop Then install it to VMware workstation player v12 or PC, after finishing installation, use “Software Update” to update system. In order to compile android9.0.0-2.0.0 BSP, necessary packages should also be installed on Ubuntu 16.04. $ sudo apt-get install gnupg $ sudo apt-get install flex $ sudo apt-get install bison $ sudo apt-get install gperf $ sudo apt-get install build-essential $ sudo apt-get install zip $ sudo apt-get install zlib1g-dev $ sudo apt-get install libc6-dev $ sudo apt-get install lib32ncurses5-dev $ sudo apt-get install x11proto-core-dev $ sudo apt-get install libx11-dev $ sudo apt-get install lib32z1-dev $ sudo apt-get install libgl1-mesa-dev $ sudo apt-get install tofrodos $ sudo apt-get install python-markdown $ sudo apt-get install libxml2-utils $ sudo apt-get install xsltproc $ sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 $ sudo apt-get install gcc-multilib g++-multilib $ sudo apt-get install subversion $ sudo apt-get install openssh-server openssh-client $ sudo apt-get install uuid uuid-dev $ sudo apt-get install zlib1g-dev liblz-dev $ sudo apt-get install liblzo2-2 liblzo2-dev $ sudo apt-get install lzop $ sudo apt-get install git-core curl $ sudo apt-get install u-boot-tools $ sudo apt-get install mtd-utils $ sudo apt-get install android-tools-fsutils $ sudo apt-get install openjdk-8-jdk $ sudo apt-get install device-tree-compiler $ sudo apt-get install gdisk $ sudo apt-get install liblz4-tool $ sudo apt-get install m4 $ sudo apt-get install libz-dev More detail, see Android_User’s_Guide.pdf ( android 9.0.0-2.0.0 BSP documents) 2. Downloading and unpacking Android release package [ For android 9.0.0_2.2.0, see commemts, please!] https://www.nxp.com/support/developer-resources/evaluation-and-developmentboards/ sabre-development-system/android-os-for-i.mx-applicationsprocessors: IMXANDROID?tab=Design_Tools_Tab -- P9.0.0_2.0.0_GA_ANDROID_SOURCE File name is imx-p9.0.0_2.0.0-ga.tar.gz # cd ~ # tar xzvf imx-p9.0.0_2.0.0-ga.tar.gz Downloading Android 9.0.0-2.0.0 source code 1. Getting repo # cd ~ # mkdir bin # cd bin # curl https://mirrors.tuna.tsinghua.edu.cn/git/git-repo > ~/bin/repo # chmod a+x ~/bin/repo # export PATH=${PATH}:~/bin 2. Modifying repo File Open ~/bin/repo file with 'gedit' and Change google address From REPO_URL = 'https://gerrit.googlesource.com/git-repo' To REPO_URL = ' https://mirrors.tuna.tsinghua.edu.cn/git/git-repo/ ' 3、Setting email address # git config --global user.email "[email protected]" # git config --global user.name "xxxx" [ Email & Name should be yours] 4、Modifying android setup script and Running it Open ~/imx-p9.0.0_2.0.0-ga/imx_android_setup.sh and add a line like below: ... ... if [ "$rc" != 0 ]; then echo "---------------------------------------------------" echo "-----Repo Init failure" echo "---------------------------------------------------" return 1 fi find -name 'aosp-p9.0.0_2.0.0-ga.xml'| \ xargs perl -pi -e 's|https://android.googlesource.com/|https://aosp.tuna.tsinghua.edu.cn/|g' fi ... ... Then save it and exit. # cd ~/ # source ~/imx-p9.0.0_2.0.0-ga/imx_android_setup.sh Then android_build directory is created at ~/ If fetching errors occur, like below, run “repo sync” again. # repo sync # export MY_ANDROID=~/android_build [Note] imx_android_setup.sh will be in charge of downloading all android source code. 5.Begin to compile android 9.0.0-2.0.0 BSP $ export ARCH=arm64 $ export CROSS_COMPILE=${MY_ANDROID}/prebuilts/gcc/linuxx86/aarch64/aarch64-linuxandroid-4.9/bin/aarch64-linux-android- $ cd ~/android_build/vendor $ cp -r ~/imx-p9.0.0_2.0.0-ga/vendor/* ./ $ cd ~/android_build $ source build/envsetup.sh $ lunch evk_8mm-userdebug $ make –j4 NXP TIC team Weidong sun 2019-05-05

In order to run the QT5 demos on i.MX6 you should follow the instructions on this link: Building QT for i.MX6 Some of the demos on the release such as  /examples/opengl/hellogl_es2,  consist of a group of multiple widgets appearing on the screen. Normally these demos should work OK in a windowed environment such as Wayland or X11. In the case of Linux only environment, the plugin that draws to the screen is called EGLFS. This plugin has the restriction that it only supports one single widget at a time on the screen surface. Then demos such as hellogl_es2 are *not intended* to work along with this plugin, and it will never work. The errors found when using EGLFS consist on: These issues can be seen in the Qt OpenGL examples.  "hellogl_es2" and "2dpaint" seem to display one rendered frame and then break --   "hellogl_es2" shows the QT word and bubbles, and the GUI is hidden, while  "2dpaint" just shows the openGL version without label. It seems that when including  a QGLWidget on a form, the QGLWidget would work OK, but the rest of the form would not appear. I couldn't click any buttons or do anything.   Along with these problems I would also see one or more of these error messages in the output:   * This plugin does not support setParent!   * This plugin does not support propagateSizeHints()   * QOpenGLContext::swapBuffers() called with non-opengl surface However other demos such as hellowindow work well with EGLFS because they are single widget.  Also all demos created with qtquick will work OK since all visual QML items are rendered as a single widget using the scene graph, a low-level, high-performance rendering stack, closely tied to OpenGL. This is better explained here: Qt5 QPainter vs. QML &amp; Scene Graph.

This article introduces how to connect a device via Bluetooth to the i.MX8M family of boards.

On i.MX8MP EVK, image is downloaded into eMMC/SD via OTG1, if customer wants to enable USB OTG2 on i.MX8MP for uuu tool. Pls find modification as attached.

HW: i.MX7 SabreSD SW: Android N7.1.1_1.0.0   There is KPP module on i.MX7, but NXP reference board didn't have it. We reworked a "keypad" and has the demo. Signal: For testing, launch an app in Android that can accept text input. KPP also supports multiple input, the "A" is showed by pressing "shift" + "a".   As a side note, 1. The input device driver is drivers/input/keyboard/imx_keypad.c 2. The input event driver is drivers/tty/vt/keyboard.c Original Attachment has been moved to: 0001-Enable-KPP-on-i.MX7.patch.zip

lspci output on iMX95EVK as PCIe RC Please take a good look at the snippet above. It is taken from the console of iMX95 after executing 'lspci' on a specific PCIe device[iMX8MM as PCIe EP] that gets enumerated as BDF[Bus Device Function] 01:00.0. This blog attempts to debunk the mystery revolving around the "Memory at " info of the lspci output. We will discuss what this address is, why it is used and its relevance in the PCIe world. This blog will focus on the following agendas: - 1. PCIe parent and child relationship in Linux Device Tree 2. What is CPU and PCIe address space and the need for address space translation?  3. Assigning resources to a PCIe device in Linux 4. How is address space translation carried out in Linux PCI Subsystem?   PCIe parent and child relationship in Linux Device Tree In the Linux device tree, PCIe parent and child relationship defines how PCIe Root Complex and Endpoints are positioned in the system. A PCIe parent node in the device tree represents a PCIe controller (Root Complex / Host-Bridge). Taking reference from a PCIe node present in the device tree source of imx95: -   pcie@4c300000 {                         compatible = "fsl,imx95-pcie";                         reg = <0x00 0x4c300000 0x00 0x10000 0x00 0x4c360000 0x00 0x20000 0x00 0x60100000 0x00 0xfe00000>;                         reg-names = "dbi\0atu\0config";                         #address-cells = <0x03>   …  }   pcie@4c300000 represents a Designware PCIe controller Root Complex which is a parent to the devices/bridge that will be connected to it. -- 'compatible' property identifies the specific PCIe controller. Its corresponding driver resides in drivers/pci/controller/dwc/pci-imx6.c -- 'reg' property specifies the memory mapped registers of the PCIe controller. Child nodes under PCIe RC represent devices on the PCIe bus. They can be fixed function devices like Wi-fi, Ethernet, NVMe or they can be PCIe bridges which further can have devices connected to it. Taking reference from 'arch/arm64/boot/dts/freescale/imx95.dtsi'   pcie_4ca00000: pcie@4ca00000 {                         compatible = "pci-host-ecam-generic";                         reg = <0x0 0x4ca00000 0x0 0x100000>;                         /* Must be 3. */              …              …              enetc_port0: ethernet@0,0 {                                 compatible = "fsl,imx95-enetc";                                 reg = <0x000000 0 0 0 0>;                                 clocks = <&scmi_clk IMX95_CLK_ENET>,                                          <&scmi_clk IMX95_CLK_ENETREF>;                                 clock-names = "ipg_clk", "enet_ref_clk";                                 nvmem-cells = <&eth_mac0>;                                 nvmem-cell-names = "mac-address";                                 status = "disabled";                         }; }   ethernet@0,0 is a PCIe device at bus 0, device 0, function 0. It is a child of PCIe RC which is memory mapped at 0x4ca00000   These child devices/bridges can either be dynamically discovered using PCI enumeration or they can be statically described in a device tree as seen in the device-tree snippet above in which "ethernet@0,0" entry statically tells the RC that the ethernet child device is connected to it. These child nodes are nested within a PCI parent node of the device tree as seen in the above example.   What is CPU and PCIe address space and the need for address space translation ? CPU address space is the system's physical memory map as seen by the processor. Example of CPU Physical Address Space viewed by Cortex-A55 on iMX95:-   Start address      End address    Module 0x48000000       0x4812FFFF    GIC Programming registers 0x4AA00000      0x4AAFFFFF    Neutron SRAM 0x4AC10000      0x4AC1FFFF    Camera domain block control 0x4E080000       0x4E08FFFF    DDR Controller This address space is kind of a global system view which is managed by system firmware/OS. These addresses are fixed by hardware-design. On the other hand, PCIe address space is local to PCI bus, managed by PCIe subsystem. The  addresses in this space are dynamically assigned. An example of PCIe address space that could look like the following:- 0x00000000   -    0x0FFFFFFF 0x10000000   -    0x1FFFFFFF 0x20000000   -    0x2FFFFFFF It is evident from the above explanation that CPU and PCIe address space operate in a separate and independent address domains. So the CPU cannot access the space of PCIe device unless a translation mechanism is in place. In one of the upcoming sections we will get to that as well but please spare a few minutes and ponder the question below:- Question : Why do you need separate address spaces for CPU and PCIe? Answer : One of the major reasons is modularity. We have separate spaces so that PCIe devices can be designed independently of the CPU architecture. Same card will work in different system. It will always have the flexibility of CPU remapping the PCIe space as and when needed. Also, different address spaces prevent devices to access arbitrary system memory. Based on the discussion in this section, it is evident that the PCIe address space is inherently different from the CPU address space and truth be told- it has its advantages. Therefore we need an entity to translate to/fro these address spaces. Here comes 'iATU' - Internal Address Translation Unit. On iMX SOCs, these hardware units are responsible for carrying out the address translation. These units are a part of Synopsys DesignWare PCIe Controller, providing programmable address translation windows for inbound and outbound transactions. For the readers who are uninitiated on the inbound and outbound transactions in pcie, please spare some time go through this technical blog - Understanding PCIe Outbound/Inbound windows with a use-case - NXP Community Note: - Address translation simply ensures that the CPU can access a PCIe device's memory and vice-versa.   Up until here, the readers must have got a basic picture of PCIe Address Translation. Before jumping into the nitty-gritty of this translation in the Linux PCI subsystem, let's discuss how the resources are assigned to a PCIe device.   Assigning resources to a PCIe device in Linux PCIe devices do not have a direct CPU instruction interface so they communicate through memory-mapped regions. Devices need memory for DMA operations or for MSI/MSIX interrupts. Different devices have different needs, so resources in PCIe could be MMIO where device registers are mapped or memory regions needed for DMA transfer. In linux, pci_assign_resource function of PCI subsystem is responsible for assigning IO and memory resources to the PCIe devices during system initialisation after PCIe devices are enumerated. It is called for all the devices on a PCI bus and based on the PCI devices' resource requirement, it assigns them. But how does the PCI subsystem in linux figure out what resources does the PCIe devices need ? - Every PCIe device has a configuration space defined by the PCIe specification. This includes   BAR[Base Address Registers] - To indicate what type of resource[IO/Mem] does  the device needs and the size of resource. Capabilities - To broadcast the device capabilities such as MSI Interrupts, ASPM low power states etc. Reading the BARs from the PCIe device will tell us what kind and size of the resources are needed by the device. // To determine the size of resource from the BAR of PCIe device:- Step-1: Write all 1's to the target BAR register. Step-2: Read back the value and clear the lower 4 bits (for a memory BAR) or 2 bits (for an I/O BAR), as these are status bits, not part of the size calculation Step-3 Perform Bitwise NOT on the value and add 1 to it. Step-4: The returned value indicates the size. Taking an example to understand this:- Let's assume that after reading back the value in Step-2 above, the BAR returns 0xFFFFF000. The lower 4 bits are already cleared. Step-3  we perform bitwise NOT on the value -> ~(0xFFFFF000) = 0x00000FFF Adding 1 to it : 0x00000FFF + 1 = 0x00001000 The obtained value 0x1000 = 4096 bytes indicates the size, meaning the BAR requires a 4KB memory region. // To determine the type of resource from the BAR of PCIe device:-   A Base Address Register (BAR) in PCI configuration space: Bit 0 → Resource type: 1 = I/O space 0 = Memory space For memory BARs: 00 = 32-bit 10 = 64-bit Bits 1–2 → Addressing type: Bit 3 → Prefetchable flag   Interpreting the value 0xFFFFF000, we get:-   Bit 0 = 0 → Memory space Bits 1–2 = 00 → 32-bit address Bit 3 = 0 → Prefetchable Upper bits → Base address (after masking)   pci_read_bases [drivers/pci/probe.c] in linux PCI subsystem is responsible to figure out the BAR memory size and type requirement during device enumeration. Needless to say, the above sequence of writing to the Endpoint's BAR and identifying the size and type of resource is executed on the PCIe RC. We have the following setup :- iMX95 <------> iMX8MM [RC]                     [EP] After PCIe RC has the size of the BAR that is required, the pci_assign_resource function allocates a memory range and then sets up translation from this memory range to the PCIe address space. we started this blog with a snippet, that shows the following lspci log:-   Referring to the above, please note that the RC driver has allocated: - 0x910100000 - 0x910110000 as the non-prefetchable memory address range, size=64KB The above memory address range is in the PCIe 1 Outbound space memory mapped on iMX95 SoC: -   The range 0x910100000 - 0x910110000 will be mapped to the PCIe address space of the End-point. This essentially means that if the cpu generates any address in between this range [inclusive of start and end-address], a PCIe TLP will be sent by the PCIe controller on the RC to the End-point on the bus. It could be a read or write to the memory of Endpoint. The address to write/read would be decided based on the address space translation. We shall discuss in-detail how this translation is exercised in the linux kernel in the next section.   How is address space translation carried out in Linux PCI Subsystem?   We start with some important questions: - Where is the range 0x910100000 - 0x910110000 specified ? How does the kernel know that it has to map the PCIe 1 Outbound space and not PCIe2 Outbound space or any other address space for that matter? -- Like all good things in Linux, this also starts with a 'device tree binary'. A dtb is passed by Uboot to the kernel so that it could get the hardware description of our board. Since we are using Torradex 's Verdin iMX95 EVK Board as Root Complex, this is the dtb that we are using - imx95-19x19-verdin-adv7535.dtb I will be attaching a working dtb with this blog so that the readers can use it if needed. This dtb includes - arch/arm64/boot/dts/freescale/imx95.dtsi Let's have a look at a particular pcie node of interest: -   'ranges' property is the answer to the questions that were asked in this section earlier.  - This property defines the address translation rules between the parent's address space and the child PCI address space.   Note:- This blog focuses only on 'ranges' property since it is relevant to our discussion. So the readers are advised to look elsewhere if they want to understand other device-tree properties of the PCIe node.  Let's decode the ranges property : It has the following format:- <PCI address><CPU address> <PCI size>      3 cells               2 cells             2 cells             So one entry will have 7 cells. In our dtsi we have 2 entries. 1st is for IO space translation and the 2nd is for Mem space translation. Referring to the second entry  :-   0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000 |------PCI address---------------| |-CPU address-| |---PCI size---|   The above gives us the following info: - MEM Space prefetchable <   0x82000000 0x00 0x10000000   // PCIe address: 0x10000000   0x09 0x10000000              // CPU/system address: 0x910000000   0x00 0x10000000              // Size: 256MB >;   0x82000000 = 1000 0010 0000 0000 0000 0000 0000 0000   Bits 31–30 (10) → Configuration space type: This indicates memory space. Bit 29 (0) → Non-relocatable Bit 28 (1) → Prefetchable = No (0 means non-prefetchable) Bits 27–24 (0010) → Address space type = Memory So, 0x82000000 means: PCI memory space Non-prefetchable 32-bit address space   Note:- For those of you wondering why lspci output mentions [size=64K] and dts says 256 MB. This is because 256MB is the maximum address space available for the PCIe devices. It is upto the Endpoint device, how large address space does it require and accordingly it gets allocated.     Similary IO space translation is also created from the 1st entry in 'ranges':- < 0x81000000 0x00 0x00 → PCI I/O address: 0x00000000 0x00 0x6ff00000 → CPU/system address: 0x6ff00000 0x00 0x100000 → Size: 1MB >;   we observe the same in the dmesg output of iMX95 Verdin EVK Linux console:-   So the MEM Space mapping is from CPU Address 0x910000000 - 0x091fffffff translated to PCIe Address 0x10000000 - 0x1fffffff It is only fair that we mention the driver that uses the 'ranges' property. The 'ranges' property get parsed in "pci_parse_request_of_pci_ranges -> devm_of_pci_get_host_bridge_resources" of "drivers/pci/of.c"     devm_of_pci_get_host_bridge_resources, for each range automatically  manages the memory allocated for these resources. It ensures that the resources are freed when the device is detached or the driver is removed. We have got the answer what & why is the cpu and pci address range the way it is. But in the lspci, you see 0x910100000 and not 0x910000000 which is what the intended start range is supposed to be as per the dtb. Why is that ? To answer this - we need to go back to the PCIe device enumeration. During PCIe enumeration, in the linux PCI driver the bar resources were determined like we had discussed earlier and then the PCI core driver may assign addresses keeping alignment requirements in mind that is why EP's BAR0 was assigned a PCI bus address as 0x10100000 with a 1MB[0x100000] offset from 0x10000000. And keeping the device tree pci translation window in mind:- 0x10100000 translates to 0x910100000 This translation doesn't happen on its own. Device tree binary just mentions the translation window specifics such as the CPU address space to translate to and the PCI address space to translate from. The actual translation is done via iATU. This is done in the dw_pcie_iatu_setup function of drivers/pci/controller/dwc/pcie-designware-host.c by creating the outbound window using dw_pcie_prog_outbound_atu function. Translation is configured on the RC successfully but there is still something missing. .. .. Inbound window !! Without an inbound window on the Endpoint i.e iMX8MM, the writes/reads to 0x910100000 would be meaningless. On iMX8MM we are using PCI Endpoint test driver which is quite popular in linux community and I would urge the readers to visit this page if they want more info - 9. PCI Endpoint Framework — The Linux Kernel documentation pci_epc_map_addr function in drivers/pci/endpoint/pci-epc-core.c creates inbound window by mapping PCI address [0x10100000] to physical address in EP's memory. That's how the reads and writes go through. If there's no Inbound window configured, something like this unfolds in case of read:-   So now everything is set up. Translation windows are configured in the PCI drivers and you are at linux console. The following sequence unfolds when the CPU issues a memory read:-   In case of memory writes:- The following happens on the Endpoint: - The beauty is that this entire translation happens transparently in hardware - your driver just reads/writes to the CPU address, and the PCI host controller handles all the translation automatically! -- How do we test the Address Translation ?   To test reads and writes, either we can make some changes in the driver itself or use devmem5 user-space binary. We are going to make minor driver side changes on iMX8MM and use devmem5 on the RC. iMX8MM is the PCIe Endpoint and we are using end-point test driver to configure it as such. If  you want to do the same, please follow this blog - Enabling PCIe End-point framework on iMX95 torradex board and iMX8MM EVK - NXP Community On the contrary if you want to make iMX95 as RC and iMX8MM Endpoint, feel free to follow this blog - How to configure iMX95EVK as PCIe Endpoint and test it using PCIe Endpoint Test Framework - NXP Community Two things we are going to do next: - 1. On iMX8MM EP, we are going to write some random values  in the drivers/pci/endpoint/pci-epf-core.c, make the following changes in pci_epf_alloc_space function: -     'space' is the virtual address and 'phys_addr' is the physical address that is contiguous. Please note that it is a crude way to test this translation. There are better ways to do it. Build the kernel after the changes and boot the board with it. Make iMX8MM an Endpoint using PCI Endpoint Test Framework. 2. On iMX95 Verdin EVK [PCIe RC], we are going to read the address 0x910100000 using devmem5 to verify that we can observe the same data on the RC.   That's it for today. This was a long blog and if you feel overwhelmed by the details, please feel free to drop in the DMs or comments so that I can try to make it easier. Until next time! Gaurav Sharma  

In the i.MX 8M Plus LPDDR4 EVK board there are two Type-C port design. For the port0 is used to power supply no usb function, for the port1 used for USB function but without PD function. But in customer’s design, customer only use one USB design on their board, how to make the one USB work with the PD and USB function, we need to make the hardware design and software modify. This article only give method to realized it and have tested and realized the port1 PD function. 1 Introduction of the USB interface on i.MX8MP         There are two USB 3.0 TypeC controllers with integrated PHY interface on the i.MX8MP: Backward compatibility with USB 2.0 Spread spectrum clock support   The USB on the i.MX8MP supports USB3.0 and is compatible with USB2.0 downward. We can see that the upper layer is the universal layer for USB 2.0 and USB 3.0 operations. This is a common interface, buffer management block, list processor, used to schedule and control the status register (CSR) function： USB 2.0 physical layer and MAC layer USB 3.0 physical layer, link layer and MAC layer   Features of USB 3.0: USB compliant version 3.0 (xHCI compatible) Supports operation as a stand-alone USB host controller USB dual role operation, configurable as host or device Ultra high speed (5Gbit/s), high speed (480Mbit/s), full speed (12Mbit/s) and low speed (1.5Mbit/s) operation. Support independent single port USB operation Support for four programmable bidirectional USB endpoints Support system memory interface with 40 bit addressing capability   2 Design of USB on Development Board         The i.MX 8M Plus processor includes two USB 2.0/3.0 controllers and two integrated USB PHYs. USB supports both running as an independent USB host controller and dual role USB operation, and can be configured as a host or device. Therefore, the design of these two functions is implemented on the development board of i.MX8MP.   We can see that on the development board, one USB1 is used for the USB Type-C port and the other USB2 is used for the USB 3.0 host port. USB Type-C port 0 (J5) is only used for power supply. It does not support USB data transfer. It is the only power port, so the system must always be powered.   On the CPU side of the schematic diagram, we can also see that USB1 is the port for USB Type-C, and USB2 is the host for USB3.0.    USB1 is designed as USB Type-C:   USB2 USB3.0 Host design：   Power design of the USB Type-C port：   3 Only one USB interface is used in the design (compatible with both USB PD function and USB dual roles function)         Two USB Type-C ports are used on our development board. One is used to power the board separately, and the other is used as the function of USB Type-C. However, due to the limited design cost and chip layout and space on the board, some customers will use a USB interface to realize the dual role function of power supply and USB. How to achieve this? USB Device(Download mode)：     USB　Host mode（power+device　Need the hub support PD function）:     The specific implementation and design are as follows: 3.1 Hardware realize PTN5110 To realize the USB Type-C support power supply function, PTN5110 (USB PD TCPC PHY IC) chip is required to realize Type-C data logic and power control and management. The selection of PTN5110 is critical and important.   PTN5110 is a single port USB PD (power supply) PHY IC that conforms to TCPC. It integrates Type-C configuration channel (CC) interface and USB PD physical layer functions into Type-C port manager (TCPM) that handles PD policy management. It complies with USB PD, Type-C and TCPC specifications.   The IC is mainly aimed at applications in system platforms (such as laptops, desktops, Chromebooks, tablets, flip notebooks, etc.). Other application cases may be feasible, depending on the application architecture, such as docking stations, displays, accessories, cable adapters, smartphones, etc.   It can support various Type-C applications: Sink, Source, Sink with accessory support or DRP. It executes Type-C CC simulation part (i.e. Rd/Rp/Ra detection, Rd/Rp indication) and PD Tx/Rx PHY and protocol state machine. PTN5110 supports TCPM in the system implementation of the following PD roles.   PTN5110 integrates VCONN load switch, programmable current limit, reverse leakage current blocking and over temperature protection (OTP). It is equipped with two enable control outputs to control the load switch/FET in the VBUS pull and/or sink path. It can also perform VBUS voltage monitoring/measurement, VBUS forced discharge and discharge discharge.   PTN5110 provides the main IO related functions for the main processor/TCPM, so that Type-C/PD interfaces can be easily controlled and managed through the TCPC interface.   PTN5110 supports a wide range of power input voltages, providing platform integrators with great flexibility. PTN5110 can run on VBUS to support specific system use cases that require no power operation.https://www.nxp.com/products/interfaces/usb-interfaces/usb-type-c/usb-pd-phy-and-cc-logic/usb-pd-tcpc-phy-ic:PTN5110   The design only use the USB1：   Here, it is required to weld R53 or R54. You can refer to this design completely. 2 Software modify Modify the BPS of the software: Take the newest released Linux 5.15.32_2.0.0​ as example: In the u-boot /board/freescale/imx8mp_evk/imx8mp_evk.c     It can be seen that the PD function of the port is turned off, so if you want to use USB1 for power supply, remove the following commands and turn on the PD function of USB1. “-   .disable_pd = true,” Use the above action to enable Port1 PD function. Kernel section modify： Kernel section modify towards to PTN5110. Type-C Configure channel (CC) interface： root/drivers/usb/typec/tcpm/tcpci.c @@ -524,6 +524,7 @@ static int tcpci_vbus_force_discharge(struct tcpc_dev *tcpc, bool enable)  static int tcpci_set_vbus(struct tcpc_dev *tcpc, bool source, bool sink)  {        struct tcpci *tcpci = tcpc_to_tcpci(tcpc); +      unsigned int reg;        int ret;          if (tcpci->data->set_vbus) { @@ -533,16 +534,20 @@ static int tcpci_set_vbus(struct tcpc_dev *tcpc, bool source, bool sink)                         return ret < 0 ? ret : 0;        }   +      ret = regmap_read(tcpci->regmap, TCPC_POWER_STATUS, &reg); +      if (ret < 0) +              return ret; +        /* Disable both source and sink first before enabling anything */   -       if (!source) { +      if (!source && (reg & TCPC_POWER_STATUS_SOURCING_VBUS)) {                 ret = regmap_write(tcpci->regmap, TCPC_COMMAND,                                     TCPC_CMD_DISABLE_SRC_VBUS);                 if (ret < 0)                         return ret;        }   -       if (!sink) { +      if (!sink && (reg & TCPC_POWER_STATUS_SINKING_VBUS)) {                 ret = regmap_write(tcpci->regmap, TCPC_COMMAND,                                     TCPC_CMD_DISABLE_SINK_VBUS);                 if (ret < 0)   Type-C port manager managed by PD (TCPM)： root/drivers/usb/typec/tcpm /tcpm.c @@ -340,6 +340,7 @@ struct tcpm_port {         */        bool vbus_vsafe0v;   +      bool vbus_keep;        bool vbus_never_low;        bool vbus_source;        bool vbus_charge; @@ -3662,7 +3663,8 @@ static void tcpm_reset_port(struct tcpm_port *port)        port->rx_msgid = -1;          port->tcpc->set_pd_rx(port->tcpc, false); -       tcpm_init_vbus(port);     /* also disables charging */ +      if (!port->vbus_keep) +              tcpm_init_vbus(port);  /* also disables charging */        tcpm_init_vconn(port);        tcpm_set_current_limit(port, 0, 0);        tcpm_set_polarity(port, TYPEC_POLARITY_CC1); @@ -5834,6 +5836,9 @@ static void tcpm_init(struct tcpm_port *port)          port->tcpc->init(port->tcpc);   +      port->vbus_present = port->tcpc->get_vbus(port->tcpc); +      if (port->vbus_present) +              port->vbus_keep = true;        tcpm_reset_port(port);          /* @@ -5872,7 +5877,10 @@ static void tcpm_init(struct tcpm_port *port)         * Some adapters need a clean slate at startup, and won't recover         * otherwise. So do not try to be fancy and force a clean disconnect.         */ -       tcpm_set_state(port, PORT_RESET, 0); +      if (!port->vbus_keep) +              tcpm_set_state(port, PORT_RESET, 0); + +      port->vbus_keep = false;  }    static int tcpm_port_type_set(struct typec_port *p, enum typec_port_type type) Note: The software just needs to modify these two parts. You also need to mention to the proper the I2C port use, if not proper the driver of the PTN5110 can not driver. 4 Test         In our i. MX8MP EVK development board show that R53 and R54 in the USB1 part of our development board are in DNP status, so VBUS_ IN is disconnected and no power comes in. Here, connect R53 or R54 with solder, so that VBUS_ IN, the power comes in again. After the power is connected. The board can be powered through USB1. 4.1 Download images to the emmc on the Board: Power from the USB1, set the boot mode to serial download mode, then go to download images finished. 4.2 Boot up the board from the EMMC Change the boot mode to boot up from EMMC，the board boot up, the log file is as following show：   It will stop at the TCPC for the section of PTN5110 driver. By default, the PD function of port1 in the u-boot is turned off, so if you want to use USB1 for power supply, remove the following commands and turn on the PD function of USB1. “-   .disable_pd = true,” After the PD function is turned on, the board can be started normally, but the whole part running to the kernel will be powered down, so the kernel part of PTN5110 still needs to be modified. After the patch modification of the above kernel part, the board can run normally.         I also did the same experiment on the i.MX8MM EVK development board. The same phenomenon occurs when the kernel starts. Therefore, similar modifications to the above i. MX8MP can work normally. Summary: In one word i.MX8MP and i.MX8M series can realize the role of using a USB for power supply and USB Dual. The hardware design refers to our development board, and we must use the logic chip PTN5110. For software, refer to the above code modification.  

This guide is about how to use EVIS to create user nodes and kernels in OpenVX to implement image processing on NPU(i.MX8MP)/GPU(i.MX8QM). Take gaussian filter as an example. It is tested on i.MX8QM and i.MX8MP. User Node Creation from User Kernel 1. Define a user node Register a user kernel by its ID or name For example, #define VX_KERNEL_NAME_GAUSSIAN "com.nxp.extension.gaussian" #define VX_KERNEL_ENUM_GAUSSIAN 100 Get the kernel reference by the ID or name For example, vx_kernel kernel = vxGetKernelByName(context, VX_KERNEL_NAME_GAUSSIAN); vx_kernel kernel = vxGetKernelByEnum(context, VX_KERNEL_ENUM_GAUSSIAN ); Create a user node vx_node node = vxCreateGenericNode(graph, kernel); Set input/output node parameters For example, vx_status status = vxSetParameterByIndex(node, index++, (vx_reference)in_image); status |= vxSetParameterByIndex(node, index++, (vx_reference)out_image); 2. Create InputValidator/OutputValidator functions for the node The validators are only used for graph verification. For example, static vx_status VX_CALLBACK vxGaussianInputValidator(vx_node node, vx_uint32 index) static vx_status VX_CALLBACK vxGaussianOutputValidator(vx_node node, vx_uint32 index, vx_meta_format metaObj) ToDo: a. InputValidator: Get the reference to the parameter object   vx_parameter paramObj = NULL; vx_image imgObj = NULL; paramObj=vxGetParameterByIndex(node, index); vxQueryParameter(paramObj, VX_PARAMETER_REF, &imgObj, sizeof(vx_image)); Check meta-data restriction vxQueryImage(imgObj, VX_IMAGE_FORMAT, &imgFmt, sizeof(imgFmt)); Check consistency with other parameters if (VX_DF_IMAGE_U8==imgFmt) status = VX_SUCCESS; else status = VX_ERROR_INVALID_VALUE; b. OutputValidator Set the meta_format object with expected meta-data for the output status |= vxSetMetaFormatAttribute(metaObj, VX_IMAGE_FORMAT, &imgFmt, sizeof(imgFmt)); status |= vxSetMetaFormatAttribute(metaObj, VX_IMAGE_WIDTH, &width, sizeof(width)); status |= vxSetMetaFormatAttribute(metaObj, VX_IMAGE_HEIGHT, &height, sizeof(height)); 3. Create Initializer function for the node. The initializer is used to specify workdim, global work size and local work size for the user kernel. These parameters are similiar to that in OpenCL. For example,                                                                                    /* workdim, globel offset, globel scale, local size, globel size */ vx_kernel_execution_parameters_t shaderParam = {2,               {0, 0, 0},        {0, 0, 0},        {0, 0, 0},   {0, 0, 0}}; vx_status VX_CALLBACK vxGaussianInitializer(vx_node nodObj, const vx_reference *paramObj, vx_uint32 paraNum) Set attribute to the node vxSetNodeAttribute(nodObj, VX_NODE_ATTRIBUTE_KERNEL_EXECUTION_PARAMETERS, &shaderParam, sizeof(vx_kernel_execution_parameters_t)); Note: The links below are guides about OpenCL on GPU, which are helpful to understand OpenVX implemented on GPU/NPU. OpenCL Work Item Ids: Global/Group/Local OpenCL Programming Guide OpenCL Resources Introduction to OpenCL 4. Create Deinitializer function for the node (Optional) It is used to de-allocate memory allocated at initializer. User Kernel on NPU/GPU Creation 1. Create description of a user kernel For example, vx_kernel_description_t vxGaussianKernelVXCInfo = { VX_KERNEL_ENUM_GAUSSIAN, VX_KERNEL_NAME_GAUSSIAN, nullptr, vxGaussianKernelParam, (sizeof(vxGaussianKernelParam)/sizeof(vxGaussianKernelParam[0])), vxGaussianValidator, nullptr, nullptr, vxGaussianInitializer, nullptr }; 2. Register the new kernel For example, static vx_kernel_description_t* kernels[] = { &vxGaussianKernelVXCInfo, }; 3. Write kernel source implemented on NPU/GPU For example, char vxcKernelSource[] = { "#include \ \n\ \n\ \n\ __kernel void gaussian\n\ ( \n\ __read_only image2d_t in_image, \n\ __write_only image2d_t out_image \n\ ) \n\ { \n\ int2 coord = (int2)(get_global_id(0), get_global_id(1)); \n\ int2 coord_out = coord; \n\ vxc_uchar16 lineA, lineB, lineC, out;\n\ int2 coord_in1 = coord + (int2)(-1, -1);\n\ VXC_OP4(img_load, lineA, in_image, coord_in1, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in2 = coord + (int2)(-1, 0);\n\ VXC_OP4(img_load, lineB, in_image, coord_in2, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in3 = coord + (int2)(-1, 1);\n\ VXC_OP4(img_load, lineC, in_image, coord_in3, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int info = VXC_MODIFIER_FILTER(0, 13, 0, VXC_FM_Guassian, 0);\n\ VXC_OP4(filter, out, lineA, lineB, lineC, info); ;\n\ VXC_OP4_NoDest(img_store, out_image, coord_out, out, VXC_MODIFIER(0, 13, 0, VXC_RM_TowardZero, 0)); \n\ }\n\ " }; Note: the source is written by EVIS instructions with less latency. But the EVIS instructions are limited. These fucntions defination can be found in "cl_viv_vx_ext.h" located at "/usr/include/CL/cl_viv_vx_ext.h". Read back the processed data by GPU/NPU to check if the operations are correct. For example, status = vxCopyImagePatch(vx_out_image, &rect, 0, &addressing, data2, VX_READ_ONLY, VX_MEMORY_TYPE_HOST); 4. Build the NPU/GPU source code runtime For example, programObj = vxCreateProgramWithSource(ContextVX, 1, programSrc, &programLen); vxBuildProgram(programObj, "-cl-viv-vx-extension"); 5. Add kernel to the program For example, ... kernelObj = vxAddKernelInProgram(programObj, kernels[i]->name, kernels[i]->enumeration, kernels[i]->numParams, kernels[i]->validate, kernels[i]->initialize, kernels[i]->deinitialize ); ... for(vx_uint32 j=0; j < kernels[i]->numParams; j++) { status = vxAddParameterToKernel(kernelObj, j, kernels[i]->parameters[j].direction, kernels[i]->parameters[j].data_type, kernels[i]->parameters[j].state ); 6. Finalize the kernel creation For example, status = vxFinalizeKernel(kernelObj); Exercise The example is attached. You can build and test it on i.MX8QM or i.MX8MP. Results on i.MX8QM: References: Khronosdotorg/resources.md at master · KhronosGroup/Khronosdotorg · GitHub  Further Reading: OpenVX Vision Image Extension API Introduction - Basic API OpenVX Vision Image Extension API Introduction - DP Dot Products

After Nokia acquisition of Trolltech, QT has become an even more interesting framework/tool for UI and graphics development. The new release 4.6 can be obtained under LGPL license and comes with a new integrated IDE for software development (QT Creator) with many demos, some of them using OpenGL. In order to create an environment to create, simulate and cross-compile, it's needed to build three versions of QT: Qt/X11, qmake-x11. This is the Qt version that you will be using on your PC. It is also used for building the tools, such as Designer and Linguist. Qt/QVFb, qmake-qvfb. This is an embedded Qt configuration that runs on host, but works with the virtual framebuffer instead of the actual screen. It let’s you emulate the target system, but run your code on your host machine. Qt/target, qmake-target. This is the embedded Qt configuration that runs on your target platform. This is what you use to build an actual application running on your embedded device. On Host you need TO install following package (for Ubuntu distri) to install this QT toolsuit: [X] libx11-dev [X] libpng-dev [X] libjpeg-dev [X] libxext-dev [X] x11proto-xext-dev [X] qt3-dev-tools-embedded [X] libxtst-dev Building Qt/X11 Extract downloaded Qt package (from here) and install it by running: ./configure make sudo make install Qt will be installed on /usr/local/Trolltech/Qt-version directory. We also need to build qvfb tool that will provide virtual framebuffer for X11. To build and install it run: cd tools/qvfb make sudo make install qvfb will be installed on /usr/local/Trolltech/Qt-version/bin directory. Building Qt/QVFb To build Qt/QVFb, will be needed some parameters on configure file. Extract again Qt package on other folder and build as following: ./configure -embedded -qt-gfx-qvfb -qt-kbd-qvfb -qt-mouse-qvfb -prefix /usr/local/Trolltech/Qt-qvfb-version make sudo make install Used parameters: -qt-gfx-qvfb, the graphics driver will be for QVFb, i.e., the virtual framebuffer. -qt-kbd-qvfb, the keyboard input will come from the QVFb. -qt-mouse-qvfb, the mouse input will come from the QVFb. -prefix /usr/local/Trolltech/Qt-qvfb-version, the prefix is used to separate the QVFb version of embedded Qt from the target version. Testing QVFb So far you have two versions of Qt: 1. Qt/X11 built for PC host using X11 and located at /usr/local/Trolltech/Qt-version 2. Qt/QVFb built for PC host using Qt virtual framebuffer and located at /usr/local/Trolltech/Qt-qvfb-version Call qvfb from X11 version cd /usr/local/Trolltech/Qt-version/bin ./qvfb & A simple virtual framebuffer will open. To change screen configuration and add a skin, click in "file -> configure". The following window will open: i.e., choose ClamshellPhone and click ok. A cell phone skin will open. On QVFb version, there are a lot of example applications that can be run using Qt virtual framebuffer. Let's open fluidlauncher demo: cd /usr/local/Trolltech/Qt-qvfb-version/demos/embedded/fluidlauncher ./fluidlauncher -qws The argument -qws is used to inform that the application will run on Qt virtual framebuffer. Building Qt/Target To build Qt for target (i.MX), it's necessary to build Ltib with some required packages. In this example, a kernel and rootfs will be built for i.MX51 EVK with the following extra packages. [x] amd-gpu-bin-mx51 [x] freetype [x] glib2 [x] gstreamer [x] gstreamer-plugins-base [x] gstreamer-plugins-good [x] gstreamer-plugins-bad [x] gstreamer-plugins-ugly [x] libxml2 [x] tslib [x] zlib If you are building for any other i.MX processor, you don't need the "amd-gpu-bin-mx51" option. After build ltib, make a symbolic link /tftpboot/ltib pointing to your rootfs folder. It's needed to make the i.MX libs and incs available to qmake. ln -s <rootfs folder dir> /tftpboot/ltib Restart nfs server. If using Ubuntu, the command is: sudo /etc/init.d/nfs-kernel-server restart Extract downloaded Qt package on a new folder. Export the crosscompiler path. Usually it's located at /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin: export PATH=$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin If you are building Qt for i.MX51 Download the mkspec package and extract the folder linux-mxc-g++ under <Qt source code folder>/mkspecs/qws Configure, build and install with the following commands: ./configure -embedded arm -xplatform qws/linux-mxc-g++ -release -prefix /usr/local/Trolltech/Qt-target-version -qt-gfx-linuxfb -qt-kbd-tty -qt-mouse-tslib -opengl es2 -little-endian -host-little-endian make sudo make install For targets without 3D engine support If you are building Qt for a target that doesn't support OpenGL, i.e., i.MX25, 233: Download the makespecs_no3D package and extract the folder linux-mxc-g++ under <Qt source code folder>/mkspecs/qws Configure, build and install with the following commands: ./configure -embedded arm -xplatform qws/linux-mxc-g++ -release -prefix /usr/local/Trolltech/Qt-target-version -qt-gfx-linuxfb -qt-kbd-tty -qt-mouse-tslib -little-endian -host-little-endian make sudo make install Copy Cross Qt to target's RFS The crosscompiled version of Qt will be located on your host machine as indicated on -prefix, in this case /usr/local/Trolltech/Qt-target-version Copy Qt-target-version folder to rootfs: cd /tftpboot/usr/local mkdir Trolltech cd Trolltech cp -a /usr/local/Trolltech/Qt-target-version . Now it's ready to use. On target, run: /usr/local/Trolltech/Qt-qvfb-version/demos/embedded/fluidlauncher/fluidlauncher -qws See some pictures of the same application running on host and on EVK: Tips 1. To clean all Qt configuration settings: make confclean 2. To check the current configuration: On Qt source code folder, you can open the file config.status to check the current configuration settings.

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.