i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
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.
View full article
Customer is asking high-capacity external storage(for example >64GB) support on i.MX BSP, ext4 is ok for HC storage, but it can’t be supported by Windows. Pls find NFTS and exFAT support status on Linux BSP below: Updated test result on L5.4.70.2.3.0 and L6.1.22: L5.4.70.2.3.0 1.You can enable ntfs support in kernel config as below,  ntfs can be mounted normally, but you can only modify existing file content in disk, you can’t create/delete/rename file on disk. > File systems > DOS/FAT/NT Filesystems   Log: root@imx8mpevk:~# mount -t ntfs /dev/sda1 /mnt/fat/ [  662.732869] ntfs: volume version 3.1. root@imx8mpevk:~# cp ntfs-3g /mnt/fat/ cp: cannot create regular file '/mnt/fat/ntfs-3g': Permission denied root@imx8mpevk:~# ls /mnt/fat/ 111.png  Image_org  System Volume Information  gpuinfo.sh root@imx8mpevk:~# vi /mnt/fat/gpuinfo.sh root@imx8mpevk:~# umount /mnt/fat/ root@imx8mpevk:~# ntfs file system can be accessed via ntfs-3g in user space as below //build: wget https://tuxera.com/opensource/ntfs-3g_ntfsprogs-2017.3.23.tgz tar zxvf ntfs-3g_ntfsprogs-2017.3.23.tgz cd ntfs-3g_ntfsprogs-2017.3.23/ source ../../sdk/environment-setup-aarch64-poky-linux   ./configure --host=aarch64-linux --build=aarch64-poky-linux --disable-shared --enable-static   make   ls /src/ntfs-3g   //put it into rootfs cp ntfs-3g /bin   //test log: root@imx8mpevk:/# [ 1058.724471] usb 1-1: USB disconnect, device number 4 [ 1062.058613] usb 1-1: new high-speed USB device number 5 using xhci-hcd [ 1062.214029] usb-storage 1-1:1.0: USB Mass Storage device detected [ 1062.220986] scsi host0: usb-storage 1-1:1.0 [ 1063.235871] scsi 0:0:0:0: Direct-Access     VendorCo ProductCode      2.00 PQ: 0 ANSI: 4 [ 1063.246185] sd 0:0:0:0: [sda] 15728640 512-byte logical blocks: (8.05 GB/7.50 GiB) [ 1063.254023] sd 0:0:0:0: [sda] Write Protect is off [ 1063.259164] sd 0:0:0:0: [sda] No Caching mode page found [ 1063.264540] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 1063.296946]  sda: sda1 [ 1063.300860] sd 0:0:0:0: [sda] Attached SCSI removable disk   root@imx8mpevk:/# ntfs-3g /dev/sda1 /mnt/fat/ root@imx8mpevk:/# ls /mnt/fat/ README  System Volume Information  gpu.sh  gpuinfo.sh root@imx8mpevk:/# cp /unit_tests/memtool /mnt/fat/ root@imx8mpevk:/# umount /mnt/fat/ root@imx8mpevk:/# ntfs-3g /dev/sda1 /mnt/fat/ root@imx8mpevk:/# ls /mnt/fat/ README  System Volume Information  gpu.sh  gpuinfo.sh  memtool root@imx8mpevk:/#   3.exFAT is not supported on this BSP..   L6.1.22(you can check it on L5.15 and above, should be the same) You can enable ntfs support in kernel config as below, full features can be supported. > File systems > DOS/FAT/EXFAT/NT Filesystems   Pls use ‘-t ntfs3’ during mounting, otherwise it will be mounted as ‘read-only’ Log: root@imx8ulpevk:~# mount -t ntfs3 /dev/sda1 /mnt/fat/ root@imx8ulpevk:~# ls /mnt/fat/ 111.png   Image_org  'System Volume Information' root@imx8ulpevk:~# root@imx8ulpevk:~# cp gpuinfo.sh /mnt/fat/ root@imx8ulpevk:~# umount /mnt/fat/ root@imx8ulpevk:~# root@imx8ulpevk:~# mount -t ntfs3 /dev/sda1 /mnt/fat/ root@imx8ulpevk:~# ls /mnt/fat/ 111.png   Image_org  'System Volume Information'   gpuinfo.sh root@imx8ulpevk:~#   exFAT has been supported in L6.1.22. > File systems > DOS/FAT/EXFAT/NT Filesystems   /dev/sda1 on /run/media/sda1 type exfat (rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro) root@imx8ulpevk:~# ls /run/media/sda1 'Certificate of Completion.pdf'             carlife.MP4 Image_org                                  example.tflite L5.4.70_2.3.0                              mx8mp_vpu.txt NXP-5G.mp4                                 sd.mp4 'System Volume Information'                 vela.ini android_p9.0.0_2.1.0-auto-ga_image_8qmek root@imx8ulpevk:~# ls Image_org  gpuinfo.sh root@imx8ulpevk:~# cp gpuinfo.sh /run/media/sda1/ root@imx8ulpevk:~# umount /run/media/sda1 root@imx8ulpevk:~#
View full article
Hello everyone! In this quick example its focused on how to customize uboot code to generate an uboot image with a silent console so its speed up the flash and boot time, this may provide helpful for customers who have a bigger images or just want to have a silent console. Note: this should not be enabled if the image is still being under test, since this will disable all communication with the debug terminal and there won't be boot messages. Requirements: I.MX 8M Nano DDR4 EVK i.MX 8M Nano EVK Prebuilt image (6.1.1-1.0.0) UUU tool First clone the code from the uboot repository: $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.1.1-1.0.0 $ cd uboot-imx After we get the code, then proceed to enable the silent console in the uboot defconfig: $ nano configs/imx8mn_ddr4_evk_defconfig CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y For this to actually work we need to create the silent environmental variable and give it a value different from "0": $ nano include/configs/imx8mn_evk.h "silent=1\0"      \ As specified in our Linux porting guide: Generate an SDK from the Yocto Project build environment with the following command. To set up the Yocto Project build environment, follow the steps in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG). In the following command, set Target-Machine to the machine you are building for. See Section "Build configurations" in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG) Set up the host terminal window toolchain environment: $ source/opt/fsl-imx-xwayland/6.1.1/environment-setup-aarch64-poky-linux $ export ARCH=arm64 Build uboot binary: $ make distclean $ make imx8mn_ddr4_evk_defconfig $ make Build ARM Trusted Firmware (ATF) $ cd .. $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.1.1-1.0.0 $ cd imx-atf/ $ make PLAT=imx8mn bl31 In case you get the error aarch64-poky-linux-ld.bfd: unrecognized option '-Wl,-O1' $ unset LDFLAGS Download the DDR training & HDMI binaries $ cd .. $ mkdir firmware-imx $ cd firmware-imx $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.19.bin $ chmod a+x firmware-imx-8.19.bin $ ./firmware-imx-8.19.bin Accept EULA and the firmware will be deployed. Download imx-mkimage and build the boot image $ cd .. $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.1.1-1.0.0 $ cd imx-mkimage $ cp ../uboot-imx/spl/u-boot-spl.bin iMX8M/ $ cp ../uboot-imx/u-boot-nodtb.bin iMX8M/ $ cp ../uboot-imx/arch/arm/dts/imx8mn-ddr4-evk.dtb iMX8M/ $ cp ../imx-atf/build/imx8mn/release/bl31.bin iMX8M/ $ cp ../firmware-imx/firmware-imx-8.19/firmware/ddr/synopsys/ddr4_* iMX8M/ $ cp ../uboot-imx/tools/mkimage iMX8M/mkimage_uboot $ make SOC=iMX8MN flash_ddr4_evk After this we can download our uboot image to our board, we can either use the uboot image for boot or for flashing purpose only. We can compare the time it takes using UUU with a standard pre-built image uuu -V -b emmc_all imx-boot-imx8mn-ddr4-evk-sd.bin-flash_ddr4_evk imx-image-full-imx8mnevk.wic It takes 485.5 seconds using normal uboot with debug console enabled. uuu -V -b emmc_all flash.bin imx-image-full-imx8mnevk.wic It takes 477.5 seconds using silent uboot console. Even if the speed is not greatly improved (~8 seconds), in larger files it could help to speed up flashing, even if wants to have the console silent is a good option. Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.
View full article
  Introduction   Prior to 6.1.22_2.0.0 BSP release, Bluetooth interface are based on the tty line discipline framework, so we need to use hciattach tool to enable it in the user space. From 6.1.22_2.0.0 BSP, the nxp bluetooth driver no longer needs the help of the userspace hciattach tool, and the tty port bound by bluetooth also won't be exported to the user space, so you cannot find the corresponding tty device anymore. So, you won't see the (/dev/ttymxcX), for the Bluetooth interface. All jobs has been done in the new NXP Bluetooth driver. New Method   The new NXP Bluetooth UART Driver is based on a server driver for the NXP BT serial protocol, which can enable the built-in Bluetooth device inside an NXP BT chip. This driver has a Power Save feature that will put the chip into a sleep state whenever there is no activity for 2000ms and will be woken up when any activity is to be initiated over UART.  Device Tree support The new BT framework requires adding a "bluetooth" sub node with a device compatibility string to the attached UART node in the dts file &uart1 { bluetooth { compatibility = "nxp,88w8987-bt"; fw-init-baudrate = <3000000>; #Optional. Default is considered 115200 if this parameter not defined. }; };   Note: The parameter ‘compatibility = “nxp,88w8987-bt”’ will use for 88W8987, IW416, 88Q9098, IW612 chipsets and need to change for 88W8997 with parameter ‘compatibility = “nxp,88w8997-bt”’.   Note: ’fw-init-baudrate’ parameter depends on the module vendor. The Murata and Azuere wifi modules support in BSP release uses the default value -- 115200. We strongly recommend looking at the module vendor-specific baud rate parameter. Note: For the old 88Q9098 Murata 1XL module that uses the 3Mbps by default, please add the fw-init-baudrate = <3000000> property in dts files to make it work. Enable Guide   Use wifi interface to load combo (wifi & bt) firmware and enable BT Need to load wifi driver first, then load the BT driver, otherwise, BT driver suspend/resume test will fail. This is a HW limitation, since NXP wifi and BT module use the same power control pin(W_DISABLE1#), if we don't load the wifi driver, SDIO bus will power down the wifi chip during suspend resume, which may cause the BT chip also been powered down and cannot work after resume back. So we need to load the wifi driver to make sure SDIO bus won't power down the BT chip to make sure BT functions can work during suspend resume. modprobe moal mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart or insmod mlan.ko insmod moal.ko mod_para=nxp/wifi_mod_para.conf insmod btnxpuart   Unload UART Driver modprobe moal Make sure run hciconfig hci0 up or hciconfig hci0 reset or bluetootctl power on before unload btnxpuart driver. If we don't open hci0 interface, the driver cannot send change to 115200 baud rate command to BT chip, which causes the host and BT chip baud rate mismatch, the host still uses 115200bps talk to the BT chip which now use 3Mbps, it cannot work anymore. So we need to make sure open the hci0 interface before unload btnxpuart driver.   mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart sleep 3 hciconfig hci0 up #Note: Need to up hci interface before unload the BT module hcitool -i hci0 cmd 3F 23 02 00 00 modprobe -r btnxpuart modprobe -r moal sleep 3​ For better reference: Please find the I.MX 8MQ Linux getting started user guide, UM11483, Chapter "7.1 Bring-up using NXP Bluetooth UART driver"  Bluetooth Deep Sleep Feature App Note AN13920, Chapter 6 Load NXP UART driver module NOTE: Please do not run the power save feature for Murata IW612 2EL Module Regards, Mario
View full article
In some cases, such as mass production or preparing a demo. We need u-boot environment stored in demo sdcard mirror image.  Here is a way: HW:  i.MX8MP evk SW:  LF_v5.15.52-2.1.0_images_IMX8MPEVK.zip The idea is to use fw_setenv to set the sdcard mirror as the operation on a real emmc/sdcard. Add test=ABCD in u-boot-initial-env for test purpose. And use fw_printenv to check and use hexdump to double confirm it. The uboot env is already written into sdcard mirror(imx-image-multimedia-imx8mpevk.wic). All those operations are on the host x86/x64 PC. ./fw_setenv -c fw_env.config -f u-boot-initial-env Environment WRONG, copy 0 Cannot read environment, using default ./fw_printenv -c fw_env.config Environment OK, copy 0 jh_root_dtb=imx8mp-evk-root.dtb loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bsp_script}; mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi arch=arm baudrate=115200 ...... ...... ...... splashimage=0x50000000 test=ABCD usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi vendor=freescale hexdump -s 0x400000 -n 2000 -C imx-image-multimedia-imx8mpevk.wic 00400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| hexdump -s 0x400000 -n 10000 -C imx-image-multimedia-imx8mpevk.wic 00400000 5f a4 9b 97 20 6a 68 5f 72 6f 6f 74 5f 64 74 62 |_... jh_root_dtb| 00400010 3d 69 6d 78 38 6d 70 2d 65 76 6b 2d 72 6f 6f 74 |=imx8mp-evk-root| 00400020 2e 64 74 62 00 20 6c 6f 61 64 62 6f 6f 74 73 63 |.dtb. loadbootsc| 00400030 72 69 70 74 3d 66 61 74 6c 6f 61 64 20 6d 6d 63 |ript=fatload mmc| 00400040 20 24 7b 6d 6d 63 64 65 76 7d 3a 24 7b 6d 6d 63 | ${mmcdev}:${mmc| 00400050 70 61 72 74 7d 20 24 7b 6c 6f 61 64 61 64 64 72 |part} ${loadaddr| 00400060 7d 20 24 7b 62 73 70 5f 73 63 72 69 70 74 7d 3b |} ${bsp_script};| 00400070 00 20 6d 6d 63 5f 62 6f 6f 74 3d 69 66 20 6d 6d |. mmc_boot=if mm| ...... ...... ...... 00401390 76 3d 31 00 73 6f 63 3d 69 6d 78 38 6d 00 73 70 |v=1.soc=imx8m.sp| 004013a0 6c 61 73 68 69 6d 61 67 65 3d 30 78 35 30 30 30 |lashimage=0x5000| 004013b0 30 30 30 30 00 74 65 73 74 3d 41 42 43 44 00 75 |0000.test=ABCD.u| 004013c0 73 62 5f 62 6f 6f 74 3d 75 73 62 20 73 74 61 72 |sb_boot=usb star| 004013d0 74 3b 20 69 66 20 75 73 62 20 64 65 76 20 24 7b |t; if usb dev ${| 004013e0 64 65 76 6e 75 6d 7d 3b 20 74 68 65 6e 20 64 65 |devnum}; then de| flash the sdcard mirror into i.MX8MP evk board emmc to check uuu -b emmc_all imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk imx-image-multimedia-imx8mpevk.wic  The first time boot, the enviroment is already there.  How to achieve that: a. fw_setenv/fw_printenv: https://github.com/sbabic/libubootenv.git Note: Please do not use uboot fw_setenv/fw_printenv Compile it on the host x86/x64 PC. It is used on host. b. u-boot-initial-env Under uboot, make u-boot-initial-env Note: Yocto deploys u-boot-initial-env by default c. fw_env.config  imx-image-multimedia-imx8mpevk.wic 0x400000 0x4000 0x400000 0x4000 are from uboot-imx\configs\imx8mp_evk_defconfig CONFIG_ENV_SIZE=0x4000 CONFIG_ENV_OFFSET=0x400000 Now, you can run  ./fw_setenv -c fw_env.config -f u-boot-initial-env
View full article
Environment BSP: L6.1.22_2.0.0​ Platform: i.MX93 Links:  https://github.com/NXP/swupdate-scripts https://github.com/nxp-imx-support/meta-swupdate-imx   The AN13872 provides us the swupdate yocto layer, swupdate-scripts and test steps, but there is still much to add. The purpose of this knowledge base is to provide customized advice. 1.How to port meta-swupdate-imx to any yocto version you want? As meta-swupdate-imx only provide kirkstone version, we can upgrade or degrade it based on this version. We will take L6.1.22_2.0.0​ porting steps as an example. 1.1 Download Yocto layer  cd imx-yocto-bsp/sources git clone https://github.com/sbabic/meta-swupdate.git -b mickledore git clone https://github.com/nxp-imx-support/meta-swupdate-imx.git 1.2 Modify  Yocto layer  imx-yocto-bsp/sources/meta-swupdate-imx/conf/layer.conf   You can find swupdate version in imx-yocto-bsp/sources/meta-swupdate/recipes-support/swupdate/ 1.3 Handle patches in meta-swupdate-imx/recipes-bsp/u-boot/files/ About patchs in sources/meta-swupdate-imx/recipes-bsp/u-boot/files/ and imx-yocto-bsp/sources/meta-swupdate-imx/recipes-support/swupdate/files/, you need use devtool to unpack uboot and swupdate into workspace and add changes manunally for development. CONFIG_ENV_OFFSET_REDUND=CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE   sources/meta-swupdate-imx/recipes-bsp/u-boot/u-boot-imx_%.bbappend 2.How to flash base image? Use uuu or dd command, just like common imx-image-xxx 3.swupdate-scripts porting suggestions 3.1 Partition table You can modify partition table refer the size of images. For different soc, the first offset is different. If you are porting i.MX8MP based on iMX8MM, the offset should be 32K.   3.2 Some errors 3.2.1 This error indicates that you need enlarge size of rootfs. e2fsck 1.45.5 (07-Jan-2020) The filesystem size (according to the superblock) is 887599 blocks The physical size of the device is 768000 blocks Either the superblock or the partition table is likely to be corrupt! Abort<y>?    3.2.2 You need upgrade e2fsck verison. e2fsck 1.46.5 (30-Dec-2021) /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4 has unsupported feature(s): FEATURE_C12 e2fsck: Get a newer version of e2fsck! /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4: ********** WARNING: Filesystem still has errors ********** resize2fs 1.46.5 (30-Dec-2021) resize2fs: Filesystem has unsupported feature(s) (/home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_ass  solution: wget https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.47.0/e2fsprogs-1.47.0.tar.xz tar -xf e2fsprogs-1.47.0.tar.xz cd e2fsprogs-1.47.0/ ./configure make -j16 sudo make install   3.2.3 mtools /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 58: mdir: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 68: mdir: command not found solution: sudo apt-get install mtools
View full article
1.Compile full aosp or only kernel Build full aosp: source build/envsetup.sh lunch evk_8mm-userdebug ./imx-make.sh -j8  Only build kernel: ./imx-make.sh kernel -j8 2.Build GKI locally Download GKI outside of android_build. mkdir gki && cd gki (Make sure folder gki is not inside of ${MY_ANDROID}) repo init -u https://android.googlesource.com/kernel/manifest -b commonandroid13-5.15 repo sync Build GKI locally. BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh 3. Export symbols After building GKI locally, you can copy linux-imx from /vendor/nxp-opensource/kernel_imx into common. cd common rm -r ./* cp ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/* ./ ln -s ${MY_ANDROID}/vendor/nxp-opensource/verisilicon_sw_isp_vvcam verisilicon_sw_isp_vvcam ln -s ${MY_ANDROID}/vendor/nxp-opensource/nxp-mwifiex nxp-mwifiex  Build GKI about i.MX: BUILD_FOR_GKI=yes BUILD_CONFIG=common/build.config.imx EXT_MODULES_MAKEFILE="verisilicon_sw_isp_vvcam/vvcam/v4l2/Kbuild" EXT_MODULES="nxp-mwifiex/mxm_wifiex/wlan_src" build/build_abi.sh --update-symbol-list -j8 Then the  common/android/abi_gki_aarch64_imx will be generated. cd gki cp common/android/abi_gki_aarch64_imx /tmp/abi_gki_aarch64_imx   Update GKI kernel rm -r common/* # delete imx kernel repo sync # recover aosp kernel cp /tmp/abi_gki_aarch64_imx android/abi_gki_aarch64_imx cd .. BUILD_CONFIG=common/build.config.gki.aarch64 build/build_abi.sh LTO=thin --update -j8  Then, common/android/abi_gki_aarch64.xml is updated.  
View full article
Installing the new release (Ubuntu 22.04) was detected some NXP boards as iMX8MNEVK, iMX8MM-EVK, iMX8MP-EVK and iMX8ULP-EVK had an issue with the WIFI module that basically it does not initialize at boot. Remember, the supported WIFI modules in Ubuntu 22.04 in the EVKs are the following:       • NXP 88W8987       • NXP 88W9098       • NXP 88W8997       • NXP IW416       • NXP 88W8801       • NXP IW612 To initialize the WIFI module of NXP EVKs in Ubuntu 22.04 you can set the following command in console:   sudo modprobe moal mod_para=nxp/wifi_mod_para.conf   That command find the correct driver for our WIFI module and then initialize it, but this only works when Ubuntu is working and if you reset the EVK you need to set the command again.   The definitive solution is create a custom startup script as a service:   Step 1: Go to etc/systemd/system   cd etc/systemd/system   Step 2: In this directory create a new file with the name of your preference but the extension must be .service. You can do it with nano or vim: sudo nano or sudo vim   The file must contain: [Unit] Description=”Wifi Start” [Service] ExecStart=sudo modprobe moal mod_para=nxp/wifi_mod_para.conf [Install] WantedBy=multi-user.target   Now save the file, in my case the name was wifi_start.service.   Step 3: Now we need to enable the script in the startup/boot sequence following the command: sudo systemctl enable wifi_start.service   Remember in wifi_start.service is the name as you saved your file.   Finally, each time you boot your board, the WIFI module will initialize automatically.   Boards tested: iMX8MN (With WIFI module NXP 88W8987) iMX8MM (With WIFI module NXP 88W8987) iMX8MP (With WIFI module NXP 88W8997) iMX8ULP (With WIFI module NXP IW416)  
View full article
This demo for all(bootloader, device tree, Linux kernel, rootfs) in spi. It uses raw read(sf read)/raw write(sf write in uuu script) to achieve that. sf probe 0; sf read ${fdt_addr} 0x500000 0x100000; sf read ${loadaddr} 0x600000 0x1E00000; sf read ${initrd_addr} 0x2400000 0x600000; setenv bootargs console=${console},${baudrate} earlycon=${earlycon},${baudrate} rdinit=/linuxrc; booti ${loadaddr} ${initrd_addr} ${fdt_addr} |-- 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch --- patch for this demo |-- demo_binary | |-- flash.b0.bin --- b0 bootloader | |-- flash.bin --- c0 bootloader | |-- Image-imx8qxpc0mek.bin --- Linux kernel | |-- imx8qxp-mek.dtb --- device tree | |-- uramdisk_boot.rootfs.aarch64.img --- ram disk | |-- uuu.qspi.all.b0.uuu --- uuu script for b0 | `-- uuu.qspi.all.uuu --- uuu script for c0 `-- readme.txt --- this file # The spi layout used is: # - --------- -------------------------------------------- # | | flash.bin | env | dtb | Image |rootfs| # - --------------- -------------------------------------- # ^ ^ ^ ^ ^ ^ ^ # | | | | | | | # 0 4kiB 4MiB 5MiB 6MiB 36MiB 42MiB 0x1000 0x400000 0x500000 0x600000 0x2400000 Test: HW: i.MX8QXP MEK SW: lf-5.10.72-2.2.0 + 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch Test log: SF: Detected mt35xu512aba with page size 256 Bytes, erase size 128 KiB, total 64 MiB device 0 offset 0x500000, size 0x100000 SF: 1048576 bytes @ 0x500000 Read: OK device 0 offset 0x600000, size 0x1e00000 SF: 31457280 bytes @ 0x600000 Read: OK device 0 offset 0x2400000, size 0x600000 SF: 6291456 bytes @ 0x2400000 Read: OK [ 4.787552] imx6q-pcie 5f010000.pcie: unable to add pcie port. [ 4.797467] Freeing unused kernel memory: 2944K [ 4.807379] Run /linuxrc as init process Starting syslogd: OK Starting klogd: OK Running sysctl: OK Starting network: OK /bin/sh: can't access tty; job control turned off / #  
View full article
This is about the case studay from two USB related issues: #1. Plugin detection issue caused by an errata in i.MX8/8X (host mode).       Very limited unit may encounter this problem. When issue happens, there will be totally no action on USB host port when a debug plugged in. #2: High Speed disconnection detection issue (host mode):       This may happen on some special USB design which have complex circuit and connector design on the USB path and long USB cable. The USB enumeration might be interrupted by an un-expected disconnection event. System log shows USB recognition started but failed at several different stages during handshake. For details, please refer to the doc attached (#1/#2). A reference patch for each has also been made by David.
View full article
Hello everyone, We have recently migrated our Source code from CAF (Codeaurora) to Github, so i.MX NXP old recipes/manifest that point to Codeaurora eventually will be modified so it points correctly to Github to avoid any issues while fetching using Yocto. Also, all repo init commands for old releases should be changed from: $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b <branch name> [ -m <release manifest>] To: $ repo init -u https://github.com/nxp-imx/imx-manifest -b <branch name> [ -m <release manifest>] This will also apply to all source code that was stored in Codeaurora, the new repository for all i.MX NXP source code is: https://github.com/nxp-imx For any issues regarding this, please create a community thread and/or a support ticket. Regards, Aldo.
View full article
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 8/8X DDR Tools Overview   This page contains the latest releases for the i.MX 8/8X DDR Tools. The tools described on this page cover the following i.MX 8/8X Family SoCs with the System Controller Unit (SCU): i.MX 8QuadMax and its derivatives i.MX 8QuadPlus i.MX 8QuadXPlus and its derivatives i.MX 8DualXPlus and i.MX 8DualX  i.MX 8DXL (i.MX 8XLite) and its derivatives i.MX 8SXL  NOTE: For the i.MX 8M Family of DDR tools please refer to the : i.MX 8M Family DDR Tool Release                           The purpose of the i.MX 8/8X DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.).  This process equips the user to then proceed with the bring-up of a boot loader and an OS.  Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface.     The i.MX 8/8X DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test   For more details regarding these DDR tools and their usage, refer to the MX8X_DDR_Tools_quickstart_guide.pdf attached to this page.   i.MX 8/8X DDR Register Programming Aid (RPA)   The i.MX 8/8X DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization in two formats (in separate Excel worksheet tabs):   DDR Stress Test script: This format is used specifically with the DDR stress test by first copying the contents in this worksheet tab and then pasting it to a text file, naming the document with the “.ds” file extension. The user will select this file when executing the DDR stress test. DCD CFG file: This format is the configuration file used specifically by the SCU Firmware (SCFW). In this scenario, the user copies the contents in this worksheet tab and pastes it to a text file, naming the document with the “.cfg” file extension and placing this file in the appropriate SCFW board file directory.   i.MX 8/8X DDR Register Programming Aid (RPA): Current Versions Note: In all cases, the RPA revision is aligned to a minimum SCFW version as shown in the table below. In some cases, the BSP alignment is provided as extra detail, however, the RPA tool is specifically aligned to a minimum SCFW version and later. To obtain the latest RPAs, please refer to the following links (note, existing RPAs have been removed from this main page and moved to the SoC specific links below): i.MX8QM: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX8QXP/QXP/DX: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302 i.MX8DXL/SXL: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8DXL-DDR-Register-Programming-Aid-RPA/ta-p/1602262   Processor Mask Revisions Memory Supported Latest RPA Version * Notes i.MX 8QM B0 LPDDR4 Rev 23*** Rev 22** Rev 21** Rev 20** Rev 19** Rev 23: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev22: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 21: Fixed 1 DRC operation to comment out calls to VREF training to DRC1 and added DDRC_SCHED register programming to align with latest SCFW programming (refer to RPA revision history for more details). Rev 20: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 19: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 LPDDR4 Rev 16*** Rev 15** Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 DDR3L Rev 23 Rev 22*** Rev 21 Rev 20 Rev 23:  -Corrected Register Configuration DDR_PHY_PTR4.tDINIT1 bit field programming. Previously, the calculation was based on tRFC only, however, the calculation should have been based on "tRFC+10ns". This was corrected. -Set DDRC_INIT4, DDR3 MR2.ASR=1 as the default setting to allow for the DRAM to select the self refresh rate automatically based on its case temperature (but user has the option to disable via pull-down menu). Also, removed conditional setting for DTCR0.DTRDBITR as it is not needed since DDR3 does not support DBI. Default setting of this was zero and will remain that way. -Provided option to user to select auto refresh rate based on the intended max temperature of the DDR3L device (1X, 2X, 4X). User should confirm with the DDR3L data sheet for supported temperature ranges and associated refresh rate. Rev 22: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 21: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW. -Compatible with SCFW 1.1.10 and later -Changes made to this revision do not affect the DCD CFG file output based on v19 -Issue discovered in the DDR stress test script, wherein certain commands were not being properly configured based on the ECC setting in the Register Configuration worksheet; this was resolved (cells A84, A87, A90, A93 ) -In addition, in both DCD CFG and DDR stress test script worksheets, all commands that depend on ECC config have been updated to include an "OR" with whether or not the data bus is configured for 16-bit (ECC is only supported for full 32-bit data bus width configurations) i.MX 8DualX C0, B0 LPDDR4 Rev 16*** Rev 15* Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8DualX C0, B0 DDR3L Rev 21 Rev 20*** Rev 19 Rev 18 Rev 21: -Corrected Register Configuration DDR_PHY_PTR4.tDINIT1 bit field programming. Previously, the calculation was based on tRFC only, however, the calculation should have been based on "tRFC+10ns". This was corrected. -Set DDRC_INIT4, DDR3 MR2.ASR=1 as the default setting to allow for the DRAM to select the self refresh rate automatically based on its case temperature (but user has the option to disable via pull-down menu). Also, removed conditional setting for DTCR0.DTRDBITR as it is not needed since DDR3 does not support DBI. Default setting of this was zero and will remain that way. -Provided option to user to select auto refresh rate based on the intended max temperature of the DDR3L device (1X, 2X, 4X). User should confirm with the DDR3L data sheet for supported temperature ranges and associated refresh rate. Rev 20: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 19: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  -Compatible with SCFW 1.1.10 and later * For a history of the previous versions of an RPA, refer to the Revision History tab of the respective RPA.  ** In general, it is recommended to use the latest RPA tool even with a pre-released BSP as it ensures you are testing with the latest fixes and features. Older versions of the RPA may be provided to support existing/released versions of the BSP.  This only applies to those RPA tools that are compatible with pre-release BSPs but may not be compatible with released versions of the BSP.   ***IMPORTANT: as stated in the table above, for the noted RPA version, it is aligned to SCFWv1.7.0 (and later SCFW versions).  Older versions of the RPA are not aligned to SCFWv1.7.0 (and later SCFW versions).  If trying to use an older version of an RPA with SCFWv1.7.0 (and later SCFW versions), it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QXP/DualX: DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ For MX8QM: DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 (and later SCFW versions) (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QXP: [remove] ifndef SCFW_DCD [remove] /* For 1200MHz DDR, DRC 600MHz operation */ [remove] DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ [remove] #else <keep code as is> [remove] #endif Note: when it is stated "SCFWv1.7.0 (and later SCFW versions)", it implies SCFWv1.7.0, 1.7.1, 1.7.2... 1.8.0, 1.9.0, 1.10.0... etc., where "..." are minor versions/patches, so when you see 1.7.2... it implies 1.7.3, 1.7.4, etc.).  Unless otherwise noted, the latest RPA shown in the table above is aligned to the latest SCFW release.    i.MX 8/8X DDR Stress Test    The i.MX 8/8X DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational prior to building the SCFW for use with u-boot and OS bring-up. The DDR stress test uses the .ds DDR stress test script generated from the RPA tool along with a special build of the SCFW, built with option: DDR_CON=ddr_stress_test_parser Or in the case of i.MX 8QuadMax use of one DDR Controller: DDR_CON=ddr_stress_test_parser_DRC0_only The DDR stress test offers a Target option to dictate which SoC is under test. The following are Target options to select from: MX8QM – used to test i.MX 8QuadMax and its derivatives i.MX 8QuadPlus MX8QX – used to test i.MX 8QuadXPlus and its derivatives i.MX 8DualXPlus/DualX MX8DXL – used to test i.MX 8DXL and its derivatives i.MX8 SXL     To install the DDR Stress Test, save and extract the zip file mx8_ddr_stress_test_ERxx_installation.zip   (where 'xx' is the current version number) and follow the on-screen installation instructions. Note, when extracting the DDR Stress Test tool .zip file, it is recommended to perform an "Extract here" operation.  Some systems do not allow for the extracted installation executable to run from another folder and will only work when being executed from the same location as the original, downloaded zip file.  For more details on the DDR stress test usage, refer to the MX8_DDR_Tool_User_Guide found in the DDR Stress Test tool delivery. NOTE: Before using the DDR tools on a new custom board, the user should properly port the SCU Firmware (SCFW) to this new board. The DDR tools will not be able to run without a properly ported and working SCFW.            i.MX 8/8X DDR Stress Test Requirements The tool requires access to the Windows registry, hence users must run it in administrator mode. The tool cannot run on an OEM closed device that requires images signed by the customer When users design new i.MX 8/8X boards, please make sure to follow the rules outlined in the respective Hardware Developers Guide and the MX8_DDR_Tool_User_Guide, which can help users bring up DDR devices on their respective i.MX 8/8X boards.   i.MX 8/8X DDR Stress Test SECO Firmware It is generally not recommended to update the SECO (ahab) firmware that comes default with the DDR Stress Test. This is not recommended because the purpose of the DDR Stress Test is to test the DDR memory interface, not the entire SCFW to SECO firmware operation even though a newer version of the SCFW may complain that the SECO firmware version is not the latest. The SECO firmware version that comes with the DDR Stress Test has been tested and proven to work by the factory before the DDR Stress Test release; updating the SECO firmware to a different version may result in unintended consequences rendering the DDR stress test inoperable. In most cases, it is allowable to update only the SCFW without updating the SECO firmware. Should the user wish to update the SECO firmware version in the DDR Stress Test, then they will need to rename this firmware without the silicon version (for example, if updating the MX8QM SECO firmware, the user will need to rename mx8qmb0-ahab-container.img to mx8qm-ahab-container.img, basically remove the “b0”). The exception is for the MX8QXP, if updating the C0 silicon version SECO firmware, then the user should maintain the C0 nomenclature. If the user finds that the updated SECO firmware causes the DDR Stress Test to become inoperable, then it is recommended to revert to the default SECO firmware version that came with the DDR Stress Test release. i.MX 8/8X DDR Stress Test User Guide The i.MX 8/8X DDR Stress Test tool includes the document: MX8_DDR_Tool_User_Guide.pdf NOTE: Please read the MX8_DDR_Tool_User_Guide inside the package carefully before you use this tool.   DDR Stress Test Revision History   Rev Major Changes (Features) NXP BSP Software Version ER 14 Updated to support parsing of the VREF training command in the DDR Stress Test script This version is aligned with NXP BSP GA version L5.4.3_2_0_0 and later. ER15 - Support for i.MX 8Lite (aka DXL) - Provides more verbose output in event of data training failures, specifically on which byte lanes failed - Aids in debug of board layout issues This version is aligned with NXP BSP GA version Linux 5.15.71_2.2.0 and later.    Related Resources Links: i.MX 8ULP DDR tools: i.MX Software and Development Tools | NXP Semiconductors Scroll down to “Other Resources --> Tools --> DDR Tools” i.MX 8M Family DDR Tool Release  i.MX 6/7 DDR Stress test GUI Tool i.MX 8QM RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX 8QXP/DXP/DX RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302 i.MX 8DXL (i.MX 8XLite) RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8DXL-DDR-Register-Programming-Aid-RPA/ta-p/1602262   FAQs: Q. When the DDR stress test is running, it indicates testing region 1 and then region 2. What is region 1 and region 2? A. There are two distinct DDR memory regions in the i.MX8X series which is due to the architecture of Cortex A core and the associated memory map of the i.MX8X. Region 1 is the 32-bit region, starting at 0x080000000 and ending at 0x0FFFFFFFF (2GB total) Region 2 is the 64-bit region (for the Cortex A core architecture), starting at 0x880000000 and ends at the remaining density: • For 4GB total on board density, 2GB for region 1 and 2GB for region 2, so region 2 will end at 0x8FFFFFFFF (0x900000000 minus 1) • For 6GB total (NXP board density), 2GB for region 1 and 4GB for region 2, so region 2 will end at 0x97FFFFFFF (0x980000000 minus 1) • For 8GB total, 2GB for region 1 and 6GB for region 2, so region 2 will end at 0x9FFFFFFFF (0xA00000000 minus 1) Hence there is a “hole” in the memory map between region 1 and region 2. As such, the DDR stress test first tests the lower region (region 1) until it is exhausted (up to 2GB), and if the DDR density exceeds 2GB, the test will test the remaining density in region 2. Q. Do the i.MX8X series SoCs support LPDDR4 memories with 17 row addresses (R[16:0])? A. The i.MX8QM, i.MX8QXP, and i.MX8DXP SoCs and their derivatives cannot support newer 17-row-address LPDDR4 memories. This means, in order to support the maximum 4GB (32Gb) LPDDR4 density, the configuration must be 16-row, 2 rank (as opposed to the unsupported 17-row, 1 rank). The upcoming i.MX8DXL is planned to support 17-row address LPDDR4 devices. Q. I can select a different i.MX8X AP UART port when running the DDR Stress Test? A. It is highly recommended to follow NXP board designs including selecting the same UART ports; this eases the user’s software porting efforts and minimizes issues with needless debugging. The DDR Stress Test requires the use of the USB OTG port and the AP UART port (and it is highly recommended to connect the SCFW UART port for SCFW debug messages). To date, the factory sees no reason why the user would need to select a different AP UART port than what is used on NXP boards. Selecting the same AP UART port ensures a faster bring up of the DDR stress test rather than needlessly debugging why a different UART port is not working. In any event, some wish to use a different UART port for whatever reason, as such, NXP has placed work arounds to allow the selection of a different UART port. To select a different UART port (0,1, or 2), the user simply needs to add the following line to the end of the DDR Stress Test DDR initialization (.ds) script: memory set  0x5C01042C 32   <UART port value> memory set  0x5C01042C 32   0x00000000   # UART0 port selection for AP UART (default) memory set  0x5C01042C 32   0x00000001   # UART1 port selection for AP UART memory set  0x5C01042C 32   0x00000002   # UART2 port selection for AP UART Note that UART ports 0, 1, and 2 have pad names that are default UART pins (IOMUX ALT0 config). To date, the DDR tools do not support other UART ports that are mux’d out on other non-default UART pins. However, there is an exception for i.MX8QXP/DXP and the upcoming i.MX8DXL where UART3 mux’d out on FLEXCAN2 can be used. To select this, add the following to the end of the .ds file: memory set  0x5C01042C 32   0x00000003   # UART3 port selection for AP UART (exception for i.MX8QXP/DXP and i.MX8DXL) Some RPAs do have support built in (via a pull down menu) to select the UART port. For those RPAs that do not have this feature, this is due to the fact that these RPA (NXP boards) were not tested with a different UART port as the board requires cutting traces and re-wiring the UART signals and some boards may not have these UART traces readily available. However, the user is still able to manually add this UART port selection. Refer to the following RPAs to see the UART port select option: MX8QXP DDR3 MX8DXP DDR3 Q. Why does the DDR stress test appear to hang when testing [MX8QM with 8GB (64Gb) or MX8QXP with 4GB (32Gb)] of LPDDR4 memory? A. The issue is not caused by the DDR stress test itself but by the version of the SCFW being used. The default version of the SCFW binary pre-dates a change made by the SCFW to ignore DRAM density limitations when it detects that the DDR stress test is running. This version of the SCFW associated with the DDR stress test ER14 limits the testable DRAM density to [MX8QM: 6GB, MX8QXP: 3GB], as this version of the SCFW is configured to operate on NXP boards as a basis. As noted in the DDR stress test user guide, it is recommended for users to port the latest SCFW to their board first before using the DDR stress test to account for board differences between NXP’s board and their board.  In addition, the user has the following options to enable testing beyond [MX8QM: 6GB, MX8QXP: 3GB]; note it is the responsibility of the user to ensure a properly working, ported version of the SCFW prior to operating the DDR stress test. 1. The latest SCFW should contain an update that sets no density limit if it is detected that the SCFW is built for usage with the DDR Tool - the user can try to get the latest porting kit and build the new firmware.  This is the recommended change. 2. In board.c, function board_system_config(), there is this chunk of code (MX8QM example shown) if using an existing/older SCFW that pre-dates this change: /* Board has 6GB memory so fragment upper region and retain 4GB */         BRD_ERR(rm_memreg_frag(pt_boot, &mr_temp, 0x980000000ULL,             0xFFFFFFFFFULL)); User can modify it as follows:     if (ddrtest == SC_FALSE)     {         sc_rm_mr_t mr_temp;         /* Board has 6GB memory so fragment upper region and retain 4GB */         BRD_ERR(rm_memreg_frag(pt_boot, &mr_temp, 0x980000000ULL,             0xFFFFFFFFFULL));         BRD_ERR(rm_memreg_free(pt_boot, mr_temp));     } This is disables execution of this section of code if the SCFW is built for the DDR Tool (the same as 1. but needs to be done by the user manually when using an earlier firmware version). 3. Change 0x980000000 to 0xA00000000 in the above chunk of code. That should allow for 8GB density for MX8QM example shown above (for MX8QXP, change 0x8C0000000ULL to 0x900000000ULL for 4GB density).  
View full article
  Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/...  
View full article
Introduction This document intends to describe how to implement workaround for ERR050145 (ISI: Memory overwrite occurring outside of allocated buffer space corrupting system memory) based on Linux BSP. ERR050145 is applicable for i.MX8QM B0, i.MX8QXP B0 series products.   Software Platform Reference patches stated into this document are developed and validated on L4.14.98_GA2.0.0 release.   Software Workaround As workaround stated, the xRDC can be programmed to grant write access to the ISI only within its allocated frame buffer space, which can prevent the corruption. So under Linux, we can consider to implement workaround like so: Create children partition for ISI and allocate buffers. Then Linux can access these buffers as normal, but ISI can't access other memory out of these buffers, it is limited by xRDC hardware. Considering the xRDC hardware can only support up to 16 memory regions, we may need to consider different workaround implementations for different camera use case scenarios.   For single camera use case, the required camera buffer number is usually less than 16. So “0001-iMX8QM-iMX8QX-ERR050145-ISI-overwrite-workaround.patch” is enough. No modification is needed for camera application in this case.   For multiple camera use case, all patches (0001~0003) are needed. If the camera application used VB2_MEMORY_MMAP memory mode, then no code modification is needed in application. The V4l2 ISI driver can handle everything (Allocate physical continued memory for each camera, and map them as one xRDC memory region for overwrite protect). If the camera application used VB2_MEMORY_USERPTR and VB2_MEMORY_DMABUF memory mode, then it needs allocate camera buffers with physical continued memory for each camera, then the driver will merge them as one xRDC memory region in SCFW.   How to prove workaround take effective? After applying the patches, the ISI will report AXI_WR_ERR due to it failed to write data out of the allocated buffers when the errata happens. To reduce the ISI interrupt, we can also change the ISI interrupt setting as followed: void mxc_isi_enable_irq(struct mxc_isi_dev *mxc_isi) {     u32 val;     val = CHNL_IER_FRM_RCVD_EN_MASK |         CHNL_IER_EXCS_OFLW_V_BUF_EN_MASK |         CHNL_IER_EXCS_OFLW_U_BUF_EN_MASK |         CHNL_IER_EXCS_OFLW_Y_BUF_EN_MASK;     writel(val, mxc_isi->regs + CHNL_IER); }   Add reference patch for L5.4.70_2.3.0 and L5.10.72_2.2.0.
View full article
This is a summary for the software lockup issue found in the following platform: −i.MX8/8X −Linux 4.14.98_2.3.3   Issue description: •Issue happens during the boot procedure, at the systemd stage. •The symptom of the issue: −From user perspective, the symptom varies, but mainly fall into several types: §At the console, there may be login prompt, but no response (only echo) when input user/password. Unable to login. §Some user service in systemd failed to start. E.g. weston. −When checking the task status using sysrq (w/t), many tasks, including some kernel core tasks stays in “D” (uninterruptable sleep) state. E.g. agetty, login, chvt, etc. •Kernel itself is still alive. This can be verified by triggering some drivers, such as plugin a USB device. Issue can be reproduced on MEK through long time stress.   Please refer to the doc/patch attached for details.
View full article
i.MX8 series contains internal HiFi4 DSP. It is targeted for Audio related signal processing. SOF (Sound Open Firmware) is open source audio DSP firmware, driver and SDK. This document introduces basic theory about IIR/FIR digital filters, how to design IIR/FIR digital filters and the Equalizer filters implementation by SOF. After that, the document also describes how HiFi4 DSP MAC engine accelerate the EQ filters calculation.
View full article
BSP: L5.15.5_1.0.0   Platform: i.MX8MPlus EVK   1. Parameter preparation For more parameter calculation, please refer to: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-8M- Mini-Register-Programming-Aid-DRAM-PLL-setting/ta-p/111209  For 1866MHz LPDDR4, we need a DRAM PLL size of 933MHz. The PLL dividing parameters are: m=622,p=16,s=0, k=0.   2. Calibration and stress test with DDR Tool 2.1 Creating a test script for 1866MHz Here we copy the script from another file (e.g. 2000MHz) and modify the contents of the script.   2.2 Modify the script to adapt to 1866MHz 2.3 Download the test script After selecting the ddr script we created, click on the download button   2.4 Calibrating the stress test Set the core clock of the chip's cpu to 1.2GHz, then click the Calibration button to calibrate, then click Gen Code to generate the lpddr4_timing.c file. Set the start frequency to 1866MHz for the stress test.   2.5 Modify lpddr4_timing.c We need to modify the generated lpddr4_timing.c file to change the maximum speed to 3732MTS.   3. SPL patch After getting the correct lpddr4_timing.c file, the SPL code also needs to be modified to add support for the 933MHz DRAM PLL. diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c b/arch/arm/mach-imx/imx8m/clock_imx8mm.c index e39f238fdf...5622a6334e 100644 --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c @@ -55,6 +55,7 @@ static struct imx_int_pll_rate_table imx8mm_fracpll_tbl[] = { PLL_1443X_RATE(650000000U, 325, 3, 2, 0), PLL_1443X_RATE(600000000U, 300, 3, 2, 0), PLL_1443X_RATE(594000000U, 99, 1, 2, 0), + PLL_1443X_RATE(933000000U, 622, 16, 0, 0), PLL_1443X_RATE(400000000U, 400, 3, 3, 0), PLL_1443X_RATE(2660000U, 266, 3, 3, 0), PLL_1443X_RATE(167000000U, 334, 3, 4, 0), diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index 326b92d784..ebd005bc2b 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -117,6 +117,10 @@ void ddrphy_init_set_dfi_clk(unsigned int drate) dram_pll_init(MHZ(1000)); dram_disable_bypass(); break; + case 3732: + dram_pll_init(MHZ(933)); + dram_disable_bypass(); + break; case 3200: dram_pll_init(MHZ(800)); dram_disable_bypass();   4. Test results   Reference blog. DDR Tool: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467  RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8MPlus-m865S-DDR-Register-Programming-Aids-RPA/ta-p/1235352 
View full article
This article describes how to integrate NXP WiFi & BT module into i.MX platform, some debug tips, how to test, etc. Although it takes i.MX8MM as example, it is also suitable for all i.MX8 serials platform.
View full article
This doc will show: i.MX8DXL EVK board without connect  hardware LCD display, using FreeRDP to share screen to remote PC which is in same network,  PC take this shared screen could  run any command on i.MX8DXL EVK board.   HW: i.MX8DXL EVK board,  PC  SW: i.MX8DXL Linux 5.15.32 BSP release, and code change in this doc   1> i.MX8DXL Linux kernel side, just use imx8dxl-evk-lcdif.dts, but did not connect any LCD display,  so Linux kernel could create related drm device, and weston could be start. But on 8DXL EVK board, ENET1_RGMII_TXD3 and ADMA_LCDIF_D03 pin conflict,  so need code change as 5.15.32-imx8dxl-evk-lcdif.dts.diff.   2> yocto/bld/conf/local.conf, add below line, as freerdp depend on ffmpeg. LICENSE_FLAGS_ACCEPTED+="commercial"   3> For i.MX8DXL,  weston use software pixman render, to use NEON optimization,  pixman need switch to  latest 0.42.0,  enter folder (yocto/bld/tmp/work/armv8a-poky-linux/pixman/1_0.40.0-r0/pixman-0.40.0),  git clone (https://github.com/freedesktop/pixman.git) and checkout to latest 0.42.0:  Also chaneg related build flag at bb file as pixman_0.40.0.bb.diff.     4> Default  freerdp need switch to 2.8.0, enter folder (yocto/bld/tmp/work/armv8a-poky-linux/freerdp/1_2.4.1-r0/git),  git clone (https://github.com/FreeRDP/FreeRDP.git), check out to 2.8.0; And to use neon accelerate freerdp related function, such as color space conversion, image codec encoding ,  need apply patch  freerdp-codechange-neon.diff. And related bb file compile flag change as freerdp_2.4.1.bb.diff     5> bitbake -c compile ffmpeg bitbake -c install ffmpeg   bitbake -c compile pixman  bitbake -c install pixman    bitbake -c compile  freerdp bitbake -c install  freerdp   Copy  generated new libs to default released i.MX8DXL rootfs, make sure ffmeg , pixman, freerdp related libs are  from your build, for example: libfreerdp-client2.so.2 -> libfreerdp-client2.so.2.8.0 libfreerdp2.so.2 -> libfreerdp2.so.2.8.0 libwinpr-tools2.so.2 -> libwinpr-tools2.so.2.8.0 libwinpr2.so.2 -> libwinpr2.so.2.8.0   6> i.MX8DXL Linux rootfs:  file /etc/xdg/weston/weston.ini,  change start-on-startup to true: [screen-share] command=/usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize --rdp-tls-cert=/etc/freerdp/keys/serve start-on-startup=true   7> i.MX8DXL Linux OS, run below cmd: winpr-makecert -path $PWD copy generated files to /etc/freerdp/keys/server.crt and /etc/freerdp/keys/server.key   8> reboot i.MX8DXL EVK board,  make sure  EVK board and PC in the same network; check i.MX8DXL Linux OS , there are two process name as "weston", one process is weston rdp backend to share screen to PC.   9> PC side, get wfreerdp.exe from  https://github.com/FreeRDP/FreeRDP/wiki/Prebuilds PC side run cmd as: wfreerdp.exe /v:ipaddress_of_8DXLEVK     Reference: 1>https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX#design-resources 2>https://github.com/FreeRDP 3>https://github.com/freedesktop/pixman 4>https://github.com/DLTcollab/sse2neon  
View full article