Question: To connect an FPGA to the i.MX6Q over LVDS.,to connect the 2 LVDS channels in split mode. The datasheet indicates the driver output max skew due to different propagation time of rising and falling edge. For the sake of the design of their FPGA interface, it would be also interesting to get the skew between the 2 LVDSn_CLK (of the 2 channels) as well as the intrachannel- skew. Answer: Backend database are checked. We can provide the result in the view of design. Since we do not check inter-channel skew in production, the following may not be guaranteed.  At the core boundary, we found that, timing skews between every data and clock are within 30ps. Path from core boundary to PAD are matched by analog layout, should produce some skew well below 30ps also. As the result, I think, all LVDS signal can be considered as one single group, and skew in datasheet can apply to any signal.

[中文翻译版] 见附件   原文链接： i.MX Create Android SDCard Mirror 

Using Clock Out - i.MX31PDK i.MX31 has a clock out pin that can be used to output internal clock signals. On the i.MX31PDK the clock out pin is accessible on TP1. The clock out is controlled by register COSR (Clock Out Source Register) at address 0x53F8001C. There three fields on COSR: Field Description CLKOEN (bit 9) Clock output enable bit CLKOUTDIV (bits 8-6) Clock output divide factor CLKOSEL (bits 3-0) These bits select which clock is to be reflected on the clock output CKO. Here are the values each field may assume: CLKOEN Values CLKOUTDIV Values CLKOSEL Values 1 clock output IO pin is enabled 0 clock output IO pin disabled 000 => 1 001 => 2 010 => 4 011 => 8 100 => 16 0000 => mpl_dpdgck_clk 0001 => ipg_clk_ccm 0010 => upl_dpdgck_clk 0011 => pll_ref_clk 0100 => fpm_ckil512_clk 0101 => ipg_clk_ahb_arm 0110 => ipg_clk_arm 0111 => spl_dpdgck_clk 1000 => ckih 1001 => ipg_clk_ahb _emi_clk 1010 => ipg_clk_ipu_hsp 1011 => ipg_clk_nfc_20m 1100 => ipg_clk_perclk_uart1 1101 => ref_cir1 (ref_cir_gateload) 1110 => ref_cir2 (ref_cir_intrcload) 1111 => ref_cir3 (ref_cir_path) Based on the Clock Generation Scheme, we can play with COSR register using the Register Accessing application to test Clock out pin by checking some i.MX31 internal clocks. Testing First we can check the value of CKIH, it should be 26MHz as a 26MHz is connected to that pin. We can write 0x208 to COSR. [CLKOEN = 1| CLKOUTDIV = 1| CLKOSEL = ckih] root@freescale /home$ ./io2 0x53f8001c w 0x208 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x208 Then we can check pll_ref_clock. We can write 0x203 to COSR. [CLKOEN = 1| CLKOUTDIV = 1| CLKOSEL = pll_ref_clk] root@freescale /home$ ./io2 0x53f8001c w 0x203 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x203 As expected, pll_ref_clock is equals to CKIH because CCMR[PCRS]=10. Reading CCMR to confirm CCMR[PCRS]=10: root@freescale /home$ ./io2 0x53f80000 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80000 (0x4001f000): 0x174B0D7D The pll_ref_clock inputs to MCU PLL and Serial PLL. We can check MCU PLL and Serial PLL configurations on MPCTL (0x53F80010) and SPCTL (0x53F80010) registers respectively. Reading MPCTL and SPCTL: root@freescale /home$ ./io2 0x53f80010 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80010 (0x4001f010): 0x33280C root@freescale /home$ ./io2 0x53f80018 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80018 (0x4001f018): 0x2072356 Determine the PLL multiplication factor from MPCTL and SPCTL: - MPCTL: PD = 1 (0000) | MFD = 52 (0000110011) | MFI = 10 (1010) | MFN = 12 (0000001100) - MCPTL Multiplication Factor: 20,46153 - mpl-dpdgck-clk = 20,46153 * 26MHz = 532 MHz - SPCTL: PD = 1 (0000) | MFD = 520 (1000000111) | MFI = 8 (1000) | MFN = -170 (1101010110) - SCPTL Multiplication Factor: 15,3461538 - spl-dpdgck-clk = 15,3461538 * 26MHz = 399 MHz Finally we can output mpl-dpdgck-clk and spl_dpdgck_clk values to check the calculations above. We can write 0x300 to COSR for mpl-dpdgck-clk. [CLKOEN = 1| CLKOUTDIV = 16| CLKOSEL = mpl_dpdgck_clk] And 0x307 for spl-dpdgck-clk. [CLKOEN = 1| CLKOUTDIV = 16| CLKOSEL = spl_dpdgck_clk] root@freescale /home$ ./io2 0x53f8001c w 0x300 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x300 root@freescale /home$ ./io2 0x53f8001c w 0x307 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x307 By multiplying the results above by 16 to compensate for CLKOUTDIV we have the expected results.

