Useful information about push buttons.   Physical level.            When there is a change of voltage level on P0-P7 pins, PCA9555PW will generate interrupt on INT pin. The driver (running on SoC) can read the status of P0-P7 pins via I2C (SCL/SDA pins) and generate separate interrupts for each of P0-P7 pins. This is why this driver acts as interrupt controller. Consider next configuration:        One push button changes level on P4 pin, tempting PCA9555PW to generate interrupt. Interrupt from PCA9555PW is connected to GPIO5 IP-core (inside of SoC), and it uses line #9 of that GPIO5 module to notify CPU about interrupt. So we can say that PCA9555PW is cascaded to GPIO5 controller. GPIO5 also acts as interrupt controller, and it's cascaded to GIC interrupt controller.   Device tree properties.   The meaning of properties is as follows: interrupt-controller  property defines that device generates interrupts; it will be needed further to use this node as interrupt-parent in each push button node. #interrupt-cells defines format of interrupts property; in our case it's 2 : 1 cell for line number and 1 cell for interrupt type interrupt-parent and interrupts properties are describing interrupt line connection   Interrupt handling.   CPU now is in interrupt context in GIC interrupt handler. From gic_handle_irq() it calls handle_domain_irq() , which in turn calls generic_handle_irq() . See Documentation/gpio/driver.txt for details. Now we are in SoC's GPIO controller IRQ handler. SoC's GPIO driver also calls generic_handle_irq() to run handler, which is set for each particular pin. See for example how it's done in omap_gpio_irq_handler() . Now we are in PCA9555PW IRQ handler. PCA9555PW IRQ handler calls handle_nested_irq() . Finally, gpio_keys_gpio_isr() is called.      The following steps allow you to enable rgb led's and push buttons on 8MIC-RPI-MX8 board with i.MX 8M Mini Applications Processor Evaluation Kit (EVKB). You have to use a led driver and change the device tree. On the Host. Cloning the Linux kernel repository.   Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone https://source.codeaurora.org/external/imx/linux-imx This guide will use the following commit which corresponds to Kernel 5.10.35-2.0. cd linux-imx/ git checkout -b RGB ef3f2cfc6010 Patching the device tree.   Download the "0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch" file attached to this post and copy it into linux-imx directory, then apply the patch. cp 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch ~/linux-imx/ cd ~/linux-imx/ patch < 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch When prompted, select the file to patch: File to patch: arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts patching file arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8mm-evk-8mic-revE.dtb Copy the .dtb file to the EVK, for example with scp: scp imx8mm-evk-8mic-revE.dtb root@<EVK_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. Compiling the Led driver.   Obtain the leds-pca995x.h file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/include/linux/platform_data/leds-pca995x.h  Copy it into the next path: cp leds-pca995x.h ~/linux-imx/include/linux Create a new directory. mkdir ~/linux-imx/PCA9955 Create a makefile. cd ~/linux-imx/PCA9955 vim Makefile   KERNEL_ROOT?=~/linux-imx obj-m += leds-pca995x.o all: make -C $(KERNEL_ROOT) M=$(PWD) modules clean: make -C $(KERNEL_ROOT) M=$(PWD) clean   Press the key "Esc" and then: :wq Obtain the leds-pca995x.c file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/drivers/leds/leds-pca995x.c Copy it into the next path: cp leds-pca995x.c ~/linux-imx/PCA9955 Obtain 0001-PCA9955BTW.patch file and copy it into the next path: cp 0001-PCA9955BTW.patch ~/linux-imx/PCA9955 Apply the patch. patch < 0001-PCA9955BTW.patch Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate .ko file. cd ~/linux-imx/PCA9955 make all Copy the .ko file to the EVK, for example with scp: scp leds-pca995x.ko [email protected]:/home/root NOTE: The linux version of .ko file must be the same as EVK. On the EVK. Switching the device tree.   To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8mm-evk-8mic-revE.dtb Partition_1/ Reboot the board. reboot Stop on u-boot and modify the .dtb file to use the device tree for 8mic board. u-boot=> editenv fdtfile edit: imx8mm-evk-8mic-revE.dtb u-boot=> saveenv Saving Environment to MMC... Writing to MMC(1)... OK u-boot=> boot Installing a led driver.   Execute the following command to load the led driver into the kernel. insmod leds-pca995x.ko And you will see something like: [ 249.359103] leds_pca995x: loading out-of-tree module taints kernel. [ 249.366864] ALL [ 249.368740] ALL 0 [ 249.370667] ALL 1 [ 249.372609] ALL 2 [ 249.374536] ALL 2 [ 249.376475] ALL 2 [ 249.378401] ALL 2 [ 249.380338] ALL 2 [ 249.382264] ALL 2 [ 249.384202] ALL 2 [ 249.386127] ALL 2 [ 249.388063] ALL 2 [ 249.389989] ALL 2 [ 249.391913] ALL 2 [ 249.393847] ALL 2 [ 249.395774] ALL 2 [ 249.397709] ALL 2 [ 249.399635] ALL 2 [ 249.401568] ALL 2 [ 249.403496] ALL 3 Turning on a Led.   If you changed the device tree, you can turn on a led with the following command: echo 250 > /sys/class/leds/pca995x\:blue0/brightness To turn off a led: echo 0 > /sys/class/leds/pca995x\:blue0/brightness The red, blue and green leds can be turned on at different intensities provided. Testing the push buttons.   If you changed the device tree, you can test the push buttons with the following command: evtest Select the correct number: No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: 30370000.snvs:snvs-powerkey /dev/input/event1: sw_keys /dev/input/event2: gpio_ir_recv Select the device event number [0-2]: 1 And you will see: Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sw_keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 67 (KEY_F9) Event code 113 (KEY_MUTE) Event code 114 (KEY_VOLUMEDOWN) Event code 115 (KEY_VOLUMEUP) Properties: Testing ... (interrupt to exit) Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------ Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------

