i.MX Processors Knowledge Base

Discussions

iMX6DQ TP2854 MIPI CSI2 720P HD-TVI camera surround view solution for Linux BSP. For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time. The attached patch can make the BSP support up to 4 cameras based on 3.14.52 GA 1.1.0 BSP and 4.1.15 GA1.2.0 BSP. The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel. In this patch, we given the example driver for Techpoint TP2854, it was verified working on iMX6DQ SabreAuto board. The input to TP2854 is four 720P30 HD-TVI cameras. The MIPI CSI2 720P digital camera surround view solution can be found at: iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP The kernel patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch Updated IPU common code to support up to four cameras. 0002-Remove-the-page-size-align-requirement-for-v4l2-capt.patch With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly. 0003-Add-TP2854-support-on-SabreAuto-board-which-can-supp.patch TP2854 driver. How to builld the kernel with TP2854 support: make imx_v7_defconfig make menuconfig (In this command, you should select the TP2854 driver: Device Drivers ---> <*> Multimedia support ---> [*] V4L platform devices ---> <*> MXC Video For Linux Video Capture MXC Camera/V4L2 PRP Features support ---> <*>Techpoint tp2854 HD CVBS Input support <*>mxc VADC support <*>Select Overlay Rounting (Queue ipu device for overlay library) <*>Pre-processor Encoder library <*>IPU CSI Encoder library) make zImage make dtbs The built out image file: arch/arm/boot/dts/imx6q-sabreauto.dtb arch/arm/boot/zImage "mxc_v4l2_tvin_3.14.52.zip" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d & Details for TP2854, please contact with Techpoint. [2019-04-04] Update Add application to preview + encode at the same time: /mxc_vpu_test.out -E "-x 0 -o /enc.h264 -w 1280 -h 720 -L 0 -T 0 -W 512 -H 384 -c 5000 -f 2" The camera input data go through CSI->MEM path, and IDMAC 0/1 will convert data from YUV422 ro NV12 for VPU encoder, no resize. Another modification in the mxc_vpu_test, it use different thread to encode and preview.

KSZ9031 is a very common PHY used with many ethernet design. This document will show you how to add it in u-boot and kernel. 1. Schematic The MODE[3:0] strap-in pins are sampled and latched at power-up/reset. MODE[3:0]=1111 is RGMII mode - Advertise all capabilities (10/100/1000 speed half-/full-duplex) The PHY address, PHYAD[2:0], is sampled and latched at power-up/reset. Here PHY address is set to 001. In this design example, the ENET_RESET_B is connected to GPIO pin GPIO1_IO03. 2. Source code modification In u-boot source code, add the following code in the <board_name>.c file. - IOMUX setup for the GPIO1_IO03 pin. static iomux_v3_cfg_t const phy_reset_pads[] = { MX7D_PAD_GPIO1_IO03__GPIO1_IO3 | MUX_PAD_CTRL(NO_PAD_CTRL), }; - In the function setup_fec(int fec_id), add the code for phy reset. imx_iomux_v3_setup_multiple_pads(phy_reset_pads, ARRAY_SIZE(phy_reset_pads)); gpio_request(IMX_GPIO_NR(1, 3), "ENET PHY Reset"); gpio_direction_output(IMX_GPIO_NR(1, 3) , 0); mdelay(20); gpio_set_value(IMX_GPIO_NR(1, 3), 1); - There is a PHY config for the KSZ9031. int board_phy_config(struct phy_device *phydev) { /* * Default setting for GMII Clock Pad Skew Register 0x1EF: * MMD Address 0x2h, Register 0x8h * * GTX_CLK Pad Skew 0xF -> 0.9 nsec skew * RX_CLK Pad Skew 0xF -> 0.9 nsec skew * * Adjustment -> write 0x3FF: * GTX_CLK Pad Skew 0x1F -> 1.8 nsec skew * RX_CLK Pad Skew 0x1F -> 1.8 nsec skew * */ /* control data pad skew - devaddr = 0x02, register = 0x04 */ ksz9031_phy_extended_write(phydev, 0x02, MII_KSZ9031_EXT_RGMII_CTRL_SIG_SKEW, MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000); /* rx data pad skew - devaddr = 0x02, register = 0x05 */ ksz9031_phy_extended_write(phydev, 0x02, MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW, MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000); /* tx data pad skew - devaddr = 0x02, register = 0x05 */ ksz9031_phy_extended_write(phydev, 0x02, MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW, MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000); /* gtx and rx clock pad skew - devaddr = 0x02, register = 0x08 */ ksz9031_phy_extended_write(phydev, 0x02, MII_KSZ9031_EXT_RGMII_CLOCK_SKEW, MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x03FF); if (phydev->drv->config) phydev->drv->config(phydev); return 0; } The KSZ9031 driver (drivers/net/phy/micrel.c) had already supported in the u-boot source code. Add the following #define in the <board_name>.h file to enable the driver for building. #define CONFIG_PHY_MICREL As the PHY address on the board is 001, change the PHYADDR to 1 in the <board_name>.h file. #define CONFIG_FEC_MXC_PHYADDR 0x1 In the kernel source code, add/modify the PHY setting in dts file like this. &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1 &pinctrl_enet_reset>; assigned-clocks = <&clks IMX7D_ENET_PHY_REF_ROOT_SRC>, <&clks IMX7D_ENET_AXI_ROOT_SRC>, <&clks IMX7D_ENET1_TIME_ROOT_SRC>, <&clks IMX7D_ENET1_TIME_ROOT_CLK>, <&clks IMX7D_ENET_AXI_ROOT_CLK>; assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_25M_CLK>, <&clks IMX7D_PLL_ENET_MAIN_250M_CLK>, <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>; assigned-clock-rates = <0>, <0>, <0>, <100000000>, <250000000>; phy-mode = "rgmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio1 3 0>; fsl,magic-packet; status = "okay"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0: ethernet-phy@1 { //here '@1' is the PHY address compatible = "ethernet-phy-ieee802.3-c22"; reg = <1>; }; }; }; Add the GPIO pin for the ENET_RESET_B &iomuxc { ... ... pinctrl_enet_reset: enet_resetgrp { fsl,pins = < MX7D_PAD_GPIO1_IO03__GPIO1_IO3 0x14 //ENET_RESET_B >; }; } There is a PHY fixup in the arch/arm/mach-imx/<imx_cpu>.c Here is the example in mach-imx7d.c #define PHY_ID_KSZ9031 0x00221620 #define MICREL_PHY_ID_MASK 0x00fffff0 static void mmd_write_reg(struct phy_device *dev, int device, int reg, int val) { phy_write(dev, 0x0d, device); phy_write(dev, 0x0e, reg); phy_write(dev, 0x0d, (1 << 14) | device); phy_write(dev, 0x0e, val); } static int ksz9031rn_phy_fixup(struct phy_device *dev) { /* * min rx data delay, max rx/tx clock delay, * min rx/tx control delay */ mmd_write_reg(dev, -1, 0x4, 0); mmd_write_reg(dev, -1, 0x5, 0); mmd_write_reg(dev, -1, 0x6, 0); mmd_write_reg(dev, -1, 0x8, 0x003ff); return 0; } static void __init imx7d_enet_phy_init(void) { if (IS_BUILTIN(CONFIG_PHYLIB)) { phy_register_fixup_for_uid(PHY_ID_AR8031, 0xffffffff, ar8031_phy_fixup); phy_register_fixup_for_uid(PHY_ID_BCM54220, 0xffffffff, bcm54220_phy_fixup); phy_register_fixup_for_uid(PHY_ID_KSZ9031, MICREL_PHY_ID_MASK, ksz9031rn_phy_fixup); } } Now, the PHY is working on your board. Reference: 1. Create an Ubuntu VM environment to build Yocto BSP 2. i.MX Software | NXP

