Use case: iMX8QXP system can be a video input source to another system.   Hardware Pins： LCDIF_D00 ~ LCDIF_D07 LCDIF_CLK LCDIF_VSYNC LCDIF_HSYNC LCDIF_EN   Reference patch： It is based on L5.4.70_2.3.0 GA BSP.  File: L5.4.70_2.3.0-iMX8QXP-LCDIF-add-YUV422-8-bits-output.patch Customer can change the timing parameters in file "panel-lcdif-yuv422.c" as needed, the default timing is a 1280x720 P30 mode: static const struct display_timing yuv422_lcd_timing = {     .pixelclock = { 74250000, 74250000, 74250000 },     .hactive = { 1280, 1280, 1280 },     .hfront_porch = { 220, 220, 220 },     .hback_porch = { 110, 110, 110 },     .hsync_len = { 40, 40, 40 },     .vactive = { 720, 720, 720 },     .vfront_porch = { 20, 20, 20 },     .vback_porch = { 5, 5, 5 },     .vsync_len = { 5, 5, 5 },     .flags = DISPLAY_FLAGS_DE_HIGH, };   Test application: drm_test_yuv.zip: it can set framebuffer to UYVY mode, in this case, no CSC is needed, the data in framebuffer memory will be same as output on display data interface. drm_test_rgb.zip: it can set framebuffer to RGBA mode, in this case, RGB to YUV CSC is needed, application can draw RGB data into framebuffer as normal, the LCDIF will convert it to YUV422 format on the fly, then output the YUV data to display interface.    

This article will describe one suggestion for one issue that UART continuously generate RX interrupts and receive 0xFF even when Rx line is continuously high in some cases on imx6 series. Below I will explain with imx6DL. Some settings are just to make it easier to reproduce. BSP version: L5.4.70-2.3.0 Board HW: MCIMX6DL-SDB When issue happen Config imx6DL UART3 as the serial port to 1200 baud, 8-N-1 format. Keep the RX Line high. Make the RX line low and keep it for a short time (360 usec-370 usec).   At this condition, you will find that the UART will continuously generate RX interrupts and show receiving 0xFF even you make the RX line return to be high. Why issue happen The low time is not in the correct range and out of our spec. In the imx6DL AEC document, there is one chapter named UART Receiver like blow   If using 1200 band, that means one valid bit time is 833 usec. And there is a definition that “tolerate 1/(16 x Fbaud_rate) tolerance in each bit”. That’s means in the case of 1200 baud. A range of valid bit is 781 to 885 usec. But is reproducing, the Low level time is 360 usec. This time out of range will make UART state machine to be confused. How to fix Actually, the best way is following our spec. If there is such an unknown situation in the customer’s environment, then the following method could be regarded as a suggestion to fix the issue meet by the customer. The interrupt handler will check USR1[AWAKE]. 2    If AWAKE is asserted, clear it and proceed as usual (assume we have valid data), else, check if USR1[AGTIM] is asserted. 3    if AGTIM is asserted, clear it and proceed as usual, else perform software reset (assume we have invalid data). Checking AGTIM is for one race condition when the RX fifo has some characters (less than RXTL) but no more data is coming in. When following this procedure, the UART will perform a software reset when a block interrupt occurs. Notes: From customer report, error could be cleared if a valid start-bit is detected on the RX line. This needs to be verified by the customer themselves. Test code has been included in attachment.   Besst Regards

Introduction This document intends to describe how to implement workaround for ERR050145 (ISI: Memory overwrite occurring outside of allocated buffer space corrupting system memory) based on Linux BSP. ERR050145 is applicable for i.MX8QM B0, i.MX8QXP B0 series products.   Software Platform Reference patches stated into this document are developed and validated on L4.14.98_GA2.0.0 release.   Software Workaround As workaround stated, the xRDC can be programmed to grant write access to the ISI only within its allocated frame buffer space, which can prevent the corruption. So under Linux, we can consider to implement workaround like so: Create children partition for ISI and allocate buffers. Then Linux can access these buffers as normal, but ISI can't access other memory out of these buffers, it is limited by xRDC hardware. Considering the xRDC hardware can only support up to 16 memory regions, we may need to consider different workaround implementations for different camera use case scenarios.   For single camera use case, the required camera buffer number is usually less than 16. So “0001-iMX8QM-iMX8QX-ERR050145-ISI-overwrite-workaround.patch” is enough. No modification is needed for camera application in this case.   For multiple camera use case, all patches (0001~0003) are needed. If the camera application used VB2_MEMORY_MMAP memory mode, then no code modification is needed in application. The V4l2 ISI driver can handle everything (Allocate physical continued memory for each camera, and map them as one xRDC memory region for overwrite protect). If the camera application used VB2_MEMORY_USERPTR and VB2_MEMORY_DMABUF memory mode, then it needs allocate camera buffers with physical continued memory for each camera, then the driver will merge them as one xRDC memory region in SCFW.   How to prove workaround take effective? After applying the patches, the ISI will report AXI_WR_ERR due to it failed to write data out of the allocated buffers when the errata happens. To reduce the ISI interrupt, we can also change the ISI interrupt setting as followed: void mxc_isi_enable_irq(struct mxc_isi_dev *mxc_isi) {     u32 val;     val = CHNL_IER_FRM_RCVD_EN_MASK |         CHNL_IER_EXCS_OFLW_V_BUF_EN_MASK |         CHNL_IER_EXCS_OFLW_U_BUF_EN_MASK |         CHNL_IER_EXCS_OFLW_Y_BUF_EN_MASK;     writel(val, mxc_isi->regs + CHNL_IER); }   Add reference patch for L5.4.70_2.3.0 and L5.10.72_2.2.0.