We will build a remote debug environmet of Qt Creator in this user guide.   Contents 1 Change local.conf file in Yocto 2 2 Build and deploy Yocto SDK 2 2.1 Build full image SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Deploy SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Configure QT Kit 2 3.1 Setup device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2 Configure QT version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3 Configure gcc and g++ manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Configure gdb manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Configure Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6 Very important thing!! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Test result

In some cases, such as OTA, need a complete reset/reboot of the i.MX8/i.MX8X. Current BSP default design for  i.MX8/i.MX8X is partition reset/reboot. So even using spl bootloader(flash.bin). The scfw is still running old version. Not the upgrade version as expected. Because the reset/reboot by the u-boot or Linux, Only reset/reboot the A Core partition. SCU is not reset. Need to change to the board reset, which will launch entire reset/reboot of the i.MX8/i.MX8X including SCU.

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

    Test environment: MPU6050 module,i.MX8MP,Android11_2.4.0 This solution ported the MPU6050 module on Android to realize auto rotation of screen.      

Hello everyone, this document will explain on how to create and run a custom script for UUU (Universal Update Utility) tool Requirements: I.MX 8M Mini EVK Linux Binary Demo Files - i.MX 8MMini EVK (L5.10.35) UUU Serial console emulator (tera term or putty) Text editor (Notepad++, nano, etc) UUU is a pretty flexible tool since it uses the Fastboot protocol through uboot to flash the desired images, this will make possible to create a custom script to add many uboot commands to customize further the boot settings. In this example I will create a custom script which will flash uboot and Linux rootfs and write a Cortex-M binary to the FAT partition of the eMMC. At the same time I’ll create and modify a set of environmental variables, this variables will have a set of uboot commands that will load to the TCM this same binary before the device starts booting into Linux.   Creating the script For this document I'll be using Notepad++ but any text editor may be used instead, since the scripts used by UUU are written in plain text. The very first line of the script must be the version number which will represent the minimum UUU version that UUU can parse this script. For this case that version is 1.2.39 After it, we will add all standard commands to flash uboot and filesystem into the eMMC. Note: This may be also copied from the uuu.auto script inside the Demo files. Please note that the UUU commands format is PROTOCOL: CMD, for this example we will be using mainly SDP and FB protocols which corresponds to the serial download protocol and Fastboot respectively. For a list of all supported UUU protocols and commands please refer to the UUU documentation here: https://github.com/NXPmicro/mfgtools/releases/download/uuu_1.4.165/UUU.pdf Now add the following commands to the script, this will download and write into eMMC FAT partition, which was created when flashing the .wic image, the Cortex-M binary.   FB: ucmd setenv fastboot_buffer ${loadaddr} FB: download -f hello_world_test.bin FB[-t 20000]: ucmd fatwrite mmc ${emmc_dev}:1 ${fastboot_buffer} hello_world_test.bin ${fastboot_bytes}   #fatwrite write file into a dos filesystem "<interface> <dev[:part]> <addr> <filename> [<bytes> [<offset>]] - write file 'filename' from the address 'addr' in RAM  to 'dev' on 'interface' Note: The Cortex-M binary was named as hello_world_test.bin, but any example name may be used. At this point, in the script we will be using only uboot commands as seen above, in this case was fatwrite. The script will look as following: If the script is run now uboot (imx-boot-imx8mmevk-sd.bin-flash_evk), rootfs (imx-image-multimedia-imx8mmevk.wic) will be flashed and the Cortex-M binary (hello_world_test.bin) written to the FAT partition of the eMMC. To add environmental variables to modify uboot boot settings, i.e. overwrite the dtb variable so the EVK will select the RPMSG dtb, this in case the Cortex-M example needs to be run at the same time as Cortex-A. FB: ucmd setenv fdtfile imx8mm-evk-rpmsg.dtb Next add to the UUU script the set of uboot commands in form of environmental variables that will load to the TCM the Cortex-M binary   FB: ucmd setenv loadm4image "fatload mmc ${emmc_dev}:1 0x48000000 hello_world_test.bin; cp.b 0x48000000 0x7e0000 0x20000" FB: ucmd setenv m4boot "run loadm4image; bootaux 0x48000000" Note: This can be changed to load it to different targets not only TCM, for example DRAM. Now for the set of environmental variable to run when uboot starts booting into Linux we may add it to the variable mmcboot. Also adding the command to save the environmental variables set so the settings persist after reboot, this by adding the following commands to the script:   FB: ucmd setenv mmcboot "run m4boot; $mmcboot" FB: ucmd saveenv The resulting script will be the following: Now just save the script and name it as you see fit, for this example the name will be custom_script.auto.   Running the script To run a UUU script is pretty simple, just make sure that the files used in the script are in the same folder as the script. Windows > .\uuu.exe  custom_script.auto Linux $ sudo ./uuu custom_script.auto   Wait till it finish, turn the board off, set it to boot from eMMC and turn it on, the EVK will boot into Linux automatically and will launch the Cortex-M core automatically. We may also, double check that the environmental variables were written correctly by stopping at uboot and using the printenv command For this test I have used the Prebuilt image which includes sample Cortex-M4 examples for the EVK   further flexibility UUU scripts can be customized even more, for example using macros, so the script can take input arguments so it may be possible to select the uboot, rootfs, Cortex-M binary and dtb to be used when booting, and to be used for other i.MX chips as well. The resulting script will be as following: Note: Here is assumed that the dtb file is already at the FAT partition, if not same procedure may be added as the Cortex-M binary. To run a script which expect to have input arguments is as follow: Windows > .\uuu.exe -b uuu_cortexM_loader.auto imx-boot-imx8mmevk-sd.bin-flash_evk imx-image-multimedia-imx8mmevk.wic hello_world_test.bin imx8mm-evk-rpmsg.dtb Linux $ sudo ./uuu -b uuu_cortexM_loader.auto imx-boot-imx8mmevk-sd.bin-flash_evk imx-image-multimedia-imx8mmevk.wic hello_world_test.bin imx8mm-evk-rpmsg.dtb Please find both UUU scripts attached and feel free to use them. Hope this helps everyone to better understand how this tool works and the capabilities it have.

