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 root@192.168.100.105:/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 ------------

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.

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

  1.overwrite the sources/meta-freescale/recipes-security/optee-imx with optee-imx.zip 2.add below code to conf/local.conf DISTRO_FEATURES_append += " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "systemd-compat-units" MACHINE_FEATURES_append += "optee" DISTRO_FEATURES_append += "optee" IMAGE_INSTALL_append += "optee-test optee-os optee-client optee-examples" 3.bitbake optee-examples or bitbake imx-image-xxx You can directly install optee-examples_3.11.0-r0_arm64.deb in your device.  

What is Automotive Grade Linux? Automotive Grade Linux is a collaborative, open source project that brings together automakers, suppliers, and technology companies for the purpose of building Linux-based, open source software platforms for automotive applications that can serve as de facto industry standards. AGL address all software in the vehicle: infotainment, instrument cluster, heads-up-display (HUD), telematics, connected car, advanced driver assistance systems (ADAS), functional safety, and autonomous driving. Architecture The Automotive Grade Linux Software Architecture diagram is below. The architecture consists of five layers. The App/HMI layer contains applications with their associated business logic and HMI. The Application Framework layer provides the APIs for creating both managing and running applications on an AGL system. The Services layer contains user space services that all applications can access. The Operating System (OS) layer provides the Linux kernel and device drivers along with standard OS utilities. For IVI (In Vehicle Infotainment) system a full fledged demo is available. Supported Boards The following table briefs about the various hardware platforms, supported by AGL : BOARD $MACHINE ARCHITECHTURE BeagleBone bbe arm32   beaglebone arm32       i.MX 6 cubox-i arm32   imx6qdlsabreauto arm32   nitrogen6x arm32       i.MX 8 imx8mqevk arm64   imx8mqevk-viv arm64       Snapdragon dragonboard-410c arm64   dragonboard-820c arm64       ARC HS hsdk ARC       virtio virtio-aarch64 arm64   AGL Components AGL includes some major components showing as follow: agl-compositor waltham-receiver_waltham-transmitter rba drm-leasemanager appfw cynagora. pyagl pipewire_wireplumber agl-compositor When the AGL project was started, weston was chosen as the compositor, which is the reference implementation of a Wayland compositor, while for window management functionality it relied on ivi-shell (In-Vehicle Infotainment) together with an extension, called wayland-ivi-exension.   Waltham protocol is a IPC library similar to Wayland, developed with networking in mind. It operates over TCP sockets, while the wayland protocol only works locally over a UNIX socket. It retains wayland-esque paradigm, making use of XMLs to describe the protocol, and it follows an object-oriented design with an asynchronous architecture. DRM Lease Manager The DRM Lease Manager is used in AGL to allocate display controller outputs to different processes. Each process has direct access to its allocated output via the kernel DRM interface, and is prevented from accessing any other outputs managed by the display controller. PyAGL  PyAGL was written to be used as a testing framework replacing the Lua afb-test one, however the modules are written in a way that could be used as standalone utilities to query and evaluate apis and verbs from the App Framework Binder services in AGL. PipeWire / WirePlumber AGL uses the PipeWire daemon service to provide audio playback and capture capabilities. PipeWire is accompanied by a secondary service, WirePlumber (also referred to as the session manager), which provides policy management, device discovery, configuration and more. Applications can connect to the PipeWire service through its UNIX socket, by using either the libpipewire or libwireplumber libraries as a front-end to that socket. How to port AGL in i.MX8qm get agl source as follow: repo init -b koi -uhttps://git.automotivelinux.org/AGL/AGL-repo repo sync apply patches in attachment add file agl_imx8qmmek.inc to path 'meta-agl\meta-agl-bsp\conf\include'. add files 40_bblayers.conf.inc, 50_local.conf.inc and 50_setup.sh to path 'meta-agl\templates\machine\imx8qmmek'. build as follow: source meta-agl/scripts/aglsetup.sh -f -m imx8qmmek agl-demo bitbake agl-demo-platform Then the wic image can be flashed into i.mx8qm showing as below:

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.

