Here is the explaination of relationship of SD-CAN, SD-MAN, 6233, 6003, 3002: AR6003 + AR3002 = AR6233 AR6233 + RF Components = SX-SDMAN-2830S SX-SDMAN-2830S + SDIO CONN = SX-SDCAN-2830BT SX-SDCAN-2830BT card is inserted into SD3 slot. BT adaptor board (attached files) is inserted into SD1 slot. SX-SDCAN-2830BT card is connected with BT adaptor board via 20-pin FFC. Software: signals of SD1 are muxed into UART4 and GPIO for BT application. Below is the description of IO mux on SD1:

File related to the following question: MX53 u-boot Splash Screen support

     The following steps allow you to build a bootable image in two different ways and also how to enable and use SCFW debug monitor. There are four files needed to generate a bootable image: ├── bl31.bin ├── u-boot.bin   ├── mx8qm-ahab-container.img     └── scfw_tcm.bin There are some ways to get the four files, one way is with Yocto and other way is with stand alone build. Get the four files needed to generate a bootable image with Yocto.   To get the four files needed with Yocto, you have to build an i.MX 8QuadMax image, maybe some steps are not necessary. 1.-Host packages. sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa \ libsdl1.2-dev pylint3 xterm rsync curl 2.-Setting up the Repo utility. mkdir ~/bin (this step may not be needed if the bin folder already exists) curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo export PATH=~/bin:$PATH 3.-Yocto Project Setup. git config --global user.name "Your Name" git config --global user.email "Your Email" git config --list mkdir imx-yocto-bsp cd imx-yocto-bsp repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-hardknott -m imx-5.10.72-2.2.0.xml repo sync 4.-Build configurations. DISTRO=fsl-imx-xwayland MACHINE=imx8qmmek source imx-setup-release.sh -b imx8qmmek 5.-Building an image. bitbake imx-image-full The four files needed to generate a bootable image are in: ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools Note: With Yocto you can not enable the SCFW debug monitor. For more information see the i.MX Yocto Project User's Guide. Get the four files needed to generate a bootable image with stand alone build.   To build all required binaries from source you can use standard aarch64 Linux toolchain, on Ubuntu 20.04 LTS: sudo apt-get install gcc-aarch64-linux-gnu Get the bl31.bin file - Arm Trust Firmware.   Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/imx-atf Build: cd imx-atf make clean PLAT=imx8qm CROSS_COMPILE=aarch64-linux-gnu- make PLAT=imx8qm CROSS_COMPILE=aarch64-linux-gnu- bl31 The compiled bl31.bin location: build/imx8qm/release/bl31.bin Get the u-boot.bin file - u-boot.   Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/uboot-imx Build: cd uboot-imx make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx8qm_mek_defconfig make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- The compiled u-boot.bin location: ./u-boot.bin Get the mx8qmb0-ahab-container.img file - iMX Seco. wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-3.7.4.bin chmod +x imx-seco-3.7.4.bin ./imx-seco-3.7.4.bin --auto-accept The mx8qmb0-ahab-container.img file location: imx-seco-3.7.4/firmware/seco/mx8qmb0-ahab-container.img Get the scfw_tcm.bin file - SCFW.   Download and Install a GNU Toolchain.   Look at the packages/imx-scfw-porting-kit-1.7.4/doc/pdf/ , chapter Porting Guide, sub-chapter Tool Chain to check which GNU Toolchain version corresponds to the SCFW you are building. The imx-scfw-porting-kit-1.7.4 version uses the GNU Toolchain version gcc-arm-none-eabi-8-2018-q4-major . It is recommended to install toolchain in “opt” folder: cd /opt sudo wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 sudo tar xjf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 Download and Install a Arm GCC toolchain. It is recommended to install toolchain in “opt” folder: sudo wget https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz sudo tar -Jxvf gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz After installing the toolchain, set up the environment variable relevant for building. export ARCH=arm CROSS_COMPILE=/opt/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- export TOOLS=/opt Build the scfw_tcm.bin file. cd ~ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-scfw-porting-kit-1.7.4.bin chmod +x imx-scfw-porting-kit-1.7.4.bin ./imx-scfw-porting-kit-1.7.4.bin --auto-accept cd imx-scfw-porting-kit-1.7.4/src Extract the desired scfw porting kit: tar -xvf scfw_export_mx8qm_b0.tar.gz cd scfw_export_mx8qm_b0/ Build without debug monitor: make clean make qm B=mek R=B0 Build with debug monitor: make clean make qm B=mek D=1 M=1 R=B0 DDR_CON=imx8qm_dcd_1.6GHz The scfw_tcm.bin file location: build_mx8qm_b0/scfw_tcm.bin   Generate the bootable image.   Once you have the four files needed to generate a bootable image, use imx-mkimage tool. Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/imx-mkimage Copy the four binaries to iMX8QM folder. You have to rename some files. If you got the four binaries with Yocto. cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/bl31-imx8qm.bin ~/imx-mkimage/iMX8QM/bl31.bin cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/u-boot-imx8qmmek.bin-sd ~/imx-mkimage/iMX8QM/u-boot.bin cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/mx8qmb0-ahab-container.img ~/imx-mkimage/iMX8QM cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/mx8qm-mek-scfw-tcm.bin ~/imx-mkimage/iMX8QM/scfw_tcm.bin If you got the four binaries with stand alone build. cp ~/imx-atf/build/imx8qm/release/bl31.bin ~/imx-mkimage/iMX8QM cp ~/uboot-imx/u-boot.bin ~/imx-mkimage/iMX8QM cp ~/imx-seco-3.7.4/firmware/seco/mx8qmb0-ahab-container.img ~/imx-mkimage/iMX8QM cp ~/imx-scfw-porting-kit-1.7.4/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ~/imx-mkimage/iMX8QM Build the bootable image. cd ~/imx-mkimage make SOC=iMX8QM flash The compiled file is flash.bin and its location is: iMX8QM/flash.bin   Flash the bootable image.   To flash the bootable image follow the next steps: -Copy the flash.bin and uuu.exe in a folder. -Change SW2 on the base board to 000100 (from MSB to LSB, 1-ON and 0-OFF) to boot from the Serial Downloader. -Run the following command in Command Prompt: uuu.exe -b sd flash.bin -Power on the MEK CPU board.   SCFW debug monitor.        If the SCFW is compiled using the M=1 option (default is M=0) then it will include a debug monitor. This can be used to R/W memory or registers, R/W power state, and dump some resource manager state. Production SCFW should never have the monitor enabled (M=0, the default)!      The debug monitor allows command-line interaction via the SCU UART. Inclusion of the debug monitor affects SCFW timing and therefore should never be deployed in a product! Note the terminal needs to be in a mode that sends CR or LF for a new line (not CR+LF). The following commands are supported: Command                                   Description exit                                              exit the debug monitor quit                                              exit the debug monitor reset [mode]                                request reset with mode (default = board) reboot partition [type]                  request partition reboot with type (default = cold) md.b address [count]                  display count bytes at address md.w address [count]                 display count words at address md[.l] address [count]                 display count long-words at address mm.b address value                   modify byte at address mm.w address value                  modify word at address mm[.l] address value                  modify long-word at address ai.r ss sel addr                            read analog interface (AI) register ai.w ss sel addr data                  write analog interface (AI) register fuse.r word                                 read OTP fuse word fuse.w word value                      write value to OTP fuse word dump rm                                    dump all the resource manager (RM) info dump rm part [part]                    dump all partition info for part (default = all) dump rm rsrc [part]                    dump all resource info for part (default = all) dump rm mem [part]                  dump all memory info for part (default = all) dump rm pad [part]                    dump all pad info for part (default = all) power.r [resource]                     read/get power mode of resource (default = all) power.w resource mode            write/set power mode of resource to mode (off, stby, lp, on) info                                             display SCFW/SoC info like unique ID, etc. seco lifecycle change                send SECO lifecycle update command (change) to SECO seco info                                    display SECO info like Lifecycle, SNVS state, etc. seco debug                                dump SECO debug log seco events                               dump SECO event log seco commit                              commit SRK and/or SECO FW version update pmic.r id reg                               read pmic register pmic.w id reg val                        write pmic register pmic.l id                                      list pmic info (rail voltages, etc) Resource and subsystem (ss) arguments are specified by name. All numeric arguments are decimal unless prefixed with 0x (for hex) or 0 (for octal). Testing SCFW debug monitor to display count long-words at address on Linux side and on SCU side. -Change SW2 on the base board to 001100 (from MSB to LSB, 1-ON and 0-OFF) to boot from the SD card. -Power on the MEK CPU board. -Open Tera Term and you will see: Hello from SCU (Build 5263, Commit 9b3d006e, Aug 20 2021 12:20:10) ​ DDR frequency = 1596000000  ROM boot time = 262368 usec      Boot time = 24583 usec         Banner = 10 usec           Init = 9038 usec         Config = 3232 usec            DDR = 2677 usec        SConfig = 444 usec           Prep = 5039 usec ​ *** Debug Monitor *** ​ >$ -Run the following commands: power.r power.w db on power.w dblogic on power.w mu_1a on -Example reading on Linux side: md.l 0x5d1c0000 10 -You will see: >$ md.l 0x5d1c0000 10 5d1c0000: 00000000 00000000 00000000 00000000 5d1c0010: 00010201 23c34600 d63fdb21 00000000 5d1c0020: 00f00200 18000000 -Example reading on SCU side: md.l 0x41cac080 10 -You will see: >$ md.l 0x41cac080 10 41cac080: 00000000 00000000 00000000 00000000 41cac090: 0d070201 ff0001f1 ffff8000 ffff00fb 41cac0a0: 00f00000 18000000 For more information see the System Controller Firmware Porting Guide.