This is a quick article focused on how to add the support of SFTP on the i.MX devices using Yocto to add that packages.   Refer to the pdf attached.

This is a quick article focused on how to add the support of the ssh on the i.MX devices using Yocto to add that packages.   Refer to the pdf attached.

Enable HDMI CEC function Board: i.MX8MQ Board BSP version: imx-android-11.0.0_2.2.0  Following the Android user guide download and built the Android-11.0.0_2.2.0 BSP  The build directory shared here:  http://10.168.2.226/android/build_folder/device/nxp/imx8m/evk_8mq/hdmicec/. or use the files in attachment. The steps are: Copy the above link code to their android env under device/nxp/imx8m/evk_8mq/hdmicec/.  In device/nxp/imx8m/evk_8mq/evk_8mq.mk, adding below code: +PRODUCT_PACKAGES += \ hdmi_cec.nxp\ hdmicec_test" (2) Compile that. (3) Copy to board  adb root adb remount adb push hdmi_cec.nxp.so /vendor/lib64 adb push hdmi_test /vendor/bin evk_8mq:/vendor/bin # ./hdmicec_test [  349.297183] msg[0]=0x40 [  349.299641] msg[1]=0x4

Symptoms   When configure a gpio pin for a driver in the dts/dtsi file like below example,   e.g.   a-switch {            compatible = "a-switch-driver";            pinctrl-names = "default";            pinctrl-0 = <&pinctrl_switch>;            gpios = <&lsio_gpio1 1 GPIO_ACTIVE_HIGH>;            status = "okay"; };   pinctrl_switch: switch_gpio {     fsl,pins = < IMX8QXP_SPI2_SDO_LSIO_GPIO1_IO01    0x21 >; };   then you may get the error when request the gpio in the driver during the kernel boot up.   Error message like this: a-switch: failed to request gpio a-switch: probe of a-switch failed with error -22   Linux version: L5.4.x   Diagnosis   Because the gpio_mxc_init function run before the function imx_scu_driver_init. The pm_domains for gpio is not ready before running mxc_gpio_probe, so gpio request will be failed.     Solution   There are two ways to resolve this issue 1. Build the driver as a module. i.e. select the driver in kernel’s menuconfig as “M”. Then , run “insmod” to load the driver after the kernel boot up.   OR   2. Apply below patch, let gpio driver init after scu driver. diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c index 1dfe513f8fcf..52b5799040b3 100644 --- a/drivers/gpio/gpio-mxc.c +++ b/drivers/gpio/gpio-mxc.c @@ -892,7 +892,7 @@ static int __init gpio_mxc_init(void) return platform_driver_register(&mxc_gpio_driver); } -subsys_initcall(gpio_mxc_init); +device_initcall(gpio_mxc_init);  

