This is simple known-how for how to implement "boot animation" with DRM under i.MX8/X + Linux:   Code to refer to: ========================================================================= 1. kmscube: Either open source one or the customized on for i.MX will be OK: https://cgit.freedesktop.org/mesa/kmscube/ https://source.codeaurora.org/external/imx/kmscube-imx/ 2. Android display HAL: KmsDisplay.cpp   Known-how: ========================================================================= 1. Only one application can grab the master role of the DRM device. If need to control DRM from two applicaiton simultanously, possible solution:     A, Use "controlD" node instead of "card" node in /dev/dri/. This requires L4.14 or before. This device node was removed by two commits in L4.14.x:           8a357d10043c75e980e7fcdb60d2b913491564af           6449b088dd51dd5aa6b38455888bbf538d21f2fc     Can be brought back by reverting these two commits in L4.14.98.     B, Use framebuffer emulator to emulate a FB device (/dev/fb0). (not recommended due to lack of vsync). 2. Some kernel functions will re-config the DRM device during boot. This will cause display abnormal after user application has configured the DRM device. Better to disable these kernel features:       CONFIG_DRM_FBDEV_EMULATION       CONFIG_FRAMEBUFFER_CONSOLE 3. Use atomic mode of KMS API instead of legacy mode for any dynamically screen drawing application, such as video, game and etc. Atomic mode will have much better performance compare to legacy mode. The kmscube has sample code for both mode. 4. Better to do commit checking before doing any real commit, especially when doing display during boot. Sometimes some internal component in DRM is not fully ready after card device is present.       DRM_MODE_ATOMIC_ALLOW_MODESET 5. If video playback will be used, some points to remind:     a, Sample code for direct video decoding (in unit-test): imx-test/test/mxc_v4l2_vpu_test/     b, VPU in i.MX8/X only support tiled NV12 output and it has pixel alignment requirement (128). Need to use CPU or G2D to do un-tile, CSC and cropping. Sample code: <android>/vendor/nxp/fsl_imx_omx/OpenMAXIL/src/component/v4l2_common/G2dProcess.cpp If using G2D under Linux, it will support un-tile directly (through OpenCL internally).

 This article instruct customer how to develop on i.MX8MP NPU and how to debug performance. 