Host TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. U-Boot will download the Linux kernel and dtb file using tftp and then the kernel will mount (via NFS) its root file system on the computer hard drive. 1. TFTP Setup   1.1.1 Prepare the TFTP Service   Get the required software if not already set up. On host for TFTP: Install TFTP on Host $ sudo apt-get install tftpd-hpa   (Note: There are a number of examples in various forums, etc, of how to automatically start the TFTP service - but not all are successful on all Linux distro's it seems! The following may work for you.)   Start the tftpd-hpa service automatically by adding a command to /etc/rc.local. $ vi /etc/rc.local   Now, just before the exit 0 line edit below command then Save and Exit. $ service tftpd-hpa start  Now, To control the TFTP service from the command line use: $ service tftpd-hpa restart    To check the status of the TFTP service from the command line use: $ service tftpd-hpa status   1.1.1 Setup the TFTP Directories Now, we have to create the directory which will contain the kernel image and the device tree blob file. $ mkdir -p /imx-boot/imx6q-sabre/tftp Then, copy the kernel image and the device tree blob file in this directory. $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/zImage /imx-boot/imx6q-sabre/tftp $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/<dtb file> /imx-boot/imx6q-sabre/tftp   OR we can use the default directory created by yocto {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/ The tftpd-hpa service looks for requested files under /imx-boot/imx6q-sabre/tftp The default tftpd-hpa directory may vary with distribution/release, but it is specified in the configuration file: /etc/default/tfptd-hpa. We have to change this default directory with our directory   Edit default tftp directory $ vi /etc/default/tftpd-hpa   Now, change the directory defined as TFTP_DIRECTORY with your host system directory which contains kernel and device tree blob file. Using created directory TFTP_DIRECTORY=”/imx-boot/imx6q-sabre/tftp” OR Using Yocto directory path TFTP_DIRECTORY=”{YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}” Restart the TFTP service if required $ service tftpd-hpa restart   1.2 NFS Setup 1.2.1 Prepare the NFS Service Get the required software if not already set up. On host for NFS: Install NFS on Host $ sudo apt-get install nfs-kernel-server The NFS service starts automatically. To control NFS services : $ service nfs-kernel-server restart To check the status of the NFS service from the command line : $ service nfs-kernel-server status 1.2.2 Setup the NFS Directories Now, we have to create the directory which will contain the root file system. $ mkdir -p /imx-boot/imx6q-sabre/nfs   Then, copy the rootfs in this directory. $ cp -R {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs/* /imx-boot/imx6q-sabre/nfs   OR we can use the default directory created by yocto. $ {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs 1.2.3 Update NFS Export File The NFS server requires /etc/exports to be configured correctly to access NFS filesystem directory to specific hosts. $ vi /etc/exports Then, edit below line into the opened file. <”YOUR NFS DIRECTORY”> <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex. If you created custom directory for NFS then, /imx-boot/imx6q-sabre/nfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex: /imx-boot/imx6q-sabre/nfs 192.168.*.*(rw,sync,no_root_squash,no_subtree_check) OR /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check)   Now, we need to restart the NFS service. $ service nfs-kernel-server restart   2 Target Setup   We need to set up the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters, setenv serverip 192.168.0.206       //This must be your Host IP address The path where the rootfs is placed in our host has to be indicated in the U-Boot, Ex. // if you choose default folder created by YOCTO setenv nfsroot /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs   OR // if you create custom directory for NFS setenv nfsroot /imx-boot/imx6q-sabre/nfs Now, we have to set kernel image name and device tree blob file name in the u-boot, setenv image < zImage name > setenv fdt_file <dtb file name on host> Now, set the bootargs for the kernel boot, setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp' Use printenv command and check loadaddr and fdt_addr environment variables variables for I.MX6Q SABRE, loadaddr=0x12000000 fdt_addr=0x18000000   Also, check netboot environment variable. It should be like below, netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi; Now, set environment variable bootcmd to boot every time from the network, setenv bootcmd run netboot Now finally save those variable in u-boot: saveenv Reset your board; it should now boot from the network: U-Boot 2016.03-imx_v2016.03_4.1.15_2.0.0_ga+ga57b13b (Apr 17 2018 - 17:13:43 +0530)  (..) Net:   FEC [PRIME] Normal Boot Hit any key to stop autoboot:  0   Booting from net ... Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'zImage'. Load address: 0x12000000 Loading: #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         ###########################################################         2.1 MiB/s done Bytes transferred = 6578216 (646028 hex) Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'imx6q-sabresd.dtb'. Load address: 0x18000000 Loading: ####         1.8 MiB/s done Bytes transferred = 45893 (b345 hex) Kernel image @ 0x12000000 [ 0x000000 - 0x646028 ] ## Flattened Device Tree blob at 18000000   Booting using the fdt blob at 0x18000000   Using Device Tree in place at 18000000, end 1800e344 switch to ldo_bypass mode!   Starting kernel ...

This document explains the pad implementation and its relationship with the System Controller Firmware pad configuration service. There are two components to pad configuration in the SCFW, there are the modules that generate the signals that will ultimately appear on the physical pad, let's say GPIO/Ethernet/I2C/UART etc... and then there is the part that configures the muxing of the pad (what signal is going to be outputted through the specific pad), the drive strength of the pad, pull selection, etc, this is the part that the SCFW pad service configures. Introduction‌ The i.MX8 has three types of I/Os: 1.8V only I/Os 3.3V only I/Os 1.8V / 3.3V I/Os Dual Voltage I/Os Note: USB High Speed Inter-Chip (HSIC) and Ethernet interfaces have specific integration schemes with dedicated features. They are a modified versions of the above I/O types. HSIC are a special kind of I/O modified to sustain 480Mbps data rates ENET I/Os are modified versions of Dual Voltage I/Os to support 2.5V operations All of these I/Os have "common features" and "technology specific features" which depend on the type of I/O and the chip manufacturing process (FDSOI in the i.MX8QM case) I/O common features Muxing capability of up to 4 signals Each Pad can have up to 4 signals, only one signal can be present in the pad. To select the signal that will output on the pad simply look at the Pinmux spreadsheet and use the desired alternative, for instance in the following image SCU_GPIO0_00 has 3 options, SCU_GPIO (ALT0 - GPIO controlled directly by the SCU), SCU_UART0_RX (ALT1 - SCU UART receiver) or LSIO_GPIO0_IO28 (ALT3 - Low speed I/O GPIO).   Pads without GPIO functionality (i.e. without the GPIO option in the pinmux spreadsheet) are implemented for one purpose only, these pins are connected directly to the module that drives them and they feature their own physical interface. Examples are XTAL pins, DDR pins and SCU PMIC interface (shown above). Mode of operation All GPIO types support four modes of operation: Normal mode Data is being driven directly to the pad (an internal signal of 1 shows in the pad as a 1 and vice-versa) and the pad works either as an output or as an input but not both at the same time. The output buffer while on this mode looks like this: Open drain Data is being driven through an open drain configuration, the output on the pad switches between 0 and high-z. The pad works either as an output or as an input but not both at the same time, e.g. if the Output Buffer is enabled the Input Buffer is disabled. This is how the output buffer looks like on Open drain mode: Open drain and input Output buffer acts as in open drain mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to simultaneously read the signal at the pad while driving it. Output and input Output buffer acts as in normal mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to read the signal at the pad while driving it. Wake-up capability Each I/O can be configured to wake-up the device, the following configuration options are available: OFF I/O cannot wake-up the system Low detect Generate wake-up event when the pad remains in low-level High detect Generate wake-up event when the pad remains in high-level Rising edge Generate wake-up event on rising edge detection Falling edge Generate wake-up event on falling edge detection Technology specific features Some of the available features for each pad depend on two factors: Chip manufacturing process (FDSOI or LPP) I/O type (1.8V, 3.3V or Dual Voltage) The i.MX8QM is manufactured using FDSOI technology and it features all of the three available I/O types. Drive strength Drive strength options vary within I/O types and chip manufacturing options. The available options for a FDSOI chip are: 1.8V Drive strength options 3.3V Drive strength options Dual Voltage drive strength options Drive strength of 1mA Drive strength of 2mA Low drive strength (50 ohms) Drive strength of 2mA Drive strength of 4mA High drive strength (33 ohms) Drive strength of 4mA Drive strength of 8mA Drive strength of 6mA Drive strength of 12mA Drive strength of 8mA Drive strength of 10mA Drive strength of 12mA High-speed drive strength Pull Select The pull select available options are almost the same for all I/O types (1.8V being the exception) and they also depend on chip manufacturing process. The available options for a FDSOI chip are: Pull select options for FDSOI Bus-keeper (only available for 1.8V) Pull-up Pull-down No Pull (Disabled) A bus-keeper or bus-holder is used to keep the last state on the bus. In normal operation it makes no difference, but once the bus is tri-stated it keeps the last logic level in the bus to prevent the bus from floating. Compensation The compensation feature is only available on Dual Voltage I/Os. Dual Voltage I/Os have a different implementation, they require: Voltage reference generator - which provides a voltage reference to the supply detector and compensation cell Supply detector - detects automatically whether the I/O is being supplied with 1.8V or 3.3V and broadcasts this information to compensation cell and I/O  Compensation cell - adjusts drive strength of dual voltage I/Os depending on Process Voltage and Temperature (PVT) conditions. The default configuration takes care of adjusting this parameters and no further modifications are required. Pad configuration service SCFW API Mux selection The very first function that needs to be called to configure a pad is: sc_err_t sc_pad_set_mux(sc_ipc_t ipc, sc_pad_t pad, uint8_t mux, sc_pad_config_t config, sc_pad_iso_t iso);‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the muxing alternative and setting the common features, its parameters are: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. mux - The mux setting that you require, basically Alt0 -> 0, Alt1 -> 1, Alt2 -> 2 and Alt3-> 3, the pinmux spreadsheet contains the required information (take a look at I/O common features above). config - Used to select the desired mode of operation (take a look at I/O common features above), the available options are declared under sc_pad_config_t Normal mode - SC_PAD_CONFIG_NORMAL Open Drain mode - SC_PAD_CONFIG_OD Open Drain and input - SC_PAD_CONFIG_OD_IN Output and input - SC_PAD_CONFIG_OUT_IN iso - This is the low-power isolation configuration (take a look at I/O common features above). The available options are declared under sc_pad_iso_t ISO_OFF - SC_PAD_ISO_OFF ISO_EARLY - SC_PAD_ISO_EARLY ISO_LATE - SC_PAD_ISO_LATE ISO_ON - SC_PAD_ISO_ON For instance to configure M40_I2C0_SCL with its UART alternative in normal mode with low-power isolation off, the call would look like this: sc_pad_set_mux(ipc, SC_P_M40_I2C0_SCL, 1, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);‍‍‍‍‍‍‍‍‍‍ Pad configuration To configure drive strength and pull select options the technology specific functions need to be used (FDSOI for i.MX8QM): sc_pad_set_gp is being used by our Linux team because it admits the passing of the configuration parameters as a single value and this eases the handling on the device tree, but you should aim to use the technology specific functions. sc_err_t sc_pad_set_gp_28fdsoi(sc_ipc_t ipc, sc_pad_t pad, sc_pad_28fdsoi_dse_t dse, sc_pad_28fdsoi_ps_t ps);‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the drive strength (DSE) and pull select settings (PS) for the specified pad, here is a break down of the parameters it uses: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. dse - The desired drive strength configuration (see Technology specific features above). DSE settings depend on the I/O type being used, the available options for each I/O type are defined under sc_pad_28fdsoi_dse_t: ENET pads capable of operating at 2.5V are a subset of dual voltage I/Os, the dse options available for these pads are the same as normal dual voltage I/Os. i.e. High drive and low drive. ps - The desired pull select configuration (see Technology specific features above). The available options are defined under sc_pad_28fdsoi_ps_t: To determine whether a GPIO pad is 1.8V, 3.3V or Dual Voltage one can look at the pinmux spread sheet, the supply for the pad will indicate what implementation of the GPIO is used. For instance: pads under VDD_SIM_1P8_3P3 are Dual voltage I/Os pads under VDD_SCU_1P8 are 1.8V I/Os pads under VDD_ADC_3P3 are 3.3V I/Os taking the same example as above we could configure the M40_I2C0_SCL as follows: sc_pad_set_gp_28fdsoi(ipc, SC_P_M40_I2C0_SCL, SC_PAD_28FDSOI_DSE_DV_LOW, SC_PAD_28FDSOI_PS_NONE);‍‍‍‍‍‍‍‍‍‍‍‍‍ Configuration under Linux Linux configures pads through the device tree, the full documentation of the binding is under Documentation/devicetree/bindings/pinctrl/fsl,imx8qxp-pinctrl.txt. but here is an extract: * Freescale i.MX8QXP IOMUX Controller Required properties: - compatible: "fsl,imx8qxp-iomuxc" - fsl,pins: each entry consists of 2 integers. Its format is <pin_id pin_config>. pin_config definition: - i.MX8QXP have different pad types, please refer to below pad register definitions, the pinctrl driver will just write the pin_config into the hardware register.‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The driver uses the following API: sc_err_t sc_pad_set_gp (sc_ipc_t ipc, sc_pad_t pad, uint32_t ctrl) ‍‍‍ Instead of configuring each parameter individually as done with sc_pad_set_gp_28fdsoi it configures the pad as if writing to a register, the bitfield format is under the binding documentation but it is as follows: struct _hw_pad_iomux_bitfields0 { uint32_t GP : 19; /*!< [18:0] GP controls. */ uint32_t WAKEUP : 3; /*!< [21:19] Wakeup controls. */ uint32_t WAKEUP_ENB : 1; /*!< [22] Wakeup write enable. */ uint32_t LPCONFIG : 2; /*!< [24:23] Low-power config. */ uint32_t CONFIG : 2; /*!< [26:25] Config. */ uint32_t IFMUX : 3; /*!< [29:27] Mux. */ uint32_t GP_ENB : 1; /*!< [30] GP write enable. */ uint32_t IFMUX_ENB : 1; /*!< [31] Mux write enable. */ } B; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ All the configurations mentioned above can be configured, but they are done in a single pass, e.g. Muxing, Configuration (Norma, Open Drive, etc...), Wakeup control, and GP controls are for Pull Select Drive Strenght etc... Check the Reference Manual Chapter for IOMUXD for the register definition for each pad. References For more details refer to the sc_fw_api.pdf document: Chapter 1.3.3 Pad Configuration Service Chapter 6 Pad List Chapter 9.3 (SVC) Pad Service System Controller Firmware 101 

Note: This guide is specifically for use with Segger software. For steps to use with the MCUXpresso extension for VSCode please refer to How to Use Segger J-Link Plus with i.MX 8M Process... - NXP Community This guide aims to be a technical reference to start using the SEGGER J-Link Plus debug probe on the i.MX 8M Family processors. The board used for this guide specifically is the i.MX 8M Nano EVK, but it also applies to all processors of the i.MX 8M Family. Here we will describe the process using the following structure: Hardware requirements Software requirements How to find, build, and download the i.MX SDK Host setup Build an example application Target setup Run an example application Hardware requirements Evaluation Kit for the i.MX8M Nano Applications Processor (i.MX 8M Nano Evaluation Kit | NXP Semiconductors) Quick Start Guide for i.MX8M Nano (I.MX 8M Nano EVK Quick Start Guide (nxp.com)) J-Link Plus JTAG/SWD debug probe with USB interface (SEGGER J-Link PLUS) Features Download speed up to 1MB/s Unlimited breakpoints in flash memory Supports direct download into RAM and flash memory Supported NXP Devices Supported Devices - Search results "nxp" (segger.com) 9 Pin Cortex-M Adapter (9-Pin Cortex-M Adapter (segger.com)) Description Adapts from the 20-pin 0.1'' JTAG connector to a 9-pin 0.05'' Samtec FTSH connector as defined by Arm. Software requirements Windows 10 OS (host) J-Link Software and Documentation Pack for Windows (https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/) i.MX 8M Nano SDK (Welcome | MCUXpresso SDK Builder (nxp.com)) MinGW CMake GNU ARM Embedded Toolchain Terminal Emulator for serial port connection (Tera Term, PuTTY, etc.)   How to find, build, and download the i.MX 8M Nano SDK Enter Welcome | MCUXpresso SDK Builder (nxp.com) Click on "Select Development Board"  Select EVK-MIMX8MN (MIMX8MN6xxxJZ) from Boards -> i.MX -> EVK-MIMX8MN Click on the Build MCUXpresso SDK button Click on Download SDK, you'll be redirected to the MCUXpresso SDK Dashboard Look for the i.MX 8M Nano SDK and click on Download SDK Click on Download SDK archive and documentation, accept the Software Terms and Conditions and the .zip file for the SDK will be downloaded.   Host Setup J-Link Software and Documentation Pack for Windows Download J-Link Software and Documentation Pack for Windows (https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/) Execute .exe file downloaded and then click on "Next" Follow the installation wizard with default parameters and click on "Finish".   MinGW Download the MinGW installer from MinGW - Minimalist GNU for Windows - Browse /Installer at SourceForge.net. Follow the installer instructions leaving all options in their default values. Click on Continue when the installer finishes. A MinGW Installation Manager window will pop up, select mingw32-base and msys-base from basic setup. Click on the Installation menu and select Apply Changes. On the next window, click on Apply and wait for the package to finish downloading. Add the appropriate item to the Windows operating system path environment variable. It can be found under Control Panel->System and Security->System->Advanced System Settings in the Environment Variables... section. The path is: \bin. Assuming the default installation path, "C:\MinGW". If the path is not set correctly, the toolchain does not work. Note: If you have C:\MinGW\msys\x.x\bin in your PATH variable (as required by KSDK 1.0.0), remove it to ensure that the new GCC build system works correctly.   CMake Download CMake Windows x64 Installer from  Download CMake. Scroll down to find the latest release for the installer: Run the installer and follow the instructions. Make sure to check the Add CMake to system PATH for all users option during the installation process. Restart your PC to apply changes. GNU ARM Embedded Toolchain Download the GNU ARM Embedded Toolchain installer from Downloads | GNU Arm Embedded Toolchain Downloads – Arm Developer, scroll down to find the latest release for the installer: Follow the installer instructions and check the Add to PATH option at the end of the process. Add a new system environment variable named ARMGCC_DIR with the GNU ARM embedded Toolchain installation path as its value ARMGCC_DIR=ARMGCC_DIR=C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10​   Build and example application Press the Windows Key and search for GCC Command Prompt and run it. Change the directory to the example application project directory (inside the armgcc folder), for example: C:\Users/<user>\Documents\8MNANO\boards\evkmimx8mn\demo_apps\hello_world\armgcc Type build_debug.bat on the command line or double click the build_debug.bat file (inside the armgcc folder of the application project) through Windows Explorer Wait for the building process to end and make sure no error messages are shown. Target Setup Connect the debug cable (USB-UART) to the board and the other end to your PC. Connect the power cable to the second USB-C port and to a wall socket. Don't turn on the board yet. Connect the JLink Plus to your PC with the USB cable. Connect the JLink Plus to the JTAG of the i.MX 8M Nano EVK board In this part we will need to identify pin number 1 from the 9 Pin Cortex-M adapter and from the i.MX 8M Nano EVK board. For the first one identify pin 7 identifiable by a "Non-connect pin". For the i.MX 8M Nano, you can identify easily with a number 1 in one corner of the connectors.    The whole setup should look similar to this: Run an example application Open a terminal application (TeraTerm, PuTTY, etc.) on your host PC and set it to the serial debug port with the lowest numbered port with the following settings: Speed: 115200 Data: 8-bit Parity: none Stop bits: 1 bit Flow Control: none Start SEGGER J-Link GDB Server. On section “Target Device” select MIMX8MN6_M7 and click “OK”. You will see the following window. Open a new instance of GCC Command Prompt. Change to the directory with the example previously compiled. Here is the path to folder that contains the files: <install_dir>/boards/<boad_name>/<example_type>/<application_name>/armgcc/debug​ Run the command: arm-none-eabi-gdb.exe <application_name>.elf.​ Example: At this point you are in the GDB Command Prompt, run the following commands: target remote localhost:2331 monitor reset monitor halt load monitor go The application will be now running and you can see the “hello world” on your terminal (PuTTY,Tera Term, etc.).  

One of the most popular use cases for embedded systems are projects destinated to show information and interact with users. These views are called GUI or Graphic User Interface which are designed to be intuitive, attractive, consistent, and clear. There are many tools that we can use to achieve great GUIs, mostly implemented for platforms such as Web, Android, and iOS. Here, we will need to introduce the concept of framework, basically, it is a set of tools and rules that provides a minimal structure to start with your development. Frameworks usually comes with configuration files, code snippets, files and folders organization helping us to save time and effort. Also, it is important to review the concept of SDK or Software Development Kit which is a set of tools that allows to build software for specific platforms. Usually supplies debugging tools, documentation, libraries, API’s, emulators, and sample code. Flutter is an open-source UI software development kit by Google that help us to create applications with great GUIs on different platforms from a single codebase. Depends on the reference, you can find Flutter defined as a framework or SDK and both are correct, however, an SDK could be a best definition thanks to Flutter supplies a wide and complete package to create an application in which framework is also included. This article is aimed at those that are in a prototyping stage looking for a different tool to develop projects. Also, this article pretends to be a theoretical introduction explaining the most important concepts. However, is a good practice to learn more about reviewing the official documentation from Flutter. (Flutter documentation | Flutter) Here is the structure used throughout this article: What is Flutter? Flutter details Platforms Programming language Official documentation Flutter for embedded systems What is Flutter? Flutter was officially released by Google in December 2018 with a main aim, to give developers a tool to create applications natively compiled for mobile (Android, iOS), web and desktop (Windows, Linux) from a single codebase. It means that as a developer, Flutter will create a structure with minimal code, configuration files, build files for each operating system, manifests, etc. in which we will add our custom code and finally build this code for our preferred OS. For example, we can create an application to review fruit and vegetable information and compile for Android and iOS with the same code. A basic Flutter development process based on my experience looks like the following diagram: Flutter has the following key features: Cross-platform development. Flutter allows the developer to create applications for different platforms using a single codebase. It means that you will not need to recreate the application for each platform you want to support.   Hot-reload. This feature allows the developer to see changes in real time without restarting the whole application, this results in time savings for your project.   High Performance Flutter apps achieve high performance due to the app code is compiled to native ARM code. With this tool no interpreters are involved.   UI Widgets Flutter supplies a set of widgets (UI components such as boxes, inputs text, buttons, etc.) predefined by UI systems guidelines Material on Android and Cupertino for iOS. Source: Material 3 Design Kit | Figma Community Source: Design - Apple Developer   Great community support. This feature could be subjective but, it is useful when we are developing our project find solutions to known issues or report new ones. Because of Flutter is an open source and is widely implemented in the industry this tool owns a big community, with events, forums, and documentation. Flutter Details Supported Platforms With Flutter you can create applications for: Android iOS Linux Debian Linux Ubuntu macOS web Chrome, Firefox, Safari, Edge Windows Supported deployment platforms | Flutter Programming Language Flutter use Dart, a programming language is an open-source language supported by Google optimized to use on the creation of user interfaces. Dart key features: Statically typed. This feature helps catching errors making the code robust ensuring that the variable’s value always match with the declared variable’s type. Null safety. All variables on Dart are non-nullable which means that every variable must have a non-null value avoiding errors at execution time. This feature also, make the code robust and secure. Async/Await. Dart is client-optimized which means that this language was specially created to ensure the best performance as a client application. Async/Await is a feature part of this optimization making easier to manage network requests and other asynchronous operations. Object oriented. Dart is an object-oriented language with classes and mixin. This is especially useful to use on Flutter with the usage of widgets. Compiler support of Just-In-Time (JIT) and Ahead-of-Time (AOT) JIT provides the support that enables the Hot Reload Flutter feature that I mentioned before. It is a complex mechanism, but Dart “detects” changes in your code and execute only these changes avoiding recompiling all the code. AOT compiler produces efficient ARM code improving start up time and performance. Official documentation Flutter has a rich community and documentation that goes from UI guidelines to an Architectural Overview. You can find the official documentation at the following links: Flutter Official Documentation: Flutter documentation | Flutter Flutter Community: Community (flutter.dev) Dart Official Documentation: Dart documentation | Dart Flutter for embedded systems So far, we know all the excellent features and platforms that Flutter can support. But, what about the embedded systems? On the official documentation we can find that Flutter may be used for embedded systems but in fact there is no an official supported platform. This SDK has been supported by their community, specially there is one repository on GitHub supported by Sony that provides documentation and Yocto recipes to support Flutter on embedded Linux. To understand the reason to differentiate between Flutter for Linux Desktop with official support and to create a specific Flutter support for embedded Linux is important to describe the basics of Flutter architecture. Based on the Flutter documentation the system is designed using layers that can be illustrated as follows:   Source: Flutter architectural overview | Flutter We can see as a top level “Framework” which is a high-level layer that includes widgets, tools and libraries that are in contact with developers. Below “Framework,” the layer “Engine” is responsible of drawing the widgets specified in the previous layer and provides the connection between high-level and low-level code. This layer is mostly written in C++ for this reason Flutter can achieve high performance running applications. Specifically for graphics rendering Flutter implements Impeller for iOS and Skia for the rest of platforms. The bottom layer is “Embedder” which is specific for each target and operating system this layer allows Flutter application to run as a native app providing the access to interact with different services managed by the operating systems such as input, rendering surfaces and accessibility. This layer for Linux Desktop uses GTK/GDK and X11 as backend that is highly dependent of unnecessary libraries and expensive for embedded systems which have constrained resources for computation and memory. The work around founded by Sony’s Flutter for Embedded Linux repository is to change this backend using a widely implemented backend for embedded systems Wayland. The following image illustrates the difference between Flutter for Linux Desktop and Flutter for Embedded Linux.   Source: What's the difference between Linux desktop and Embedded Linux · sony/flutter-embedded-linux Wiki · GitHub   Source: What's the difference between Linux desktop and Embedded Linux · sony/flutter-embedded-linux Wiki · GitHub Here is the link to the mentioned repository: GitHub - sony/flutter-elinux: Flutter tools for embedded Linux (eLinux) Finally, I would like to encourage you to read the official Flutter documentation and consider this tool as a great option compared to widely used tools on embedded devices such as Qt or Chromium. Also, please have a look to a great article written by Payam Zahedi delving into the implementation of Flutter for Embedded Linux measuring performance and giving conclusions about the usage of Flutter in embedded systems. (Flutter on Embedded Devices. Learn how to run Flutter on embedded… | by Payam Zahedi | Snapp Embedded | Medium).    

Here is an example for i.MX28 EVK board to support SPI NOR boot in uboot, kernel and MFGTool.   Attached files are the patches to support SPI NOR flash on i.MX28 EVK bord based on L2.6.35 ER11.09.01 BSP. It was verified on Spansion s25fl256s SPI NOR. "ER11.09.01_uboot_imx28_spi_nor.patch" is the Uboot patch. "ER11.09.01_kernel_imx28_spi_nor.patch" is the kernel patch. "ucl.xml" is the updated MFGTool config file, please update it to "Mfgtools-Rel\Profiles\MX28 Linux Update\OS Firmware\ucl.xml".   The uboot boot paramters for SPI: setenv bootargs_base 'setenv bootargs console=ttyAM0,115200' setenv loadaddr 0x42000000 setenv bootargs_spi 'setenv bootargs ${bootargs} root=/dev/mtdblock2 rootfstype=jffs2 rootwait rw ip=none' setenv bootcmd_spi 'run bootargs_base bootargs_spi;sf probe 2:0; sf read ${loadaddr} 0x100000 0x300000;bootm' setenv bootcmd 'run bootcmd_spi' saveenv   To boot the board from SPI NOR s25fl256s, the 4KB page region of the NOR should be put to top, the last 128KB of the NOR address space. The uboot.sb is about 220KB, it can't be put to 4KB and 64KB combined region. The IMX28 boot ROM can only handle simple page size for boot. All 4KB page region or all 64KB page region are both OK for boot, but combined region can't boot.   For default, the s25fl256s NOR's 128KB 4KB page size region is at the bottom of the NOR, we should update the OTP to set this region to TOP, in Uboot, we run the followed command to burn the OTP: MX28 U-Boot -> sf probe 2:0 MX28 U-Boot -> sf set_config_reg 0x04   To boot the i.MX28 EVK board from SPI2 NOR flash, the BM3~0 should be 0010.   In this example, we only used the JFFS2 file system. To support the UBIFS, there is a known issue, that the UBIFS will use vmalloc to alloc memory, and if SPI driver used the DMA, kernel will halt with error "kernel BUG at arch/arm/mm/dma-mapping.c:409!".   For 11.09.01 BSP, the default MFGTool rootfs "initramfs.cpio.gz" will be bigger than 4MB, but in i.MX28 bootlets code, the BSP only set ramdisk to 4MB, so we need modify this limitation for MFGTool.   Use command "./ltib -p imx-bootlets -m prep" to get the bootlets code, modify "ltib/rpm/BUILD/imx-bootlets-src-11.09.01/linux_prep/core/setup.c", function setup_initrd_tag(), change from "params->u.initrd.size =  0x00400000;" to "params->u.initrd.size =  0x00500000;". Modify "ltib/rpm/BUILD/imx-bootlets-src-11.09.01/updater.bd" and "updater_ivt.bd", change from "load 0.b    > 0x40800000..0x40c00000;" to "load 0.b    > 0x40800000..0x40d00000;".   Now the MFGTool rootfs size can be 5MB.   2013-05-09: Updated hardware rework: On iMX28 EVK board, rework J89 as followed and mount R320,R321,R322 and C178. MX28 U49 Pin1 /CS <-> NOR Pin7 CS# MX28 U49 Pin2  D0 <-> NOR Pin8 SI/IO1 MX28 U49 Pin5 DIO <-> NOR Pin15 SI/IO0 MX28 U49 Pin6 CLK<-> NOR pin 16 SCK. MX28 U49 Pin8 VCC <-> NOR Pin2 VCC                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 MX28 U49 Pin4 GND <-> NOR Pin10 VSS MX28 U49 Pin3 /WP <-> NOR Pin9 WP MX28 U49 Pin7 /Hold <-> NOR Pin pin1 hold   Software reset issue for 32MB SPI NOR: For 32MB SPI NOR, after booted into kernel, the kernel driver will set SPI NOR to 4 bytes address mode, but for iMX28 SPI boot, it can only boot with 3 bytes address mode, if reset the iMX28 board but SPI NOR was not reset, it will fail to reboot. Hardware solution: when iMX28 was reboot, reset the SPI NOR too, the SPI NOR will work in 3 bytes address mode as default. Software solution: In kernel SPI NOR driver, always switch SPI NOR to 3 bytes address mode after each SPI NOR access, and switch to 4 bytes address mode before each access. There is no such issue if the SPI NOR size is less than 32MB.    

  Introduction   Prior to 6.1.22_2.0.0 BSP release, Bluetooth interface are based on the tty line discipline framework, so we need to use hciattach tool to enable it in the user space. From 6.1.22_2.0.0 BSP, the nxp bluetooth driver no longer needs the help of the userspace hciattach tool, and the tty port bound by bluetooth also won't be exported to the user space, so you cannot find the corresponding tty device anymore. So, you won't see the (/dev/ttymxcX), for the Bluetooth interface. All jobs has been done in the new NXP Bluetooth driver. New Method   The new NXP Bluetooth UART Driver is based on a server driver for the NXP BT serial protocol, which can enable the built-in Bluetooth device inside an NXP BT chip. This driver has a Power Save feature that will put the chip into a sleep state whenever there is no activity for 2000ms and will be woken up when any activity is to be initiated over UART.  Device Tree support The new BT framework requires adding a "bluetooth" sub node with a device compatibility string to the attached UART node in the dts file &uart1 { bluetooth { compatibility = "nxp,88w8987-bt"; fw-init-baudrate = <3000000>; #Optional. Default is considered 115200 if this parameter not defined. }; };   Note: The parameter ‘compatibility = “nxp,88w8987-bt”’ will use for 88W8987, IW416, 88Q9098, IW612 chipsets and need to change for 88W8997 with parameter ‘compatibility = “nxp,88w8997-bt”’.   Note: ’fw-init-baudrate’ parameter depends on the module vendor. The Murata and Azuere wifi modules support in BSP release uses the default value -- 115200. We strongly recommend looking at the module vendor-specific baud rate parameter. Note: For the old 88Q9098 Murata 1XL module that uses the 3Mbps by default, please add the fw-init-baudrate = <3000000> property in dts files to make it work. Enable Guide   Use wifi interface to load combo (wifi & bt) firmware and enable BT Need to load wifi driver first, then load the BT driver, otherwise, BT driver suspend/resume test will fail. This is a HW limitation, since NXP wifi and BT module use the same power control pin(W_DISABLE1#), if we don't load the wifi driver, SDIO bus will power down the wifi chip during suspend resume, which may cause the BT chip also been powered down and cannot work after resume back. So we need to load the wifi driver to make sure SDIO bus won't power down the BT chip to make sure BT functions can work during suspend resume. modprobe moal mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart or insmod mlan.ko insmod moal.ko mod_para=nxp/wifi_mod_para.conf insmod btnxpuart   Unload UART Driver modprobe moal Make sure run hciconfig hci0 up or hciconfig hci0 reset or bluetootctl power on before unload btnxpuart driver. If we don't open hci0 interface, the driver cannot send change to 115200 baud rate command to BT chip, which causes the host and BT chip baud rate mismatch, the host still uses 115200bps talk to the BT chip which now use 3Mbps, it cannot work anymore. So we need to make sure open the hci0 interface before unload btnxpuart driver.   mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart sleep 3 hciconfig hci0 up #Note: Need to up hci interface before unload the BT module hcitool -i hci0 cmd 3F 23 02 00 00 modprobe -r btnxpuart modprobe -r moal sleep 3​ For better reference: Please find the I.MX 8MQ Linux getting started user guide, UM11483, Chapter "7.1 Bring-up using NXP Bluetooth UART driver"  Bluetooth Deep Sleep Feature App Note AN13920, Chapter 6 Load NXP UART driver module NOTE: Please do not run the power save feature for Murata IW612 2EL Module Regards, Mario

Materials: i.MX8M Plus EVK Rev. A USB cable type-C USB cable type-B AC Adapter EA1045CR Micro SD (Optional) 88W8997-based wireless modules Software: Yocto Project Mobaxterm Personal Edition v20.2 Build 4296 This test was done on an i.MX8M Plus EVK with Linux 5.10. Hardknott.   To achieve this, you need to identify your WI-FI module and look for the necessary drivers for that module, in my case I am using the 88W8997 module that comes with the i.MX8M Plus, but you can select any other WI-FI module you want.   In my case I build a basic image on Yocto, following the Yocto users guide, I bitbake just the core boot image that allows me to boot the i.MX8M plus. Deploy your image on an SD or eMMC. These instructions apply to SD and MMC cards although for brevity, and usually, only the SD card is listed. For a Linux image to be able to run, four separate pieces are needed: Linux OS kernel image (zImage/Image) Device tree file (*.dtb) Bootloader image Root file system (i.e., EXT4)   The Yocto Project build creates an SD card image that can be flashed directly. This is the simplest way to load everything needed onto the card with one command. A .wic image contains all four images properly configured for an SD card. The release contains a pre-built .wic image that is built specifically for the one board configuration. It runs the Wayland graphical backend. It does not run on other boards unless U-Boot, the device tree, and rootfs are changed. When more flexibility is desired, the individual components can be loaded separately, and those instructions are included here as well. An SD card can be loaded with the individual components one-by-one or the .wic image can be loaded and the individual parts can be overwritten with specific components. The rootfs on the default .wic image is limited to a bit less than 4 GB, but re-partitioning and re-loading the rootfs can increase that to the size of the card. The rootfs can also be changed to specify the graphical backend that is used. Carry out the following command to copy the SD card image to the SD/MMC card. Change sdx below to match the one used by the SD card. $ sudo dd if=<image name>.wic of=/dev/sdx bs=1M && sync The entire contents of the SD card are replaced. If the SD card is larger than 4 GB, the additional space is not accessible. As this build does not contain the driver integrated we need to add it manually on Linux user space. Follow these instructions to load the driver modules and bring up the 88W8987-based wireless module, more info can be found on the next link: https://www.nxp.com/products/wireless/wi-fi-plus-bluetooth/2-4-5-ghz-dual-band-2x2-wi-fi-5-802-11ac-plus-bluetooth-5-3-solution:88W8997?tab=Documentation_Tab   Use the nano editor included in the pre-built image to edit and verify the module parameters in the wifi_mod_para.conf configuration file.   Add the following lines to the configuration file: PCIE8997 = { cfg80211_wext=0xf wfd_name=p2p max_vir_bss=1 cal_data_cfg=none drv_mode=7 ps_mode=2 auto_ds=2 fw_name=nxp/pcieuart8997_combo_v4.bin } Load the modules in the kernel:   Verify the kernel debug messages in the command output   Verify that the module is now visible to the system:     Now that the module is ready to work, we need to enable it, in my case the Wi-Fi is named mlan0, it could vary on other Linux systems.   In the case you need to see which networks are available you can scan it and select the one you need.   Identify your network and add it to the  WPA supplicant file:     Associate the Wi-Fi with config:   Check if you have right SSID associated:   Use DHPC to get the IP   Ping any public site you know to check the network.   In the case you have a Temporary failure in name resolution you will need to change the default DNS that was assigned by DHCP:     Modify /etc/resolv.conf file and add the DNS of your preference, for my case I add the one that uses Google, as they have access to the most common web pages.   And with that should work.    

Starting from $52, the VAR-SOM-MX6 sets the bar for unparalleled design flexibility. The VAR-SOM-MX6 ensures scalable and simplified development, while also extending the product lifecycle. Thanks to four CPU core assembly options, customers can apply a single System on Module in a broad range of applications to achieve short time-to-market for their current innovations, while still accommodating potential R&D directions and marketing opportunities.     VAR-SOM-MX6 CPU: Freescale iMX6 Key features include: Freescale i.MX6 1.2GHz Quad / Dual / Single core Cortex-A9       2GB DDR3, 1GB SLC NAND Flash       Full HD 1080p video encoding/decoding capability       Vivante GPU providing 2D/3D acceleration       Simultaneous multiple display support       Gigabit Ethernet       TI WiLink™ 6.0 single-chip connectivity solution (Wi-Fi, Bluetooth®)       PCI-Express 2.0, S-ATA 3.0       Camera interface       USB 2.0: Host, OTG       Audio In/Out       Dual CAN Bus This versatile solution's -40 to 85°C temperature range and Dual CAN support is ideal for industrial applications, while 1080p video and graphics accelerations make it equally suitable for intensive multimedia applications. The impressive scalability of the VAR-SOM-MX6 satisfies the needs of the most demanding future application requirements whether faster processing power, enhanced algorithms or improved graphics and video performance to name just a few. The VAR-SOM-MX6 is an all-round solution with broad connectivity and sophisticated video and acceleration graphic capabilities, delivering a range of middle to high end assembly options all from the same product. For more details, please see VAR-SOM-MX6 CPU: Freescale iMX6

Installation, patching and building the SDK The i.MX 6 Series Platform SDK v1.1.0 does not enable neither the MMU nor L1/L2 Caches (depending on the benchmark you are running, enabling these yield much better numbers), so there is a need to patch the code to enable these. Please download the SDK from the Freescale portal and the patch attached on this document, then follow these instructions: $ tar zxvf imx6_platform_sdk_v1.1.0.tgz $ cd iMX6_Platform_SDK $ patch -p1 < 0001-add-L2-cache-enable-to-mx6-SDK-1.1.0.patch $ export PATH=$PATH:<toolchain_install_path>/bin $ ./tools/build_sdk For more help, please look at the README.pdf and documents inside the doc folder.

Hello! Here's some CODE!!! #include <iostream> #include <stdio.h> #include <assert.h> #include <string.h> #include <fcntl.h> #include <malloc.h> #include <math.h> #include <stdlib.h> //#define EGL_USE_GLES2 #include <GLES2/gl2.h> #include <EGL/egl.h> #include <GLES2/gl2ext.h> #include <EGL/eglext.h> #include <termios.h> #include <unistd.h> #include <fcntl.h> #ifdef EGL_USE_X11 #include <X11/X.h> #include <X11/Xlib.h> #endif EGLDisplay egldisplay; EGLConfig eglconfig; EGLSurface eglsurface; EGLContext eglcontext; EGLNativeWindowType eglNativeWindow; EGLNativeDisplayType eglNativeDisplayType; EGLNativeDisplayType fsl_getNativeDisplay() {   EGLNativeDisplayType eglNativeDisplayType = NULL; #if (defined EGL_USE_X11)   eglNativeDisplayType = XOpenDisplay(NULL);   assert(eglNativeDisplayType != NULL); #elif (defined EGL_API_FB)   eglNativeDisplayType = fbGetDisplayByIndex(0); //Pass the argument as required to show the framebuffer #else   display = EGL_DEFAULT_DISPLAY; #endif   return eglNativeDisplayType; } EGLNativeWindowType fsl_createwindow(EGLDisplay egldisplay, EGLNativeDisplayType eglNativeDisplayType) {   EGLNativeWindowType native_window = (EGLNativeWindowType)0; #if (defined EGL_USE_X11)   Window window, rootwindow;   int screen = DefaultScreen(eglNativeDisplayType);   rootwindow = RootWindow(eglNativeDisplayType,screen);   window = XCreateSimpleWindow(eglNativeDisplayType, rootwindow, 0, 0, 400, 533, 0, 0, WhitePixel (eglNativeDisplayType, screen));   XMapWindow(eglNativeDisplayType, window);   native_window = window; #else   const char *vendor = eglQueryString(egldisplay, EGL_VENDOR);   if (strstr(vendor, "Imagination Technologies"))   native_window = (EGLNativeWindowType)0;   else if (strstr(vendor, "AMD"))   native_window = (EGLNativeWindowType)  open("/dev/fb0", O_RDWR);   else if (strstr(vendor, "Vivante")) //NEEDS FIX - functs don't exist on other platforms   { #if (defined EGL_API_FB)   native_window = fbCreateWindow(eglNativeDisplayType, 0, 0, 0, 0); #endif   }   else   {   printf("Unknown vendor [%s]\n", vendor);   return 0;   } #endif   return native_window; } void fsl_destroywindow(EGLNativeWindowType eglNativeWindowType, EGLNativeDisplayType eglNativeDisplayType) {   (void) eglNativeWindowType; #if (defined EGL_USE_X11)   //close x display   XCloseDisplay(eglNativeDisplayType); #endif } void GLInit (void) {   static const EGLint s_configAttribs[] =   {   EGL_RED_SIZE, 5,   EGL_GREEN_SIZE, 6,   EGL_BLUE_SIZE, 5,   EGL_ALPHA_SIZE, 0,   EGL_SAMPLES, 0,   EGL_NONE   };   EGLint numconfigs;   printf("1");   eglNativeDisplayType = fsl_getNativeDisplay();   printf("2");   egldisplay = eglGetDisplay(eglNativeDisplayType);   printf("3");   eglInitialize(egldisplay, NULL, NULL);   printf("4");   assert(eglGetError() == EGL_SUCCESS);   printf("5");   eglBindAPI(EGL_OPENGL_ES_API);   printf("6");   eglChooseConfig(egldisplay, s_configAttribs, &eglconfig, 1, &numconfigs);   assert(eglGetError() == EGL_SUCCESS);   assert(numconfigs == 1);   printf("7");   eglNativeWindow = fsl_createwindow(egldisplay, eglNativeDisplayType);   assert(eglNativeWindow);   printf("8");   eglsurface = eglCreateWindowSurface(egldisplay, eglconfig, eglNativeWindow, NULL);   assert(eglGetError() == EGL_SUCCESS);   printf("9");   EGLint ContextAttribList[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };   eglcontext = eglCreateContext( egldisplay, eglconfig, EGL_NO_CONTEXT, ContextAttribList );   assert(eglGetError() == EGL_SUCCESS);   printf("10");   eglMakeCurrent(egldisplay, eglsurface, eglsurface, eglcontext);   assert(eglGetError() == EGL_SUCCESS); } void GLEnd (void) {   printf("Cleaning up...\n");   eglMakeCurrent(egldisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);   assert(eglGetError() == EGL_SUCCESS);   eglDestroyContext(egldisplay, eglcontext);   eglDestroySurface(egldisplay, eglsurface);   fsl_destroywindow(eglNativeWindow, eglNativeDisplayType);   eglTerminate(egldisplay);   assert(eglGetError() == EGL_SUCCESS);   eglReleaseThread(); } int main (int argc, char **argv) {   GLInit();   for( int i = 0; i < 100000; ++i)   {   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);     // Clear The Screen And The Depth Buffer   glClearColor (.0f, .0f, 1.0f, 1.0f);   eglSwapBuffers (egldisplay, eglsurface);   }   GLEnd(); } Above code is stitched together from samples from GPU SDK. I've built an image using Yocto (dylan branch) and build the meta-toolchain-qt (and qte). Successfully managed to build above code ONLY FOR X11. Issues i am facing: 1) if build for X11 and run app on the board, window shows, but it stays white, when it should be BLUE...doesn't update no matter what color i glClear to. 2) when compiling with FB, fbCreateWindow and etc don't get recognized, i.e. undefined reference to `fbCreateWindow' .... WHAT header contains these functions???? 3) if even the basic samples don't work, how the hell is anybody supposed to build a GL application on this board?? --- more rhetorical than a real question, just frustrated here... what did i do wrong? 4) please show me a working tutorial or some code on how to get this EGL context initialized...i'm running at wit's end here...

Installation Build the development image (fsl-image-gui-sdk) using Yocto and flash it into the board Download LMbench's tarball from LMbench - Tools for Performance Analysis Untar the file and move the created folder Run the benchmarks following these steps: lmbench $ cd src lmbench/src $ make results lmbench/src $ cd .. lmbench $ make see Benchmarks Attached are the benchmarks results from several machines. In case you run them in a different machine, please attach your results file on this document. For more robust results, rerun several times the test and create the result document following these steps: lmbench $ make results lmbench $ make rerun lmbench $ make rerun lmbench $ make rerun lmbench $ cd results lmbench/results $ make > results # results is the output file you may want to attach to this document

Hi all, I shared my test results and solutions in attachments. Best regards, Carl

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

Hello everyone! In this document you'll find an example on how to setup your own recipe for Yocto Project to add your own custom changes, such as custom device tree, patches, custom drivers, etc. Linux kernel used in this guide 6.1.36_2.1.0 At least 120(250)GB HDD in the host PC Ubuntu 20.04 or later host PC ##Host Setup $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev python3-subunit mesa-common-dev zstd liblz4-tool file locales -y $ sudo locale-gen en_US.UTF-8 ##Setup Repo utility $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH ##Git Setup $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config --list ##Yocto Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml $ repo sync $ DISTRO=fsl-imx-wayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b buildwayland ##Create the new layer $ cd ../sources $ bitbake-layers create-layer meta-newlayer ##Add the new layer to the bblayers.conf in the build directory $ bitbake-layers add-layer meta-newlayer ##Check that it has been added correctly $ tree -L 4 ./meta-newlayer ##Edit the new layer and delete the samples created by yocto $ cd meta-newlayer $ rm -r recipes-example $ rm conf/layer.conf ##Use any text editor to create the layer configuration $ nano conf/layer.conf ##Add the following to the layer configuration file BBPATH .= ":${LAYERDIR}" BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \             ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "meta-newlayer" BBFILE_PATTERN_meta-newlayer := "^${LAYERDIR}/" BBFILE_PRIORITY_meta-newlayer = "8" LAYERSERIES_COMPAT_meta-newlayer = "mickledore" ##Prepare bbappend files so the patches get applied $ mkdir -p recipes-kernel/linux $ cd recipes-kernel/linux $ nano linux-imx_%.bbappend ##Add the following to the .bbappend file FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "file://001-add-imx8mp-dts-test.patch" PACKAGE_ARCH = "${MACHINE_ARCH}" KERNEL_DEVICETREE:append = " freescale/imx8mp-evk-test.dtb" ##Copy the patches to the layer file path, for this example I have created a simple patch to just rename the default device tree. $ mkdir files $ cp ~/patches/001-add-imx8mp-dts-test.patch files ##Make sure that the layers is created correctly $ bitbake-layers show-layers  ##Finally we bitbake our image $ cd ~/imx-yocto-bsp/buildwayland $ bitbake imx-image-multimedia #All the images built should appear at  <build directory>/tmp/deploy/images/<machine> Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.  

Introduction ARM SoC+FPGA/CPLD is widely used in some application like industry control and data acquisition system, there were many customers adopted i.MX6 EIM (a memory parallel interface) to access FPGA/CPLD, and archived good data throughput, but EIM is removed from i.MX8M and i.MX9, some customers is asking for such a compatible solution for i.MX8/8M and coming i.MX9 family.  FlexSPI is designed for connecting storage devices like NOR Flash, integrated in most of i.MXRT/i.MX8/LS products and provides flexible configuration for 4-wire/8wire working mode, this article provides a low-cost and efficiency demo to show how  to support CPLD/FPGA  via FlexSPI, as a replacement of EIM for EP i.MX8/9/LS products. key features Implement a  new kernel driver for FlexSPI to support read/write access to FPGA/CPLD. Support two type connections: Support 4-wire(QSPI) and 8-wire(HypeBUS, OctalSPI) Deliverables A new kernel driver for FlexSPI to support read/write access to FPGA/CPLD by AHB command A kernel patch to disable the QSPI Flash in kernel A test program shows how to do read/write performance test. Hardware Hardware Prepare: i.MX8MM-LPDDR4-EVK Lattice LFE5U EVK Figure1 4-wire SPI HW Block diagram Figure2 8-wire OctalSPI   Hardware Rework on i.MX8MM-EVK     1 Need to remove the SPI-Flash(U5, MT25QU256ABA) on the i.MX8MM-EVK board, and wire below signals: QSPI_DATA0 QSPI_DATA1 QSPI_DATA2 QSPI_DATA3 QSPI_SCLK QSPI_nSS0 VDD_1V8 GND Figure3 QPSI signals for FPGA/CPLD Figure4 Hardware rework on i.MX8MM-EVK board Note that, i.MX8MM-EVK QSPI power rails is 1.8v, so be careful that the FPGA/CPLD side IO should be 1.8V. Software BSP version 1 Linux BSP version: L5.10.52 Software Change  Apply 0001-FlexSPI-FPGA-need-to-disable-flexspi-for-fpga-usage.patch in Linux kernel and generate the new dtb extract the flexspi-fpga driver compile the flexspi-fpga driver with the kernel$ $make -C $(YOUR_KDIR) M=$(FlexSPI_FPGAW_DIVER_DIR) modules ARCH=arm64 CROSS_COMPILE=$(CROSS_COMPILE) Deployment  upload new generated i.mx8mm-evk.dtb to the target board(the 1st partition) upload the flex-spi driver and fpga/cpld test program to the target board   Test Test1: Set the flexspi working at 40Mhz   $insmod imx_flexspi_fpga.ko pre_div=2 post_div=5 Read/write FPGA/CPLD test .$/flexspi_fpga_test -p 0x08000000 -s 768 Test2: Set the FlexSPI working at 100MHz   $ insmod imx_flexspi_fpga.ko pre_div=1 post_div=4 Read/write FPGA/CPLD test $./flexspi_fpga_test -p 0x08000000 -s 768   Limitation FPGA and Flash devices can’t work at the same time due to just one FlexSPI controller. Due to the IO assignment conflict in i.MX8M EVK design, this demo just tested 4-wire（QSPI) mode at 50MHz and got data throughput as expected. Disclaimer: − “Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.”

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

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.