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:
On behalf of Gopise Yuan. This is an update for the DRM framebuffer capture tool I used to share with the team. Some enhancement added. Might be useful for debugging some display related issues.   Some special notes: Behavior of DRM subsystem is different between L4.x and L5.x. For L4.x, you can capture the RGB buffer without any problem. But, there’s no API for YUV (multi-plane) buffer. To capture YUV, need to apply “kernel_0001-drm-Add-getfb2-ioctl_L4.14.98.patch”. For L5.x, mapping/capturing the internal buffer is not allowed by default due to security reason. A simple change in “0001-drm-enable-mapping-of-internal-object-for-debugging_L5.x.patch” can disable this guard. Capture raw data only. RGB and YUV (packed/planar, 420/422) supported. Support de-tile on “Amphion tile” (VPU, NV12 only) and “Super tile” (Vivante GPU). Please use “-t” to enable this. Other tile might not be supported. This is a static linked binary. You can run it on any ARM64 based Linux/Android system in theory (prerequisites in item #1). If you need source code, come to me.   To get more details on how to use it, use “-?” option: DRM screen capture DRM based screen capture program Usage:     ./drmfbcap [OP] [ARG] [OP] OPeration (optional):     -v Show version.     -? Show help information.     -i Show information about target DRM device only (no capture).     -t Perform de-tile for tile format.     -d DRM device to open. [ARG] should contain the path to the device node. Default: '/dev/dri/card0'     -o Output folder. [ARG] should contain the path to the output folder. Default: '.'     -p Specific plane # to capture. [ARG] should contain the plane number. If no '-p' specified, capture all planes   Example:     ./drmfbcap   Capture all planes on default DRM device.     ./drmfbcap -d /dev/dri/controlD64   Capture all planes on '/dev/dri/controlD64' device.     ./drmfbcap -p 44 -t -o /sdcard   Capture plane 44, do de-tile after capture and then output to /sdcard/.   Raw buffer capture will be done for each enabled/target plane and one file for each. Captured file will be saved to './' if not specified. --- By Gopise, 2022/08   Updated_2023_10_16: continuous capture (repeat mode) support with this link: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/DRM-screen-capture-tool/ta-p/1725363
View full article
  Background PCIe interface of Android 12 prebuilt and Built image on iMX8MM mini is not coming up. The Android BSP doesn't enable the pcie driver. Solution 1. imx8mm_gki.fragment CONFIG_PHY_FSL_IMX_PCIE=m CONFIG_PCI_IMX6=m 2. device/nxp/imx8m/evk_8mm/SharedBoardConfig.mk $(KERNEL_OUT)/drivers/pci/controller/dwc/pci-imx6.ko \ Result evk_8mm:/ # dmesg | grep pci [ 0.561609] ehci-pci: EHCI PCI platform driver [ 6.515345] imx6q-pcie 33800000.pcie: supply epdev_on not found, using dummy regulator [ 6.524925] imx6q-pcie 33800000.pcie: EXT REF_CLK is used!. [ 6.560211] imx6q-pcie 33800000.pcie: PCIe PLL locked after 20 us. [ 6.567328] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges: [ 6.584463] imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000 [ 6.593833] imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000 [ 6.603140] imx6q-pcie 33800000.pcie: invalid resource [ 6.708123] imx6q-pcie 33800000.pcie: Link up [ 6.713393] imx6q-pcie 33800000.pcie: Link up [ 6.718586] imx6q-pcie 33800000.pcie: Link up, Gen1 [ 6.832372] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00 [ 6.840023] pci_bus 0000:00: root bus resource [bus 00-ff] [ 6.846535] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] [ 6.853805] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff] [ 6.861601] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400 [ 6.868529] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff] [ 6.876439] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref] [ 6.884101] pci 0000:00:00.0: supports D1 [ 6.888954] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold [ 6.899174] pci 0000:01:00.0: [1b4b:2b42] type 00 class 0x020000 [ 6.906127] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x000fffff 64bit pref] [ 6.914221] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x000fffff 64bit pref] [ 6.922740] pci 0000:01:00.0: supports D1 D2 [ 6.927854] pci 0000:01:00.0: PME# supported from D0 D1 D3hot D3cold [ 6.935200] pci 0000:01:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0000:00:00.0 (capable of 4.000 Gb/s with 5.0 GT/s PCIe x1 link) [ 6.962608] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff] [ 6.970251] pci 0000:00:00.0: BAR 15: assigned [mem 0x18100000-0x182fffff pref] [ 6.978426] pci 0000:00:00.0: BAR 6: assigned [mem 0x18300000-0x1830ffff pref] [ 6.986479] pci 0000:01:00.0: BAR 0: assigned [mem 0x18100000-0x181fffff 64bit pref] [ 7.001517] pci 0000:01:00.0: BAR 2: assigned [mem 0x18200000-0x182fffff 64bit pref] [ 7.010203] pci 0000:00:00.0: PCI bridge to [bus 01-ff] [ 7.016271] pci 0000:00:00.0: bridge window [mem 0x18100000-0x182fffff pref] [ 7.025830] pcieport 0000:00:00.0: PME: Signaling with IRQ 238 [ 7.033786] pcieport 0000:00:00.0: AER: enabled with IRQ 238  
View full article
On behalf of Gopise Yuan. A collection of several GST debugging tips and known-how. When you need to play onto a DRM layer/plane directly without going through compositor, kmssink should be a good choice: // kmssink, with scale and adjust alpha property (opaque) and zpos (this requires kmssink>=1.16): gst-launch-1.0 filesrc location=/media/AVC-AAC-720P-3M_Alan.mov ! decodebin ! imxvideoconvert_g2d ! kmssink plane-id=37 render-rectangle="<100,100,720,480>" can-scale=false plane-properties=s,alpha=65535,zpos=2 When using playbin, you can still customize the pipeline besides the sink plugin, e.g. add a converter plugin: // Playbin with additional customization on converter before sink: gst-launch-1.0 playbin uri=file:///mnt/MP4_H264_AAC_1920x1080.mp4 video-sink="imxvideoconvert_g2d ! video/x-raw,format=BGRA,width=1920,height=1080 ! kmssink plane-id=44" GST can generate a pipeline graph for analyzing the pipeline in a intuitive manner: // Generate pipeline graph: 1. Export GST_DEBUG_DUMP_DOT_DIR=<dump-folder>, GST_DEBUG=4 2. Run pipeline with gst-launch or others. 3. Copy all dump files (.dot) from <dump-folder>. Note: one dump file will be created for each state transaction. Normally, what we need will be PAUSE_READY or READY_PAUSE, after which pipeline has been setup. 4. Convert the .dot file to PDF with Graphviz: dot -Tpdf 0.00.03.685443250-gst-launch.PAUSED_READY.dot > pipeline_PAUSED_READY.pdf  
View full article
This is a simple known-how for how to enable KASAN on L4.14.98 with i.MX8/8X and also a collection of related patches for fixing issues reported by KASAN.   Enable KASAN: It's very simple, just enable "CONFIG_KASAN" in kernel configuration. Besides this, adjusting the kernel's loading address is also required, due to KASAN (which will alloc more memory as a "tracker" for each allocation). For e.g., on imx8qxp MEK, we need to change the kernel loadaddr in uboot:     0x80280000 --> 0xE0280000 through uboot env: setenv loadaddr 0xE0280000 After this, it supposed to be working.   KASAN related patches on L4.14.98: KASAN will do detection/sanitizing for any memory allocation/access. In case of L4.14.98 on i.MX8/8X, there're several "BUG" reported by KASAN in default BSP. The attached patches are a collection for these issues.    Note: not all "BUG" reported by KASAN are really bug. Most of them are just some programming rule related problems and may not really cause memory access violation.
View full article
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 Background   The function lpddr4_mr_read in BSP always return zero and this casue the customer can't use it to read MR registers in DRAM. This is a simple demo for reading MR registers. Patch Code   diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h b/arch/arm/include/asm/arch-imx8m/ddr.h index 0f1e832c03..fd68996a23 100644 --- a/arch/arm/include/asm/arch-imx8m/ddr.h +++ b/arch/arm/include/asm/arch-imx8m/ddr.h @@ -721,6 +721,8 @@ int wait_ddrphy_training_complete(void); void ddrphy_init_set_dfi_clk(unsigned int drate); void ddrphy_init_read_msg_block(enum fw_type type); +unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr); + void update_umctl2_rank_space_setting(unsigned int pstat_num); void get_trained_CDD(unsigned int fsp); diff --git a/board/freescale/imx8mp_evk/spl.c b/board/freescale/imx8mp_evk/spl.c index 33bbbc09ac..85e40ffbbe 100644 --- a/board/freescale/imx8mp_evk/spl.c +++ b/board/freescale/imx8mp_evk/spl.c @@ -150,6 +150,40 @@ int board_fit_config_name_match(const char *name) return 0; } #endif +void lpddr4_get_info() +{ + int i = 0, attempts = 5; + + unsigned int ddr_info = 0; + unsigned int regs[] = { 5, 6, 7, 8 }; + + for(i = 0; i < ARRAY_SIZE(regs); i++){ + unsigned int data = 0; + data = lpddr4_mr_read(0xF,regs[i]); + ddr_info <<= 8; + ddr_info += (data & 0xFF); + switch (i) + { + case 0: + printf("DRAM INFO : Manufacturer ID = 0x%x",ddr_info); + if(ddr_info & 0Xff) + printf(", Micron\n"); + break; + case 1: + printf("DRAM INFO : Revision ID1 = 0x%x\n",ddr_info); + break; + case 2: + printf("DRAM INFO : Revision ID2 = 0x%x\n",ddr_info); + break; + case 3: + printf("DRAM INFO : I/O Width and Density = 0x%x\n",ddr_info); + break; + default: + break; + } + } + +} void board_init_f(ulong dummy) { @@ -187,6 +221,8 @@ void board_init_f(ulong dummy) /* DDR initialization */ spl_dram_init(); + + lpddr4_get_info(); board_init_r(NULL, 0); } diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index 326b92d784..f45eeaf552 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -194,8 +194,15 @@ unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr) tmp = reg32_read(DRC_PERF_MON_MRR0_DAT(0)); } while ((tmp & 0x8) == 0); tmp = reg32_read(DRC_PERF_MON_MRR1_DAT(0)); - tmp = tmp & 0xff; reg32_write(DRC_PERF_MON_MRR0_DAT(0), 0x4); + + while (tmp) { //try to find a significant byte in the word + if (tmp & 0xff) { + tmp &= 0xff; + break; + } + tmp >>= 8; + } return tmp; }     Test Result  
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.  Checked L4.14.98_2.3.0 and found it added internal PLL for PCIe clock support. Solution The attached patch based on 4.14.98 can’t be used directly on 5.10.52, the following is the main modification for PLLOUT of PCIe clock. PLLOUT Monitor Configuration Register contains bits to control the clock that will be generated on the CCM clock mapped to CLK2_P/N.        
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. 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:   For this example we are using "LOW". The third parameter corresponds to the "line", the number of bit in 32bit gpio group, you can find it in include/dt-bindings/pinctrl/pads-imx8qm.h In this example, "IMX8QM_MIPI_CSI1_I2C0_SDA" belongs to gpio group 2, line 1. Build the device tree.   Setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8qm-mek.dtb Copy the .dtb file to the MEK CPU Board, for example with scp: scp imx8qm-mek.dtb root@<MEK_CPU_Board_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. On the MEK CPU Board.   Switching the device tree.   To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8qm-mek.dtb Partition_1/ Reboot the board. reboot How to wake up the i.MX 8QuadMax MEK CPU Board.   In this example a wire was soldered on "R204":     Run the following command on the MEK CPU Board: echo mem > /sys/power/state And you will see something like: [   53.769266] PM: suspend entry (deep) [   53.902130] Filesystems sync: 0.129 seconds [   53.908068] Freezing user space processes ... (elapsed 0.002 seconds) done. [   53.917189] OOM killer disabled. [   53.920420] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [   53.929626] printk: Suspending console(s) (use no_console_suspend to debug) Connect the wire that was soldered on "R204" to ground, the MEK CPU Board will wake up and you will see something like: [   54.687125] fec 5b040000.ethernet eth0: Link is Down [   54.689876] PM: suspend devices took 0.756 seconds [   54.709570] Disabling non-boot CPUs ... [   54.710562] CPU1: shutdown [   54.711582] psci: CPU1 killed (polled 0 ms) [   54.714360] CPU2: shutdown [   54.715376] psci: CPU2 killed (polled 0 ms) [   54.717365] CPU3: shutdown [   54.718382] psci: CPU3 killed (polled 0 ms) [   54.719887] CPU4: shutdown [   54.720884] psci: CPU4 killed (polled 4 ms) [   54.722213] CPU5: shutdown [   54.723229] psci: CPU5 killed (polled 0 ms) [   54.724731] Enabling non-boot CPUs ... [   54.725388] Detected VIPT I-cache on CPU1 [   54.725423] GICv3: CPU1: found redistributor 1 region 0:0x0000000051b20000 [   54.725486] CPU1: Booted secondary processor 0x0000000001 [0x410fd034] [   54.726455] CPU1 is up [   54.726930] Detected VIPT I-cache on CPU2 [   54.726947] GICv3: CPU2: found redistributor 2 region 0:0x0000000051b40000 [   54.726976] CPU2: Booted secondary processor 0x0000000002 [0x410fd034] [   54.727478] CPU2 is up [   54.727955] Detected VIPT I-cache on CPU3 [   54.727971] GICv3: CPU3: found redistributor 3 region 0:0x0000000051b60000 [   54.728001] CPU3: Booted secondary processor 0x0000000003 [0x410fd034] [   54.728497] CPU3 is up [   54.729806] Detected PIPT I-cache on CPU4 [   54.729825] GICv3: CPU4: found redistributor 100 region 0:0x0000000051b80000 [   54.729857] CPU4: Booted secondary processor 0x0000000100 [0x410fd082] [   54.730490] CPU4 is up [   54.730985] Detected PIPT I-cache on CPU5 [   54.730999] GICv3: CPU5: found redistributor 101 region 0:0x0000000051ba0000 [   54.731021] CPU5: Booted secondary processor 0x0000000101 [0x410fd082] [   54.731679] CPU5 is up [   54.756440] hdmi_rx_hd_core_clk: failed to set clock parent -16 [   54.765828] gpio-mxc 5d0a0000.gpio: wakeup by pad, line 1 [   54.844242] ahci-imx 5f020000.sata: external osc is used. [   54.913582] caam 31400000.crypto: registering rng-caam [   54.918358] PM: resume devices took 0.148 seconds [   55.096663] OOM killer enabled. [   55.099814] Restarting tasks ... done. [   55.111833] PM: suspend exit  
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
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
Following OTA in Android User Guide would have HASH verification error: update_engine: [0913/085233.421711:ERROR:delta_performer.cc(1140)] Expected: sha256|hex = 685B998E4308F20FEA83D97E60222121FFE27983F013AED5C203709E139AE9DB update_engine: [0913/085233.421760:ERROR:delta_performer.cc(1143)] Calculated: sha256|hex = B1025634138BF2B5378196E364350E1E5FCA126DEE0990A592290CEBFADC3F8B The OTA process that produced the error: * After compiling the images according to the user guide, burn the images in the /out directory into the board * Then build the first target file according to 7.1.1 Building target files, such as PREVIOUS-target_files.zip * Modify part of the code to build the second target file, such as NEW-target_files.zip: * Make a differential upgrade package and perform differential OTA The root cause of the error caused by the above steps: Differential OTA requires that the onboard system.img must be the system.img generated when the target files are created for the first time. Only in this way can the correct hash value be calculated. When we execute the following command to make target files make target-files-package -j4 Will repackage a copy of system.img in the /out directory and this system.img does not meet the requirements. The system.img used by the differential package must be system.img in out/target/product/evk_8mm/obj/PACKAGING/systemimage_intermediates/. Therefore, the system.img we burned in the first step did not meet the requirements, resulting in hash verification errors. Solution 1: After the first step of programming, do a full update. When using the make otapackage -j4 command, a target_files.zip file will also be generated, which we will regard as PREVIOUS-target_files.zip. Modify part of the code and make NEW-target_files.zip. Finally, the differential upgrade can be successful. Solution 2: After finishing the first target_files.zip, copy the system.img in out/target/product/evk_8mm/obj/PACKAGING/systemimage_intermediates/ to the out/target/product/evk_8mm directory, and then use uuu Perform programming. After burning and writing, make the second target_files.zip, and finally you can upgrade by differential.
View full article