The A53 Debug Console Changing consists in several major updates like: RDC settings, Pinmux, Clocks and Ecosystem Updates.

Some case need configure the GPIO as power off button. One solution is to use “gpio-keys” to send the “KEY_POWER” event to the system. Co-work with systemd, system gets power off.  

     

Software environment: L5.4.47_2.2.0 Hardware i.MX8QXPC0 EVK board In the uuu script we can see the bootloader imx-boot-imx8qxpc0mek-sd.bin-flash is necessary. The default BSP build generate in the yocto project is with the spl, some customers are confused about the how to build the imx-boot-imx8qxpc0mek-sd.bin-flash. Here I give the manually compile way and generate it in yocto. In the yocto generate it is more convenient than the manually compile way. Hope this can do help for you.

This doc share one OpenGL ES sample code, it is running on i.MX8 MEK board with QNX SDP7.1. HW: i.MX8 MEK board, HDMI display SW: QNX SDP7.1, i.MX8 MEK board BSP, and this sample code   This sample code will draw 3D object model, and with some animation. Reference: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8-family-arm-cortex-a53-cortex-a72-virtualization-vision-3d-graphics-4k-video:i.MX8 https://github.com/NXPmicro/gtec-demo-framework https://github.com/syoyo/tinyobjloader-c https://github.com/nothings/stb https://3dhaupt.com/futuristic-car-game-ready-download/ https://wallpapersafari.com/w/Y5JZNh https://www.pngwing.com/en/free-png-ysaus https://www.shadertoy.com/view/Ms2SWW#

  Question: How can we generate an ARM DS5 DStream format DDR initialization script using the DRAM Register Programming Aid?  Answer: Some RPAs include a  "DStream .ds file" tab for the ARM DS5 debugger specific commands. The i.MX6UL/ULL/ULZ DRAM Register Programming Aids for example already has this supported. However, the user can easily create  the .ds format from the existing .inc format. The basic steps to convert .inc files to .ds format are as follows: 1)  Replace the one instance of setmem /16 with mem set 2)  In that same line, replace 0x020bc000 = with 0x020bc000 16 3)  Use a Replace All command to change setmem /32 with mem set 4)  Use a Replace All command to change = with 32 5)  Use a Replace All command to change // with # 6)  Save as a .ds file.   Question: When using a 528MHz DRAM Controller interface with a DDR memory of a faster speed bin, which speed bin timing options should one use? Answer: For example, let’s assume our MX6DQ design is using a DDR3 memory from a DDR3-1600 speed bin.  However, the maximum speed of the MMDC interface for the MX6DQ using DDR3 is 528MHz.  Should we use the 1600 speed bin (800MHz clock speed) or the 1066 speed bin (533MHz clock speed)?  In short, the user should use the timings rated for the maximum speed (frequency) with which you are running, in this case DDR3-1066 (533MHz).  In some cases, like when using the MX6DL, the maximum DDR frequency is 400MHz.  In this case, you would want to try and use 800 timings found in the AC timing parameters table.  However, most DDR3 devices have speed bin tables that may go only as low as 1066, in which case you would use the closest speed bin to your operational frequency (i.e. the 1066 speed bin table).     Question: Some timing parameters may specify a min and max number, which should I use? Answer: In most cases, you will want to choose the minimum timings.  Some DRAM controllers may have a tRAS_MAX timing parameter, in which case you would obviously use the maximum tRAS parameter given in the DRAM data sheet. Also, for timing parameters tAONPD and tAOFPD, we also want to use the maximum values given in the DDR3 data sheet. These represent the maximum amount of time the DDR3 device takes to turn on or off the RTT (termination), therefore, we should wait at least this amount of time before issuing any commands or accesses.   Question: Some timing parameters state things like “Greater of 3CK or 7.5ns”; which should I use? Answer: This depends on your clock speed.  Say you are running at 533MHz.  At 533MHz, 7.5ns equates to 4CKs.  In this case, 7.5ns at 533MHz is GREATER than 3CK, so we would use the 7.5ns number, or 4CKs. At 400MHz, 7.5ns equates to 3CKs.  In this case, we’d simply use 3CKs.   Question: I have a design that will throttle the DDR frequency (dynamic frequency scaling).  At full speed, I plan to run at 533MHz, and then I plan to throttle down to say 400MHz whenever possible.  Do I need to re-calculate my 400 MHz timing parameters that were initially set for 533MHz? Answer: It is not necessary to re-calculate timing parameters for 400MHz, and you can re-use the ones for 533MHz.  The timings at 533 MHz are much tighter than 400 MHz, and the key here is to NOT violate timings.  Also, it may be a bit of a hassle maintaining two sets of timing parameters, especially if later in the design, you swap DDR vendors that might require you to re-calculate some timing parameters.  It’s easier to do it once and to come up with a combined worse-case timing parameters for 533MHz, which you know will work at 400MHz.  But, if you don’t mind maintaining two sets of timing parameters, and really want to optimize timings down to the last pico-second for 400MHz, then knock yourself out.   Question: Can I use these Register programming aids for both Fly by and T- Topology ? Answer Yes The DDR register programming aid is agnostic to the DDR layout. The same spreadsheet works for both topologies. We recommend running write leveling calibration for both topologies and the values returned by the Write Leveling routine from the Freescale DDR stress test should be incorporated back to the customer specific initialization script. The DDR stress test also has a feature whereby it evaluates the write leveling values returned from calibration and increments WALAT to 1 if the values exceed a defined limit. The DDR stress test informs the user when the Write Additional latency (WALAT) exceeds the limit and should be increased by 1, and reminds the user to add it back in the customer specific initialization script if required.   WALAT - 0 00000000 WALAT: Write Additional latency. Recommend to clear these bits. Proper board design should ensure that the DDR3 devices are placed close enough to the MMDC to ensure the skew between CLK and DQS is less than 1 cycle.     Question: Can I use the DEFAULT Register programming aid values for MDOR when using an Internal OSC instead of the recommended 32.768 KHZ XTAL ? Answer No, NXP recommends reprogramming these values based on the worse case frequency (Max clock) of the internal OSC of the device to guarantee JEDEC timings are met. Please refer to Internal Oscillator Accuracy considerations for the i.MX 6 Series for more details  