The i.MX 8QuadXPlus Multisensory Enablement Kit (MEK) is a NXP development platform based on Cortex A-35 + Cortex-M4 cores. Built with high-level integration to support graphics, video, image processing, audio, and voice functions, the i.MX 8X processor family is ideal for safety-certifiable and efficient performance requirements. This tutorial shows how to enable the Cortex-M4 using the MCUXpresso SDK package and loading the binary from the network. NOTE: It is also possible to load the Cortex-M4 image from the SCFW using the imx-mkimage utility. But now we are going to focus on MCUXpresso. Setting up the machine   Install cmake on the host machine: $ sudo apt-get install cmake Download the armgcc toolchain and export the location as ARMGCC_DIR: $ export ARMGCC_DIR=<your_path_to_arm_gcc>/gcc-arm-none-eabi-9-2020q2/ NOTE: The ARMGCC_DIR variable needs to be exported on the terminal used for compilation. To setup the TFTP server on the host machine: Configuring your Host PC for TFTPPermalink   The first step is to install all the prerequisite packages for TFTP: $ sudo apt-get install xinetd tftpd tftp Create a TFTP folder in your desired location with root owner and the “rwx” permission for all users: $ sudo mkdir /tftpboot $ sudo chmod –R 777 /tftpboot $ sudo chown –R root /tftpboot Create a configuration file for the TFTP with the following content. (The server_args parameter must match with the folder created above) $ cat /etc/xinetd.d/tftp service tftp { protocol = udp port = 69 socket_type = dgram wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s /tftpboot disable = no } Restart the xinetd service: $ sudo /etc/init.d/xinetd restart You can place any file at the TFTP folder and load it through U-Boot, you can also create symbolic links from your building directory avoiding to copy and paste your zImage and dtb files every time. Configuring your Host PC for NFSPermalink   Install all the needed packages for NFS: $ sudo apt-get install nfs-kernel-server Create a folder for placing your rootfs: $ mkdir /tftpboot/rfs Add the following line in the end of your /etc/exports file: /tftpboot/rfs *(rw,no_root_squash,no_subtree_check) Restart the NFS service: $ sudo service nfs-kernel-server restart Place your rootfs or create a symbolic link for the NFS folder.    Downloading the SDK Download the MCUXpresso following these steps: Click on “Select Development Board”; Select MEK-MIMX8QX under “Select a Device, Board, or Kit” and click on “Build MCUXpresso SDK” on the right; Select “Host OS” as Linux and “Toolchain/IDE” as GCC ARM Embedded; Add “FreeRTOS” and all the wanted Middleware and hit “Request Build”; Wait for the SDK to build and download the package. Building the image All demos and code examples available on the SDK package are located in the directory <<SDK_dir>>/boards/mekmimx8qx/. This tutorial shows how to build and flash the hello_world demo but similar procedures can be applied for any example (demo, driver, multicore, etc) on the SDK. To build the demo, enter the armgcc folder under the demo directory and make sure that the ARMGCC_DIR variable is set correctly. $ cd ~/SDK_2.3.0_MEK-MIMX8QX/boards/mekmimx8qx/demo_apps/hello_world/armgcc $ export ARMGCC_DIR=<your_path_to_arm_gcc>/gcc-arm-none-eabi-9-2020q2/ Run the build_release.sh script to build the code. $ ./build_release.sh NOTE: If needed, give the script execution permission by running chmod +x build_release.sh. This generates the M4 binary (hello_world.bin) under the release folder. Copy this image to the /tftpboot/ directory on the host PC. NOTE: This procedure shows how to build the M4 image that runs on TCM. To run the image from DDR, use the build_ddr_release.sh script to build the binary under the ddr_release folder. Flashing the image Open two serial consoles, one for /dev/ttyUSB0 for Cortex-A35 to boot Linux, and one for /dev/ttyUSB1 for Cortex-M4 to boot the SDK image. On the A35 console, with a SD Card with U-Boot, stop the booting process and enter the following commands to load the M4 binary to TCM: => dhcp => setenv serverip <ip_from_host_pc> => tftp 0x88000000 hello_world.bin => dcache flush => bootaux 0x88000000 Then the M4 core will load the image to the /dev/ttyUSB1 console.    