The i.MX 6 D/Q/DL/S/SL  Android JB4.3_1.1.1 Patch release is now available on www.freescale.com ·         Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board o   i.MX6SL EVK board This patch release is based on the i.MX 6 Android JB 4.3_1.1.0-GA BSP release. ·         Release Description o   To upgrade the GPU kernel and libraries to improve GPU stability o   To handle the Android SDK build failure o   To improve FSL OMX The table below describes the contents of this release.      Release Description Patches Contains the patches included in this release. The patches   are described in “Patch Description”. Documentation Contains the following document: • i.MX 6 Android JB 4.3_1.1.1 Patch Release Notes: This   document. ·         Patch Description Please consult the release notes.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343242 

Pre-Sales: i.MX8/8X applications in automotive(Chinese Version) https://community.nxp.com/docs/DOC-345825 i.MX8X website design resource guide: (Chinese Version) https://community.nxp.com/docs/DOC-345676 After-Sales: i.MX8X memory configuration&test application notes: (Chinese Version) https://community.nxp.com/docs/DOC-345803 i.MX8X hardware design guide: (Chinese Version) https://community.nxp.com/docs/DOC-346582 i.MX8X_4.19.35_bootloader customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-345713 i.MX8X_4.19.35_kernal customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-345714 i.MX8X_4.14.98_bootloader customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-342448 i.MX8X_4.14.98_kernal customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-344217 i.MX8X_5.4.24_bootloader customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-347131

The customer would like to test BT.656 using Test mode. Is it supported? 38.4.3.3 Test mode in RM shows only one CSIx_SENS_CONG setting. Does it mean Test mode support only one as follows? Does Test mode support other settings? CSIx_EXT_VSYNC = 0x1 CSIx_DATA_WIDTH = 0x1 CSIx_SENS_DATA_FORMAT = 0x0 CSIx_PACK_TIGHT = 0x0 CSIx_SENS_PRTCL = 0x1 CSIx_SENS_PIX_CLK_POL = 0x1 CSIx_DATA_POL = 0x0 CSIx_HSYNC_POL = 0x0 CSIx_VSYNC_POL = 0x0 For example, customer want to know if Test mode support  CSIx_SENS_PRTCL=0x2or 0x3 instead of 0x1? customer want to know if Test mode support CSIx_SENS_DATA_FORMAT=0x1or 0x2 instead of 0x0? Answer: CSI CM TEST MODE is working as below: 1,only ungated mode. 2,data width should be configured to 8 3,data format should be configured to rgb888 It cannot be other format such as bt656. It uses CSI1_TST_CTRL register to configure {R,G,B} 24 bit value and taking it as RGB888/YUV444 format for further process.  The generated image size is due to the configured width & height in the registers.

The document is a master page for learning i.MX6Q SABRE. It contains several parts as following. The pdf files listed below(item 0, 1, 2) are contained in the NXP official website and others are in the community links. 0. i.MX6 SMART DEVICE SYSTEM(Schematics): SPF-27516_C5.pdf(in the iMX6Q_SABRE_SDB_DESIGNFILES) i.MX 6Quad SABRE Development Board|NXP  1. How to build an image for an i.MX NXP board by using a Yocto Project build environment: Freescale_Yocto_Project_User's_Guide.pdf(in the L4.1.15_1.1.0_LINUX_DOCS) i.MX 6Quad SABRE Development Board|NXP  2. How to build and install the NXP Linux OS BSP: i.MX_Linux_User's_Guide.pdf (in the L4.1.15_1.1.0_LINUX_DOCS) i.MX 6Quad SABRE Development Board|NXP  3. How to Use Trace32 to Run U-boot in the i.MX6Q SABRE Platform: How to Use Trace32 to Run U-boot in the i.MX6Q SABRE Platform  4. Bootloader Boot Procedure for linux OS in i.MX6Q: Bootloader Boot Procedure for linux OS in i.MX6Q  5. Kernel Loading Procedure for Linux OS in i.MX6Q: Kernel Loading Procedure for Linux OS in i.MX6Q 