Steps to replace the Wi-Fi/Bluetooth firmware on the i.MX 8M series on Linux    Applicable to versions L5.4.47, L5.4.70, L5.10.9   1. Download the newest firmware. you can download the attachment in this thread and unzip it. 2. Copy it to the EVK board. 3. Copy the firmware to /lib/firmware/nxp   root@imx8mmevk: cp pcieuart8997_combo_v4.bin sdiouart8987_combo_v0.bin  /lib/firmware/nxp If the Linux version is L5.4.3，Then the step3 is to copy firmware to lib/firmware/mrvl/ root@imx8mmevk: cp pcieuart8997_combo_v4.bin sdiouart8987_combo_v0.bin  /lib/firmware/mrvl    

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 6/7 Series Family DDR Tools Overview This page contains the latest releases for the i.MX 6/7 series DDR Tools. The tools described on this page cover the following i.MX 6/7 series SoCs: i.MX 6DQP (Dual/Quad Plus) i.MX 6DQ (Dual/Quad) i.MX 6DL/S (Dual Lite/Solo) i.MX 6SoloX i.MX 6SL i.MX 6SLL i.MX 6UL i.MX 6ULL/ULZ i.MX 7D/S i.MX 7ULP The purpose of the i.MX 6/7 series DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.). This process equips the user to then proceed with the bring-up of a boot loader and an OS. Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface. The i.MX 6/7 series DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test _________________________________________________________ i.MX 6/7 Series DDR Stress Test The i.MX 6/7 Series DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational prior for use in u-boot and OS bring-up. The DDR Stress Test tool can be found here: i.MX 6/7 DDR Stress Test Tool Note that the DDR Stress test tool supports all of the above i.MX SoCs, however, some of the supported i.MX SoCs named in the tool support multiple i.MX SoCs as follows: MX6DQ – when selected, this supports both i.MX 6DQ and i.MX 6DQP (Plus) MX6DL – when selected, this supports both i.MX 6DL and i.MX 6S (i.MX 6DLS family) MX6ULL – when selected, this supports both i.MX 6ULL and i.MX6 ULZ MX7D – when selected, this supports both i.MX 7D and i.MX 7S _____________________________________________________________________________ i.MX 6/7 Series DDR Register Programming Aid (RPA) The i.MX 6/7 series DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization script for use with the DDR Stress Test tool. For a history of the previous versions of an RPA, refer to the Revision History tab of the respective RPA. To obtain the latest RPAs, please refer to the following links: i.MX 6DQP i.MX6DQP Register Programming Aids i.MX 6DQ i.MX6DQ Register Programming Aids i.MX 6DL/S i.MX6DL Register Programming Aids i.MX 6SoloX i.MX6SX Register Programming Aids i.MX 6SL i.MX6SL Register Programming Aids  i.MX6SLL i.MX6SLL Register Programming Aids i.MX 6UL/ULL/ULZ i.MX6UL/ULL/ULZ DRAM Register Programming Aids i.MX7D i.MX7D DRAM Register Programming Aids i.MX 7ULP i.MX7ULP DRAM Register Programming Aids _____________________________________________________________________________ DRAM Register Programming Aids FAQ    