In some cases, i.MX board connect to different module. It has very tiny changes, such as just one gpio different driver strength. We can build an entire new software to handle this requirement. Here we introduce another way, using u-boot to modify the device tree(dtb) at runtime.   Here is u-boot fdt command for  How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709   run loadfdt fdt addr ${fdt_addr_r} fdt print /soc/bus/pinctrl/uart3grp fdt rm /soc/bus/pinctrl/uart3grp fdt print serial2 fdt set serial2 status disabled fdt print serial2 fdt print gpio4 fdt resize fdt mknode gpio4 gpio_hog_demo fdt set gpio4/gpio_hog_demo gpio-hog fdt set gpio4/gpio_hog_demo gpios <7 0> fdt set gpio4/gpio_hog_demo output-high fdt print gpio4 run mmcargs run loadimage booti ${loadaddr} - ${fdt_addr_r} root@imx8mmevk:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/30200000.gpio, 30200000.gpio: gpio-5 ( |PCIe DIS ) out hi gpio-13 ( |ir-receiver ) in hi IRQ ACTIVE LOW gpio-15 ( |cd ) in hi IRQ ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/30210000.gpio, 30210000.gpio: gpio-38 ( |? ) out hi gpio-42 ( |reset ) out lo ACTIVE LOW gpio-51 ( |regulator-usdhc2 ) out lo gpiochip2: GPIOs 64-95, parent: platform/30220000.gpio, 30220000.gpio: gpio-80 ( |status ) out hi gpiochip3: GPIOs 96-127, parent: platform/30230000.gpio, 30230000.gpio: gpio-117 ( |PCIe reset ) out hi gpiochip4: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: gpio-135 ( |gpio_hog_demo ) out hi gpio-141 ( |spi1 CS0 ) out hi ACTIVE LOW gpio-149 ( |wlf,mute ) out hi ACTIVE LOW root@imx8mmevk:~# [ 33.758914] VSD_3V3: disabling dtc_utils-v1.6.1-win-x86_64.zip by msys2   