i.MX8MP and i.MX95 both support USB3.0. In EVK board, USB download pin is USB3.0 with Type-C.  While in other boards, they may delete CC logic design PTN5110, or use USB2.0 signals instead. This document describes how to modify U-Boot to support a design without PTN5110 when using the uuu tool to download.

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the IMX8MM-EVK board using the MCU-LINK Pro. You’ll install the necessary firmware, compile and flash a binary, and finally, initiate a debug session using MCUXpresso for VS Code. Requirements: IMX8MM-EVK Board MCU-LINK Pro Debug Probe PC Host with MCUXpresso for VS Code installed Install Segger Firmware on MCU-LINK Pro By default, the MCU-LINK Pro does not support i.MX processors. Installing the Segger firmware is essential for proper debugging. Follow the firmware update guide to update your MCU-LINK Pro.   Compile the Binary for the M Core Ensure MCUXpresso for VS Code is properly installed.   Import the iMX8MM-EVK SDK   Import "hello world" example Ensure that we are compiling a debug binary Build Project   Flash the Binary using UUU Tool Connect the IMX8MM-EVK Board to your Host PC via USB   Enter Fastboot Mode in U-Boot Terminal => fastboot 0   On your Host PC, navigate to the binary location and flash it using the next commands: $ cd <project_location>/armgcc/debug/ $ uuu -b fat_write hello_world.bin mmc X:1 hello_world_debug.bin Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card Connect MCU-LINK Pro to the Target     IMX8MM-EVK Debug connection:   Launch the M Core from U-Boot Terminal Use the following commands in the U-Boot terminal: => fatload mmc X:1 0x48000000 hello_world_debug.bin; cp.b 0x48000000 0x7e0000 0x20000; => bootaux 0x7e0000 Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card     Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:      With the MCU-LINK Pro configured, the IMX8MM-EVK, and the binary successfully flashed and executed, you are now ready to debug applications on the M core using MCUXpresso and VS Code. This setup enables a reliable development workflow for i.MX8MM based projects.   References: AN14120.pdf 

This article is to show how to use CLK2 for PCIe ref clock for i.MX8MQ. Test Environment  i.MX8MQ + BSP L5.10.52 Background In order to cost down, some customers used CLK2 as PCIe reference clock as below while no external OSC installed, which is different with i.MX8MQ EVK design, so no clock output for PCIe.  Checked L4.14.98_2.3.0 and found it added internal PLL for PCIe clock support. Solution The attached patch based on 4.14.98 can’t be used directly on 5.10.52, the following is the main modification for PLLOUT of PCIe clock. PLLOUT Monitor Configuration Register contains bits to control the clock that will be generated on the CCM clock mapped to CLK2_P/N.        

  Some our customers want to use the mfgtool to download the images to QSPI and boot up. When download the demo images on our website (Linux 4.1.15) to the QSPI-NOR on IMX7D SABRE-SDB. The error occurred as follows: Is it able to program the QSPI-NOR on i.MX7D SABRE-SDB by using MFG-Tool? Answer is yes. In the above error message we can see that the system can not find and detect the qspi, so it can not excute the following code,<CMD state="body="$ flash_erase /dev/mtd0 0 20">Erasing Boot partition</CMD>Updater" type="push" when use the mfgtool to download the images to the QSPI-NOR . The board i.MX7D SABRE-SDB and default BSP are boot up from EPDC.  Here customer want to boot up from QSPI, When using QSPI, you need to de-populate R388-R391, R396-R399 and populate R392-R395, R299, R300 in your hardware. QSPI signals are muxed with EPDC_D[7:0]. You can see the schematic, details you can see as follow. After hardware modify, you can use the mfgtool2-yocto-mx-sabresd-qspi-nor-mx25l51245g.vbs to download. And then boot up from qspi, boot mode you can refer to the schematic boot up setting. Both software and mfgtool you can download here http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx-software-and-tools:IMXSW_HOME. Demo images can documents you can also get.    

Question: What is the correct path for the buffer generated by the GPU and sent to the display? When referring to Linux Manual Chapter 5 "Image Processing Unit (IPU) Drivers" and sect.37.5.68 "Current Buffer Register 0". i.MX6DQ Reference Manual (rev.1  4/2013) and further on text and associated with buffer events interrupts. A lot of printouts in the mxc_ipuv3_fb.c file have been added and in other files located in the drivers/video/mxc/ directory and still unable to capture the interrupt generated by the IPU. An open GL buffer (using the GLES and EGL) is generated with the frame buffer mechanism to a monitor connected to the HDMI output on the evaluation board. Direct it to /dev/fb0. The following functions are used to create EGL context fbGetDisplayByIndex(0) fbCreateWindow(…); Everything works and openGL on the monitor can be seen. To measure how long it takes for the data to be sent to the display/monitor after the buffer is ready in the GPU, can it be done in the IPU if where it is performed is known? Where is the exact location where the interrupt can be captured. The ltib on the Ubuntu 12.04 OS (the alsa-utils package was also installed using some patch)) is installed. Answer: GPU EGL swapbuffer is asyncronous. It means when you call swapbuffer it will not be displayed immediately. If will just flush the command buffer and when the GPU completes the frame, it will be displayed to the scree, To make sure the frame is complete, use glFinish after eglswapbuffer. Also please try with simple program rather using GPU driver to measure time to display on the screen. Swapbufferinterval will work when FB_MULTI_BUFFER = 2. By default it will be 1.