Since LF_v5.10.52-2.1.0 crypto_af_alg blackkey demo “caam-decrypt” becomes default in release. You can try it with binary demo release image. The demo is using black key to decrypt data. This document goes more detail based on BSP release document i.MX Linux® User's Guide, Rev. LF5.10.52_2.1.0, 15 October 2021 10.6 crypto_af_alg application support   HW: i.MX8MM EVK SW: LF_v5.10.52-2.1.0_images_IMX8MMEVK binary demo image PC side: 1. generate key and iv by openssl echo 12345 | openssl enc -aes-256-cbc -k - -P -md sha1 -pbkdf2 salt=1982686A7BACEE4D key=D84041EC14BB28543E8545BEB094FE643B5BC1345C31CD576BC708A1559FBD2D iv =F950CACE80F76F0AC00D9C8762B3A5C9 2. encrption by openssl echo "For test caam-decrypt" | openssl enc -e -aes-256-cbc -in - -out test.txt.enc -K D84041EC14BB28543E8545BEB094FE643B5BC1345C31CD576BC708A1559FBD2D -iv F950CACE80F76F0AC00D9C8762B3A5C9 3. decryption by openssl openssl enc -d -aes-256-cbc -in test.txt.enc -out - -K D84041EC14BB28543E8545BEB094FE643B5BC1345C31CD576BC708A1559FBD2D -iv F950CACE80F76F0AC00D9C8762B3A5C9 4. convert key and iv to plian txt for caam-decrypt. echo F950CACE80F76F0AC00D9C8762B3A5C9| xxd -r -p > fromopenssl.iv.txt echo D84041EC14BB28543E8545BEB094FE643B5BC1345C31CD576BC708A1559FBD2D| xxd -r -p > fromopenssl.key.txt 5. prepare data for caam-decrypt cat fromopenssl.iv.txt test.txt.enc > data.caam-decrypt.enc note: the format for with blackkey AES Encrypted file format 16 Octets - Initialization Vector (IV) is an input to encryption algorithm. nn Octets - Encrypted message (for AES-256-CBC, it must be multiple of 16) 6. send fromopenssl.key.txt and data.caam-decrypt.enc to the board on i.MX8MM evk board 1. generate blackkey blob caam-keygen create blackkey ecb -t $(cat fromopenssl.key.txt) 2. delete fromopenssl.key.txt 3. test decryption by caam-decrypt with blackkey caam-decrypt /data/caam/blackkey.bb AES-256-CBC data.caam-decrypt.enc data.caam-decrypt.dec root@imx8mmevk:/# cat data.caam-decrypt.dec For test caam-decrypt  

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.    

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.

Here is the docment about arm64 kernel booting process, which is helpful for us to port kernel. It include the bootloader protocol, virtual memory layout, dtb, memory init, irq init, timer init and so on, please take the attachment for details. vmlinux ELF vmlinux.lds.S head.S __create_page_tables __cpu_setup __primary_switch init_task IRQ Vectors Start_kernel setup_arch paging_init bootmem_init psci_dt_init mm_init sched_init init_IRQ time_init rest_init You can refer the diagram show as below:  