Introduction This document intends to describe how to implement workaround for ERR050145 (ISI: Memory overwrite occurring outside of allocated buffer space corrupting system memory) based on Linux BSP. ERR050145 is applicable for i.MX8QM B0, i.MX8QXP B0 series products.   Software Platform Reference patches stated into this document are developed and validated on L4.14.98_GA2.0.0 release.   Software Workaround As workaround stated, the xRDC can be programmed to grant write access to the ISI only within its allocated frame buffer space, which can prevent the corruption. So under Linux, we can consider to implement workaround like so: Create children partition for ISI and allocate buffers. Then Linux can access these buffers as normal, but ISI can't access other memory out of these buffers, it is limited by xRDC hardware. Considering the xRDC hardware can only support up to 16 memory regions, we may need to consider different workaround implementations for different camera use case scenarios.   For single camera use case, the required camera buffer number is usually less than 16. So “0001-iMX8QM-iMX8QX-ERR050145-ISI-overwrite-workaround.patch” is enough. No modification is needed for camera application in this case.   For multiple camera use case, all patches (0001~0003) are needed. If the camera application used VB2_MEMORY_MMAP memory mode, then no code modification is needed in application. The V4l2 ISI driver can handle everything (Allocate physical continued memory for each camera, and map them as one xRDC memory region for overwrite protect). If the camera application used VB2_MEMORY_USERPTR and VB2_MEMORY_DMABUF memory mode, then it needs allocate camera buffers with physical continued memory for each camera, then the driver will merge them as one xRDC memory region in SCFW.   How to prove workaround take effective? After applying the patches, the ISI will report AXI_WR_ERR due to it failed to write data out of the allocated buffers when the errata happens. To reduce the ISI interrupt, we can also change the ISI interrupt setting as followed: void mxc_isi_enable_irq(struct mxc_isi_dev *mxc_isi) {     u32 val;     val = CHNL_IER_FRM_RCVD_EN_MASK |         CHNL_IER_EXCS_OFLW_V_BUF_EN_MASK |         CHNL_IER_EXCS_OFLW_U_BUF_EN_MASK |         CHNL_IER_EXCS_OFLW_Y_BUF_EN_MASK;     writel(val, mxc_isi->regs + CHNL_IER); }   Add reference patch for L5.4.70_2.3.0 and L5.10.72_2.2.0.