Platform: i.MX8MP SW:Linux 5.4.70.2.3.0 On current linux BSP, PCIE driver does not support Hot-plug, customers wants to turn off PCIE device to save power, attached is guide. Remove PCIE device driver Suspend PCIE driver Turn off PCIE device power supply Turn on PCIE device power supply Resume PCIE driver Rescan PCIE device Load PCIE device driver

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343046 

on Host: libx11-dev libpng-dev libjpeg-dev libxext-dev x11proto-xext-dev qt3-dev-tools-embedded libxtst-dev On Target (i.MX device) alsa-utils libpng tslib

Symptoms   Customer want to add gps dynamic link library as service in android system,but can not be allowed by Android SE Policy. Diagnosis   Customer didn't set the correct config file.   Solution ① Open the file android_build/device/fsl/imx8q/mek_8q/mek_8q.mk, add gnss service   # GNSS HAL PUALPRODUCT_PACKAGES += \[email protected] \[email protected]     ② Open the file android_build/device/fsl/imx8q/mek_8q/manifest.xml and add gnss hidl     android.hardware.gnsshwbinder 1.0 IGnss default     ③ Open the file android_build/device/fsl/imx8q/mek_8q/BoardConfig.mk, add   #GNSS PUALBOARD_HAS_GPS_HARDWARE := true     ④ Open the file android_build/device/fsl/imx8q/mek_8q/ueventd.freescale.rc, add   /dev/ttyLP1 0660 system gps       Add Selinux permissions     Add in device/fsl/imx8q/sepolicy/system_server.te:   allow hal_gnss_default vndbinder_device:chr_file {read };     After adding the test, there are also permission issues such as write, open, etc., we add it all at once:   allow hal_gnss_default vndbinder_device:chr_file {open read write execute getattr create ioctl map};

Question: The code signing tool(CST) of i.MX6 with "CST -h" command just for viewing help message took about 22 minutes. On other system, it was shorter but still took about 2 minutes. CST version is BLN_CST_MAIN_02.00.00. More test results: 1. Print help message => 4 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --help && date Fri Oct 18 14:10:52 KST 2013 Fri Oct 18 14:15:01 KST 2013 2. Signing 512MB file => 11 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --output "out_system.csf" < "example_system.csf" && date Fri Oct 18 14:15:01 KST 2013 CSF Processed successfully and signed data available in out_system.csf Fri Oct 18 14:25:47 KST 2013 3. Signing 3MB file => 17 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --output "out_kernel.csf" < "example_kernel.csf" && date Fri Oct 18 14:25:47 KST 2013 CSF Processed successfully and signed data available in out_kernel.csf Fri Oct 18 14:42:39 KST 2013 4. Signing 160KB file => 2 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --output "out_uboot.csf" < "example_uboot.csf" && date Fri Oct 18 14:42:39 KST 2013 CSF Processed successfully and signed data available in out_uboot.csf Fri Oct 18 14:45:05 KST 2013 Answer: The slow performance is caused by lack of entropy source and it takes long time to initialize random number generator. Check amount of entropy  "cat /proc/sys/kernel/random/entropy_avail" Tried to install package rng-tools. 1. $sudo apt-get install rng-tools 2. add the following settings in /etc/default/rng-tools HRNGDEVICE=/dev/urandom RNGDOPTIONS=”-W 90% -t 1? 3. sudo /etc/init.d/rng-tools restart 4. cat /proc/sys/kernel/random/entropy_avail After rng-tools starts, entropy increases from less than 100 to more than 1000, then command ./cst -h can run very smoothly.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343178 

Booting from NAND    Some hardware configurations (switches) must be set for booting from NAND:    On the debug board:      Switch SW4 -> 10000001      Switch SW5 -> Off      Switch SW6 -> Off      Switch SW7 -> Off      Switch SW8 -> Off      Switch SW9 -> Off      Switch SW10 -> Off    On the personality board:      Switch SW21 -> 10011000      Switch SW22 -> 00100000 Booting from SD Card    Some hardware configurations (switches) must be set for booting from an SD card:       On the debug board:      Switch SW4 -> 10000001      Switch SW5 -> Off      Switch SW6 -> Off      Switch SW7 -> Off      Switch SW8 -> Off      Switch SW9 -> Off      Switch SW10 -> Off    On the personality board:      Switch SW21 -> 11000000      Switch SW22 -> 00000000