Following OTA in Android User Guide would have HASH verification error: update_engine: [0913/085233.421711:ERROR:delta_performer.cc(1140)] Expected: sha256|hex = 685B998E4308F20FEA83D97E60222121FFE27983F013AED5C203709E139AE9DB update_engine: [0913/085233.421760:ERROR:delta_performer.cc(1143)] Calculated: sha256|hex = B1025634138BF2B5378196E364350E1E5FCA126DEE0990A592290CEBFADC3F8B The OTA process that produced the error: * After compiling the images according to the user guide, burn the images in the /out directory into the board * Then build the first target file according to 7.1.1 Building target files, such as PREVIOUS-target_files.zip * Modify part of the code to build the second target file, such as NEW-target_files.zip: * Make a differential upgrade package and perform differential OTA The root cause of the error caused by the above steps: Differential OTA requires that the onboard system.img must be the system.img generated when the target files are created for the first time. Only in this way can the correct hash value be calculated. When we execute the following command to make target files make target-files-package -j4 Will repackage a copy of system.img in the /out directory and this system.img does not meet the requirements. The system.img used by the differential package must be system.img in out/target/product/evk_8mm/obj/PACKAGING/systemimage_intermediates/. Therefore, the system.img we burned in the first step did not meet the requirements, resulting in hash verification errors. Solution 1: After the first step of programming, do a full update. When using the make otapackage -j4 command, a target_files.zip file will also be generated, which we will regard as PREVIOUS-target_files.zip. Modify part of the code and make NEW-target_files.zip. Finally, the differential upgrade can be successful. Solution 2: After finishing the first target_files.zip, copy the system.img in out/target/product/evk_8mm/obj/PACKAGING/systemimage_intermediates/ to the out/target/product/evk_8mm directory, and then use uuu Perform programming. After burning and writing, make the second target_files.zip, and finally you can upgrade by differential.

This document describes the steps to create your own out-of-tree kernel module recipe for Yocto.

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. These are detailed programming aids for the registers associated with DRAM initialization (LPDDR3 and LPDDR2). The last work sheet tab in the tool formats the register settings for use with the ARM DS5 debugger. It can also be used with the windows executable for the DDR Stress Test (note the removal of debugger specific commands in this tab). These programming aids were developed for internal NXP validation boards.   This tool serves as an aid to assist with programming the DDR interface of the i.MX 7ULP and is based on the DDR initialization scripts developed for NXP boards and no guarantees are made by this tool.   The following are some general notes regarding this tool: The default configuration for the tool is to enable bank interleaving. Refer to the "How To Use" tab in the tool as a starting point to use this tool. The tool can be configured for one of the two memory types supported by the i.MX 7ULP.  Nevertheless, two separate programming aids are provided based on the DRAM type: LPDDR3 and LPDDR2.  Therefore, you may use the tool pre-configured for your desired memory type as a starting point. Some of the CCM programming at the beginning of the DRAM initialization script (in the "DStream .ds file" tab) were automatically generated and in very few cases may involve writing to reserved bits, however, these writes to reserved bits are simply ignored. Note that in the "DStream .ds file" tab there are DS5 debugger specific commands that should be commented out or removed when using the DRAM initialization for non-debugger specific applications (like when porting to bootloaders). This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance. For questions or additional assistance using this tool, please contact your local sales or FAE.

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

Some customers want a method to build imx8mp isp standalone instead of using yocto. For such purpose, the NXP kernel, yocto imx-isp and yocto vvcam can be built separately on your local machine. After necessary files are remotely transferred, you will be able to run isp on an evk board. The attached file contains detailed steps for building isp standalone. Please see the guide for further information.

  From L5.4 BSP, the iMX8QM HDMI RX feature is removed from BSP, but it is added back in L5.10.52 2.1.0 BSP. The followed is the detail steps to use HDMI RX.   We need enable the followed kernel config to make hdmirx driver work:     CONFIG_IMX8_MEDIA_DEVICE=y     CONFIG_MHDP_HDMIRX=y apply the attached kernel patch. put hdmi firmware “hdmirxfw.bin” and “hdmitxfw.bin” to SD card’s FAT partition test command:     gst-launch-1.0 v4l2src device=/dev/video2 ! autovideosink   Note: To test the hdmi feature, the display should also use the HDMI TX. And in Uboot, to load the hdmirx firmware, we can run the followed commands first, then run the "boot" command:     run loadhdprx     hdprx load 0x9c800000     setenv fdt_file imx8qm-mek-hdmi-rx.dtb  

Here are some debug methods for kernel performance requirements or related issues. It includes all the common methods such as oops/panic issues, memory issues, and so on. Please check it in the attachments for details. OS and System analysis Oops/Panic case addr2line objdump gdb Pstore Kdump Memory debugging SLAB KASAN Kmemleak Performance Perf Ftrace eBPF/bcc