This article is to show how to use CLK2 for PCIe ref clock for i.MX8MQ. Test Environment  i.MX8MQ + BSP L5.10.52 Background In order to cost down, some customers used CLK2 as PCIe reference clock as below while no external OSC installed, which is different with i.MX8MQ EVK design, so no clock output for PCIe.  Checked L4.14.98_2.3.0 and found it added internal PLL for PCIe clock support. Solution The attached patch based on 4.14.98 can’t be used directly on 5.10.52, the following is the main modification for PLLOUT of PCIe clock. PLLOUT Monitor Configuration Register contains bits to control the clock that will be generated on the CCM clock mapped to CLK2_P/N.        

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   

     The following steps allow you to toggle a pin on i.MX 8M Mini EVK, you can use the EVK as not gate, trigger a wake up signal, etc. With an script and modifying the device tree you can read an input and get as output the invert input.   On the Host.   Cloning the Linux kernel repository.   Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/linux-imx cd linux-imx/   Patching the device tree.   Open the imx8mm-evk.dtsi file: vim arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi For the purpose of this example, uart3 has to be "disabled" in order to avoid pins conflict, so change "okay" to "disabled": &uart3 {        pinctrl-names = "default";        pinctrl-0 = <&pinctrl_uart3>;        assigned-clocks = <&clk IMX8MM_CLK_UART3>;        assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;        fsl,uart-has-rtscts;        status = "disabled"; }; Add the following lines in the iomuxc node: &iomuxc {       pinctrl-names = "default";       pinctrl-0 = <&pinctrl_hog>; ​       pinctrl_hog: hoggrp {               fsl,pins = <                       MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9               0x19                       MX8MM_IOMUXC_ECSPI1_MISO_GPIO5_IO8              0x19               >;       };   Build the device tree.   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.dtb Copy the .dtb file to the EVK, for example with scp: scp imx8mm-evk.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.   On the EVK Board.   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.dtb Partition_1/ Reboot the board. reboot   Create an script.   Use vi: vi toggle.sh Add the following lines: #!/bin/bash ​ echo 136 > /sys/class/gpio/export echo in > /sys/class/gpio/gpio136/direction ​ echo 137 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio137/direction echo 0 > /sys/class/gpio/gpio137/value ​ while : do ​ if [[($(cat /sys/class/gpio/gpio136/value) == "0")]]; then         echo 1 > /sys/class/gpio/gpio137/value else         echo 0 > /sys/class/gpio/gpio137/value        fi ​ done Save the file: :wq Change file permissions: chmod +x toggle.sh   Toggling a pin.   In this example we are using the pin "UART3_CTS" like an input and "UART3_RTS" like an output. To toggle the pin, run the script: ./toggle.sh

     The following steps allow you to add a pad Wakeup on i.MX 8QuadMax MEK CPU Board. On the Host.   Cloning the Linux kernel repository.   Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/linux-imx cd linux-imx/ Patching the device tree.   Open the imx8qm-mek.dts file: vim arch/arm64/boot/dts/freescale/imx8qm-mek.dts Add the following lines: &lsio_gpio2{       pad-wakeup-num = <1>;       pad-wakeup = <81 4 1>; }; In the line pad-wakeup-num = <1>; , the number "1" corresponds to the number of pads that you want to add. The line pad-wakeup = <81 4 1>; has three parameters: The first parameter corresponds to the "pin_id", you can find it in include/dt-bindings/pinctrl/pads-imx8qm.h , in this example we are using "IMX8QM_MIPI_CSI1_I2C0_SDA". The second parameter corresponds to the "'type'", you can find it in the i.MX 8QuadMax Applications Processor Reference Manual, in the page 802:   For this example we are using "LOW". The third parameter corresponds to the "line", the number of bit in 32bit gpio group, you can find it in include/dt-bindings/pinctrl/pads-imx8qm.h In this example, "IMX8QM_MIPI_CSI1_I2C0_SDA" belongs to gpio group 2, line 1. Build the device tree.   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/imx8qm-mek.dtb Copy the .dtb file to the MEK CPU Board, for example with scp: scp imx8qm-mek.dtb root@<MEK_CPU_Board_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. On the MEK CPU Board.   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 imx8qm-mek.dtb Partition_1/ Reboot the board. reboot How to wake up the i.MX 8QuadMax MEK CPU Board.   In this example a wire was soldered on "R204":     Run the following command on the MEK CPU Board: echo mem > /sys/power/state And you will see something like: [   53.769266] PM: suspend entry (deep) [   53.902130] Filesystems sync: 0.129 seconds [   53.908068] Freezing user space processes ... (elapsed 0.002 seconds) done. [   53.917189] OOM killer disabled. [   53.920420] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [   53.929626] printk: Suspending console(s) (use no_console_suspend to debug) Connect the wire that was soldered on "R204" to ground, the MEK CPU Board will wake up and you will see something like: [   54.687125] fec 5b040000.ethernet eth0: Link is Down [   54.689876] PM: suspend devices took 0.756 seconds [   54.709570] Disabling non-boot CPUs ... [   54.710562] CPU1: shutdown [   54.711582] psci: CPU1 killed (polled 0 ms) [   54.714360] CPU2: shutdown [   54.715376] psci: CPU2 killed (polled 0 ms) [   54.717365] CPU3: shutdown [   54.718382] psci: CPU3 killed (polled 0 ms) [   54.719887] CPU4: shutdown [   54.720884] psci: CPU4 killed (polled 4 ms) [   54.722213] CPU5: shutdown [   54.723229] psci: CPU5 killed (polled 0 ms) [   54.724731] Enabling non-boot CPUs ... [   54.725388] Detected VIPT I-cache on CPU1 [   54.725423] GICv3: CPU1: found redistributor 1 region 0:0x0000000051b20000 [   54.725486] CPU1: Booted secondary processor 0x0000000001 [0x410fd034] [   54.726455] CPU1 is up [   54.726930] Detected VIPT I-cache on CPU2 [   54.726947] GICv3: CPU2: found redistributor 2 region 0:0x0000000051b40000 [   54.726976] CPU2: Booted secondary processor 0x0000000002 [0x410fd034] [   54.727478] CPU2 is up [   54.727955] Detected VIPT I-cache on CPU3 [   54.727971] GICv3: CPU3: found redistributor 3 region 0:0x0000000051b60000 [   54.728001] CPU3: Booted secondary processor 0x0000000003 [0x410fd034] [   54.728497] CPU3 is up [   54.729806] Detected PIPT I-cache on CPU4 [   54.729825] GICv3: CPU4: found redistributor 100 region 0:0x0000000051b80000 [   54.729857] CPU4: Booted secondary processor 0x0000000100 [0x410fd082] [   54.730490] CPU4 is up [   54.730985] Detected PIPT I-cache on CPU5 [   54.730999] GICv3: CPU5: found redistributor 101 region 0:0x0000000051ba0000 [   54.731021] CPU5: Booted secondary processor 0x0000000101 [0x410fd082] [   54.731679] CPU5 is up [   54.756440] hdmi_rx_hd_core_clk: failed to set clock parent -16 [   54.765828] gpio-mxc 5d0a0000.gpio: wakeup by pad, line 1 [   54.844242] ahci-imx 5f020000.sata: external osc is used. [   54.913582] caam 31400000.crypto: registering rng-caam [   54.918358] PM: resume devices took 0.148 seconds [   55.096663] OOM killer enabled. [   55.099814] Restarting tasks ... done. [   55.111833] PM: suspend exit  

     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.

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

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

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

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.

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.

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

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);  