This document is aimed to introduce seamless switch on rear view camera function in android P9 auto, and this can also be referenced for sharing dpu(display process unit) between A core and m4 core on imx8qxp/qm platform. OS: Android p9 auto beta. (linux needs some modifies). SDK_2.5.1_MEK-MIMX8QX for m4 core. Hardware platform: imx8qxp/qm mek board IT6263 lvds to hdmi cable. max9286 deserializer board. ov16035 camera. Hardware block： Imx8qxp dpu block, for imx8qm there are two dpus: Android/Linux and M4 shared dpu path: The switch function is done by framegen0 unit in dpu, framegen unit can select 7 modes: primary src only second src only primary on second second on primary .....etc. for more details, please refer to the kernel codes at include/video/dpu.h, fgdm_t type. Seamless switch booting flow: Patches contain three main parts: Linux kernel: remove init or configure codes of dpu units and lvds used by m4 core, add ui ready rpmsg pipe. M4 code: modify dpu pipes, add ui ready rpmsg handle. AOSP init.rc scripts: add sending ui ready message scripts.

Brief introduction on the aarch64 linux kernel memory mapping layout and basic management stuffs. Contents include: Kernel's virtual memory layout and mapping after running i.MX8QM/QXP kernel reserved memory layout Kernel memory allocation method and technology (Buddy, cma, ION...) DMA buffer management, SWIOTLB, IOMMU GPU memory management How to customize the memory for different use cases How to avoid using CMA for a better stability and performance

Q:How use USB as both gadget mode and host mode usb USB_OTG? A: Hardware: imx6 sabresd board usb otg diagram, as follow Software: You can use USB OTG port for both host mode and device gadget mode. There are 2 signals you should care: - USB_OTG_ID - USB_OTG_MODE (control power for usb vbus in host mode, this is EIM_D22 pin) In device tree: reg_usb_otg_vbus: regulator@0 { compatible = "regulator-fixed"; reg = <0>; regulator-name = "usb_otg_vbus"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; gpio = <&gpio3 22 0>; enable-active-high; }; pinctrl_usbotg: usbotggrp { fsl,pins = < MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059 MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x80000000 >; }; &usbotg { vbus-supply = <&reg_usb_otg_vbus>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usbotg>; disable-over-current; srp-disable; hnp-disable; adp-disable; dr_mode = "otg"; status = "okay"; }; With above config, one can use OTG port for mouse, usb stick in host mode, and gadget mode for ADB... https://community.nxp.com/message/943460

The init file is a key component of the Android boot sequence. It is a program to initialize the elements of the Android system. Unlike Linux, Android uses its own initialization program. This Android init program processes 2 files, and it executes the commands it finds in both programs. These programs are: ‘init.rc’ and ‘init<machine name>.rc’ (this machine name is the name of the hardware that Android is running on). What does each program contain?: init.rc provides the generic initialization instructions init<machine name>.rc provides specific initialization instructions init<machine name>.rc is imported by the init.rc program. What is the syntax of these .rc files? The android init language consists of 4 classes of statements: Actions, Commands, Services and Options. Actions and Services declare new sections. All the commands or options belong to the section most recently declared. Actions and Services have to have unique names. If a second Action or Service has the same name of a previous one, it is ignored. Actions Actions are sequences of commands. They have a trigger which is used to determine when the action should occur. Actions take following form. On <trigger> <command> <command> <command>… Services Services are programs which init launches and (optionally) restart when it exists Services take the following form. Service <name> <patchname> [argument] <option> <option>… Options Options are modifiers to services. These affect how and when init runs a service. Critical This is a device-critical service. If it exits more than four times in four minutes, the device will reboor into recovery mode. Disabled This service will not automatically start with its class. It must be explicitly started by name. Setenv <name> <value> Set the environment variable <name> to <value> in the launched process. User <username> Change to username before executing this service. Currently defaults to root. Group <groupname> [<groupname>] Change to groupname before executing this service. Oneshot Do not restart the service when it exists Class <name> Specify a class name for the service. All services in a named class may be started or stopped together. Onrestart Execute a command when service restarts Triggers Triggers are strings which can be used to match certain kinds of events and used to cause an action to occur. Boot This is the first trigger that will occur when init starts (after /init.conf is loaded) Commands: Exec <path> [<arguments>] Fork and execute a program (<path>). This will block until the program completes execution. Export <name> <value> Set the environment variable <name> equal to <value> in the global environment. Ifup <interface> Bring the network interface <interface> online. Import <filename> Parse and init config file, extending the current configuration. Hostname <name> Set the host name Chdir <directory> Change working directory Chmod <octal-dmoe> <path> Change file access permissions Chwon <owner> <group> <path> Change file owner and group Chroot <directory> Change process root directory Class_start <serviceclass> Start all services of the specified class if they are not already running. Class_stop <serviceclass> Stop all services of the specified class if they are currently running. Domainname <name> Set the domain name Enable <servicename> Turns a disabled service into an enabled one. Insmod <path> Install the module at <path> Mkdir <path> Create a directory at <path> Mount <type><device><dir> Attempt to mount the named device at the directory. Restorecon <path> Restore the file named by <path> to the security context specified in the file_contexts configuration. Setcon <securitycontext> set the current process security context to the specified string. Setenforce 0|1 Set the SELinux system wide enforcing status. 0 = permissive. 1 = enforcing. Setprop <name><value> Set system property <name> to <value> Setrlimit <resource><cur><max> Set the rlimit for a resource Setsebool <name><value> Set SELinux Boolean <name> to <value> Start <service> Start a service Stop <service> Stop a service Symlink <target><path> Create a symbolic link at <path> with the value <target> Trigger <event> Trigger an event. Used to queue an action from another action Wait <path> Poll for the existence of the given file and return when found. Write <path> <string> Open the file at <path> and write a string to it. Examples How to run a script: service my_service /data/test class main oneshot Here we are declaring the service named 'my service' with location in /data/test. It belongs to the main class and will start along with any other service that belongs with that class and we declare that the service wont restart when it exits (oneshot). Change file access permissions: chmod 0660 /sys/fs/cgroup/memory/tasks Here we are changing access permissions in path /sys/fs/cgroup/memory/tasks Write a string to a file in a path: write /sys/fs/cgroup/memory/memory/memory.move_charge_at_immigrate 1 Create a symbolic link: symlink /system/etc /etc Here we are creating a symbolic link to /system/etc -> /etc Set a specific density of the display: setprop ro.sf.lcd_density 240 Here we are setting a system property of 240 to ro.sf.lcd_density Set your watchdog timer to 30 seconds: service watchdog /sbin/watchdogd 10 20 class core We are petting the watchdog every 10 seconds to get a 20 second margin Change file owner: chown root system /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq The new owner being 'root' from the group 'system'

