Since LF_v5.10.52-2.1.0 crypto_af_alg blackkey demo “caam-decrypt” becomes default in release. You can try it with binary demo release image. The demo is using black key to decrypt data. This document goes more detail based on BSP release document i.MX Linux® User's Guide, Rev. LF5.10.52_2.1.0, 15 October 2021 10.6 crypto_af_alg application support   HW: i.MX8MM EVK SW: LF_v5.10.52-2.1.0_images_IMX8MMEVK binary demo image PC side: 1. generate key and iv by openssl echo 12345 | openssl enc -aes-256-cbc -k - -P -md sha1 -pbkdf2 salt=1982686A7BACEE4D key=D84041EC14BB28543E8545BEB094FE643B5BC1345C31CD576BC708A1559FBD2D iv =F950CACE80F76F0AC00D9C8762B3A5C9 2. encrption by openssl echo "For test caam-decrypt" | openssl enc -e -aes-256-cbc -in - -out test.txt.enc -K D84041EC14BB28543E8545BEB094FE643B5BC1345C31CD576BC708A1559FBD2D -iv F950CACE80F76F0AC00D9C8762B3A5C9 3. decryption by openssl openssl enc -d -aes-256-cbc -in test.txt.enc -out - -K D84041EC14BB28543E8545BEB094FE643B5BC1345C31CD576BC708A1559FBD2D -iv F950CACE80F76F0AC00D9C8762B3A5C9 4. convert key and iv to plian txt for caam-decrypt. echo F950CACE80F76F0AC00D9C8762B3A5C9| xxd -r -p > fromopenssl.iv.txt echo D84041EC14BB28543E8545BEB094FE643B5BC1345C31CD576BC708A1559FBD2D| xxd -r -p > fromopenssl.key.txt 5. prepare data for caam-decrypt cat fromopenssl.iv.txt test.txt.enc > data.caam-decrypt.enc note: the format for with blackkey AES Encrypted file format 16 Octets - Initialization Vector (IV) is an input to encryption algorithm. nn Octets - Encrypted message (for AES-256-CBC, it must be multiple of 16) 6. send fromopenssl.key.txt and data.caam-decrypt.enc to the board on i.MX8MM evk board 1. generate blackkey blob caam-keygen create blackkey ecb -t $(cat fromopenssl.key.txt) 2. delete fromopenssl.key.txt 3. test decryption by caam-decrypt with blackkey caam-decrypt /data/caam/blackkey.bb AES-256-CBC data.caam-decrypt.enc data.caam-decrypt.dec root@imx8mmevk:/# cat data.caam-decrypt.dec For test caam-decrypt  

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.

Here is the docment about arm64 kernel booting process, which is helpful for us to port kernel. It include the bootloader protocol, virtual memory layout, dtb, memory init, irq init, timer init and so on, please take the attachment for details. vmlinux ELF vmlinux.lds.S head.S __create_page_tables __cpu_setup __primary_switch init_task IRQ Vectors Start_kernel setup_arch paging_init bootmem_init psci_dt_init mm_init sched_init init_IRQ time_init rest_init You can refer the diagram show as below: Peter_Liu_0-1637315886812.png  

Some customers want a method to build imx8mp isp standalone instead of using yocto. For such purpose, the NXP kernel, yocto imx-isp and yocto vvcam can be built separately on your local machine. After necessary files are remotely transferred, you will be able to run isp on an evk board. The attached file contains detailed steps for building isp standalone. Please see the guide for further information.

  From L5.4 BSP, the iMX8QM HDMI RX feature is removed from BSP, but it is added back in L5.10.52 2.1.0 BSP. The followed is the detail steps to use HDMI RX.   We need enable the followed kernel config to make hdmirx driver work:     CONFIG_IMX8_MEDIA_DEVICE=y     CONFIG_MHDP_HDMIRX=y apply the attached kernel patch. put hdmi firmware “hdmirxfw.bin” and “hdmitxfw.bin” to SD card’s FAT partition test command:     gst-launch-1.0 v4l2src device=/dev/video2 ! autovideosink   Note: To test the hdmi feature, the display should also use the HDMI TX. And in Uboot, to load the hdmirx firmware, we can run the followed commands first, then run the "boot" command:     run loadhdprx     hdprx load 0x9c800000     setenv fdt_file imx8qm-mek-hdmi-rx.dtb  

Enable HDMI CEC function Board: i.MX8MQ Board BSP version: imx-android-11.0.0_2.2.0  Following the Android user guide download and built the Android-11.0.0_2.2.0 BSP  The build directory shared here:  http://10.168.2.226/android/build_folder/device/nxp/imx8m/evk_8mq/hdmicec/. or use the files in attachment. The steps are: Copy the above link code to their android env under device/nxp/imx8m/evk_8mq/hdmicec/.  In device/nxp/imx8m/evk_8mq/evk_8mq.mk, adding below code: +PRODUCT_PACKAGES += \ hdmi_cec.nxp\ hdmicec_test" (2) Compile that. (3) Copy to board  adb root adb remount adb push hdmi_cec.nxp.so /vendor/lib64 adb push hdmi_test /vendor/bin evk_8mq:/vendor/bin # ./hdmicec_test [  349.297183] msg[0]=0x40 [  349.299641] msg[1]=0x4