adv7180 is the 8 bits parallel CSI interface TVin to iMX8QXP validation board. Its weaving mode de-interlace can be supported on both iMX8QXP B0 and C0 chips, but blending mode de-interlace can only work on iMX8QXP C0 chips.   ISL79987 is the 4 virtual channel TVin chip which can input 4 CVBS cameras to iMX8QXP with MIPI CSI2 inteface, it can only work with iMX8QXP C0 chips. The iMX8QXP B0 chips have MIPI CSI2 virtual channel errata.   To test the capture to file: $ /unit_tests/V4L2/mx8_v4l2_cap_drm.out -cam 1 -num 300 -fmt YUYV -of   To test the preview on screen: $ killall weston $ /unit_tests/V4L2/mx8_v4l2_cap_drm.out -cam 1 -fmt RGBP -num 30000   Note: 1. For weaving mode de-interlace, when the ISI is doing de-interlace, it can't do CSC at the same time, so preview will get color issue, because the real output video is always YUYV format. 2. For blending mode de-interlace, it must use ISI0, so for ISL79987, only one camera can use blending mode, the other three cameras are still using weaving mode. The preview color is OK for such use case. 3. The patch is for L4.19.35 BSP.     2019-11-14 update: Add the test application "mx8_v4l2_cap_drm.tar.gz" to support YUYV render to display. Test command to render 4 weaving mode cameras:    ./mx8_v4l2_cap_drm.out -cam 0xF -fmt YUYV -num 30000     2020-04-29 update: Add "0006-isl7998x-fix-the-mipi_bps-overwrite-issue-from-set_f.patch", it fixed the issue that MIPI bps information in isl7998x_data->format.reserved[0] had been overwritten by isl7998x_set_fmt().   2021-06-11 update: Added the patches based on L5.4.70_2.3.0 GA BSP.

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.    

The A53 Debug Console Changing consists in several major updates like: RDC settings, Pinmux, Clocks and Ecosystem Updates.