Agenda: 1. How-to M4 boot-up from TCM, DDR, OCRAM or QSPI in i.MX7D SABRE board 2. About multicore communication, Linux / Cortex-A and FreeRTOS / Cortex-M a. RPMsg Ping-Pong FreeRTOS demo b. RPMsg String Echo FreeRTOS demo 3. Multi-core Resource Sharing and Protection, RDC (Resource Domain Controller), Master Assignment Registers, Peripheral Mapping and Memory region Map 4. RDC settings in FreeRTOS BSP

Introduction Disk encryption on Android is based on dm-crypt, which is a kernel feature that works at the block device layer. Therefore, it is not usable with YAFFS, which talks directly to a raw nand flash chip, but does work with emmc and similar flash devices which present themselves to the kernel as a block device. The current preferred filesystem to use on these devices is ext4, though that is independent of whether encryption is used or not. [1] Let's encrypt! I will show the whole process first, and then point out the issue I noticed on i.MX6. To use this feature, go to settings and security as below: Encrypted phones need to set the numeric PIN, so click Screen lock to set password: Choose PIN: After setting up PIN code, the Screen lock is showed "Secured with PIN" as below: We can then click Encrypt phone to start: Note the words on this page, it needs start with a charged battery and the charger needs to be on. Click Encrypt phone button and it will ask PIN code setup before: Enter the PIN code and then has the confirmed page: Click Encrypt phone, it will reset framework and starting to encrypt: After running 100%: It then reset the device. When it boots, it will ask you enter the PIN to enter system. Check Setting -> Security again: The status showed Encrypted under Encrypt phone. Errors While Doing Encryption on i.MX6 In the following, I list the error I met and the way to fix. Orig filesystem overlaps crypto footer region. Cannot encrypt in place It needs to make sure the filesystem doesn't extend into the last 16 Kbytes of the partition where the crypto footer is kept. The encryption in place and get_fs_size() in system/vold/cryptfs.c will check it, so needs to re-make data partition. sudo mke2fs -t ext4 /dev/sde7 1034000 -Ldata The original size is larger than 103400, so I used this value to reserved 16 Kbytes for crypto footer. device-mapper: table: 254:0: crypt: Error creating IV E/Cryptfs ( 2221): Cannot load dm-crypt mapping table. The actual encryption used for the filesystem for first release is 128 AES with CBC and ESSIV:SHA256. The master key is encrypted with 128 bit AES via calls to the openssl library. This is done by enable CONFIG_CRYPTO_SHA256 in kernel. Enable post_fs_data_done Vold sets the property vold.post_fs_data_done to "0", and then sets vold.decrypt to "trigger_post_fs_dat". This causes init.rc to run the post-fs-data commands in init.rc and init..rc. They will create any necessary directories, links, et al, and then set vold.post_fs_data_done to "1". Vold waits until it sees the "1" in that property. Finally, vold sets the property vold.decrypt to "trigger_restart_framework" which causes init.rc to start services in class main again, and also start services in class late_start for the first time since boot. This is done by: diff --git a/imx6/etc/init.rc b/imx6/etc/init.rc index 17cbd4c..f2823f2 100644 --- a/imx6/etc/init.rc +++ b/imx6/etc/init.rc @@ -203,7 +203,7 @@ on post-fs-data # must uncomment this line, otherwise encrypted filesystems # won't work. # Set indication (checked by vold) that we have finished this action - #setprop vold.post_fs_data_done 1 + setprop vold.post_fs_data_done 1 Don't unmount data partition when cryptfs_restart After the steps above, it can finish encryption. But I found Android will crash after encryption and reboot. When data partition is encrypted, Android's init to mount /data will fail. The cryptfs.c here to try unmount will fail since the data partition isn't mounted before. diff --git a/cryptfs.c b/cryptfs.c index 052c033..fd05259 100644 --- a/cryptfs.c +++ b/cryptfs.c @@ -694,7 +694,7 @@ int cryptfs_restart(void) if (! get_orig_mount_parms(DATA_MNT_POINT, fs_type, real_blkdev, &mnt_flags, fs_options)) { SLOGD("Just got orig mount parms\n"); - if (! (rc = wait_and_unmount(DATA_MNT_POINT)) ) { + //if (! (rc = wait_and_unmount(DATA_MNT_POINT)) ) { /* If that succeeded, then mount the decrypted filesystem */ mount(crypto_blkdev, DATA_MNT_POINT, fs_type, mnt_flags, fs_options); @@ -710,7 +710,7 @@ int cryptfs_restart(void) /* Give it a few moments to get started */ sleep(1); - } + //} } References: [1]: Notes on the implementation of encryption in Android 3.0 | Android Open Source