The i.MX 8QuadXPlus Multisensory Enablement Kit (MEK) is a NXP development platform based on Cortex A-35 + Cortex-M4 cores. Built with high-level integration to support graphics, video, image processing, audio, and voice functions, the i.MX 8X processor family is ideal for safety-certifiable and efficient performance requirements. This tutorial shows how to enable the Cortex-M4 using the MCUXpresso SDK package and loading the binary from the network. NOTE: It is also possible to load the Cortex-M4 image from the SCFW using the imx-mkimage utility. But now we are going to focus on MCUXpresso. Setting up the machine   Install cmake on the host machine: $ sudo apt-get install cmake Download the armgcc toolchain and export the location as ARMGCC_DIR: $ export ARMGCC_DIR=<your_path_to_arm_gcc>/gcc-arm-none-eabi-9-2020q2/ NOTE: The ARMGCC_DIR variable needs to be exported on the terminal used for compilation. To setup the TFTP server on the host machine: Configuring your Host PC for TFTPPermalink   The first step is to install all the prerequisite packages for TFTP: $ sudo apt-get install xinetd tftpd tftp Create a TFTP folder in your desired location with root owner and the “rwx” permission for all users: $ sudo mkdir /tftpboot $ sudo chmod –R 777 /tftpboot $ sudo chown –R root /tftpboot Create a configuration file for the TFTP with the following content. (The server_args parameter must match with the folder created above) $ cat /etc/xinetd.d/tftp service tftp { protocol = udp port = 69 socket_type = dgram wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s /tftpboot disable = no } Restart the xinetd service: $ sudo /etc/init.d/xinetd restart You can place any file at the TFTP folder and load it through U-Boot, you can also create symbolic links from your building directory avoiding to copy and paste your zImage and dtb files every time. Configuring your Host PC for NFSPermalink   Install all the needed packages for NFS: $ sudo apt-get install nfs-kernel-server Create a folder for placing your rootfs: $ mkdir /tftpboot/rfs Add the following line in the end of your /etc/exports file: /tftpboot/rfs *(rw,no_root_squash,no_subtree_check) Restart the NFS service: $ sudo service nfs-kernel-server restart Place your rootfs or create a symbolic link for the NFS folder.    Downloading the SDK Download the MCUXpresso following these steps: Click on “Select Development Board”; Select MEK-MIMX8QX under “Select a Device, Board, or Kit” and click on “Build MCUXpresso SDK” on the right; Select “Host OS” as Linux and “Toolchain/IDE” as GCC ARM Embedded; Add “FreeRTOS” and all the wanted Middleware and hit “Request Build”; Wait for the SDK to build and download the package. Building the image All demos and code examples available on the SDK package are located in the directory <<SDK_dir>>/boards/mekmimx8qx/. This tutorial shows how to build and flash the hello_world demo but similar procedures can be applied for any example (demo, driver, multicore, etc) on the SDK. To build the demo, enter the armgcc folder under the demo directory and make sure that the ARMGCC_DIR variable is set correctly. $ cd ~/SDK_2.3.0_MEK-MIMX8QX/boards/mekmimx8qx/demo_apps/hello_world/armgcc $ export ARMGCC_DIR=<your_path_to_arm_gcc>/gcc-arm-none-eabi-9-2020q2/ Run the build_release.sh script to build the code. $ ./build_release.sh NOTE: If needed, give the script execution permission by running chmod +x build_release.sh. This generates the M4 binary (hello_world.bin) under the release folder. Copy this image to the /tftpboot/ directory on the host PC. NOTE: This procedure shows how to build the M4 image that runs on TCM. To run the image from DDR, use the build_ddr_release.sh script to build the binary under the ddr_release folder. Flashing the image Open two serial consoles, one for /dev/ttyUSB0 for Cortex-A35 to boot Linux, and one for /dev/ttyUSB1 for Cortex-M4 to boot the SDK image. On the A35 console, with a SD Card with U-Boot, stop the booting process and enter the following commands to load the M4 binary to TCM: => dhcp => setenv serverip <ip_from_host_pc> => tftp 0x88000000 hello_world.bin => dcache flush => bootaux 0x88000000 Then the M4 core will load the image to the /dev/ttyUSB1 console.    

SW Environment Setup: 1. Prepare L5.10.35 Yocto and build Image  The prebuilt image also is available and useable. 2. Flash image to the SD card  Refer to the Yocto User Guide. 3. Compile flash.bin without M4 and flash it to sdcard (flash.bin as attachment)  make SOC=iMX8QM flash sudo dd if=flash.bin of=/dev/sde bs=1k seek=32 conv=fsync HW Environment Setup: Prepare the imx8qm MEK CPU board and base board and DB9 male cable, connect to CAN0 and CAN1 female connector on base board. (Pin to Pin connection) Capture.JPG User Case: 1. Power on board and configure specify dtb file in uboot  setenv fdt_file imx8qm_mek.dtb 2. Boot up and config bitrate for can0 and can1 in kernel root@imx8qmmek:~# ip link set can0 up type can bitrate 500000 root@imx8qmmek:~# ip link set can1 up type can bitrate 500000 3. Check CAN0 and CAN1 devices root@imx8qmmek:~# ifconfig can0: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 85 can1: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 86 3. Run candump for CAN1 root@imx8qmmek:~# candump can1 & [1] 1215 [ 65.624580] can: controller area network core [ 65.630225] NET: Registered protocol family 29 [ 65.641158] can: raw protocol 4. Run cansend for CAN0 root@imx8qmmek:~# cansend can0 5A1#11.2233.44556677.88 can1 5A1 [8] 11 22 33 44 55 66 77 88   The above red is output result from CAN1.

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 hongting_dong_0-1630284809892.png   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. qiang_limpu_se_0-1629784287984.png   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