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:
Before I have presentation named “i.MX6 SDCARD Secondary Boot Demo”  in following link. i.MX Development Miscellanea(i.MX 开发杂记) - NXP Community   Now I have the “i.MX8MM SDCARD Secondary Boot Demo”.   The big difference is i.MX8MM using spl. And in the “i.MX6 SDCARD Secondary Boot Demo” I manually edit the secondary image table and manually combine the images. Now, I have written done a script “imx_sd_secondary_boot_creator.sh” to do above.
View full article
On behalf of Gopise Yuan. A simple sharing for enabling some kernel options for using “lockdep”. It will be useful for detecting some deadlock (spinlock/mutex/…) issue. Validated on L4.14.x, and, found a lock violation…
View full article
The IOMUX module on i.MX 8M enables flexible I/O multiplexing, allowing users to configure each IO pad as one of selectable functions. The CSU (Central Security Unit) module on i.MX 8M can be used to configure some devices as secure only accessible to protect the security of these devices. But as the IOMUX is Non-Secure accessilbe and thus the pad function can be configured dynamicaly, there is one risk if hackers reconfigure the IO pad to make the device connected to other controller which is accessible to Non-Secure world. One solution for this issue is configuring the CSU to limit Non-Secure access to IOMUX, all IOMUX registers write operations are routed to Trusty OS. In the Trusty OS, add all sensitive IO resources to one blacklist, the IOMUX driver in Trusty OS should check and deny any write attemption to sensitive registers from Non-Secure world. One example patch set is attached to show how to assign the IOMUX to secure world and how to route the IOMUX write operations to Trusty OS. In this example, the USB Host pinctrl PAD on i.MX8MP EVK was assigned to secure world. The layout of the example codes are:     . ├── atf │ └── 0001-config-iomux-to-secure-write.patch --> ${MY_ANDROID}/vendor/nxp-opensource/arm-trusted-firmware ├── kernel │ └── 0001-Use-Trusty-OS-to-handle-iomux-registers-written-oper.patch --> ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/ ├── trusty │ └── 0001-Add-iomux-pinctrl-TEE-handler.patch --> ${MY_TRUSTY}/trusty/hardware/nxp └── u-boot └── 0001-Use-Trusty-OS-to-handle-IOMUX-operation.patch --> ${MY_ANDROID}/vendor/nxp-opensource/uboot-imx      
View full article
Sometimes we got CMA allocation error while there're still many free pages in CMA area.  This article analyze several cases/reason for this kind of failure.
View full article
On behalf of Gopise Yuan. In case some customer may make mistake in mechanical design, they may need to flip/mirror the screen. DPR in DPU can do this in a simple way. This patch demonstrate how to enable VFLIP and HFLIP in DPR to do a V+H flip (=180 rotate) of the screen
View full article
  Purpose Under some situations, need to modify the binary image. Under some situations, no development environment. Under some situations, even no Linux. Only have windows. Board bring up need simple settings, such as simple/tiny rootfs.  Key Features Create small sdcard mirror image All operations are on binary files no need development environment(offline) Set the u-boot environment on binary image Windows OS support Snapshot:   Please download  create_sdcard_mirror_ext.zip.001.zip create_sdcard_mirror_ext.zip.002.zip create_sdcard_mirror_ext.zip.003.zip create_sdcard_mirror_ext.zip.004.zip create_sdcard_mirror_ext.zip.005.zip create_sdcard_mirror_ext.zip.006.zip extract each one to have below files  create_sdcard_mirror_ext.zip.001 create_sdcard_mirror_ext.zip.002 create_sdcard_mirror_ext.zip.003 create_sdcard_mirror_ext.zip.004 create_sdcard_mirror_ext.zip.005 create_sdcard_mirror_ext.zip.006 Put together and extract them.  
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.   UmiCrGJNSlwEjZD 2.2 Modify the script to adapt to 1866MHz mMBhQZqsXItExWb 2CLDIHet8qJbnSu 2.3 Download the test script After selecting the ddr script we created, click on the download button kCXU2R4YDxP5Fqp   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. e6c9d24egy1h2clzytmqej20wm0n6wi1   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 1tiJu2A8P4qNeQB   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
On behalf of Gopise Yuan. This is a debugging patch for adding support for showing interrupt status (same as ‘cat /proc/interrupts’) in Sysrq. Can be triggered by “y”. Might be useful for debugging some hang/stuck issue. Note: Only for debugging purpose. Triggering it in normal case may throttle current cpu and cause IPC/RCU abnormal due to long printing to console.
View full article
This is simple known-how for how to implement "boot animation" with DRM under i.MX8/X + Linux:   Code to refer to: ========================================================================= 1. kmscube: Either open source one or the customized on for i.MX will be OK: https://cgit.freedesktop.org/mesa/kmscube/ https://source.codeaurora.org/external/imx/kmscube-imx/ 2. Android display HAL: KmsDisplay.cpp   Known-how: ========================================================================= 1. Only one application can grab the master role of the DRM device. If need to control DRM from two applicaiton simultanously, possible solution:     A, Use "controlD" node instead of "card" node in /dev/dri/. This requires L4.14 or before. This device node was removed by two commits in L4.14.x:           8a357d10043c75e980e7fcdb60d2b913491564af           6449b088dd51dd5aa6b38455888bbf538d21f2fc     Can be brought back by reverting these two commits in L4.14.98.     B, Use framebuffer emulator to emulate a FB device (/dev/fb0). (not recommended due to lack of vsync). 2. Some kernel functions will re-config the DRM device during boot. This will cause display abnormal after user application has configured the DRM device. Better to disable these kernel features:       CONFIG_DRM_FBDEV_EMULATION       CONFIG_FRAMEBUFFER_CONSOLE 3. Use atomic mode of KMS API instead of legacy mode for any dynamically screen drawing application, such as video, game and etc. Atomic mode will have much better performance compare to legacy mode. The kmscube has sample code for both mode. 4. Better to do commit checking before doing any real commit, especially when doing display during boot. Sometimes some internal component in DRM is not fully ready after card device is present.       DRM_MODE_ATOMIC_ALLOW_MODESET 5. If video playback will be used, some points to remind:     a, Sample code for direct video decoding (in unit-test): imx-test/test/mxc_v4l2_vpu_test/     b, VPU in i.MX8/X only support tiled NV12 output and it has pixel alignment requirement (128). Need to use CPU or G2D to do un-tile, CSC and cropping. Sample code: <android>/vendor/nxp/fsl_imx_omx/OpenMAXIL/src/component/v4l2_common/G2dProcess.cpp If using G2D under Linux, it will support un-tile directly (through OpenCL internally).
View full article
This article is to show how to use CLK2 for PCIe ref clock for i.MX8MQ. Test Environment  i.MX8MQ + BSP L5.10.52 Background In order to cost down, some customers used CLK2 as PCIe reference clock as below while no external OSC installed, which is different with i.MX8MQ EVK design, so no clock output for PCIe.  CLK2 for PCIE clock.png Checked L4.14.98_2.3.0 and found it added internal PLL for PCIe clock support. internal PLL of PCIe REF_CLK.JPG Solution The attached patch based on 4.14.98 can’t be used directly on 5.10.52, the following is the main modification for PLLOUT of PCIe clock. PLLOUT Monitor Configuration Register contains bits to control the clock that will be generated on the CCM clock mapped to CLK2_P/N. internal PLL clock.png        
View full article
     The following steps allow you to toggle a pin on i.MX 8M Mini EVK, you can use the EVK as not gate, trigger a wake up signal, etc. With an script and modifying the device tree you can read an input and get as output the invert input.   On the Host.   Cloning the Linux kernel repository.   Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/linux-imx cd linux-imx/   Patching the device tree.   Open the imx8mm-evk.dtsi file: vim arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi For the purpose of this example, uart3 has to be "disabled" in order to avoid pins conflict, so change "okay" to "disabled": &uart3 {        pinctrl-names = "default";        pinctrl-0 = <&pinctrl_uart3>;        assigned-clocks = <&clk IMX8MM_CLK_UART3>;        assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;        fsl,uart-has-rtscts;        status = "disabled"; }; Add the following lines in the iomuxc node: &iomuxc {       pinctrl-names = "default";       pinctrl-0 = <&pinctrl_hog>; ​       pinctrl_hog: hoggrp {               fsl,pins = <                       MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9               0x19                       MX8MM_IOMUXC_ECSPI1_MISO_GPIO5_IO8              0x19               >;       };   Build the device tree.   Setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8mm-evk.dtb Copy the .dtb file to the EVK, for example with scp: scp imx8mm-evk.dtb root@<EVK_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located.   On the EVK Board.   Switching the device tree.   To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8mm-evk.dtb Partition_1/ Reboot the board. reboot   Create an script.   Use vi: vi toggle.sh Add the following lines: #!/bin/bash ​ echo 136 > /sys/class/gpio/export echo in > /sys/class/gpio/gpio136/direction ​ echo 137 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio137/direction echo 0 > /sys/class/gpio/gpio137/value ​ while : do ​ if [[($(cat /sys/class/gpio/gpio136/value) == "0")]]; then         echo 1 > /sys/class/gpio/gpio137/value else         echo 0 > /sys/class/gpio/gpio137/value        fi ​ done Save the file: :wq Change file permissions: chmod +x toggle.sh   Toggling a pin.   In this example we are using the pin "UART3_CTS" like an input and "UART3_RTS" like an output. 40 pin.png To toggle the pin, run the script: ./toggle.sh
View full article
Background Some customers connect their imx running Android to the cloud, so reboot-bootloader and the use of fastboot oem unlock is not acceptable. This way the system is disconnected and cannot be operated remotely using adb. This article therefore proposes to execute oem unlock before the bootloader is started when the system is first run, which can be unlocked directly.   Patch diff --git a/drivers/fastboot/fb_fsl/fb_fsl_boot.c b/drivers/fastboot/fb_fsl/fb_fsl_boot.c index 86b919775a..d60cd248ee 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_boot.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_boot.c @@ -529,6 +529,42 @@ bool __weak is_power_key_pressed(void) { return false; } +static void wipe_all_userdata(void) +{ + char response[FASTBOOT_RESPONSE_LEN]; + + /* Erase all user data */ + printf("Start userdata wipe process....\n"); + /* Erase /data partition */ + fastboot_wipe_data_partition(); + +#if defined (CONFIG_ANDROID_SUPPORT) || defined (CONFIG_ANDROID_AUTO_SUPPORT) + /* Erase the misc partition. */ + process_erase_mmc(FASTBOOT_PARTITION_MISC, response); +#endif + +#ifndef CONFIG_ANDROID_AB_SUPPORT + /* Erase the cache partition for legacy imx6/7 */ + process_erase_mmc(FASTBOOT_PARTITION_CACHE, response); +#endif + +#if defined(AVB_RPMB) && !defined(CONFIG_IMX_TRUSTY_OS) + printf("Start stored_rollback_index wipe process....\n"); + rbkidx_erase(); + printf("Wipe stored_rollback_index completed.\n"); +#endif + process_erase_mmc(FASTBOOT_PARTITION_METADATA, response); + printf("Wipe userdata completed.\n"); +} +void do_unlock(void) +{ + int status; + wipe_all_userdata(); + status = fastboot_set_lock_stat(FASTBOOT_UNLOCK); + if (status < 0) + return FASTBOOT_LOCK_ERROR; + printf("Unlock device\n"); +} int do_boota(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]) { ulong addr = 0; @@ -563,6 +599,9 @@ int do_boota(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]) { fastboot_set_lock_stat(FASTBOOT_LOCK); lock_status = FASTBOOT_LOCK; } + if (lock_status == FASTBOOT_LOCK){ + do_unlock(); + } bool allow_fail = (lock_status == FASTBOOT_UNLOCK ? true : false); avb_metric = get_timer(0);      
View full article
     The following steps allow you to add a pad Wakeup on i.MX 8QuadMax MEK CPU Board. On the Host.   Cloning the Linux kernel repository.   Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/linux-imx cd linux-imx/ Patching the device tree.   Open the imx8qm-mek.dts file: vim arch/arm64/boot/dts/freescale/imx8qm-mek.dts Add the following lines: &lsio_gpio2{       pad-wakeup-num = <1>;       pad-wakeup = <81 4 1>; }; In the line pad-wakeup-num = <1>; , the number "1" corresponds to the number of pads that you want to add. The line pad-wakeup = <81 4 1>; has three parameters: The first parameter corresponds to the "pin_id", you can find it in include/dt-bindings/pinctrl/pads-imx8qm.h , in this example we are using "IMX8QM_MIPI_CSI1_I2C0_SDA". The second parameter corresponds to the "'type'", you can find it in the i.MX 8QuadMax Applications Processor Reference Manual, in the page 802:   wakeup_crt.PNG For this example we are using "LOW". The third parameter corresponds to the "line", the number of bit in 32bit gpio group, you can find it in include/dt-bindings/pinctrl/pads-imx8qm.h In this example, "IMX8QM_MIPI_CSI1_I2C0_SDA" belongs to gpio group 2, line 1. Build the device tree.   Setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8qm-mek.dtb Copy the .dtb file to the MEK CPU Board, for example with scp: scp imx8qm-mek.dtb root@<MEK_CPU_Board_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. On the MEK CPU Board.   Switching the device tree.   To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8qm-mek.dtb Partition_1/ Reboot the board. reboot How to wake up the i.MX 8QuadMax MEK CPU Board.   In this example a wire was soldered on "R204":   2041.PNG 2042.PNG   Run the following command on the MEK CPU Board: echo mem > /sys/power/state And you will see something like: [   53.769266] PM: suspend entry (deep) [   53.902130] Filesystems sync: 0.129 seconds [   53.908068] Freezing user space processes ... (elapsed 0.002 seconds) done. [   53.917189] OOM killer disabled. [   53.920420] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [   53.929626] printk: Suspending console(s) (use no_console_suspend to debug) Connect the wire that was soldered on "R204" to ground, the MEK CPU Board will wake up and you will see something like: [   54.687125] fec 5b040000.ethernet eth0: Link is Down [   54.689876] PM: suspend devices took 0.756 seconds [   54.709570] Disabling non-boot CPUs ... [   54.710562] CPU1: shutdown [   54.711582] psci: CPU1 killed (polled 0 ms) [   54.714360] CPU2: shutdown [   54.715376] psci: CPU2 killed (polled 0 ms) [   54.717365] CPU3: shutdown [   54.718382] psci: CPU3 killed (polled 0 ms) [   54.719887] CPU4: shutdown [   54.720884] psci: CPU4 killed (polled 4 ms) [   54.722213] CPU5: shutdown [   54.723229] psci: CPU5 killed (polled 0 ms) [   54.724731] Enabling non-boot CPUs ... [   54.725388] Detected VIPT I-cache on CPU1 [   54.725423] GICv3: CPU1: found redistributor 1 region 0:0x0000000051b20000 [   54.725486] CPU1: Booted secondary processor 0x0000000001 [0x410fd034] [   54.726455] CPU1 is up [   54.726930] Detected VIPT I-cache on CPU2 [   54.726947] GICv3: CPU2: found redistributor 2 region 0:0x0000000051b40000 [   54.726976] CPU2: Booted secondary processor 0x0000000002 [0x410fd034] [   54.727478] CPU2 is up [   54.727955] Detected VIPT I-cache on CPU3 [   54.727971] GICv3: CPU3: found redistributor 3 region 0:0x0000000051b60000 [   54.728001] CPU3: Booted secondary processor 0x0000000003 [0x410fd034] [   54.728497] CPU3 is up [   54.729806] Detected PIPT I-cache on CPU4 [   54.729825] GICv3: CPU4: found redistributor 100 region 0:0x0000000051b80000 [   54.729857] CPU4: Booted secondary processor 0x0000000100 [0x410fd082] [   54.730490] CPU4 is up [   54.730985] Detected PIPT I-cache on CPU5 [   54.730999] GICv3: CPU5: found redistributor 101 region 0:0x0000000051ba0000 [   54.731021] CPU5: Booted secondary processor 0x0000000101 [0x410fd082] [   54.731679] CPU5 is up [   54.756440] hdmi_rx_hd_core_clk: failed to set clock parent -16 [   54.765828] gpio-mxc 5d0a0000.gpio: wakeup by pad, line 1 [   54.844242] ahci-imx 5f020000.sata: external osc is used. [   54.913582] caam 31400000.crypto: registering rng-caam [   54.918358] PM: resume devices took 0.148 seconds [   55.096663] OOM killer enabled. [   55.099814] Restarting tasks ... done. [   55.111833] PM: suspend exit  
View full article
     The following steps allow you to build a bootable image in two different ways and also how to enable and use SCFW debug monitor. There are four files needed to generate a bootable image: ├── bl31.bin ├── u-boot.bin   ├── mx8qm-ahab-container.img     └── scfw_tcm.bin There are some ways to get the four files, one way is with Yocto and other way is with stand alone build. Get the four files needed to generate a bootable image with Yocto.   To get the four files needed with Yocto, you have to build an i.MX 8QuadMax image, maybe some steps are not necessary. 1.-Host packages. sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa \ libsdl1.2-dev pylint3 xterm rsync curl 2.-Setting up the Repo utility. mkdir ~/bin (this step may not be needed if the bin folder already exists) curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo export PATH=~/bin:$PATH 3.-Yocto Project Setup. git config --global user.name "Your Name" git config --global user.email "Your Email" git config --list mkdir imx-yocto-bsp cd imx-yocto-bsp repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-hardknott -m imx-5.10.72-2.2.0.xml repo sync 4.-Build configurations. DISTRO=fsl-imx-xwayland MACHINE=imx8qmmek source imx-setup-release.sh -b imx8qmmek 5.-Building an image. bitbake imx-image-full The four files needed to generate a bootable image are in: ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools Note: With Yocto you can not enable the SCFW debug monitor. For more information see the i.MX Yocto Project User's Guide. Get the four files needed to generate a bootable image with stand alone build.   To build all required binaries from source you can use standard aarch64 Linux toolchain, on Ubuntu 20.04 LTS: sudo apt-get install gcc-aarch64-linux-gnu Get the bl31.bin file - Arm Trust Firmware.   Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/imx-atf Build: cd imx-atf make clean PLAT=imx8qm CROSS_COMPILE=aarch64-linux-gnu- make PLAT=imx8qm CROSS_COMPILE=aarch64-linux-gnu- bl31 The compiled bl31.bin location: build/imx8qm/release/bl31.bin Get the u-boot.bin file - u-boot.   Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/uboot-imx Build: cd uboot-imx make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx8qm_mek_defconfig make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- The compiled u-boot.bin location: ./u-boot.bin Get the mx8qmb0-ahab-container.img file - iMX Seco. wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-3.7.4.bin chmod +x imx-seco-3.7.4.bin ./imx-seco-3.7.4.bin --auto-accept The mx8qmb0-ahab-container.img file location: imx-seco-3.7.4/firmware/seco/mx8qmb0-ahab-container.img Get the scfw_tcm.bin file - SCFW.   Download and Install a GNU Toolchain.   Look at the packages/imx-scfw-porting-kit-1.7.4/doc/pdf/ , chapter Porting Guide, sub-chapter Tool Chain to check which GNU Toolchain version corresponds to the SCFW you are building. The imx-scfw-porting-kit-1.7.4 version uses the GNU Toolchain version gcc-arm-none-eabi-8-2018-q4-major . It is recommended to install toolchain in “opt” folder: cd /opt sudo wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 sudo tar xjf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 Download and Install a Arm GCC toolchain. It is recommended to install toolchain in “opt” folder: sudo wget https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz sudo tar -Jxvf gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz After installing the toolchain, set up the environment variable relevant for building. export ARCH=arm CROSS_COMPILE=/opt/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- export TOOLS=/opt Build the scfw_tcm.bin file. cd ~ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-scfw-porting-kit-1.7.4.bin chmod +x imx-scfw-porting-kit-1.7.4.bin ./imx-scfw-porting-kit-1.7.4.bin --auto-accept cd imx-scfw-porting-kit-1.7.4/src Extract the desired scfw porting kit: tar -xvf scfw_export_mx8qm_b0.tar.gz cd scfw_export_mx8qm_b0/ Build without debug monitor: make clean make qm B=mek R=B0 Build with debug monitor: make clean make qm B=mek D=1 M=1 R=B0 DDR_CON=imx8qm_dcd_1.6GHz The scfw_tcm.bin file location: build_mx8qm_b0/scfw_tcm.bin   Generate the bootable image.   Once you have the four files needed to generate a bootable image, use imx-mkimage tool. Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/imx-mkimage Copy the four binaries to iMX8QM folder. You have to rename some files. If you got the four binaries with Yocto. cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/bl31-imx8qm.bin ~/imx-mkimage/iMX8QM/bl31.bin cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/u-boot-imx8qmmek.bin-sd ~/imx-mkimage/iMX8QM/u-boot.bin cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/mx8qmb0-ahab-container.img ~/imx-mkimage/iMX8QM cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/mx8qm-mek-scfw-tcm.bin ~/imx-mkimage/iMX8QM/scfw_tcm.bin If you got the four binaries with stand alone build. cp ~/imx-atf/build/imx8qm/release/bl31.bin ~/imx-mkimage/iMX8QM cp ~/uboot-imx/u-boot.bin ~/imx-mkimage/iMX8QM cp ~/imx-seco-3.7.4/firmware/seco/mx8qmb0-ahab-container.img ~/imx-mkimage/iMX8QM cp ~/imx-scfw-porting-kit-1.7.4/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ~/imx-mkimage/iMX8QM Build the bootable image. cd ~/imx-mkimage make SOC=iMX8QM flash The compiled file is flash.bin and its location is: iMX8QM/flash.bin   Flash the bootable image.   To flash the bootable image follow the next steps: -Copy the flash.bin and uuu.exe in a folder. -Change SW2 on the base board to 000100 (from MSB to LSB, 1-ON and 0-OFF) to boot from the Serial Downloader. -Run the following command in Command Prompt: uuu.exe -b sd flash.bin -Power on the MEK CPU board.   SCFW debug monitor.        If the SCFW is compiled using the M=1 option (default is M=0) then it will include a debug monitor. This can be used to R/W memory or registers, R/W power state, and dump some resource manager state. Production SCFW should never have the monitor enabled (M=0, the default)!      The debug monitor allows command-line interaction via the SCU UART. Inclusion of the debug monitor affects SCFW timing and therefore should never be deployed in a product! Note the terminal needs to be in a mode that sends CR or LF for a new line (not CR+LF). The following commands are supported: Command                                   Description exit                                              exit the debug monitor quit                                              exit the debug monitor reset [mode]                                request reset with mode (default = board) reboot partition [type]                  request partition reboot with type (default = cold) md.b address [count]                  display count bytes at address md.w address [count]                 display count words at address md[.l] address [count]                 display count long-words at address mm.b address value                   modify byte at address mm.w address value                  modify word at address mm[.l] address value                  modify long-word at address ai.r ss sel addr                            read analog interface (AI) register ai.w ss sel addr data                  write analog interface (AI) register fuse.r word                                 read OTP fuse word fuse.w word value                      write value to OTP fuse word dump rm                                    dump all the resource manager (RM) info dump rm part [part]                    dump all partition info for part (default = all) dump rm rsrc [part]                    dump all resource info for part (default = all) dump rm mem [part]                  dump all memory info for part (default = all) dump rm pad [part]                    dump all pad info for part (default = all) power.r [resource]                     read/get power mode of resource (default = all) power.w resource mode            write/set power mode of resource to mode (off, stby, lp, on) info                                             display SCFW/SoC info like unique ID, etc. seco lifecycle change                send SECO lifecycle update command (change) to SECO seco info                                    display SECO info like Lifecycle, SNVS state, etc. seco debug                                dump SECO debug log seco events                               dump SECO event log seco commit                              commit SRK and/or SECO FW version update pmic.r id reg                               read pmic register pmic.w id reg val                        write pmic register pmic.l id                                      list pmic info (rail voltages, etc) Resource and subsystem (ss) arguments are specified by name. All numeric arguments are decimal unless prefixed with 0x (for hex) or 0 (for octal). Testing SCFW debug monitor to display count long-words at address on Linux side and on SCU side. -Change SW2 on the base board to 001100 (from MSB to LSB, 1-ON and 0-OFF) to boot from the SD card. -Power on the MEK CPU board. -Open Tera Term and you will see: Hello from SCU (Build 5263, Commit 9b3d006e, Aug 20 2021 12:20:10) ​ DDR frequency = 1596000000  ROM boot time = 262368 usec      Boot time = 24583 usec         Banner = 10 usec           Init = 9038 usec         Config = 3232 usec            DDR = 2677 usec        SConfig = 444 usec           Prep = 5039 usec ​ *** Debug Monitor *** ​ >$ -Run the following commands: power.r power.w db on power.w dblogic on power.w mu_1a on -Example reading on Linux side: md.l 0x5d1c0000 10 -You will see: >$ md.l 0x5d1c0000 10 5d1c0000: 00000000 00000000 00000000 00000000 5d1c0010: 00010201 23c34600 d63fdb21 00000000 5d1c0020: 00f00200 18000000 -Example reading on SCU side: md.l 0x41cac080 10 -You will see: >$ md.l 0x41cac080 10 41cac080: 00000000 00000000 00000000 00000000 41cac090: 0d070201 ff0001f1 ffff8000 ffff00fb 41cac0a0: 00f00000 18000000 For more information see the System Controller Firmware Porting Guide.
View full article
         Some customer enable AHAB function on i.MX8X board to realize security boot. So they have fused hab_closed bit on the board. While they want to change DDR type on this board so need to do DDR stress test. While If using NXP official released DDR stress test, it failed to run on such hab_closed board.         This article describe how to run command line version DDR stress test on such hab_closed board.        Thanks!
View full article
We will build a remote debug environmet of Qt Creator in this user guide.   Contents 1 Change local.conf file in Yocto 2 2 Build and deploy Yocto SDK 2 2.1 Build full image SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Deploy SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Configure QT Kit 2 3.1 Setup device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2 Configure QT version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3 Configure gcc and g++ manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Configure gdb manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Configure Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6 Very important thing!! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Test result
View full article
In some cases, such as OTA, need a complete reset/reboot of the i.MX8/i.MX8X. Current BSP default design for  i.MX8/i.MX8X is partition reset/reboot. So even using spl bootloader(flash.bin). The scfw is still running old version. Not the upgrade version as expected. Because the reset/reboot by the u-boot or Linux, Only reset/reboot the A Core partition. SCU is not reset. Need to change to the board reset, which will launch entire reset/reboot of the i.MX8/i.MX8X including SCU.
View full article
Case Description There is requirement need to control(enable/disable) regulator from user space. Regulator userspace-consumer driver can help. But it doesn’t support device tree. A patch for handling device tree is needed. linux/drivers/regulator/userspace-consumer.c    
View full article
This article introduces how to connect a device via Bluetooth to the i.MX8M family of boards.
View full article
Hello everyone, this document will explain on how to create and run a custom script for UUU (Universal Update Utility) tool Requirements: I.MX 8M Mini EVK Linux Binary Demo Files - i.MX 8MMini EVK (L5.10.35) UUU Serial console emulator (tera term or putty) Text editor (Notepad++, nano, etc) UUU is a pretty flexible tool since it uses the Fastboot protocol through uboot to flash the desired images, this will make possible to create a custom script to add many uboot commands to customize further the boot settings. In this example I will create a custom script which will flash uboot and Linux rootfs and write a Cortex-M binary to the FAT partition of the eMMC. At the same time I’ll create and modify a set of environmental variables, this variables will have a set of uboot commands that will load to the TCM this same binary before the device starts booting into Linux.   Creating the script For this document I'll be using Notepad++ but any text editor may be used instead, since the scripts used by UUU are written in plain text. The very first line of the script must be the version number which will represent the minimum UUU version that UUU can parse this script. For this case that version is 1.2.39 After it, we will add all standard commands to flash uboot and filesystem into the eMMC. flashemmc.JPG Note: This may be also copied from the uuu.auto script inside the Demo files. Please note that the UUU commands format is PROTOCOL: CMD, for this example we will be using mainly SDP and FB protocols which corresponds to the serial download protocol and Fastboot respectively. For a list of all supported UUU protocols and commands please refer to the UUU documentation here: https://github.com/NXPmicro/mfgtools/releases/download/uuu_1.4.165/UUU.pdf Now add the following commands to the script, this will download and write into eMMC FAT partition, which was created when flashing the .wic image, the Cortex-M binary.   FB: ucmd setenv fastboot_buffer ${loadaddr} FB: download -f hello_world_test.bin FB[-t 20000]: ucmd fatwrite mmc ${emmc_dev}:1 ${fastboot_buffer} hello_world_test.bin ${fastboot_bytes}   #fatwrite write file into a dos filesystem "<interface> <dev[:part]> <addr> <filename> [<bytes> [<offset>]] - write file 'filename' from the address 'addr' in RAM  to 'dev' on 'interface' Note: The Cortex-M binary was named as hello_world_test.bin, but any example name may be used. At this point, in the script we will be using only uboot commands as seen above, in this case was fatwrite. The script will look as following: writteFAT.JPG If the script is run now uboot (imx-boot-imx8mmevk-sd.bin-flash_evk), rootfs (imx-image-multimedia-imx8mmevk.wic) will be flashed and the Cortex-M binary (hello_world_test.bin) written to the FAT partition of the eMMC. To add environmental variables to modify uboot boot settings, i.e. overwrite the dtb variable so the EVK will select the RPMSG dtb, this in case the Cortex-M example needs to be run at the same time as Cortex-A. FB: ucmd setenv fdtfile imx8mm-evk-rpmsg.dtb Next add to the UUU script the set of uboot commands in form of environmental variables that will load to the TCM the Cortex-M binary   FB: ucmd setenv loadm4image "fatload mmc ${emmc_dev}:1 0x48000000 hello_world_test.bin; cp.b 0x48000000 0x7e0000 0x20000" FB: ucmd setenv m4boot "run loadm4image; bootaux 0x48000000" Note: This can be changed to load it to different targets not only TCM, for example DRAM. Now for the set of environmental variable to run when uboot starts booting into Linux we may add it to the variable mmcboot. Also adding the command to save the environmental variables set so the settings persist after reboot, this by adding the following commands to the script:   FB: ucmd setenv mmcboot "run m4boot; $mmcboot" FB: ucmd saveenv The resulting script will be the following: finalscript.JPG Now just save the script and name it as you see fit, for this example the name will be custom_script.auto.   Running the script To run a UUU script is pretty simple, just make sure that the files used in the script are in the same folder as the script. Windows > .\uuu.exe  custom_script.auto Linux $ sudo ./uuu custom_script.auto   test1.JPG test2.JPG Wait till it finish, turn the board off, set it to boot from eMMC and turn it on, the EVK will boot into Linux automatically and will launch the Cortex-M core automatically. We may also, double check that the environmental variables were written correctly by stopping at uboot and using the printenv command test3.JPG For this test I have used the Prebuilt image which includes sample Cortex-M4 examples for the EVK   further flexibility UUU scripts can be customized even more, for example using macros, so the script can take input arguments so it may be possible to select the uboot, rootfs, Cortex-M binary and dtb to be used when booting, and to be used for other i.MX chips as well. The resulting script will be as following: flexiblescript.JPG Note: Here is assumed that the dtb file is already at the FAT partition, if not same procedure may be added as the Cortex-M binary. To run a script which expect to have input arguments is as follow: Windows > .\uuu.exe -b uuu_cortexM_loader.auto imx-boot-imx8mmevk-sd.bin-flash_evk imx-image-multimedia-imx8mmevk.wic hello_world_test.bin imx8mm-evk-rpmsg.dtb Linux $ sudo ./uuu -b uuu_cortexM_loader.auto imx-boot-imx8mmevk-sd.bin-flash_evk imx-image-multimedia-imx8mmevk.wic hello_world_test.bin imx8mm-evk-rpmsg.dtb Please find both UUU scripts attached and feel free to use them. Hope this helps everyone to better understand how this tool works and the capabilities it have.
View full article