iMX8QXP/iMX8QM have hardware JPEG decoder: The JPEG-D-X core. This is the example code to use this hw decoder in M4 SDK to decode JPEG files. M4_JPEG_DECODER_SDK_2.5.1.7z The attached "rear_view_camera_jpegdec.tar.bz2" is the updated source code for "SDK\boards\mekmimx8qx\demo_apps\rear_view_camera". It is based on SDK 2.5.1 for iMX8QXP MEK. The "rear_view_camera_jpegdec.patch" is the modified code, it hasn't included the added "fsl_jpeg_dec.c" and "fsl_jpeg_dec.h". The testing used two 256*256 JPEG files, they are RGB color space. We used followed commands to build them into flash.bin: ./mkimage_imx8 -soc QX -rev B0 -append ahab-container.img -c -scfw scfw_tcm.bin -m4 m4_rear_view_camera.bin 0 0x34FE0000 --data demo_rgb.jpg 0x84000000 --data demo_rgb2.jpg 0x84008000 -out flash.bin If customer need change the JPEG resoluion, they can change them in file "fsl_jpeg_dec.h", APP_JPEG_SIZE_OF_KB is the JPEG file length in memory, aligned in KB. #define APP_JPEG_WIDTH (256) #define APP_JPEG_HEIGHT (256) #define APP_JPEG_SIZE_OF_KB (32) #define APP_JPEG_FORMAT JPEG_RGB #define APP_JPEG_BUFFER (0x84000000) To created RGB format JPEG file from RGB data, the customer can use linux unit test application "/unit_tests/JPEG/encoder_test.out". M4_JPEG_DECODER_WINDOW_MODE_SDK_2.5.1.7z Based on JEPG decoder, added DPU CSC support and render JEPG decoded video in overlay window. The architecture is followed: NXP logo is put in FetchLayer0 with RGB565 format, after LayerBlend0, it will be the prim layer for LayberBlend1 (FetchLayer0 can't be used as prim layer for LayerBlend), the JPEG decoder output is put to FetchDecoder0. RGB888 format, and it will be resize to 640*480, and put to x=100, y=100 of the display. (Only the sec layer of LayerBlend can be window mode). Some limitation for layer selection in LayerBlend:

Although you can develop your own driver to control GPIOs inside kernel space, there is a much simpler way for accessing GPIOs from user space. When timing requirements are not an issue, you are able to use GPIO-SYSFS. SYSFS is a virtual file system that exports some kernel internal framework functionalities to user space and GPIO is one of the frameworks that can have functionalities exported through SYSFS. The GPIO-SYSFS feature is available in all mainline kernels from 2.6.27 onwards. Configuring Kernel to export GPIO through SYSFS To enable GPIO in SYSFS, select the following kernel option: Device Drivers ---> --- GPIO Support [*] /sys/class/gpio/... (sysfs interface) If you are using i.MX233 or i.MX28, after recompiling the kernel, do not forget to generate boot streams again, because this is not automatic even in ltib. Be sure that the pins you will try to use are really accessible as GPIO pins and were not requested by the kernel (gpio_request). If pin was gpio_request'ed, you will need to gpio_export the same pin inside the kernel in order to have it accessible through SYSFS. If pin is not set as GPIO by default, you will need to set IO MUX in the proper file inside <kernel>/arch/arm/mach-XXX. Accessing GPIO in user space After enabling GPIO-SYSFS feature, you can boot your device with the new kernel to make some tests. First you need to export the GPIO you want to test to the user space: echo XX > /sys/class/gpio/export XX shall be determined by the following algorithm: GPIOA_[B] is the GPIO you want to export, where "A" is the GPIO bank and "B" is the offset of the pin in the bank. if the first available GPIO bank is 0 // (iMX.28, for example) XX = A*32 + B; else // first GPIO bank is 1 XX = (A-1)*32 + B; After exporting a GPIO pin, you shall be able to see the GPIO interface exported to: /sys/class/gpio/gpioXX Through this interface, you are now able to do things like: # Reading the pin value cat /sys/class/gpio/gpioXX/value # Changing pin direction echo in > /sys/class/gpio/gpioXX/direction echo out > /sys/class/gpio/gpioXX/direction # Toggling GPIO output level echo 0 > /sys/class/gpio/gpioXX/value echo 1 > /sys/class/gpio/gpioXX/value It is important to note that through the GPIO virtual filesystem it is only possible to deal with one GPIO pin at a time (per command).