i.MX8DXL DDR3L EVK board, nor flash using is MT25QU512ABB8ESF-0SIT. This doc will show reference of FlexSPI configuration parameters to make booting from MT25Q flash, with QUAD pad and DDR mode. HW: i.MX8DXL DDR3L EVK board SW: Linux 5.4.70 BSP From RM 5.9.3.2 FlexSPI serial flash BOOT operation, the FlexSPI boot flow as :   FlexSPI configuration parameters,  could be think as two kind group: parameter for FlexSPI controller,  parameter related to the operation on nor flash.   Full parameter table check check i.MX8DXL RM Table 5-20. FlexSPI Configuration block. Let us check MT25Q data sheet for its feature, note our target is DDR mode(80MHZ) and QUAD pad:     Now let us change the FlexSPI configuration parameters: 1>readSampleClkSrc , set as 2 , that is loop back from SCK pad; this filed default set as 0, as found default value booting will met failure in this use case, so change to 2. 2>deviceModeCfgEnable set 1, deviceModeSeq.seqNum set 1 , deviceModeSeq. seqId set to 4; deviceModeArg set 0x5f. i.MX8DXL will send some cmd to flash to make MT25Q enter DDR mode and QUAD mode, so deviceModeCfgEnable =1. For seqNum=1, seqId =4; means index 4 of LUT table will store this sequence, and cost one LUT entry. We will explain how to change LUT entry later. For deviceModeArg=0x5f, check MT25Q data sheet, its enhanced volatile register could be write to configure the flash working mode:  3>controllerMiscOption as 0x40, this parameter only for FlexSPI controller itself, means as” External device works using DDR commands”. 4>deviceType=1(Serial Nor),  sflashPadType=4 (QUAD pad),  serialClkFreq=4(80MHZ CLK), these parameter also only for FlexSPI controller. 5>sflashA1Size fill actual size, in terms of bytes 6>LUT entry changes, check 8DXL RM Table 5-21: So LUT entry 0 is sequence for Read command, entry 1 is for Read Status sequence, entry 3 is for Write Enable sequence,  entry 15 is for Dummy command sequence. Other index LUT entry(for example 2,4,6,7,8,10,12,13,14) is could be used for store your sequence for some cmd your flash device neede. We store sequence of writing MT25Q enhance volatile register as LUT entry 4. Check 8DXL RM,  Figure 15-6. LUT and sequence structure:   Each LUT entry (sequence) will using 16 byte,  one sequence consists of up to 8 instructions, each instruction will using 16bit. Each instruction  format as opcode—num_pads—operand. Check RM 15.2.4.8 Programmable Sequence Engine, for supported instructions:   Actually the Write enable sequence is run first before the other sequence, as we will write Mt25Q volatile register, before that need issue Write enable sequence. Check MT25Q data sheet: For this sequence only need one instruction, that is 0x0406, at this time still using is SDR and one pad mode:  Opcode (CMD_SDR),  one pad (0), operand (6).   LUT entry 1, Read status sequence, it is READ STATUS REGISTER (05h) of MT25Q , check data sheet: It use two instructions: 0x0405: opcode(CMD_SDR), pad (one pad), operand (0x5, READ STATUS REGISTER) 0x2404: opcode(READ_SDR), pad (one pad), operand (0x4 , byte number)   LUT entry 4, that is for make MT25Q enter DDR mode and quad pad: From MT25Q data sheet: It will use two instructions, that is 0x0461: opcode (CMD_SDR),  one pad (0), operand (0x61 WRITE ENHANCED VOLATILE CONFIGURATION REGISTER) 0x2001: opcode (WRITE_SDR 08), one pad(0), operand (1 byte data size) The 0x5f will be send out as data.   Next check LUT entry read , at this time MT25Q had enter QUAD pad and DDR mode: LUT entry 0, Read sequence, it is fast read data from MT25Q, from data sheet: will use four instructions , that is : 86ED, opcode (CMD_DDR ), pad ( four pad), operand (0xEDh fast read) 8a18, opcode (RADDR_DDR), pad (four pad), operand (0x18 , three byte address) B210, opcode(DUMMY_ADDR), pad (four pad), operand(0x10, dummy cycle) A604, opcode (READ_DDR), pad (four pad) , operand (0x4, data byte)   Reference: 1.i.MX8DXL Reference Manual 2.MT25Q data sheet              

   

  This patch will add bootaux command to imx7ulp uboot.   This would make it easier in start M4 binary image in single boot mode.   Feature: 1. Support using m4 image in .bin format. 2. Support bootaux command in u-boot. 3. Support boot from TCM and DDR (DDR not tested, if any issue, pls let me know.).   Note: 1. SDK TCM entry address is 0x1FFD2000. But TCML base address is 0x1FFD0000. Pls take care to set a correct entry address to m4_loadaddr. 2. If user want to use M4 image generated from imx_mkimage, pls refer to bootaux patch in https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/OTA-upgrade-for-smartlocker-in-i-MX7ULP-kernel/ta-p/1112687.   Test procedure: 1. Set u-boot parameters: setenv m4_loadaddr 0x1FFD2000 setenv m4_copyaddr 0x62000000 setenv m4_image hello_world.bin setenv m4_flash_imglen 0x30000 setenv m4_loadimage "fatload mmc '${mmcdev}':'${mmcpart}' '${m4_copyaddr}' '${m4_image}'; cp.b '${m4_copyaddr}' '${m4_loadaddr}' 0x30000" setenv run_m4_image "run m4_loadimage; dcache flush; bootaux '${m4_loadaddr}'" 2. Copy hello_world.bin to SD card and boot board. Make sure board is in single boot mode. 3. Run "run run_m4_image"   4. On M core console.    

  Some customers are using sgtl5000 in android. So i generate this patch of sgtl5000 in Android11(i.MX8QM)

