Board : i.MX93 EVK BSP: imx L6.1.1-1.0.0 Gui guider: 1.6.1   We have a GUI software tool called GUI Guider. It is a user-friendly graphical user interface development tool from NXP that enables the rapid development of high quality displays with the open-source LVGL graphics library. The GUI demo can run on the i.MX93EVK board. (https://www.nxp.com/design/software/development-software/gui-guider:GUI-GUIDER)   This document will show you an example how the buttons(gpio) on the EVK to interacting with the GUI. Basically, customer could use the same method to use the gpio pins to control everything.   On the i.MX93 EVK board, there are two buttons BTN1 and BTN2. They are connected to GPIO IO23 and GPIO IO24. Below is the schematic.    Buttons on the board.      SW1005 on the board   In the EVK's device tree file, need to change the pinmux for the two buttons like this: pinctrl_spdif: spdifgrp { fsl,pins = < // MX93_PAD_GPIO_IO22__SPDIF_IN 0x31e // MX93_PAD_GPIO_IO23__SPDIF_OUT 0x31e MX93_PAD_GPIO_IO23__GPIO2_IO23 0x31e MX93_PAD_GPIO_IO24__GPIO2_IO24 0x31e >; note: all the pins are defined in imx93-pinfunc.h.   For getting the input value of the buttons in user's space, I use the sysfs gpio. Build the imx-image-multimedia image first and then select the GPIO_SYSFS in kernel's menuconfig.   $ DISTRO=fsl-imx-xwayland MACHINE=imx93evk source imx-setup-release.sh -b build-xwayland $ bitbake imx-image-multimedia   After the build completed, go to the kernel's menuconfig to select the GPIO sysfs. $ bitbake linux-imx -c menuconfig [*] General setup-> Configure standard kernel features (expert users) [*] Device Drivers->GPIO Support-> /sys/class/gpio/... (sysfs interface)   Build the whole image again by "$ bitbake imx-image-multimedia".   Using the UUU to program the image to the EMMC on the EVK board. uuu -b emmc_all imx-image-multimedia-imx93evk.rootfs.wic.zst   Connect the LVDS to the board. Use the corresponding dtb to boot the board. In u-boot, set the dtb file. => setenv fdtfile imx93-11x11-evk-boe-wxga-lvds-panel.dtb => saveenv   Then restart the board. After the board boot up, it will look like below.     You need to calibrate the LVDS touch screen before it can normally use. Please use this command: $ weston-touch-calibrator LVDS-1     Now, build the GUI guider example. I use the Air Conditioner example. Download the GUI guider from the gui-guider web page: https://www.nxp.com/design/software/development-software/gui-guider:GUI-GUIDER   Follow the steps from the below web page to build the i.MX BSP and the gui example code. https://docs.nxp.com/bundle/GUIGUIDERUG-1.6.1/page/topics/yocto.html   After the gui-guider build completed, use the 'scp' command to transfer the gui_guider executable file to the board. Execute the command on your host PC like this: $ scp bld-imx93evk/tmp/work/armv8a-poky-linux/gui-guider/1.6.0-r0/image/usr/bin/gui_guider root@<Your Board IP address>:/ Note: You could use a router to connect your board and your host PC. They are on the same network so could use the 'scp' command to transfer the file to your board.   On your board, type the following commands to execute the gui. $ chmod 755 gui_guider $ ./gui_guider &   Then the GUI is running like this:   Now, let me explain how to find out the gpio number. Type the following command to show the mapping addresses of gpio. root@imx93evk:/# cat /sys/kernel/debug/gpio gpiochip3: GPIOs 0-31, parent: platform/47400080.gpio, 47400080.gpio: gpiochip0: GPIOs 32-63, parent: platform/43810080.gpio, 43810080.gpio: gpiochip1: GPIOs 64-95, parent: platform/43820080.gpio, 43820080.gpio: gpio-64 ( |cd ) in hi IRQ ACTIVE LOW gpio-71 ( |regulator-usdhc2 ) out lo gpiochip2: GPIOs 96-127, parent: platform/43830080.gpio, 43830080.gpio: gpiochip6: GPIOs 472-477, parent: i2c/0-001a, wm8962, can sleep: gpiochip5: GPIOs 478-487, parent: platform/adp5585-gpio.1.auto, adp5585-gpio, can sleep: gpio-479 ( |regulator-audio-pwr ) out hi gpio-483 ( |regulator-can2-stby ) out hi ACTIVE LOW gpio-486 ( |enable ) out hi gpiochip4: GPIOs 488-511, parent: i2c/1-0022, 1-0022, can sleep: gpio-492 ( |Headphone detection ) in lo IRQ gpio-501 ( |? ) out hi gpio-502 ( |regulator-vdd-12v ) out hi gpio-505 ( |reset ) out lo gpio-507 ( |? ) out hi gpio-508 ( |reset ) out lo ACTIVE LOW   The gpio pins of two buttons are GPIO2_IO23 and GPIO2_IO24. They are belongs to gpio2. In the imx93.dtsi, the gpio2's address is "gpio2: gpio@43810080". So, base on the information output from "/sys/kernel/debug/gpio", the gpio2 is mapping to "gpiochip0: GPIOs 32-63". So, the GPIO2_IO23 is 32+23=55, and the GPIO2_IO24 is 32+24=56.   To verify the gpio number is correct or not. We could do the following test. root@imx93evk:/# echo 55 > /sys/class/gpio/export root@imx93evk:/# echo in > /sys/class/gpio/gpio55/direction root@imx93evk:/# echo 56 > /sys/class/gpio/export root@imx93evk:/# echo in > /sys/class/gpio/gpio56/direction   Then, run these two commands to check the values. root@imx93evk:/# cat /sys/class/gpio/gpio55/value root@imx93evk:/# cat /sys/class/gpio/gpio55/value   When the button is not pressed, the value is 1. When press the button, the value is 0.  We could add the same in the GUI's custom.c. Open the GUI Guider software and add the code in the custom.c. /********************* * INCLUDES *********************/ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <fcntl.h> #include "lvgl.h" #include "custom.h" #include "ui_Aircon.h" #include "guider_customer_fonts.h" /********************** * STATIC VARIABLES **********************/ int fdbtn1,fdbtn2,fdgpio; int btn1_pressed; int btn2_pressed; char btn1_value, btn2_value; void custom_func(void) { fdbtn1 = open("/sys/class/gpio/gpio55/value", O_RDWR); fdbtn2 = open("/sys/class/gpio/gpio56/value", O_RDWR); read(fdbtn1, &btn1_value, 1); read(fdbtn2, &btn2_value, 1); if(btn1_value=='0' && btn1_pressed) { btn1_pressed=0; ui_aircon_update_temp(0, kAIRCON_TempUp); } if(btn1_value=='1') btn1_pressed=1; if(btn2_value=='0' && btn2_pressed) { btn2_pressed=0; ui_aircon_update_temp(0, kAIRCON_TempDown); } if(btn2_value=='1') btn2_pressed=1; close(fdbtn1); close(fdbtn2); } void custom_init(lv_ui *ui) { fdbtn1 = open("/sys/class/gpio/gpio55/value", O_WRONLY); if (fdbtn1 == -1) { fdgpio = open("/sys/class/gpio/export", O_WRONLY); write(fdgpio,"55",3); write(fdgpio,"56",3); close(fdgpio); fdgpio = open("/sys/class/gpio/gpio55/direction", O_WRONLY); write(fdgpio,"in",3); close(fdgpio); fdgpio = open("/sys/class/gpio/gpio56/direction", O_WRONLY); write(fdgpio,"in",3); close(fdgpio); } else close(fdbtn1); ... ... ... ...   Add the custom_func() in the custom.h. #ifndef __CUSTOM_H_ #define __CUSTOM_H_ #ifdef __cplusplus extern "C" { #endif #include "gui_guider.h" void custom_init(lv_ui *ui); + void custom_func(void);   Also, need to add the custom function() into the dead loop in main.c.   To modify the code, bld-imx93evk$ vim tmp/work/armv8a-poky-linux/gui-guider/1.6.0-r0/gui-guider-1.6.0/ports/linux/main.c   while(1) { + custom_func(); // <--- Add the custom function here. /* Periodically call the lv_task handler. * It could be done in a timer interrupt or an OS task too.*/ time_till_next = lv_wayland_timer_handler(); #if LV_USE_VIDEO video_play(&guider_ui); #endif /* Run until the last window closes */ if (!lv_wayland_window_is_open(NULL)) { break; }   Re-build the code after modified. bld-imx93evk$ bitbake gui-guider -c compile -f   Build the whole image again. bld-imx93evk$ bitbake gui-guider Then use the 'scp' command to transfer the new gui-guider file to the board.   Finally, you can use the buttons on the EVK board to set the temperature up and down.                          

How to use UART4 on iMX8M from Linux User Space   The UART4 on iMX8MM-EVK and iMX8MN-EVK are thinking of debugging the M core which is not usable on Linux user space by default on pre-compiled images.   To use the UART4 on Linux user space you have to do the next modifications on the device tree and atf to assign that peripheral to Linux User Space     https://github.com/nxp-imx/imx-atf/blob/lf_v2.6/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c     iMX8MN-EVK   imx8mn_bl31_setup.c   https://github.com/nxp-imx/imx-atf/blob/lf_v2.6/plat/imx/imx8m/imx8mn/imx8mn_bl31_setup.c   /* Master domain assignment */ RDC_MDAn(RDC_MDA_M7, DID1), /* peripherals domain permission */ - RDC_PDAPn(RDC_PDAP_UART4, D1R | D1W), + RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART2, D0R | D0W), RDC_PDAPn(RDC_PDAP_RDC, D0R | D0W | D1R),       Device tree configurations for iMX8MN-EVK   iMX8MN-EVK.dtsi   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi   &uart3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart3>; assigned-clocks = <&clk IMX8MN_CLK_UART3>; assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_80M>; uart-has-rtscts; status = "okay"; }; + &uart4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart4>; + assigned-clocks = <&clk IMX8MN_CLK_UART4>; + assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_80M>; + status = "okay"; + }; ********************** pinctrl_uart3: uart3grp { fsl,pins = < MX8MN_IOMUXC_ECSPI1_SCLK_UART3_DCE_RX 0x140 MX8MN_IOMUXC_ECSPI1_MOSI_UART3_DCE_TX 0x140 MX8MN_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x140 MX8MN_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x140 >; }; + pinctrl_uart4: uart4grp { + fsl,pins = < + MX8MN_IOMUXC_UART4_RXD_UART4_DCE_RX 0x140 + MX8MN_IOMUXC_UART4_TXD_UART4_DCE_TX 0x140 + >; + };   iMX8MM-EVK   https://github.com/nxp-imx/imx-atf/blob/lf_v2.6/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c   imx8mm_bl31_setup.c   /* Master domain assignment */ RDC_MDAn(RDC_MDA_M7, DID1), /* peripherals domain permission */ - RDC_PDAPn(RDC_PDAP_UART4, D1R | D1W), + RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART2, D0R | D0W), RDC_PDAPn(RDC_PDAP_RDC, D0R | D0W | D1R),   Device tree configurations for iMX8MM-EVK   iMX8MM-EVK.dtsi   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi   &uart3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart3>; assigned-clocks = <&clk IMX8MM_CLK_UART3>; assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>; uart-has-rtscts; status = "okay"; }; + &uart4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart4>; + assigned-clocks = <&clk IMX8MM_CLK_UART4>; + assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>; + status = "okay"; + }; ********************** pinctrl_uart3: uart3grp { fsl,pins = < MX8MM_IOMUXC_ECSPI1_SCLK_UART3_DCE_RX 0x140 MX8MM_IOMUXC_ECSPI1_MOSI_UART3_DCE_TX 0x140 MX8MM_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x140 MX8MM_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x140 >; }; + pinctrl_uart4: uart4grp { + fsl,pins = < + MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX 0x140 + MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX 0x140 + >; + };   iMX8MP-EVK   https://github.com/nxp-imx/imx-atf/blob/lf_v2.6/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c   imx8mp_bl31_setup.c   RDC_MDAn(RDC_MDA_M7, DID1), RDC_MDAn(RDC_MDA_LCDIF, DID2), RDC_MDAn(RDC_MDA_LCDIF2, DID2), RDC_MDAn(RDC_MDA_HDMI_TX, DID2), /* peripherals domain permission */ + RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART2, D0R | D0W), RDC_PDAPn(RDC_PDAP_WDOG1, D0R | D0W), RDC_PDAPn(RDC_PDAP_RDC, D0R | D0W | D1R),   Device tree configurations for iMX8MP-EVK   iMX8MP-EVK.dts   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mp-evk.dts   &uart3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart3>; assigned-clocks = <&clk IMX8MP_CLK_UART3>; assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>; fsl,uart-has-rtscts; status = "okay"; }; + &uart4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart4>; + assigned-clocks = <&clk IMX8MP_CLK_UART4>; + assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>; + status = "okay"; + }; ************************************ pinctrl_uart3: uart3grp { fsl,pins = < MX8MP_IOMUXC_ECSPI1_SCLK__UART3_DCE_RX 0x140 MX8MP_IOMUXC_ECSPI1_MOSI__UART3_DCE_TX 0x140 MX8MP_IOMUXC_ECSPI1_SS0__UART3_DCE_RTS 0x140 MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS 0x140 >; }; + pinctrl_uart4: uart4grp { + fsl,pins = < + MX8MP_IOMUXC_UART4_RXD__UART4_DCE_RX 0x140 + MX8MP_IOMUXC_UART4_TXD__UART4_DCE_TX 0x140 + >; + };     After compiling the image with the changes previously shown, we obtained this result:      

BSP: L6.1.36 Some customer need use adb under usb ffs. The adb in Yocto can greatly improves development efficiency. This is a demo for enabling adb on Yocto.   Yocto local.conf IMAGE_INSTALL:append = "android-tools android-tools-adbd" PREFERRED_PROVIDER_android-tools-conf = "android-tools-conf-configfs"   Test script for launching adbd modprobe g_ffs idVendor=0x1fc9 idProduct=0x0146 iSerialNumber="ZhimingLiu" mkdir -p /dev/usb-ffs/adb mount -t functionfs adb /dev/usb-ffs/adb -o uid=2000,gid=2000 adbd &   Test on Windows: PS C:\Users\Administrator\Desktop\platform-tools> .\adb.exe devices List of devices attached ZhimingLiu device PS C:\Users\Administrator\Desktop\platform-tools> .\adb.exe shell sh-5.2# uname -a Linux imx8mp-lpddr4-evk 6.1.36+g04b05c5527e9 #1 SMP PREEMPT Fri Nov 24 04:46:22 UTC 2023 aarch64 GNU/Linux sh-5.2# ls config ffs t.sh test2.sh sh-5.2# cd / sh-5.2# ls bin dev home lost+found mnt proc run srv tmp usr boot etc lib media opt root sbin sys unit_tests var sh-5.2#

Platform: Demo images, i.MX8MPlus EVK   Some customer need test ffs gadget function on i.MX8MPlus EVK. Here is demo for ffs test, please connect EVK and Ubuntu PC before test.   Test script: #!/bin/sh # Setup the device (configfs) modprobe libcomposite mkdir -p config mount none config -t configfs cd config/usb_gadget/ mkdir g1 cd g1 echo 0x1fc9 >idVendor echo 0x0146 >idProduct mkdir strings/0x409 echo 12345 >strings/0x409/serialnumber echo "Signal 11" >strings/0x409/manufacturer echo "Test" >strings/0x409/product mkdir configs/c.1 mkdir configs/c.1/strings/0x409 echo "Config1" >configs/c.1/strings/0x409/configuration # Setup functionfs mkdir functions/ffs.usb0 ln -s functions/ffs.usb0 configs/c.1 cd ../../../ mkdir -p ffs mount usb0 ffs -t functionfs cd ffs ffs-test 64 & # from the Linux kernel, with mods! sleep 3 cd .. # Enable the USB device echo 38100000.usb > config/usb_gadget/g1/UDC   EVK log root@imx8mpevk:~# ./test2.sh [ 17.859597] file system registered ffs-test: dbg: ep0: writing descriptors (in v2 format) ffs-test: dbg: ep0: writing strings ffs-test: dbg: ep1: starting ffs-test: dbg: ep2: starting ffs-test: dbg: ep1: starts ffs-test: dbg: ep0: starts ffs-test: dbg: ep2: starts Event BIND Event ENABLE Ubuntu PC log: lzm@lzm-GL552VW:~$ lsusb -D /dev/bus/usb/001/008 Device: ID 1fc9:0146 NXP Semiconductors Test Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1fc9 NXP Semiconductors idProduct 0x0146 bcdDevice 6.01 iManufacturer 1 Signal 11 iProduct 2 Test iSerial 3 12345 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0020 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 Config1 bmAttributes 0x80 (Bus Powered) MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 5 Source/Sink Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x0016 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x0000010e BESL Link Power Management (LPM) Supported BESL value 256 us SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000f Device can operate at Low Speed (1Mbps) Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 0 micro seconds bU2DevExitLat 0 micro seconds Device Status: 0x0001 Self Powered  

Traditional non-matter devices cannot directly join the matter network. But Matter Bridge solves the problem. Matter bridge can join a Matter network as a Matter device and nonmatter devices need to be mapped to Matter network as a dynamic endpoint. In this way, other Matter devices can communicate with non-matter devices through dynamic endpoints. The Guide is a Matter Zigbee Bridge implement based on i.MX93 + K32W0.     Feature List • Matter over Ethernet • Matter over Wi-Fi • Register and Remove Zigbee Deivces • Connect Zigbee devices into Matter ecosystem seamlessly • Zigbee Devices o OnOff cluster o Temperature Sensor Cluster • Matter Actions o Start Zigbee Network o Zigbee Network Permit Join o Factory Reset • No limitation if migrating to other i.MX MPU like i.MX6ULL, i.MX8MP • OTBR and Zigbee bridge can be integrated into one single device

Usually, device tree source files are not a signal pure dts file. It could include dtsi, dts or C code heads .h files. Need C compiler finish the pre-compile to a pure dts file first. It is integrated inside the like Linux build system(Makefile, etc.). This document shows the original way to compile device tree. This document will show compile device tree under windows.    

    In i.MX93 EVK, it use RGMII in ethernet connection. Some customer use RMII connection. This article describe RMII HW design and SW config.

i.MX93 DDR stress test tool is different with previous i.MX tool. This Chinese article describe how to debug i.MX93 DDR and introduce DDR config tool usage.

test ov5640 with 480p, raw10 via ISP on imx8mp

  Platform & BSP :i.MX8MPlus, L6.1.36   The attachments enable the i.MX8MPlus pci function in uboot. lspci in Linux root@imx8mpevk:~# lspci -nn 00:00.0 PCI bridge [0604]: Synopsys, Inc. DWC_usb3 / PCIe bridge [16c3:abcd] (rev 01) 01:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. Device [1b4b:2b42] (rev 11) pci test results in uboot:  u-boot=> pci BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x16c3 0xabcd Bridge device 0x04 u-boot=> pci bar 00.00.00 ID Base Size Width Type ---------------------------------------------------------- 0 0x0000000018000000 0x0000000000100000 32 MEM u-boot=> pci regions 00 Buses 00-01 # Bus start Phys start Size Flags 0 0x0000000000000000 0x000000001ff80000 0x0000000000010000 io 1 0x0000000018000000 0x0000000018000000 0x0000000007f00000 mem 2 0x0000000040000000 0x0000000040000000 0x0000000016000000 mem sysmem 3 0x0000000058000000 0x0000000058000000 0x00000000a8000000 mem sysmem 4 0x0000000100000000 0x0000000100000000 0x00000000c0000000 mem sysmem u-boot=> pci header 00.00.00 vendor ID = 0x16c3 device ID = 0xabcd command register ID = 0x0007 status register = 0x0010 revision ID = 0x01 class code = 0x06 (Bridge device) sub class code = 0x04 programming interface = 0x00 cache line = 0x08 latency time = 0x00 header type = 0x01 BIST = 0x00 base address 0 = 0x18000000 base address 1 = 0x00000000 primary bus number = 0x00 secondary bus number = 0x01 subordinate bus number = 0x01 secondary latency timer = 0x00 IO base = 0x10 IO limit = 0x00 secondary status = 0x0000 memory base = 0x1820 memory limit = 0x1810 prefetch memory base = 0xfff0 prefetch memory limit = 0x0000 prefetch memory base upper = 0x00000000 prefetch memory limit upper = 0x00000000 IO base upper 16 bits = 0x0000 IO limit upper 16 bits = 0x0000 expansion ROM base address = 0x18100000 interrupt line = 0xff interrupt pin = 0x01 bridge control = 0x0000

The configuration of DDR is very important. NXP provides a tool for configuring DDR for users of i.MX series products. Here are the details steps for it. Hope can do help for someone. 1\ The DDR part startup and initialization sequence of MX8MM:   The MX 8M series DDR tools include： DDR Register Programming Aid --->Configurate custom DDR initialization MSCALE DDR Tool（DDR Stress Test Tool） --->Test DDR initialization And DDR interface ---> Generate custom DDR initialization code for the u-boot SPL DDR RPA（RPA） is an Excel spreadsheet tool used to develop DDR initialization for specific DDR configurations (DDR device type, density, etc.) of users. RPA generates DDR initialization (in a separate Excel worksheet tab). Detailed explanations and introductions will be provided here. DDR stress testing tool is a software tool based Windows that initializes PHY and generates DDRC configuration Uboot source code to verify whether DDR initialization can be used for u-boot and OS startup. DDR stress testing script, this format is specifically used for DDR stress detection. First, copy the content from this worksheet tab, and then paste it into a text file, naming the document with the ". ds" file extension. Select this file when performing DDR stress testing. 2\i.MX8M series DDR tool work flow           Above is the DDR Tool flow for the i.MX8MM: DDR RPA Tool: Configure DDR parameters to generate DDR Stress Test script ". ds". DDR Sress Test Tool: Test DDR initialization and DDR interface, generate DDR initialization code for the u-boot SPL DDR driver. For the newest DDR RPA version as below：   https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MMini-m845S-DDR-Register-Programming-Aid-RPA/ta-p/1172443 In the above link, you can download the corresponding DDR configuration tools for i.MX8MM using different DDRs.   3\How to use this script to configure DDR parameters (1)Obtain the required DRAM data sheet from the DRAM supplier firstly. The DDR parameter configuration content will be completed in the "Register Configuration" worksheet tab.   (2)"Register Configuration"，Update the device information table to include DRAM information and system usage. DDR RPA tool:  Register Configuration---->Device Information table   It should be filled out based on the datasheet and relevant hardware circuit design of the selected DDR chip. Specific users can refer to the manual for selecting DDR chips and their own hardware design. Take the i.MX 8M Mini LPDDR4 EVK board as example, it selects the Micron MT53D512M32D2DS-053 WT:D, we can go the Micron website to download the DDR’s datasheet and we can see bellow:   Density per channel (Gb)= Device density (Per Channel Per CS)=8Gb Number of ROW Addresses=R[15:0]=16 Number of Channels=2 (2 Channels i.MX8MM DDR is 32bit) Number of COLUMN Addresses=C[9:0]=10 Total DRAM density(Gb) Automatic calculation：Density per channel (Gb) * Number of Channels * Number of Chip Selects used  =8Gb * 2 * 1=16Gb=2GB Bus Width=M32=32bit: i.MX8MM DDR support 32bit Cycle Freq (MHz)=1500MHZ: The DDR controller clock of the i.MX8MM is set to 1500MHZ. The information filled in is shown in the table below:   (3)Browse through various shaded cells in the spreadsheet to update using data from the DRAM table (pay special attention to the "Legend" table to determine the meaning of different shaded cells; in many cases, these cells may not need to be updated). On the parameter filling page, we can also see the following table, with different colors indicating the need to modify and maintain the original parameters and the affected parameter information. On the register configuration tab, basically only the orange part of the color represents the bit segments that usually need to be updated, and the rest do not need to be modified or configured.   (4)Go to the BoardDataBusConfig tab, fill in the i.MX8MM data bus mapping to the memory device correctly. DDR RPA tool: BoardDataBusConfig ---->Configurate data bus bit   Users should pay special attention to ensuring that this worksheet is configured correctly, otherwise the LPDDR4 system may not function properly. The memory controller of i.MX8MM allows for BYTE internal swapping. For layout convenience, BYTE internal swapping is usually performed, so the BoardDataBusConfig column needs to be configured according to the actual schematic design. We can see the tab in the BoardDataBusConfig, user fill the i.MX8MM data bit connection to associated LPDDR4, the filling in of data bits here should be consistent with the order of our hardware design wiring, which means that if there are swapped data bits, the corresponding relationship must be filled in. Take the LPDDR4 connection to the i.MX8MM as example, the highest 8 bits on the channel B of the LPDDR4   connect to the side of DRAM_DQ00~DRAM_DQ07 of CPU, and the lowest 8 bits on the channel B of the LPDDR4 DRAM_DQ08~DRAM_DQ15 of CPU side，the lowest 8 bits on the channel A of the LPDDR4 connect to the DRAM_DQ16~DRAM_DQ23 of CPU side，the highest 8 bits on the channel A of the LPDDR4 connect to the DRAM_DQ24~DRAM_DQ31 of the CPU side. The i.MX8MM memory controller allows for BYTE internal swapping. For layout convenience, BYTE internal swapping is usually performed, and this needs to be filled in according to the actual wiring in the data bus.       (5)Generate the “.ds” file DDR RPA tool: DDR stress test file ----> “.ds”   Copy the content of the DDR stress test file into a text file and name it a. ds file. For subsequent DDR stress testing purposes.   4\Do the DDR Stress test and Generate the DDR Code The following is the workflow of the DDR tool for the MX8MM series:   Preparation Board: i.MX 8M Mini LPDDR4 EVK Software download: mscale_ddr_tool_v3.31_setup.exe(Install it) PC:Window10 PC file .ds file Hardware requirements for the board: (Please note that these interfaces are necessary when using our stress testing tools) Serial download mode USB OTG port Debug UART port 4.1 Hardware connection   SW1101set 1010xxxxxx go to Serial Download mode, connect the USB-OTG and UART to PC, USB OTG is used for serial download of binary files: UART is used to communicate with users. Note: It is recommended to connect the USB OTG directly to the host PC, rather than through the USB Hub. When power on the board，we can see HID-compliant vendor-defined device and USB Input Device:   UART port are COM3 and COM4:   4.2 Open MSCALEDDR_Tool. exe in administrator mode for DDR parameter calibration and pressure testing：   Select serial port Select Search in Debug UART and you can read that the other two serial ports COM3 and COM4 have been tried. Click on the Connect button. It should be noted that we have two serial ports, one for the A core and the other for the M core. Here, COM4 must be selected to load the script normally. COM4 is used for the A core. Select Target Select the MX8M-mini，speed of CPU chosse1200MHZ, DDR LPDDR4 size 2GB. Select .ds file, Load DDR Script: Copy the generate mx8mm_micron_lpddr4_2gb_2d_1500m_200m_50m_32bit_1cs_RPAv22.ds to the path of the DDR TOOL, then press the Download button. After the download is successful, there will be a print message indicating the successful download and the startup information of the board. We can see the CPU parameters and DDR configuration.   Pres Calibration: This step mainly involves executing the DDR initialization and calibration process. If there is a failure, it is necessary to analyze the DDR problem based on the printed information. If there is no problem, the following interface will appear.   (5) If there are no problems after calibration, perform a pressure test. Only perform this operation when the calibration is passed. Run the test on all frequency set points. If the DDR pressure test passes, you can see that the test has passed successfully. If there is an error, you should search for the problem with the DDR based on the error message.   (6) Generate u-boot timing After the stress test is successfully completed, clicking the Gen Code button will generate a file lpddr4_timing. c, and then the lpddr4_timing. C file can be copied to the u boot directory.     5\ Modifying and configuring DDR frequencies that are not supported by default         The above test is for the frequency point 1500MHZ that is supported by default in our tool. RPA provides default DRAM PLL settings (DRAM frequency) based on the default settings supported in u-boot. If the customer is not using the default supported frequency, in addition to updating the new frequency in RPA, the new DRAM PLL settings should also be manually updated in the u boot SPL. (1) Firstly, in the RPA script, "Clock Cycle Freq (MHz)" is set to the frequency we need (2) Then search for 'memory set 0x30360054' in the RPA DDR stress test file worksheet tab, with a default setting of 1500MHZ.   We can see the DRAM PLL register and bit settings：   For special frequencies, we have a calculation formula here: DDR_freq = [(24MHz x pll_main_div)/(pll_pre_div x 2^pll_post_div)] x 2 1500 = [(24 x 250) / (8 x 2^1)] x 2 Bellow are some special examples of the required configurations for various frequencies:     Finishing configuration, create a. ds test DDR script in the RPA script to specify the frequency of this configuration. （3）After creating a DDR script for the DDR stress testing tool, run the calibration and perform the DDR pressure test. Generating the lpddr4_timing.c, modify the required DDR rate parameters Manually. （4）Modify the DRAM PLL，DRAM_freq = DRAM_PLL x 2 in SPL，u-boot SPL DDR driver can will not automatically change DRAM PLL based on generated code. Therefore, users will need to manually modify the dram_pll_init  for the required DDR PLL parameter.

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

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

Note: This guide is specifically for use with VS Code. For standalone with Segger software please refer to this guide. (How to Use Segger J-Link Plus with i.MX 8M Process... - NXP Community) In this guide we will describe the process to start using VS Code to debug an SDK application. The board used for this guide specifically is the i.MX 8M Nano EVK, but it also applies to all processors of the i.MX 8M Family. This guide covers the following topics: Hardware requirements Software requirements How to find, build, and download the i.MX SDK Debug Probe and i.MX 8M Nano EVK connection Create an SDK Application with MCUXpresso for VS Code Run and debug your SDK Application with MCUXpresso for VS Code Hardware requirements Evaluation Kit for the i.MX8M Nano Applications Processor (i.MX 8M Nano Evaluation Kit | NXP Semiconductors) Quick Start Guide for i.MX8M Nano (I.MX 8M Nano EVK Quick Start Guide (nxp.com)) J-Link Plus JTAG/SWD debug probe with USB interface (SEGGER J-Link PLUS) Features Download speed up to 1MB/s Unlimited breakpoints in flash memory Supports direct download into RAM and flash memory Supported NXP Devices Supported Devices - Search results "nxp" (segger.com) 9 Pin Cortex-M Adapter (9-Pin Cortex-M Adapter (segger.com)) Description Adapts from the 20-pin 0.1'' JTAG connector to a 9-pin 0.05'' Samtec FTSH connector as defined by Arm. Software requirements Windows 10 OS (host) J-Link Software and Documentation Pack for Windows (https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/) i.MX 8M Nano SDK (Welcome | MCUXpresso SDK Builder (nxp.com)) VS Code for Windows (Installation Guide: Running Visual Studio Code on Windows) MCUXpresso Extension for VS Code (Installation Guide: Training: Walkthrough of MCUXpresso for VS Code - NXP Community)   How to find, build, and download the i.MX 8M Nano SDK Enter Welcome | MCUXpresso SDK Builder (nxp.com) Click on "Select Development Board"  Select EVK-MIMX8MN (MIMX8MN6xxxJZ) from Boards -> i.MX -> EVK-MIMX8MN Click on the Build MCUXpresso SDK button Click on Download SDK, you'll be redirected to the MCUXpresso SDK Dashboard Look for the i.MX 8M Nano SDK and click on Download SDK Click on Download SDK archive and documentation, accept the Software Terms and Conditions and the .zip file for the SDK will be downloaded. Debug Probe and i.MX 8M Nano EVK connection Connect the debug cable (USB-UART) to the board and the other end to your PC. Connect the power cable to the second USB-C port and to a wall socket. Don't turn on the board yet. Connect the JLink Plus to your PC with the USB cable. Connect the JLink Plus to the JTAG of the i.MX 8M Nano EVK board In this part we will need to identify pin number 1 from the 9 Pin Cortex-M adapter and from the i.MX 8M Nano EVK board. For the first one identifies pin 7 identifiable by a "non-connect pin". For the i.MX 8M Nano, you can identify easily with a number 1 in one corner of the connectors.    The whole setup should look similar to this: Create an SDK Application with MCUXpresso for VS Code Before delving into the details of creating an SDK Application it is important to recognize the sections of VS Code User Interface. This will help us to describe accurately the buttons' position. Click on MCUXpresso for VS Code extension icon from the Activity Bar.  In the section “Quickstart Panel” located in the Side Bar click on “Import Repository.” On this window, go to “Local” and select your previously downloaded SDK folder location. Then, click on “Import.” Expand the section “Installed Repositories” from Side Bar and verify your selected SDK. Expand the section “Projects” from Side Bar and click on “Import Example from Repository” and complete the options: Choose a toolchain Choose a board Choose a template Name Location Finally, click on the "Create" button. Click on the gear icon located in the project folder to build the code. In “Projects” expand the “Settings” options and select “mcuxpresso-tools.json.” Here you will find a JSON file with different parameters. Defines the device that will be used to connect with the J-Link Plus. Code: “segger”: { “device”: “MIMX8MN6_M7” } Expand the section “Debug Probes” and verify that your J-Link Plus debug probe appears. Start SEGGER J-Link GDB Server. On section “Target Device” select MIMX8MN6_M7 and click “OK”. You will see the following window. Run and debug your SDK Application with MCUXpresso for VS Code Click on “Debug” located in the project folder, to start with the debugging session. In the Panel click on “Serial Monitor,” set it to the serial debug port with the lowest numbered port with the following settings: Baud rate: 115200 Line ending: None Click on "Start Monitoring" Use the debug controls to run the code. Verify your code output in the “Serial Monitor.”

On behalf of Gopise Yuan. This is an update for the DRM framebuffer capture tool I used to share with the team. Some enhancement added. Might be useful for debugging some display related issues.   Some special notes: Behavior of DRM subsystem is different between L4.x and L5.x. For L4.x, you can capture the RGB buffer without any problem. But, there’s no API for YUV (multi-plane) buffer. To capture YUV, need to apply “kernel_0001-drm-Add-getfb2-ioctl_L4.14.98.patch”. For L5.x, mapping/capturing the internal buffer is not allowed by default due to security reason. A simple change in “0001-drm-enable-mapping-of-internal-object-for-debugging_L5.x.patch” can disable this guard. Capture raw data only. RGB and YUV (packed/planar, 420/422) supported. Support de-tile on “Amphion tile” (VPU, NV12 only) and “Super tile” (Vivante GPU). Please use “-t” to enable this. Other tile might not be supported. This is a static linked binary. You can run it on any ARM64 based Linux/Android system in theory (prerequisites in item #1). If you need source code, come to me.   To get more details on how to use it, use “-?” option: DRM screen capture DRM based screen capture program Usage:     ./drmfbcap [OP] [ARG] [OP] OPeration (optional):     -v Show version.     -? Show help information.     -i Show information about target DRM device only (no capture).     -t Perform de-tile for tile format.     -d DRM device to open. [ARG] should contain the path to the device node. Default: '/dev/dri/card0'     -o Output folder. [ARG] should contain the path to the output folder. Default: '.'     -p Specific plane # to capture. [ARG] should contain the plane number. If no '-p' specified, capture all planes   Example:     ./drmfbcap   Capture all planes on default DRM device.     ./drmfbcap -d /dev/dri/controlD64   Capture all planes on '/dev/dri/controlD64' device.     ./drmfbcap -p 44 -t -o /sdcard   Capture plane 44, do de-tile after capture and then output to /sdcard/.   Raw buffer capture will be done for each enabled/target plane and one file for each. Captured file will be saved to './' if not specified. --- By Gopise, 2022/08   Updated_2023_10_16: continuous capture (repeat mode) support with this link: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/DRM-screen-capture-tool/ta-p/1725363

Device: i.MX93 A1. ELE FW version: 0.0.10 Some new test scripts are added to secure enclave library, please refer to attached files. Please note: the scripts attached are for internal test/debug purpose only. The summary is from our test results and understanding, it's preliminary and may have changes later.    1. All current and all GA Sentinel FWs do not use lifecycle for key derivation of HSM keystore. Keystore created in OEM_OPEN lifecycle can be directly used in OEM_CLOSED lifecycle.  A-> Different from previous SECO devices 2. Key has lifecycle attribute. This attribute defines in which device lifecycle the key is usable. This attribute is set at key creation operation (generate key, import key, key exchange …). Before executing a key depending cryptographic or data storage (export option) operation the key lifecycle is compared with the current device lifecycle. Operation is executed only if the key lifecycle includes the current device lifecycle. When mentioned in the API command message description, the key lifecycle could be set to the current device lifecycle if the value is set to 0x0. Lifecycle values are encoded as bitfield. Multiple values could be set. The key could be used in several lifecycles.   Tested cases:   The key lifecycle attribute is verified during the key usage, not when the key is created. If the key operation doesn’t match device lifecycle, it will report 0xe29 - The key is not usable in the current lifecycle.  Please see attached hsm_generate_key.c / hsm_generate_key_signature.c  for reference.   3. SYNC operation and MC increase are separate flag. The previous STRICT operation is used to store persistent key, during which the monotonic counter will increase if the device is closed. For ELE device, two flags are used: SYNC flag and MC flag. The ELE SYNC pushes persistent key(s) in the NVM. Without executing this operation, even if the key attribute is set as persistent at the key creation the key will not be stored in the NVM. This operation is set through a flag in key management operations arguments. SYNC is applicable only for persistent key/permanent key. MC flag is new on ELE device. When used in conjunction with SYNC, the request is completed only when the monotonic counter has been updated. MC flag can be used both in OPEN and CLOSED lifecycle and increase the monotonic counter value. -> different from previous SECO device. Note: MC flag is not defined in 0.0.10 secure enclave library, but user can test it by directly setting the corresponding bit of the flag.   4. If the generated key store is deleted accidently and the monotonic counter is not 0, reprovisioning function is needed.  This is applied to both OPEN and CLOSED device. We cannot directly create a keystore again. Reprovisioning method is not supported yet.   5. One keystore can store 100 key groups at most. 100 groups are available per key store. It must be a value in the range [0; 99]. The key group ID should be 0~99, or it will report 0x429- MU sanity check failed / Invalid parameters. To push persistent keys in the NVM, a flag (SYNC) needs to be set during key management operations (generate, import, manage, …). Pushing a key to the NVM will also push all the key group data. When in use, a key group is loaded from the NVM to the internal secure RAM. The number of key group present is limited (depends on the device). A key group present in internal memory and not used, can be swapped out and replaced by a new key group containing the key to be used when there is no more free space. Note that only key 2 groups per key store can be stored in the internal secure RAM. Note that volatile keys cannot be in the same key group than persistent keys.   One assumption based on tests: It looks that each key group has its own SW counter, which may record update time of this key group. This is the test on i.MX93: If we delete the key group #2 file 0000abcd00020004 only from NVM manually, then we cannot create key of group #2 again, but we can create key of group #1. The process might be: Try to create key in group #2 -> checked the counter value is not 0 -> try to import the chunk from NVM -> fail because the chunk is deleted. Each key group has its own counter, so key group #1 is not affected.   6. Key size in one keystore One key group can store 16 ECC(p256) keys, or 1 RSA 2k key, or 1 RSA 4k key. Size of key group on i.MX93 = 8448 bits (size defined to allow 4k modulus+ 4k private exponent + header). Storage file in NVM will have additional overhead, the 8448 size is purely related to key data storage. For ECC keys, only private keys are stored (public key can be derived from private key), so P256 key only needs 256 bits of key storage + 256 bits header = 512 bits. 16 * 512 = 8192 => fits within 8448.    7. Delete key To delete the key from the NVM, an SYNC operation (in “Flags” field) must be done. To delete a key, user need to provide the key identifier which is generated when creating this key. There is also “MC” flag which should can be used for anti-rollback protection. Deleting key will not decrease the size of key group file directly, but the space in the key group will be covered by new key generated later.  Please see attached hsm_delete_key.c for reference.   8. Generic API Generic API is not supported on i.MX93 A0 due to a lack of RAM, it is supported on i.MX93 A1. In lf-6.1.22_2.0.0 ELE library, the generic feature is set as none supported, need to change the src/plat/ele/sab_msg.def file as below to test it on i.MX93 A1 chip. -MT_SAB_GC_AKEY_GEN := ${NOT_SUPPORTED} -MT_SAB_GC_ACRYPTO := ${NOT_SUPPORTED} +MT_SAB_GC_AKEY_GEN := ${FMW} +MT_SAB_GC_ACRYPTO := ${FMW} Generic cryptographic APIs can be used to perform cryptographic operation without using the FW key store. The key buffer, in plaintext, is an input parameter of the API. No need to open hsm keystore before using generic APIs. Because it will not save the key to key store, so NVM thread is also not necessary. Please see attached hsm_generic_api.c for reference. Asymmetric key generate: Only RSA is supported on S401 for now. It will return the address of output RSA key modulus /output RSA private exponent /input RSA public exponent Asymmetric crypto User can choose different operation mode for Encryption / Decryption / Signature generation / Signature verification.    9. How to get chip MC value? Command “Get device information” can be used to get generic information regarding the user, the chip and the EdgeLock Enclave FW. It can return Chip UUID/lifecycle/monotonic counter etc. User can run this API before and after some MC operation to check if the counter value is increased. Please see the attached hsm_get_info.c for reference.   Best Regards, Tia

1. MediaPlayer Architecture     MediaPlayer is the server, MediaPlayerService and MediaPlayerService :: Client is the client. MediaPlayerService realize the IMediaPlayerService, the main function is to create the right player through the url sent by MediaPlayer::setDataSource MediaPlayerService :: Client realize the IMediaPlayer, the main function is to call the player created by MediaPlayerService to do those specific start, stop, resume, pause…      Entering NuplayerDriver means entering Android MultiMedia Framework.   2. NuPlayer   The playback video is mainly completed through Nuplayer. The figure below includes parser, decoder and render.   NuPlayer::Source is the parser module. Its interface looks like a combination of MediaExtractor and MediaSource NuPlayer::Decoder connects to CCodec for decoding. CCodec has a state pattern and pass MediaBuffers around with messages. NuPlayer::Render is responsible for rendering audio and also controls when to post video buffers back to NativeWindow for A/V sync. 3. Decoding Framework 3.1 Framework of i.MX8MP, i.MX8MQ and i.MX8MM   Decoding Process between the framework, vendor decoder component and kernel as follows on i.MX8MP, i.MX8MQ and i.MX8MM.   3.2 Framework of i.MX8QM   Decoding Process between the framework, vendor decoder component and kernel as follows on i.MX8QM. stream on: start to decode/encode stream off: stop decoding/encoding qbuf:  Queue the v4l2buffer filled in the decoder into the buffer queue created in the vpu driver so that the VPU can obtain it for decoding. dqbuf: When the VPU decoding is completed, the buffer will be dequeueed so that the decoder/codec can continue to be used. 4. Decode Video and Display Process 4.1 i.MX8MM and i.MX8MP   For i.MX8MP and i.MX8MM, G2D is used to composite layers, and the buffer transmission is completed between Decoder and SurfaceFlinger through the BufferQueue mechanism. The process as follows:  BufferQueue: As the producer of BufferQueue, decoder provides the decoded buffer, and SurfaceFlinger, as the consumer of BufferQueue, composite the decoded video layer.  Display: Use G2D to composite Android layer and video layer on i.MX8MP. SurfaceFlinger will hand over all layers to Display HAL, and then composite them into the framebuffer by G2D. 4.2 i.MX8MQ   For i.MX8MQ, GPU3D is used to composite Android UI, DCSS is used to composite overlay and android UI. And the buffer transmission is completed between Decoder and SurfaceFlinger through the BufferQueue mechanism. The processing is as follows: BufferQueue: Decoder provides the decoded buffer as producer. SurfaceFlinger as the cosumer of BufferQueue.  Display: Using GPU3D to composite Android UI layers. And video layer will be submitted to DCSS (Display Controller) through Display HAL. DCSS:  Responsible for combining video overlay and Android UI for display. GLESRenderEngine: SurfaceFlinger calls the opengl interface through GLESRenderEngine to complete rendering composite. 4.3 i.MX8QM For i.MX8QM, GPU3D or DPU are used to composite. And the buffer transmission is completed between Decoder Filter Component and SurfaceFlinger through the BufferQueue mechanism. The processing as follows: Decoder Filter:  Because GPU3D cannot directly composite TILED type layers, it needs to be converted into Linear through Decoder Filter first, and then handed over to SurfaceFlinger. BufferQueue:  Decoder Fillter will receive the outputbuffer from Decoder. And Filter will be as producer of BufferQueue to provide the buffer. SurfaceFlinger will be as consumer of BufferQueue to consume the buffers. GLESRenderEngine: SurfaceFlinger calls the opengl interface through GLESRenderEngine to complete rendering composite. Note:  On i.MX8QM,  Not all situations are composited using the GPU3D. Please refer to the table below.   4.4 DRM Widevine (Secure Decoder)   Now we have enabled DRM Widevine on i.MX8MP/i.MX8MQ/i.MX8QM so that secure video can be played.  For i.MX8MP, Use OEMCrypto trusted applicaiton to decrypt the encrypted stream. And Use RDC/CSU to protected hardware for secure pipeline. The framework is as follows:   For i.MX8MQ, Use OEMCrypto trusted applicaiton to decrypt the encrypted stream. And Use RDC/CSU to protected hardware for secure pipeline. The framework is as follows:     OEMCrypto: It is a library as tipc client to send the encrypted data to Trusty OS. OEMCrypto Trusted Application: Used to decrypt the protected data into secure memory and send it to Media Framewrok. Secure Framebuffer: It is allocated from secure heap through libdmabufheap. Secure heap: Used to allocate secure memory.  Resources in domain2 can read and write secure memory, but cannot write normal memory. Resources in domain0 can write to secure memory, but cannot read normal memory. When playing secure video, VPU, GPU2D, and lcdif will be in domain2. Or they are in domain0. Resource Domain Controller (RDC): It provides support for the isolation of destination memory mapped locations such as peripherals and memory to a single core, a bus master, or set of cores and bus masters.  CSU Central Security Unit (CSU) : 1. Peripheral Access Policy - the appropriate bus master privilege and identity are required to access each peripheral. 2. Masters Privilege Policy - the CSU overrides the bus master privilege signals (secure/non-secure).  Configure the VPU so that it can only be accessed by the secure world. For i.MX8QM, also use OEMCrypto trusted applicaiton to decrypt the encrypted stream. But related hardware and memory are protected through the secure partition created by SCU. The framework is as follows: OEMCrypto: It is a library as tipc client to send the encrypted data to Trusty OS. OEMCrypto Trusted Application: Used to decrypt the protected data into secure memory and send it to Media Framewrok. Secure Framebuffer: It is allocated from secure heap through libdmabufheap. Secure heap: Used to allocate secure memory.  Only Secure partition can access secure memory. Frimware Loader: It is a trusted application in Trusty OS, It is responsible for loading the encrypted firmware into the specified memory. Secure Partition: Secure partitions are created using SCU and all hardware that needs to be protected are moved to secure partitions to isolate it from non-secure partitions. 5. Encoding Process 5.1 Encoding Process on i.MX8MP BufferQueue:  MediaFramework will create Surface and create BufferQueue, SurfaceFlinger will serve as the producer to provide the composite layers, and the Encoder component will encode it as the consumer of the BufferQueue. MPEG4Writer:  Responsible for writing the VPU-encoded data to the output file. 5.2 Encoding Process on i.MX8QM and i.MX8MM   BufferQueue:  MediaFramework will create Surface and create BufferQueue, SurfaceFlinger will serve as the producer to provide the composite layer, and the Encoder Filter component will be as the consumer of the BufferQueue. MPEG4Writer:  Responsible for writing the VPU-encoded data to the output file. 6. Buffer transfer and management 6.1 Transfer and release process of Input Buffer Input Buffer allocation: It is allocated in CCodecBufferChannel, and it is used to allocate inputbuffer and recycled. InputManager: Before the queue buffer into the decoder, it will be registered with the InputManager. When the VPU is finished using it, the InputManager will be notified to release it. Use of InputBuffer:  After the buffer is queued into the decoder, the input buffer information will be copied to v4l2buffer so that the VPU can use it. Note: For DRM Secure decoder, the VPU will only use the paddr of inputbuffer. 6.2 Transfer and release process of Output Buffer     Output Buffer allocation:  When use Surface for output, It is allocated through BufferQueueAllocator that is created in CCodecBufferChannel. It is used to allocate outputBuffer.  Management: When use Surface, OutputBuffer is managed through the BufferQueue mechanism. When the VPU filled the outputBuffer with data that can be displayed, it will notify the Consumer to acquire the buffer. Use of OutputBuffer: In the decoder, the output buffer information will be copied to v4l2buffer so that the VPU can use it. Note:  For situations where OutputSurface is not used, GrallocAllocator is used by default instead of BufferQueueAllocator. 6.3 Buffer Management of Encoder   For screen recording situations, the Encoder's buffer transfer is also managed through the BufferQueue mechanism. After SurfaceFlinger is producer to fill the GraphicBuffer of BufferQueue, the encoder is as consumer to encode the composited data.  

The default BSP is compiled based on the Yocto project, which is a streamlined production-level Linux BSP. However, for users who are accustomed to the Ubuntu environment, especially ROS users, the operation of Yocto will be relatively complicated. This article will introduce how to make an Ubuntu BSP for iMX8QM and demonstrate how to use ROS.   A complete Ubuntu BSP includes u-boot, Linux kernel and Ubuntu rootfs. We will use u-boot and Linux kernel in Yocto BSP official 6.1V BSP, and rootfs will still use ubuntu-base-18.04.4-base-arm64. The compilation method comes from the NXP forum. First download ubuntu-base-18.04.4-base-arm64.tar.gz from the link above, and then unzip it. $ mkdir ~/ubuntu-rootfs $ sudo tar vxf ubuntu-base-18.04.4-base-arm64.tar.gz -C ubuntu-rootfs Copy the script file and create ch-mount.sh. $ sudo chmod a+x ./ch-mount.sh The download above is a basic Ubuntu-base file system, which is missing many commonly used tools and requires us to install it. For this purpose, install the qemu-user-static software on your computer to simulate the arm64 operating environment. $ sudo apt install qemu-user-static Mount the Ubuntu-base file system and then operate directly in the arm64 environment. $ sudo ./ch-mount.sh -m ubuntu-rootfs/ Add a DNS server, such as 8.8.8.8, or other available DNS server IP. # echo nameserver 8.8.8.8 > /etc/resolv.conf Install relevant software, of course you can also add other software. # apt install language-pack-en-base sudo ssh net-tools \ network-manager iputils-ping rsyslog \ bash-completion htop resolvconf dialog \ vim nano v4l-utils alsa-utils git gcc \ less resolvconf autoconf autopoint libtool \ bison flex gtk-doc-tools glib-2.0 \ libglib2.0-dev libpango1.0-dev libatk1.0-dev kmod pciutils -y  Create a user and set a password, here the user name is ubuntu # useradd -s '/bin/bash' -m -G adm,sudo ubuntu # passwd ubuntu # passwd root # echo 'apalis-imx8' > /etc/hostname At this point basic Ubuntu has been configured. # exit $ sudo ./ch-mount.sh -u ubuntu-rootfs/  After the installation is complete, use the ubuntu user to log in to the debugging serial port, and the password is ubuntu. When starting for the first time after installation, it will wait for a long time due to initialization, and then enter the configuration interface including region, user settings, etc. Turn on Ethernet and set DNS server IP.  ubuntu@mx8QM:~$ sudo ifconfig eth0 up ubuntu@mx8QM:~$ sudo dhclient eth0 ubuntu@mx8QM:~$ sudo vi /etc/resolv.conf Start Weston: ubuntu@mx8QM:~$ export XDG_RUNTIME_DIR=/run/user/1000 ubuntu@mx8QM:~$ sudo -E weston --tty=1 & ubuntu@mx8QM:~$ weston-flower ROS test You can install ROS programs very conveniently in Ubuntu system. Please refer to the instructions below for details http://wiki.ros.org/melodic/Installation/Ubuntu http://wiki.ros.org/ROS/Tutorials ubuntu@mx8QM:~$ sudo apt install lsb-core ubuntu@mx8QM:~$ sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' ubuntu@mx8QM:~$ sudo apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654 ubuntu@mx8QM:~$ sudo apt update ubuntu@mx8QM:~$ sudo apt install ros-melodic-desktop  Run the following commands on three SSH terminals to simulate communication between ROS nodes. ubuntu@mx8QM:~$ source /opt/ros/melodic/setup.sh ubuntu@mx8QM:~$ roscore ubuntu@mx8QM:~$ source /opt/ros/melodic/setup.sh ubuntu@mx8QM:~$ rosrun roscpp_tutorials talker ubuntu@mx8QM:~$ source /opt/ros/melodic/setup.sh ubuntu@mx8QM:~$ rosrun roscpp_tutorials listener Due to driver limitations, iMX8 does not support Xorg, so ROS's default graphical interface tools such as rqt cannot be used directly.        

this article write down the steps when help customer bring dual camera under single mipi csi with NXP switch NX3DV642, just for a reference, connect OV5640 + os08a20 with mipi csi0 via ISP, as default, mipi csi0 just has one port with one camera, this document improve how to enable os08a20 with second port under mipi csi0, refer to the document and patch as attachment, for how to enable ov5640 with ISP, pls refer to my another document

What is a device tree? The device tree is a data structure that is passed to the Linux kernel to describe the physical devices in a system. Before device trees came into use, the bootloader (for example, U-Boot) had to tell the kernel what machine type it was booting. Moreover, it had to pass other information such as memory size and location, kernel command line, etc. Sometimes, the device tree is confused with the Linux Kernel configuration, but the device tree specifies what devices are available and how they are accessed, not whether the hardware is used. The device tree is a structure composed of nodes and properties: Nodes: The node name is a label used to identify the node. Properties: A node may contain multiple properties arranged with a name and a value. Phandle: Property in one node that contains a pointer to another node. Aliases: The aliases node is an index of other nodes. A device tree is defined in a human-readable device tree syntax text file such as .dts or .dtsi. The machine has one or several .dts files that correspond to different hardware configurations. With these .dts files we can compile them into a device tree binary (.dtb) blobs that can either be attached to the kernel binary (for legacy compatibility) or, as is more commonly done, passed to the kernel by a bootloader like U-Boot. What is Devshell? The Devshell is a terminal shell that runs in the same context as the BitBake task engine. It is possible to run Devshell directly or it may spawn automatically. The advantage of this tool is that is automatically included when you configure and build a platform project so, you can start using it by installing the packages and following the setup of i.MX Yocto Project User's Guide on section 3 “Host Setup”. Steps: Now, let’s see how to compile your device tree files of i.MX devices using Devshell. On host machine. Modify or make your device tree on the next path: - 64 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm64/boot/dts/freescale - 32 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm/boot/dts To compile, it is needed to prepare the environment as is mentioned on i.MX Yocto Project User's Guide on section 5.1 “Build Configurations”. $ cd ~/imx-yocto-bsp $ DISTRO=fsl-imx-xwayland MACHINE=<machine> source imx-setup-release.sh -b <build directory> $ bitbake -c devshell virtual/kernel (it will open a new window) On Devshell window. $ make dtbs (after finished, close the Devshell window) On host machine. $ bitbake -c compile -f virtual/kernel $ bitbake -c deploy -f virtual/kernel This process will compile all the device tree files linked to the machine declared on setup environment and your device tree files will be deployed on the next path: ~/imx-yocto-bsp/<build directory>/tmp/deploy/images/<machine> I hope this article will be helpful. Best regards. Jorge.