Hardware connection: there are two board-to-board connectors on E-INK daughter card IMXEBOOKDC4, while there is only one on i.MX7D Sabre board, as the picture below. This might be a bit confusing to connect the two: Checked with internal, the original design was trying to wire both eLCDIF and EPDC bus out to one daughter card, add the flexibility to have different configurations on one display daughter card(LCD/EPD). On i.MX7D Sabre board, only one connector is available for EPDC bus. Here is how we connect i.MX7D Sabre and IMXEBOOKDC4: Software setup: here we use pre-build L3.14.38_6UL7D_Beta Linux as our boot-image, steps to setup/boot/test EPDC: 1. download and decompress BSP pre-build image package "L3.14.38_beta_images_MX6UL7D.tar.gz", you should be able to find the SD image in it -- "fsl-image-gui-x11-imx7dsabresd.sdcard" 2. program the SD image on your SD card(>800 MBytes) with command(I'm running this in Ubuntu): "dd if=fsl-image-gui-x11-imx7dsabresd.sdcard of=/dev/sdb;sync" 3. insert SD card to the slot(J6) on i.MX7D Sabre board, connect debug-UART and power-on the board 4. modify the u-boot environment variables as below: a.) setenv fdt_file imx7d-sdb-epdc.dtb (originally this is "fdt_file=imx7d-sdb.dtb") b.) setenv mmcargs 'setenv bootargs console=${console},${baudrate} root=${mmcroot} epdc video=mxcepdcfb:E060SCM,bpp=16' (originally this is "mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot}") 5. boot into Linux kernel, run unit-test: "/unit_tests/mxc_epdc_fb_test.out", should be able to have test patterns running on EPD.

NXP i.MX 8 series of application processors support running ArmV8a 64-bit and ArmV7a 32-bit user space programs. A Hello World program that prints the size of a long int is cross-compiled as 32-bit and as 64-bit from an Ubuntu host and then each is copied to MCIMX8MQ-EVK and run. Resources: Ubuntu 18.04 LTS Host i.MX 8M Evaluation Kit|NXP MCIMX8MQ-EVK Linux Binary Demo Files - i.MX 8MQuad EVK L4.9.88_2.0.0_GA release Source Code: Create a file with contents below using your favorite editor, example name hello-sizeInt.c. #include <stdio.h> int main (int argc, char **argv) { printf ("Hello World, size of long int: %zd\n", sizeof (long int)); return 0; }‍‍‍‍‍‍‍ Ubuntu host packages: $ sudo apt-get install -y gcc-arm-linux-gnueabihf $ sudo apt-get install -y gcc-aarch64-linux-gnu‍‍‍‍ Line 1 installs the ArmV7a cross-compile tools: arm-linux-gnueabihf-gcc is used to cross compile on Ubuntu host Line 2 install the ArmV8a cross-compile tools: aarch64-linux-gnu-gcc is used to cross compile on Ubuntu host Create Linux User Space Applications Build each application and use the static option to gcc to include run time libraries. Build ArmV7a 32-bit application: $ arm-linux-gnueabihf-gcc -static hello-sizeInt.c -o hello-armv7a‍-static‍‍ Build ArmV8a 64-bit application: $ aarch64-linux-gnu-gcc -static hello-sizeInt.c -o hello-armv8a‍-static‍‍ Copy Hello applications from Ubuntu host and run on MCIMX8MQ-EVK Using a SDCARD written with images from L4.9.88_2.0.0 Linux release (see resources for image link), power on EVK with Ethernet connected to network and Serial Console port which was connected to a windows 10 PC. Launched a terminal client (TeraTerm) to access console port. Login credentials: root and no password needed. Since Ethernet was connected a DHCP IP address was acquired, 192.168.1.241 on the EVK. On the Ubuntu host, secure copy the hello applications to EVK: $ scp hello-armv7a-static root@192.168.1.241:~/ hello-armv7a-static 100% 389KB 4.0MB/s 00:00 $ scp hello-armv8a-static root@192.168.1.241:~/ hello-armv8a-static 100% 605KB 4.7MB/s 00:00 ‍‍‍‍‍‍‍‍‍‍ Run: root@imx8mqevk:~# ./hello-armv8a-static Hello World, sizeof long int: 8 root@imx8mqevk:~# ./hello-armv7a-static Hello World, sizeof long int: 4‍‍‍‍‍‍‍‍

Background Configure Trace32 Attach to SCFW with Lauterbach Snooping Perf Examples Example 1 : Snoop a function call (or a variable) Example 2: MonitorFrame Per Second Example 3: Monitor Frame Per Second and rendering size Background None of my automotive have trace pins on their board. Trace is consequently not possible. Anyway you can do "Snooping" with your Lauterbach JTAG probe. Snooping just send data as fast as possible. In the following example I will Snoop the i.MX8X' SCFW, notice I do not have the sources (except board.c) but I have the elf file (thus I have debug info with functions names for instance). Notice Snooping is available on all MCU/MPU with JTAG. In my case I used it for the first time in 2015 on Vybrid, our first heterogeneous dual core (Cortex-A5 & Cortex-M4) with no XRDC... My customer has sent the final product with a JTAG connector and flashed SW product to me. I had a laconic comment: "software is done all around the world in UK, India and the US, when we flash all the software the Vybrid Reset for some version, we don't have the sources for this specific software we have flashed in this product. Good Luck". In this case snooping on both core at the same time was the only solution for me... At the end I have discovered (thanks to the last PC addresses before the crash) the cortex-A5 was deconfiguring a pin of the QSPI flash interface on which the M4 was eXecuting In Place (XiP). Configure Trace32 When your Trace32 is open, CPU>>System Settings... menu and configure the JtagClock as fast as possible (here 40MHz) to have fast data streaming: go in Trace>>Configuration menu Select "SNOOPer" Select to stream the Pointer Counter thus select the mode "PC" Pass to State to "Arm" You can increase also the SIZE of the buffer Launch your code: Attach to SCFW with Lauterbach In Trace32, CPU>>System Settings, chose IMX8QXP-SCU: And then do an "Attach": Then yu should see your SCU core running: Snooping And break your code, your "used" field " should be filled: Open Trace>>List>>Default Click on "Chart" On the trace list you can see the sampling rate: around 48µs in our case. It means you may (almost) not see functions lasting less than 48µs (depends when it is sampled), or you'll see it sometimes. But for performance analysis it can be useful to see which function is too slow (rather then instrument the code), but as I mentioned in my case function has to last more than 48µs! Perf You can also get Performance analysis. But keep in mind if your function is faster than 48µs in my case, the result will not be accurate! Go in Perf>>Perf Configuration (it can also be done un real time with Perf>>Perf List Dynamic)... and select "Snoop": Then put the State in "Arm" and click on "List" to open the "List Window" Launch your code and stop it. In the "List" window you'll see all the function ranked according to their usage occurrence (my SCFW is almost always in sleep!) Examples Example 1 : Snoop a function call (or a variable) With Snooping you cannot trace a function calls. To do that I add a global variable in the function. You'll have a little overhead due to that. I will use an i.MXRT1170 with the SDK 2.6.1. I have built the Tiger example (vglite). April 4th 2020: i.MXRT1170 is not public, meaning not officially supported by Lauterbach. Please follow the instruction in my SharePoint folder (if the link disappears, it may signify i.MXRT1170 is supported) to add support of the i.MXRT1170. https://nxp1-my.sharepoint.com/:f:/g/personal/vincent_aubineau_nxp_com/Ej8ID8mXaNZPnVgTWgYgqHQBzR0XcE0K4sl1WusR3UMBnw?e=… I want to know the framerate. To do that I have to monitor the redraw() calls. What I do, is I put the "n" variable as global. Trace>>Configuration ... Chose "memory" and "changes" (to log only when the variable is changing): Then then click on select... and "i" Search for "n" variable and select it: Launch your software and then do a break. Click on "List": You have the list of your function call (as you can see it is not always the same), in the "ti. call" you have the duration between 2 call (keep in mind the function must not be called at high frequency: If you click on "draw", you can display the variable values (click on to scale it): Example 2: Monitor Frame Per Second I can also monitor the fps if I pass "time" variable global: And you can have a reprensentation of you fps (notive I have unchecked "Changes" to have an easy to intrepret curve Example 3: Monitor Frame Per Second and rendering size Results often depends of several variables. If you display 2 variables on 1 display window, if the 2 variable does not have the same range, it is not easy to observe. The best solution I have found in this case is to have 2 "Draw" Windows. Add the 2 variables in the "SElect" field ("time" and "ScaleCount", beware, it is case sensitive). Launch your code, and stop it after a while. Then right click on the "time" and "ScaleCount" variable in your code to display 2 "Draw" window: Thus you have 2 "Draw" windows, and you see FPS depends on rendering size... logical!

1. Description: On the i.MX Android camera HAL, It only supports YUYV sensor, regardless of whether the sensor is connected to ISP or ISI. Some users want to customize the sensor format, such as UYVY or raw, they need a guide to do this, this document intends to describe how to implement raw camera sensor on i.MX8MP android, and output raw data. Note: Base on i.MX 8M plus, Android12_1.0.0. 2. Camera HAL Android's camera hardware abstraction layer (HAL) connects the higher level camera framework APIs in android.hardware.camera2 to your underlying camera driver and hardware. For more detail information, please refer to AOSP document: https://source.android.google.cn/docs/core/camera/camera3_requests_hal?hl=en while on I.MX camera HAL, the camera subsystem can be divided into several parts: Camera framework: frameworks\av\camera Camera service: frameworks\av\services\camera\libcameraservice\ Camera provider: hardware/interfaces/camera/provider/ hardware/google/camera/common/hal/hidl_service/ hidl_service dlopen the camera HAL3. Camera HAL3: vendor\nxp-opensource\imx\camera\ Camera driver: vendor/nxp-opensource/kernel_imx/drivers/media/i2c It's callstack can be list as follow: There are 2 streams on pipeline, preview stream need 3 buffers and capture stream need 2 buffers: CameraDeviceSessionHwlImpl: ConfigurePipeline, stream 0: id 0, type 0, res 2592x1944, format 0x21, usage 0x3, space 0x8c20000, rot 0, is_phy 0, phy_id 0, size 8388608 CameraDeviceSessionHwlImpl: ConfigurePipeline create capture stream CameraDeviceSessionHwlImpl: ConfigurePipeline, stream 1: id 1, type 0, res 1024x768, format 0x22, usage 0x100, space 0x0, rot 0, is_phy 0, phy_id 0, size 0 CameraDeviceSessionHwlImpl: ConfigurePipeline create preview stream You can use this command to dump the stream input/output: "setprop vendor.rw.camera.test 1" to dump steam 0. "setprop vendor.rw.camera.test 2" to dump steam 1. Before you implement the command, you need to run “su; setenforce 0” to close the SeLinux, the data is dumped as "/data/x-src.data", "/data/x-dst.data", where "x" is the stream id as "0, "1,", "2", ... Preview Stream Capture Stream ID 1 0 Resolution 1024*768 2592*1944 Format HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED (34) HAL_PIXEL_FORMAT_BLOB (33) Usage 0x900 GRALLOC_USAGE_HW_TEXTURE (0x100) GRALLOC_USAGE_HW_COMPOSER (0x800) 0x3 GRALLOC_USAGE_SW_READ_OFTEN Data space 0 HAL_DATASPACE_V0_JFIF The following usage will be added by framework to distinguish preview and video:GRALLOC_USAGE_HW_VIDEO_ENCODER 3. Raw support 3.1 system modification The default image for i.MX 8M Plus EVK supports basler + basler and the cameras can work after the image is flashed and boot up, it’s camera with ISP, but we need ISI to process raw. You should refer to Android_User’s_Guide.pdf, you need find the correct version, as Android12_2.0.0 is different with Android12_1.0.0. To make cameras work with Non-default images, execute the following additional commands: Only OV5640 (CSI1) on host： As we use OV2775 which support 1920*1080, unpacked raw12, the json file: 3.2 DTB modification 1. Firstly, change the BoardConfig.mk to generate dtbo-imx8mp-ov2775.img device\nxp\imx8m\evk_8mp\BoardConfig.mk: TARGET_BOARD_DTS_CONFIG += imx8mp-ov2775:imx8mp-evk-ov2775.dtb 2. Secondly, add imx8mp-evk-ov2775.dts to vendor\nxp-opensource\kernel_imx\arch\arm64\boot\dts\freescale 3. Change imx8mp-evk-ov2775.dts, connect OV2775 to ISI: &isi_0 { status = "okay"; }; &isp_0 { status = "disabled"; }; &dewarp { status = "disabled"; }; 4. Build dtbo image and flash it to board: ./imx-make.sh dtboimage -j4 fastboot flash dtbo dtbo.img 3.3 Sensor driver modification I use the OV2775 driver from the isp side, be careful that all the function such as g_frame_interval and enum_frame_size should be implemented, or the HAL will get wrong parameters and return error. static struct v4l2_subdev_video_ops ov2775_subdev_video_ops = { .g_frame_interval = ov2775_g_frame_interval, .s_frame_interval = ov2775_s_frame_interval, .s_stream = ov2775_s_stream, }; static const struct v4l2_subdev_pad_ops ov2775_subdev_pad_ops = { .enum_mbus_code = ov2775_enum_mbus_code, .set_fmt = ov2775_set_fmt, .get_fmt = ov2775_get_fmt, .enum_frame_size = ov2775_enum_frame_size, .enum_frame_interval = ov2775_enum_frame_interval, }; 3.4 ISI driver modification We need to add raw format on ISI driver: }, { .name = "RAW12 (SBGGR12)", .fourcc = V4L2_PIX_FMT_SBGGR12, .depth = { 16 }, .color = MXC_ISI_OUT_FMT_RAW12, .memplanes = 1, .colplanes = 1, .mbus_code = MEDIA_BUS_FMT_SBGGR12_1X12, }, { .name = "RAW10 (SGRBG10)", .fourcc = V4L2_PIX_FMT_SGRBG10, .depth = { 16 }, .color = MXC_ISI_OUT_FMT_RAW10, .memplanes = 1, .colplanes = 1, .mbus_code = MEDIA_BUS_FMT_SGRBG10_1X10, } 3.5 Camera HAL modification As there are preview stream and capture stream on the pipeline. GPU does not support raw format, it will print error log when application set raw format: 02-10 18:49:02.162 436 436 E NxpAllocatorHal: convertToMemDescriptor Unsupported fomat PixelFormat::RAW10 02-10 18:49:02.163 2390 2445 E GraphicBufferAllocator: Failed to allocate (1920 x 1080) layerCount 1 format 37 usage 20303: 7 02-10 18:49:02.163 2390 2445 E BufferQueueProducer: [ImageReader-1920x1080f25m2-2390-0](id:95600000002,api:4,p:2148,c:2390) dequeueBuffer: createGraphicBuffer failed 02-10 18:49:02.163 2390 2405 E BufferQueueProducer: [ImageReader-1920x1080f25m2-2390-0](id:95600000002,api:4,p:2148,c:2390) requestBuffer: slot 0 is not owned by the producer (state = FREE) 02-10 18:49:02.163 2148 2423 E Surface : dequeueBuffer: IGraphicBufferProducer::requestBuffer failed: -22 02-10 18:49:02.163 2390 2445 E BufferQueueProducer: [ImageReader-1920x1080f25m2-2390-0](id:95600000002,api:4,p:2148,c:2390) cancelBuffer: slot 0 is not owned by the producer (state = FREE) 02-10 18:49:02.164 2148 2423 E Camera3-OutputStream: getBufferLockedCommon: Stream 1: Can't dequeue next output buffer: Invalid argument (-22) Modifying the gpu code is not recommended. When preview stream, it's pixel format is fixed to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, it needs YUYV format, in this patch, we don't convert raw12 to yuyv, just copy the buffer from input to output, so the preview stream is raw12 actually. When capture stream, we use the Blob format, which usually used for JPEG format. when we find the format is Blob pass down by application, camera HAL will copy the buffer from input to output directly. You can check the detail on function ProcessCapturedBuffer(), 4. Application and Tool 4.1 Application The test application on the attachment “android-Camera2Basic-master_application.7z”, It's basically a common camera application, it set the capture stream format to blob: Size largest = Collections.max( Arrays.asList(map.getOutputSizes(ImageFormat.JPEG)), new CompareSizesByArea()); mImageReader = ImageReader.newInstance(largest.getWidth(), largest.getHeight(), ImageFormat.JPEG, /*maxImages*/2); 4.2 Tool We use 7yuv tool to check the raw12 format, which is captured by applicable or dump by HAL, you need set the parameter on the right side: ImageJ tool also can be used to review raw format.

The purpose of this document is to provide supportive information for selection of suitable LPDDR4, DDR4 and DDR3L devices that are supported by i.MX 8M family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products. It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs available on NXP.com For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket. LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB dual rank, dual-channel device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8M Mini 32-bit 64Gb/8GB dual rank, dual-channel device with 17-row addresses (R0-R16) 1, 2 i.MX 8M Nano 16-bit 32Gb/4GB dual rank, single-channel device with 17-row addresses (R0-R16) 1, 2, 3, 12 i.MX 8M Plus 32-bit 64Gb/8GB dual rank, dual-channel device with 17-row addresses (R0-R16) 1, 2 LPDDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad 24Gb/3GB MT53B768M32D4NQ-062 WT:B (Micron) 15 32Gb/4GB MT53D1024M32D4DT-046 AAT:D (Micron) 14 4Gb/512MB IS43LQ16256B-062BLI (ISSI) 5, 14 8Gb/1GB IS43LQ32256B-062BLI (ISSI) 5, 14 i.MX 8M Mini 16Gb/2GB MT53D512M32D2DS-053 WT:D (Micron) 15 16Gb/2GB M56Z16G32512A (ESMT) 5, 14 32Gb/4GB MT53E1G32D2FW-046 WT:A (Micron) 5, 14 64Gb/8GB MT53E2G32D4DT-046 AIT:A (Micron) 5, 14 i.MX 8M Nano 16Gb/2GB C1612PC2WDGTKR-U (Kingston) 15 32Gb/4GB MT53E2G32D4DT-046 AIT:A (Micron) 5, 13, 15 8Gb/1GB MT53D512M32D2DS-053 WT:D (Micron) 13, 15 i.MX 8M Plus 48Gb/6GB MT53E1536M32D4DT-046 WT:A (Micron) 15 64Gb/8GB MT53E2G32D4DE-046 AUT:C (Micron) 5, 14 LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table: Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4UJE3D4AA-KU(H/F)CL 48Gb/6GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. Samsung K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. The memory device only supports the LPDDR4X mode. DDR4 - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 6 i.MX 8M Mini 32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 i.MX 8M Nano 16-bit 64Gb/8GB x8, 16Gb device with 2 bank group addresses, 17-row addresses and 10 column addresses 1, 8 i.MX 8M Plus 32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 DDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad 32Gb/4GB 4x MT40A512M16JY-083EAAT (Micron) 15 i.MX 8M Mini 16Gb/2GB 2x MT40A512M16LY-075:E (Micron) 15 i.MX 8M Nano 16Gb/2GB 1x MT40A1G16RC-062E:B (Micron) 15 i.MX 8M Plus 64Gb/8GB 4x MT40A1G16RC-062E:B (Micron) 15 16Gb/2GB NT5AD512M16C4-JRI (Nanya) 14 DDR3L - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB x16, 8Gb device with 16-row addresses and 10 column addresses 1, 9 i.MX 8M Mini 32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 10 i.MX 8M Nano 16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 11 i.MX 8M Plus i.MX 8M Plus does not support DDR3L DDR3L - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad 16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14 i.MX 8M Mini 16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14 Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standards JESD209-4/JESD209-4A (LPDDR4), JESD279-4/JESD279-4A (DDR4), and JESD79-3E/JESD79-3F/JESD79-3-1A (DDR3/DDR3L). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chips to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the DDR Controller Note 5: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 6: The density can be achieved by connecting 2 single-rank discrete devices with one 16Gb die each. Since the SoC supports x8 devices and also has connectivity for a second rank, usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Two x16 16Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (only two discrete devices used), and bandwidth aspects (full data bus width used). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 64Gb/8GB of address space dedicated for the DDR. Four x16 16Gb devices giving 64Gb/8GB in total is the optimal choice that balances the maximum density aspects, the signal integrity aspects (only four discrete devices used), and the bandwidth aspects (full data bus width used). Note 8: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Note 9: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Four x16 8Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (four discrete devices used), and bandwidth aspects (full data bus width used). Note 10: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that the first option significantly exceeds the number of devices used on the validation board (4 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis. Practically, it is not recommended to use more than 4 discrete DDR3L devices. This corresponds to the maximum density of 32Gb/4GB in the case of the single rank devices containing one 8Gb die or 64Gb/8GB in case of the dual-rank devices, each containing two 8Gb dies. Note 11: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note 12: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q1 2022). Note 13: Only one channel of the device (and hence, half of its density) was utilized due to the reduced data bus width (x16) of the SoC. Note 14: Part is active. Reviewed May 16th 2024 Note 15: Part is obsolete. Additional Links https://community.nxp.com/t5/iMX-and-Vybrid-Support/i-MX-8-8X-8XL-maximum-supported-LPDDR4-and-DDR3L-densities/ta-p/1152715

The purpose of this document is to provide supportive information for selection of suitable LPDDR4 and DDR3L devices that are supported by i.MX 8/8X/8XLite family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products. It is strongly recommended to consult with NXP and the respective memory vendor, the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the respective NXP i.MX 8 Hardware Developer's Guide available on NXP.com The i.MX8/8X/8XL Reference manuals declare that there are 16GB allocated for the DDR. Please note that this is only the address space, which is reserved for the DDR memory in the memory map. This specification does not guarantee that the entire region can be utilized as the maximum achievable densities listed below in the tables are restricted mainly by the addressing capabilities of the DDR controller, width of the data bus and other implementation-specific parameters as well as availability of supported devices on the market. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket. LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QM/8QP 29x29 mm 32-bit (per controller) 32Gb/4GB (per controller) dual rank, dual-channel device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 21x21 mm 32-bit 32Gb/4GB dual rank, dual-channel device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 17x17 mm 16-bit 16Gb/2GB dual rank, single-channel device with 16-row addresses (R0-R15) 1, 2, 3, 4, 9 i.MX 8XLite 15x15 mm 16-bit 32Gb/4GB dual rank, single channel device with 17-row addresses (R0-R16) 1, 2, 3, 9 LPDDR4 - list of validated memories The validation process is an ongoing effort - updates of the table are expected. SoC Package Maximum validated density Validated part number (vendor) Notes i.MX 8QM/8QP 29x29 mm 24Gb/3GB (per controller) MT53B768M32D4NQ-062 AIT:B (Micron) 12 32Gb/4GB (per controller) K4FBE3D4HB-KHCL (Samsung) 10,11 32Gb/4GB (per controller) MT53E1G32D2FW-046 AUT:B (Micron, Z42M) 10, 11 32Gb/4GB (per controller) MT53D1024M32D4DT-046 AAT:D (Micron) 12 16Gb/2GB (per controller) MT53D512M32D2DS-046 WT:D (Micron) 10, 12 16Gb/2GB (per controller) NT6AN512T32AC-J1J (Nanya) 10, 11 16Gb/2GB (per controller) NT6AN512T32AC-J1H (Nanya) 10, 11 32Gb/4GB (per controller) NT6AN1024F32AC-J2J (Nanya) 10, 11 32Gb/4GB (per controller) NT6AN1024F32AC-J2H (Nanya) 10, 11 i.MX 8QXP/8DXP 21x21 mm 24Gb/3GB MT53B768M32D4NQ-062 AIT:B (Micron) 12 32Gb/4GB NT6AN1024F32AC-J2J (Nanya) 10, 11 32Gb/4GB NT6AN1024F32AC-J2H (Nanya) 10, 11 16Gb/2GB NT6AN512T32AC-J2J (Nanya) 10, 11 16Gb/2GB NT6AN512T32AC-J2H (Nanya) 10, 11 32Gb/4GB MT53D1024M32D4DT-046 AAT:D (Micron) 11 i.MX 8XLite 15x15 mm 8Gb/1GB MT53D512M16D1DS 046 AAT ES:D & Z9XGG (Micron) 12 4Gb/0.5GB K4F4E164HD-THCL (Samsung) 10, 11 8Gb/1GB NT6AN512M16AV-J1I (Nanya) 10, 11 LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table: Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX8QM/8QP, i.MX8QXP/8DXP The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL 24Gb/3Gb i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4UJE3D4AA-KU(H/F)CL 48Gb/6GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. Samsung K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. The device only supports the LPDDR4X mode. DDR3L - maximum supported densities SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QXP/8DXP 21x21 mm 32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 6 i.MX 8QXP/8DXP 17x17 mm 16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 7 i.MX 8XLite 15x15 mm 16-bit 16Gb/2GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 8 DDR3L - list of validated memories The validation process is an ongoing effort - updates of the table are expected. SoC Package Density Validated part number (vendor) Notes i.MX 8QXP/8DXP 21x21 mm 8Gb/1GB 2x MT41K256M16TW-093 IT:P (Micron) 12 i.MX 8XLite 15x15 mm 4Gb/512MB MT41K256M16TW-093 IT:P (Micron) 12 Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD209-4A. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chip to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the SoCs. Note 5: The numbers are based purely on the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD79-3E/JESD79-3F. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 6: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select, or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that this number of discrete devices significantly exceeds the number of devices used on the validation board (2 discrete devices, not taking into account the device used for ECC) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies (x16 8Gb devices with 16-row addresses and 10 column addresses assumed instead of x8 devices in such case). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note that the first option exceeds the number of devices used on the validation board (2 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis, hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies. Note 8: The density can be achieved by connecting 2 single rank discrete devices with one 8Gb die each to the i.MX. 8XLite supports only one chip select for DDR3L therefore, dual-rank systems are not supported. Note 9: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q2 2022). Note 10: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 11: Part is active. Reviewed May 16th 2024 Note 12: Part is obsolete. Additional Links i.MX 8M Quad/8M Mini/8M Nano/8M Plus - LPDDR4, DDR4 and DDR3L memory compatibility guide

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

iMX6DQ TP2854 MIPI CSI2 720P HD-TVI camera surround view solution for Linux BSP

Accessing GPIO From UserSpace

Porting KSZ9031 to i.MX BSP

Seamless switch between Android/Linux and M4 core using dpu on imx8qxp/qm.

aarch64 Linux Kernel Memory Management

How to Use Trace32 to Run U-boot in the i.MX6Q SABRE Platform

How use USB as both gadget mode and host mode usb USB_OTG

What is inside the init.rc and what is it used for.

Hibernation for Android Demo

i.MX 7D with FreeRTOS

Android Data Partition Encryption on i.MX6

iMX8QXP: Use JPEG decoder in M4 SDK

FAQ All Boards GPIO Test

connecting i.MX7D Sabre(MCIMX7SABRE) and E-INK panel(IMXEBOOKDC4)

i.MX 8 Hello World Linux - ArmV7a 32-bit and ArmV8a 64-bit

Lauterbach Snooping: JTAG (almost) Trace / (almost) Perf analyser

i.MX8MP support raw format on Android

i.MX 8M Quad/8M Mini/8M Nano/8M Plus - LPDDR4, DDR4 and DDR3L memory compatibility guide

i.MX 8/8X/8XLite - LPDDR4 and DDR3L memory compatibility guide

Incorporating Out-of-Tree Modules in YOCTO