This document shows how to build genivi step by step, but I haven’t tested the images yet, before building the images, pls refer to the host setup and host packages according to the yocto project user’s guide, I don’t mention here again, this is for imx8mq as example, you can choose the different board name to build   Before building the genivi package, customer also can refer to the kernel and image name from: https://github.com/GENIVI/meta-ivi/tree/master   4.9.88 IMAGE   1. Create a bin folder in the home directory $ 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    2. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH    3. Yocto Project Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-rocko -m imx-4.9.88-2.0.0_genivi.xml $ repo sync   4.update Weston 3.0.0 to Weston 4.0.0 $ git clone https://git.yoctoproject.org/git/meta-freescale -b warrior   then replace the wayland directory in "imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland" with the "meta-freescale/recipes-graphics/wayland" in cloned directory.   5.image build DISTRO=nxp-imx-genivi-wayland MACHINE=imx8mqevk source ./nxp-setup-genivi.sh -b genivi-wayland   $bitbake  pulsar-image    6.Error fix if you don’t update Weston, you should get the error message like The error shows required Weston >=4.0.0, but current bsp includes Weston version is 3.0.0, so you need to update the Weston to the 4.0.0 step by step $ git clone https://git.yoctoproject.org/git/meta-freescale -b warrior $ rm -rf ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland $ cp -r meta-freescale/recipes-graphics/wayland ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/   $ bitbake -c cleansstate wayland-ivi-extension $ bitbake  wayland-ivi-extension $ bitbake  pulsar-image   4.14.95 IMAGE   1. Create a bin folder in the home directory $ 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   2. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH   3.Yocto Project Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-warrior -m imx-4.19.35-1.1.0_genivi.xml $ repo sync   4. change Weston 6.0.1 to Weston 5.0.0 $ git clone https://git.yoctoproject.org/git/meta-freescale -b zeus   then replace the wayland directory in "imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland" with the "meta-freescale/recipes-graphics/wayland" in cloned directory.   5.image build $ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source fsl-setup-release.sh -b build-wayland   $ bitbake  meta-ivi-image    6.Error fix if you don’t change Weston, you should get the error message like so try to change the Weston to the 5.0.0 step by step $ git clone https://git.yoctoproject.org/git/meta-freescale -b zeus $ rm -rf ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland $ cp -r meta-freescale/recipes-graphics/wayland ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics   $ bitbake -c cleansstate weston $ bitbake  weston $ bitbake  meta-ivi-image     5.4.24 IMAGE   1. Create a bin folder in the home directory $ 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   2. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH   3.Yocto Project Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.24-2.1.0_genivi.xml $ repo sync   4. image build $ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source imx-setup-release.sh -b build-wayland   $ bitbake  meta-ivi-image    

Here is simple step to create a custom partition with AVB. Tested by i.MX8MN EVK and Android P9.0.0_2.3.1. Create image for xyz partition in 1024MB in Android build output folder # cd $OUT # mkdir xyz # echo "This is test txt file" > xyz/Readme.txt # make_ext4fs -l 1073672192 -s -a xyz xyz.ext4.img xyz   Apply the attached patch. uboot patch corrects the reading problem on avb footer.   Flash images by uuu # cd $OUT # sudo ./uuu_imx_android_flash.sh -f imx8mn   Check result.  Boot up and mount xyz partition # cd /data # mount /dev/block/mmcblk2p14 xyz # cat xyz/Readme.txt This is test txt file