Default system can’t start Weston GUI in monitor after booting with NFS, so I find a solution to fix that issue. 1.Error messages imx8mpevk login: [31.274389] systemd[1]:[email protected]: Main process exited, code=exited, status=1/FAILURE [ 31.274928] systemd[1]: [email protected]: Failed with result 'exit-code'. [04:52:59.571] logind: not running in a systemd session [04:52:59.571] logind: cannot setup systemd-logind helper (-61), using legacy fallback 2.Steps Step 1:Add output in the /etc/xdg/weston/Weston.ini [output] name=HDMI-A-1 mode=1920x1080@60 Step 2:ls /sys/class/drm There will be some device nodes like card0,card1-HDMI-A-1. card1-HDMI-A-1 is we need. Step 3:Change drm_device in /etc/xdg/weston/Weston.ini drm-device=card1 Step 4:Set envs export WESTON_DRM_PRIMARY=HDMI-A-1 export WESTON_DRM_MIRROR=1 export WESTON_DRM_KEEP_RATIO=1 export WESTON_DRM_PREFER_EXTERNAL=1 export WESTON_DRM_PREFER_EXTERNAL_DUAL=1 Step 5:Start Weston weston --tty=7 -B=drm-backend.so --idle-time=0&

  This patch will add bootaux command to imx7ulp uboot.   This would make it easier in start M4 binary image in single boot mode.   Feature: 1. Support using m4 image in .bin format. 2. Support bootaux command in u-boot. 3. Support boot from TCM and DDR (DDR not tested, if any issue, pls let me know.).   Note: 1. SDK TCM entry address is 0x1FFD2000. But TCML base address is 0x1FFD0000. Pls take care to set a correct entry address to m4_loadaddr. 2. If user want to use M4 image generated from imx_mkimage, pls refer to bootaux patch in https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/OTA-upgrade-for-smartlocker-in-i-MX7ULP-kernel/ta-p/1112687.   Test procedure: 1. Set u-boot parameters: setenv m4_loadaddr 0x1FFD2000 setenv m4_copyaddr 0x62000000 setenv m4_image hello_world.bin setenv m4_flash_imglen 0x30000 setenv m4_loadimage "fatload mmc '${mmcdev}':'${mmcpart}' '${m4_copyaddr}' '${m4_image}'; cp.b '${m4_copyaddr}' '${m4_loadaddr}' 0x30000" setenv run_m4_image "run m4_loadimage; dcache flush; bootaux '${m4_loadaddr}'" 2. Copy hello_world.bin to SD card and boot board. Make sure board is in single boot mode. 3. Run "run run_m4_image"   4. On M core console.    

  Some customers are using sgtl5000 in android. So i generate this patch of sgtl5000 in Android11(i.MX8QM)

Linux kernel provide some apis to allow changing dtb node after system booted. But the node change must happen before the driver loading. We can use gereral dtb file and add some dts node after system boot.

This solution change the pf1550 driver in i.MX6ULL,fixed the cpu freq errors!  

  This is a detailed programming aid for the registers associated with i.MX 8M Plus DDR initialization. LPDDR4 DDR4  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467 Please note that this page is only intended to store the RPA spreadsheets. For questions, please create a new community thread.  

    The document is about how to use WSL2 to compile yocto(android is the same process)  

Here is simple step to create a custom partition with AVB. Tested by i.MX8MN EVK and Android P9.0.0_2.3.1. Create image for xyz partition in 1024MB in Android build output folder # cd $OUT # mkdir xyz # echo "This is test txt file" > xyz/Readme.txt # make_ext4fs -l 1073672192 -s -a xyz xyz.ext4.img xyz   Apply the attached patch. uboot patch corrects the reading problem on avb footer.   Flash images by uuu # cd $OUT # sudo ./uuu_imx_android_flash.sh -f imx8mn   Check result.  Boot up and mount xyz partition # cd /data # mount /dev/block/mmcblk2p14 xyz # cat xyz/Readme.txt This is test txt file