i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
This demo for all(bootloader, device tree, Linux kernel, rootfs) in spi. It uses raw read(sf read)/raw write(sf write in uuu script) to achieve that. sf probe 0; sf read ${fdt_addr} 0x500000 0x100000; sf read ${loadaddr} 0x600000 0x1E00000; sf read ${initrd_addr} 0x2400000 0x600000; setenv bootargs console=${console},${baudrate} earlycon=${earlycon},${baudrate} rdinit=/linuxrc; booti ${loadaddr} ${initrd_addr} ${fdt_addr} |-- 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch --- patch for this demo |-- demo_binary | |-- flash.b0.bin --- b0 bootloader | |-- flash.bin --- c0 bootloader | |-- Image-imx8qxpc0mek.bin --- Linux kernel | |-- imx8qxp-mek.dtb --- device tree | |-- uramdisk_boot.rootfs.aarch64.img --- ram disk | |-- uuu.qspi.all.b0.uuu --- uuu script for b0 | `-- uuu.qspi.all.uuu --- uuu script for c0 `-- readme.txt --- this file # The spi layout used is: # - --------- -------------------------------------------- # | | flash.bin | env | dtb | Image |rootfs| # - --------------- -------------------------------------- # ^ ^ ^ ^ ^ ^ ^ # | | | | | | | # 0 4kiB 4MiB 5MiB 6MiB 36MiB 42MiB 0x1000 0x400000 0x500000 0x600000 0x2400000 Test: HW: i.MX8QXP MEK SW: lf-5.10.72-2.2.0 + 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch Test log: SF: Detected mt35xu512aba with page size 256 Bytes, erase size 128 KiB, total 64 MiB device 0 offset 0x500000, size 0x100000 SF: 1048576 bytes @ 0x500000 Read: OK device 0 offset 0x600000, size 0x1e00000 SF: 31457280 bytes @ 0x600000 Read: OK device 0 offset 0x2400000, size 0x600000 SF: 6291456 bytes @ 0x2400000 Read: OK [ 4.787552] imx6q-pcie 5f010000.pcie: unable to add pcie port. [ 4.797467] Freeing unused kernel memory: 2944K [ 4.807379] Run /linuxrc as init process Starting syslogd: OK Starting klogd: OK Running sysctl: OK Starting network: OK /bin/sh: can't access tty; job control turned off / #  
View full article
This is about the case studay from two USB related issues: #1. Plugin detection issue caused by an errata in i.MX8/8X (host mode).       Very limited unit may encounter this problem. When issue happens, there will be totally no action on USB host port when a debug plugged in. #2: High Speed disconnection detection issue (host mode):       This may happen on some special USB design which have complex circuit and connector design on the USB path and long USB cable. The USB enumeration might be interrupted by an un-expected disconnection event. System log shows USB recognition started but failed at several different stages during handshake. For details, please refer to the doc attached (#1/#2). A reference patch for each has also been made by David.
View full article
Hello everyone, We have recently migrated our Source code from CAF (Codeaurora) to Github, so i.MX NXP old recipes/manifest that point to Codeaurora eventually will be modified so it points correctly to Github to avoid any issues while fetching using Yocto. Also, all repo init commands for old releases should be changed from: $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b <branch name> [ -m <release manifest>] To: $ repo init -u https://github.com/nxp-imx/imx-manifest -b <branch name> [ -m <release manifest>] This will also apply to all source code that was stored in Codeaurora, the new repository for all i.MX NXP source code is: https://github.com/nxp-imx For any issues regarding this, please create a community thread and/or a support ticket. Regards, Aldo.
View full article
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 8/8X DDR Tools Overview   This page contains the latest releases for the i.MX 8/8X DDR Tools. The tools described on this page cover the following i.MX 8/8X Family SoCs with the System Controller Unit (SCU): i.MX 8QuadMax and its derivatives i.MX 8QuadPlus i.MX 8QuadXPlus and its derivatives i.MX 8DualXPlus and i.MX 8DualX  i.MX 8DXL (i.MX 8XLite) and its derivatives i.MX 8SXL  NOTE: For the i.MX 8M Family of DDR tools please refer to the : i.MX 8M Family DDR Tool Release                           The purpose of the i.MX 8/8X 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 8/8X DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test   For more details regarding these DDR tools and their usage, refer to the MX8X_DDR_Tools_quickstart_guide.pdf attached to this page.   i.MX 8/8X DDR Register Programming Aid (RPA)   The i.MX 8/8X 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 in two formats (in separate Excel worksheet tabs):   DDR Stress Test script: This format is used specifically with the DDR stress test by first copying the contents in this worksheet tab and then pasting it to a text file, naming the document with the “.ds” file extension. The user will select this file when executing the DDR stress test. DCD CFG file: This format is the configuration file used specifically by the SCU Firmware (SCFW). In this scenario, the user copies the contents in this worksheet tab and pastes it to a text file, naming the document with the “.cfg” file extension and placing this file in the appropriate SCFW board file directory.   i.MX 8/8X DDR Register Programming Aid (RPA): Current Versions Note: In all cases, the RPA revision is aligned to a minimum SCFW version as shown in the table below. In some cases, the BSP alignment is provided as extra detail, however, the RPA tool is specifically aligned to a minimum SCFW version and later. To obtain the latest RPAs, please refer to the following links (note, existing RPAs have been removed from this main page and moved to the SoC specific links below): i.MX8QM: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX8QXP/QXP/DX: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302 i.MX8DXL/SXL: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8DXL-DDR-Register-Programming-Aid-RPA/ta-p/1602262   Processor Mask Revisions Memory Supported Latest RPA Version * Notes i.MX 8QM B0 LPDDR4 Rev 23*** Rev 22** Rev 21** Rev 20** Rev 19** Rev 23: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev22: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 21: Fixed 1 DRC operation to comment out calls to VREF training to DRC1 and added DDRC_SCHED register programming to align with latest SCFW programming (refer to RPA revision history for more details). Rev 20: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 19: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 LPDDR4 Rev 16*** Rev 15** Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 DDR3L Rev 23 Rev 22*** Rev 21 Rev 20 Rev 23:  -Corrected Register Configuration DDR_PHY_PTR4.tDINIT1 bit field programming. Previously, the calculation was based on tRFC only, however, the calculation should have been based on "tRFC+10ns". This was corrected. -Set DDRC_INIT4, DDR3 MR2.ASR=1 as the default setting to allow for the DRAM to select the self refresh rate automatically based on its case temperature (but user has the option to disable via pull-down menu). Also, removed conditional setting for DTCR0.DTRDBITR as it is not needed since DDR3 does not support DBI. Default setting of this was zero and will remain that way. -Provided option to user to select auto refresh rate based on the intended max temperature of the DDR3L device (1X, 2X, 4X). User should confirm with the DDR3L data sheet for supported temperature ranges and associated refresh rate. Rev 22: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 21: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW. -Compatible with SCFW 1.1.10 and later -Changes made to this revision do not affect the DCD CFG file output based on v19 -Issue discovered in the DDR stress test script, wherein certain commands were not being properly configured based on the ECC setting in the Register Configuration worksheet; this was resolved (cells A84, A87, A90, A93 ) -In addition, in both DCD CFG and DDR stress test script worksheets, all commands that depend on ECC config have been updated to include an "OR" with whether or not the data bus is configured for 16-bit (ECC is only supported for full 32-bit data bus width configurations) i.MX 8DualX C0, B0 LPDDR4 Rev 16*** Rev 15* Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8DualX C0, B0 DDR3L Rev 21 Rev 20*** Rev 19 Rev 18 Rev 21: -Corrected Register Configuration DDR_PHY_PTR4.tDINIT1 bit field programming. Previously, the calculation was based on tRFC only, however, the calculation should have been based on "tRFC+10ns". This was corrected. -Set DDRC_INIT4, DDR3 MR2.ASR=1 as the default setting to allow for the DRAM to select the self refresh rate automatically based on its case temperature (but user has the option to disable via pull-down menu). Also, removed conditional setting for DTCR0.DTRDBITR as it is not needed since DDR3 does not support DBI. Default setting of this was zero and will remain that way. -Provided option to user to select auto refresh rate based on the intended max temperature of the DDR3L device (1X, 2X, 4X). User should confirm with the DDR3L data sheet for supported temperature ranges and associated refresh rate. Rev 20: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 19: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  -Compatible with SCFW 1.1.10 and later * For a history of the previous versions of an RPA, refer to the Revision History tab of the respective RPA.  ** In general, it is recommended to use the latest RPA tool even with a pre-released BSP as it ensures you are testing with the latest fixes and features. Older versions of the RPA may be provided to support existing/released versions of the BSP.  This only applies to those RPA tools that are compatible with pre-release BSPs but may not be compatible with released versions of the BSP.   ***IMPORTANT: as stated in the table above, for the noted RPA version, it is aligned to SCFWv1.7.0 (and later SCFW versions).  Older versions of the RPA are not aligned to SCFWv1.7.0 (and later SCFW versions).  If trying to use an older version of an RPA with SCFWv1.7.0 (and later SCFW versions), it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QXP/DualX: DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ For MX8QM: DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 (and later SCFW versions) (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QXP: [remove] ifndef SCFW_DCD [remove] /* For 1200MHz DDR, DRC 600MHz operation */ [remove] DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ [remove] #else <keep code as is> [remove] #endif Note: when it is stated "SCFWv1.7.0 (and later SCFW versions)", it implies SCFWv1.7.0, 1.7.1, 1.7.2... 1.8.0, 1.9.0, 1.10.0... etc., where "..." are minor versions/patches, so when you see 1.7.2... it implies 1.7.3, 1.7.4, etc.).  Unless otherwise noted, the latest RPA shown in the table above is aligned to the latest SCFW release.    i.MX 8/8X DDR Stress Test    The i.MX 8/8X 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 to building the SCFW for use with u-boot and OS bring-up. The DDR stress test uses the .ds DDR stress test script generated from the RPA tool along with a special build of the SCFW, built with option: DDR_CON=ddr_stress_test_parser Or in the case of i.MX 8QuadMax use of one DDR Controller: DDR_CON=ddr_stress_test_parser_DRC0_only The DDR stress test offers a Target option to dictate which SoC is under test. The following are Target options to select from: MX8QM – used to test i.MX 8QuadMax and its derivatives i.MX 8QuadPlus MX8QX – used to test i.MX 8QuadXPlus and its derivatives i.MX 8DualXPlus/DualX MX8DXL – used to test i.MX 8DXL and its derivatives i.MX8 SXL     To install the DDR Stress Test, save and extract the zip file mx8_ddr_stress_test_ERxx_installation.zip   (where 'xx' is the current version number) and follow the on-screen installation instructions. Note, when extracting the DDR Stress Test tool .zip file, it is recommended to perform an "Extract here" operation.  Some systems do not allow for the extracted installation executable to run from another folder and will only work when being executed from the same location as the original, downloaded zip file.  For more details on the DDR stress test usage, refer to the MX8_DDR_Tool_User_Guide found in the DDR Stress Test tool delivery. NOTE: Before using the DDR tools on a new custom board, the user should properly port the SCU Firmware (SCFW) to this new board. The DDR tools will not be able to run without a properly ported and working SCFW.            i.MX 8/8X DDR Stress Test Requirements The tool requires access to the Windows registry, hence users must run it in administrator mode. The tool cannot run on an OEM closed device that requires images signed by the customer When users design new i.MX 8/8X boards, please make sure to follow the rules outlined in the respective Hardware Developers Guide and the MX8_DDR_Tool_User_Guide, which can help users bring up DDR devices on their respective i.MX 8/8X boards.   i.MX 8/8X DDR Stress Test SECO Firmware It is generally not recommended to update the SECO (ahab) firmware that comes default with the DDR Stress Test. This is not recommended because the purpose of the DDR Stress Test is to test the DDR memory interface, not the entire SCFW to SECO firmware operation even though a newer version of the SCFW may complain that the SECO firmware version is not the latest. The SECO firmware version that comes with the DDR Stress Test has been tested and proven to work by the factory before the DDR Stress Test release; updating the SECO firmware to a different version may result in unintended consequences rendering the DDR stress test inoperable. In most cases, it is allowable to update only the SCFW without updating the SECO firmware. Should the user wish to update the SECO firmware version in the DDR Stress Test, then they will need to rename this firmware without the silicon version (for example, if updating the MX8QM SECO firmware, the user will need to rename mx8qmb0-ahab-container.img to mx8qm-ahab-container.img, basically remove the “b0”). The exception is for the MX8QXP, if updating the C0 silicon version SECO firmware, then the user should maintain the C0 nomenclature. If the user finds that the updated SECO firmware causes the DDR Stress Test to become inoperable, then it is recommended to revert to the default SECO firmware version that came with the DDR Stress Test release. i.MX 8/8X DDR Stress Test User Guide The i.MX 8/8X DDR Stress Test tool includes the document: MX8_DDR_Tool_User_Guide.pdf NOTE: Please read the MX8_DDR_Tool_User_Guide inside the package carefully before you use this tool.   DDR Stress Test Revision History   Rev Major Changes (Features) NXP BSP Software Version ER 14 Updated to support parsing of the VREF training command in the DDR Stress Test script This version is aligned with NXP BSP GA version L5.4.3_2_0_0 and later. ER15 - Support for i.MX 8Lite (aka DXL) - Provides more verbose output in event of data training failures, specifically on which byte lanes failed - Aids in debug of board layout issues This version is aligned with NXP BSP GA version Linux 5.15.71_2.2.0 and later.    Related Resources Links: i.MX 8ULP DDR tools: i.MX Software and Development Tools | NXP Semiconductors Scroll down to “Other Resources --> Tools --> DDR Tools” i.MX 8M Family DDR Tool Release  i.MX 6/7 DDR Stress test GUI Tool i.MX 8QM RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX 8QXP/DXP/DX RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302 i.MX 8DXL (i.MX 8XLite) RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8DXL-DDR-Register-Programming-Aid-RPA/ta-p/1602262   FAQs: Q. When the DDR stress test is running, it indicates testing region 1 and then region 2. What is region 1 and region 2? A. There are two distinct DDR memory regions in the i.MX8X series which is due to the architecture of Cortex A core and the associated memory map of the i.MX8X. Region 1 is the 32-bit region, starting at 0x080000000 and ending at 0x0FFFFFFFF (2GB total) Region 2 is the 64-bit region (for the Cortex A core architecture), starting at 0x880000000 and ends at the remaining density: • For 4GB total on board density, 2GB for region 1 and 2GB for region 2, so region 2 will end at 0x8FFFFFFFF (0x900000000 minus 1) • For 6GB total (NXP board density), 2GB for region 1 and 4GB for region 2, so region 2 will end at 0x97FFFFFFF (0x980000000 minus 1) • For 8GB total, 2GB for region 1 and 6GB for region 2, so region 2 will end at 0x9FFFFFFFF (0xA00000000 minus 1) Hence there is a “hole” in the memory map between region 1 and region 2. As such, the DDR stress test first tests the lower region (region 1) until it is exhausted (up to 2GB), and if the DDR density exceeds 2GB, the test will test the remaining density in region 2. Q. Do the i.MX8X series SoCs support LPDDR4 memories with 17 row addresses (R[16:0])? A. The i.MX8QM, i.MX8QXP, and i.MX8DXP SoCs and their derivatives cannot support newer 17-row-address LPDDR4 memories. This means, in order to support the maximum 4GB (32Gb) LPDDR4 density, the configuration must be 16-row, 2 rank (as opposed to the unsupported 17-row, 1 rank). The upcoming i.MX8DXL is planned to support 17-row address LPDDR4 devices. Q. I can select a different i.MX8X AP UART port when running the DDR Stress Test? A. It is highly recommended to follow NXP board designs including selecting the same UART ports; this eases the user’s software porting efforts and minimizes issues with needless debugging. The DDR Stress Test requires the use of the USB OTG port and the AP UART port (and it is highly recommended to connect the SCFW UART port for SCFW debug messages). To date, the factory sees no reason why the user would need to select a different AP UART port than what is used on NXP boards. Selecting the same AP UART port ensures a faster bring up of the DDR stress test rather than needlessly debugging why a different UART port is not working. In any event, some wish to use a different UART port for whatever reason, as such, NXP has placed work arounds to allow the selection of a different UART port. To select a different UART port (0,1, or 2), the user simply needs to add the following line to the end of the DDR Stress Test DDR initialization (.ds) script: memory set  0x5C01042C 32   <UART port value> memory set  0x5C01042C 32   0x00000000   # UART0 port selection for AP UART (default) memory set  0x5C01042C 32   0x00000001   # UART1 port selection for AP UART memory set  0x5C01042C 32   0x00000002   # UART2 port selection for AP UART Note that UART ports 0, 1, and 2 have pad names that are default UART pins (IOMUX ALT0 config). To date, the DDR tools do not support other UART ports that are mux’d out on other non-default UART pins. However, there is an exception for i.MX8QXP/DXP and the upcoming i.MX8DXL where UART3 mux’d out on FLEXCAN2 can be used. To select this, add the following to the end of the .ds file: memory set  0x5C01042C 32   0x00000003   # UART3 port selection for AP UART (exception for i.MX8QXP/DXP and i.MX8DXL) Some RPAs do have support built in (via a pull down menu) to select the UART port. For those RPAs that do not have this feature, this is due to the fact that these RPA (NXP boards) were not tested with a different UART port as the board requires cutting traces and re-wiring the UART signals and some boards may not have these UART traces readily available. However, the user is still able to manually add this UART port selection. Refer to the following RPAs to see the UART port select option: MX8QXP DDR3 MX8DXP DDR3 Q. Why does the DDR stress test appear to hang when testing [MX8QM with 8GB (64Gb) or MX8QXP with 4GB (32Gb)] of LPDDR4 memory? A. The issue is not caused by the DDR stress test itself but by the version of the SCFW being used. The default version of the SCFW binary pre-dates a change made by the SCFW to ignore DRAM density limitations when it detects that the DDR stress test is running. This version of the SCFW associated with the DDR stress test ER14 limits the testable DRAM density to [MX8QM: 6GB, MX8QXP: 3GB], as this version of the SCFW is configured to operate on NXP boards as a basis. As noted in the DDR stress test user guide, it is recommended for users to port the latest SCFW to their board first before using the DDR stress test to account for board differences between NXP’s board and their board.  In addition, the user has the following options to enable testing beyond [MX8QM: 6GB, MX8QXP: 3GB]; note it is the responsibility of the user to ensure a properly working, ported version of the SCFW prior to operating the DDR stress test. 1. The latest SCFW should contain an update that sets no density limit if it is detected that the SCFW is built for usage with the DDR Tool - the user can try to get the latest porting kit and build the new firmware.  This is the recommended change. 2. In board.c, function board_system_config(), there is this chunk of code (MX8QM example shown) if using an existing/older SCFW that pre-dates this change: /* Board has 6GB memory so fragment upper region and retain 4GB */         BRD_ERR(rm_memreg_frag(pt_boot, &mr_temp, 0x980000000ULL,             0xFFFFFFFFFULL)); User can modify it as follows:     if (ddrtest == SC_FALSE)     {         sc_rm_mr_t mr_temp;         /* Board has 6GB memory so fragment upper region and retain 4GB */         BRD_ERR(rm_memreg_frag(pt_boot, &mr_temp, 0x980000000ULL,             0xFFFFFFFFFULL));         BRD_ERR(rm_memreg_free(pt_boot, mr_temp));     } This is disables execution of this section of code if the SCFW is built for the DDR Tool (the same as 1. but needs to be done by the user manually when using an earlier firmware version). 3. Change 0x980000000 to 0xA00000000 in the above chunk of code. That should allow for 8GB density for MX8QM example shown above (for MX8QXP, change 0x8C0000000ULL to 0x900000000ULL for 4GB density).  
View full article
  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 i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/...  
View full article
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.
View full article
This is a summary for the software lockup issue found in the following platform: −i.MX8/8X −Linux 4.14.98_2.3.3   Issue description: •Issue happens during the boot procedure, at the systemd stage. •The symptom of the issue: −From user perspective, the symptom varies, but mainly fall into several types: §At the console, there may be login prompt, but no response (only echo) when input user/password. Unable to login. §Some user service in systemd failed to start. E.g. weston. −When checking the task status using sysrq (w/t), many tasks, including some kernel core tasks stays in “D” (uninterruptable sleep) state. E.g. agetty, login, chvt, etc. •Kernel itself is still alive. This can be verified by triggering some drivers, such as plugin a USB device. Issue can be reproduced on MEK through long time stress.   Please refer to the doc/patch attached for details.
View full article
i.MX8 series contains internal HiFi4 DSP. It is targeted for Audio related signal processing. SOF (Sound Open Firmware) is open source audio DSP firmware, driver and SDK. This document introduces basic theory about IIR/FIR digital filters, how to design IIR/FIR digital filters and the Equalizer filters implementation by SOF. After that, the document also describes how HiFi4 DSP MAC engine accelerate the EQ filters calculation.
View full article
BSP: L5.15.5_1.0.0   Platform: i.MX8MPlus EVK   1. Parameter preparation For more parameter calculation, please refer to: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-8M- Mini-Register-Programming-Aid-DRAM-PLL-setting/ta-p/111209  For 1866MHz LPDDR4, we need a DRAM PLL size of 933MHz. The PLL dividing parameters are: m=622,p=16,s=0, k=0.   2. Calibration and stress test with DDR Tool 2.1 Creating a test script for 1866MHz Here we copy the script from another file (e.g. 2000MHz) and modify the contents of the script.   2.2 Modify the script to adapt to 1866MHz 2.3 Download the test script After selecting the ddr script we created, click on the download button   2.4 Calibrating the stress test Set the core clock of the chip's cpu to 1.2GHz, then click the Calibration button to calibrate, then click Gen Code to generate the lpddr4_timing.c file. Set the start frequency to 1866MHz for the stress test.   2.5 Modify lpddr4_timing.c We need to modify the generated lpddr4_timing.c file to change the maximum speed to 3732MTS.   3. SPL patch After getting the correct lpddr4_timing.c file, the SPL code also needs to be modified to add support for the 933MHz DRAM PLL. diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c b/arch/arm/mach-imx/imx8m/clock_imx8mm.c index e39f238fdf...5622a6334e 100644 --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c @@ -55,6 +55,7 @@ static struct imx_int_pll_rate_table imx8mm_fracpll_tbl[] = { PLL_1443X_RATE(650000000U, 325, 3, 2, 0), PLL_1443X_RATE(600000000U, 300, 3, 2, 0), PLL_1443X_RATE(594000000U, 99, 1, 2, 0), + PLL_1443X_RATE(933000000U, 622, 16, 0, 0), PLL_1443X_RATE(400000000U, 400, 3, 3, 0), PLL_1443X_RATE(2660000U, 266, 3, 3, 0), PLL_1443X_RATE(167000000U, 334, 3, 4, 0), diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index 326b92d784..ebd005bc2b 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -117,6 +117,10 @@ void ddrphy_init_set_dfi_clk(unsigned int drate) dram_pll_init(MHZ(1000)); dram_disable_bypass(); break; + case 3732: + dram_pll_init(MHZ(933)); + dram_disable_bypass(); + break; case 3200: dram_pll_init(MHZ(800)); dram_disable_bypass();   4. Test results   Reference blog. DDR Tool: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467  RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8MPlus-m865S-DDR-Register-Programming-Aids-RPA/ta-p/1235352 
View full article
This article describes how to integrate NXP WiFi & BT module into i.MX platform, some debug tips, how to test, etc. Although it takes i.MX8MM as example, it is also suitable for all i.MX8 serials platform.
View full article
This doc will show: i.MX8DXL EVK board without connect  hardware LCD display, using FreeRDP to share screen to remote PC which is in same network,  PC take this shared screen could  run any command on i.MX8DXL EVK board.   HW: i.MX8DXL EVK board,  PC  SW: i.MX8DXL Linux 5.15.32 BSP release, and code change in this doc   1> i.MX8DXL Linux kernel side, just use imx8dxl-evk-lcdif.dts, but did not connect any LCD display,  so Linux kernel could create related drm device, and weston could be start. But on 8DXL EVK board, ENET1_RGMII_TXD3 and ADMA_LCDIF_D03 pin conflict,  so need code change as 5.15.32-imx8dxl-evk-lcdif.dts.diff.   2> yocto/bld/conf/local.conf, add below line, as freerdp depend on ffmpeg. LICENSE_FLAGS_ACCEPTED+="commercial"   3> For i.MX8DXL,  weston use software pixman render, to use NEON optimization,  pixman need switch to  latest 0.42.0,  enter folder (yocto/bld/tmp/work/armv8a-poky-linux/pixman/1_0.40.0-r0/pixman-0.40.0),  git clone (https://github.com/freedesktop/pixman.git) and checkout to latest 0.42.0:  Also chaneg related build flag at bb file as pixman_0.40.0.bb.diff.     4> Default  freerdp need switch to 2.8.0, enter folder (yocto/bld/tmp/work/armv8a-poky-linux/freerdp/1_2.4.1-r0/git),  git clone (https://github.com/FreeRDP/FreeRDP.git), check out to 2.8.0; And to use neon accelerate freerdp related function, such as color space conversion, image codec encoding ,  need apply patch  freerdp-codechange-neon.diff. And related bb file compile flag change as freerdp_2.4.1.bb.diff     5> bitbake -c compile ffmpeg bitbake -c install ffmpeg   bitbake -c compile pixman  bitbake -c install pixman    bitbake -c compile  freerdp bitbake -c install  freerdp   Copy  generated new libs to default released i.MX8DXL rootfs, make sure ffmeg , pixman, freerdp related libs are  from your build, for example: libfreerdp-client2.so.2 -> libfreerdp-client2.so.2.8.0 libfreerdp2.so.2 -> libfreerdp2.so.2.8.0 libwinpr-tools2.so.2 -> libwinpr-tools2.so.2.8.0 libwinpr2.so.2 -> libwinpr2.so.2.8.0   6> i.MX8DXL Linux rootfs:  file /etc/xdg/weston/weston.ini,  change start-on-startup to true: [screen-share] command=/usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize --rdp-tls-cert=/etc/freerdp/keys/serve start-on-startup=true   7> i.MX8DXL Linux OS, run below cmd: winpr-makecert -path $PWD copy generated files to /etc/freerdp/keys/server.crt and /etc/freerdp/keys/server.key   8> reboot i.MX8DXL EVK board,  make sure  EVK board and PC in the same network; check i.MX8DXL Linux OS , there are two process name as "weston", one process is weston rdp backend to share screen to PC.   9> PC side, get wfreerdp.exe from  https://github.com/FreeRDP/FreeRDP/wiki/Prebuilds PC side run cmd as: wfreerdp.exe /v:ipaddress_of_8DXLEVK     Reference: 1>https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX#design-resources 2>https://github.com/FreeRDP 3>https://github.com/freedesktop/pixman 4>https://github.com/DLTcollab/sse2neon  
View full article
On behalf of Gopise Yuan. This is a patch to fix USB plug/unplug event detection failure issue on ChipIdea IP under corner case.
View full article
i.MX8 VPU hardware decoder support below video codec: H.265 HEVC Main Profile 4Kp60 Level 5.1 H.264 AVC Constrained Baseline, Main and High profile H.264 MVC WMV9 / VC-1 Simple, Main and Advanced Profile MPEG 1 and 2 Main Profile at High Level AVS Jizhun Profile (JP) MJPEG4.2 ASP, H.263, Sorenson Spark Divx 3.11, with Global Motion Compensation (GMC) ON2/Google VP6/VP8 RealVideo 8/9/10 JPEG and MJPEG A/B Baseline   i.MX8 VPU Linux driver is implemented based on V4L2 standard. Chromium beside software video decoding, it also support hardware video decoder(VideoDecodeAccelerator),  there are some kind of VideoDecodeAccelerator, one of them is V4L2VDA. Please note V4L2VDA is using V4l2 api, so it is possible that change V4L2VDA to enable Chromium hardware video playback on i.MX8.   This doc share patch to add chromium video decode accelerate by using i.MX8QM/i.MX8QXP VPU. It will support chromium H.264, H.265, VP8 hardware video decode. H.264 and H.265 need use mp4 container. VP8 use webm container.   HW: i.MX8QM/i.MX8QXP MEK board, 1080P HDMI display, mouse, keyboard SW: i.MX8 5.10.72_2.2.2 yocto bsp release(which included chromium 91.0), and patch in this doc   Patch description: imx8-5.10.72-vpudrv-update.diff, update i.MX8  5.10.72_2.2.2 kernel vpu driver to https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/mxc/vpu_malone?h=lf-5.15.y&id=fa7c67e2c9ed4fb8392fa258f931d6996339a17a chromium-ozone-wayland_91.0.4472.114.bb.diff, change meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_91.0.4472.114.bb for adding some compile flags, etc. 5.10.72-merge.patch, this patch change chromium source code to add video decode accelerate by using i.MX8 VPU.   Build steps: 1>Download i.MX8 5.10.72_2.2.2 yocto release from nxp.com 2>apply chromium-ozone-wayland_91.0.4472.114.bb.diff to change meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_91.0.4472.114.bb 3>put 5.10.72-merge.patch to folder path_of_yocto-5.10.72-2.2.2/sources/meta-browser/meta-chromium/recipes-browser/chromium/files/ 3>apply imx8-5.10.72-vpudrv-update.diff to i.MX8 5.10.72_2.2.2 kernel 4>under the yocto image build folder, add "CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland" to file path_of_yocto-5.10.72-2.2.2/folder-of-bld/conf/local.conf 5>run bitbake to build rootfs image   Test steps: After system boot up, put some video clip under /home/root/video then run below cmd (do not run chromium without any parameter, as that will start chromium with some other setting, you can check /usr/lib/chromium/chromium-wrapper) "/usr/lib/chromium/chromium-bin   --no-sandbox --ozone-platform=wayland --enable-features=VaapiVideoDecoder  --enable-accelerated-video-decode   --enable-clear-hevc-for-testing --ignore-gpu-blacklist --window-size=1920,1180  /home/root/video" then use mouse to click video clip and will start playback.   Reference: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors:IMX8-SERIES https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX https://www.chromium.org/audio-video/#:~:text=codec%20and%20container%20support https://github.com/igel-oss/meta-browser-hwdecode/blob/master/recipes-chromium/chromium/files/0001-Add-support-for-V4L2VDA-on-Linux.patch      
View full article
On behalf of Gopise Yuan. A collection of several GST debugging tips and known-how. When you need to play onto a DRM layer/plane directly without going through compositor, kmssink should be a good choice: // kmssink, with scale and adjust alpha property (opaque) and zpos (this requires kmssink>=1.16): gst-launch-1.0 filesrc location=/media/AVC-AAC-720P-3M_Alan.mov ! decodebin ! imxvideoconvert_g2d ! kmssink plane-id=37 render-rectangle="<100,100,720,480>" can-scale=false plane-properties=s,alpha=65535,zpos=2 When using playbin, you can still customize the pipeline besides the sink plugin, e.g. add a converter plugin: // Playbin with additional customization on converter before sink: gst-launch-1.0 playbin uri=file:///mnt/MP4_H264_AAC_1920x1080.mp4 video-sink="imxvideoconvert_g2d ! video/x-raw,format=BGRA,width=1920,height=1080 ! kmssink plane-id=44" GST can generate a pipeline graph for analyzing the pipeline in a intuitive manner: // Generate pipeline graph: 1. Export GST_DEBUG_DUMP_DOT_DIR=<dump-folder>, GST_DEBUG=4 2. Run pipeline with gst-launch or others. 3. Copy all dump files (.dot) from <dump-folder>. Note: one dump file will be created for each state transaction. Normally, what we need will be PAUSE_READY or READY_PAUSE, after which pipeline has been setup. 4. Convert the .dot file to PDF with Graphviz: dot -Tpdf 0.00.03.685443250-gst-launch.PAUSED_READY.dot > pipeline_PAUSED_READY.pdf  
View full article
This is a simple known-how for how to enable KASAN on L4.14.98 with i.MX8/8X and also a collection of related patches for fixing issues reported by KASAN.   Enable KASAN: It's very simple, just enable "CONFIG_KASAN" in kernel configuration. Besides this, adjusting the kernel's loading address is also required, due to KASAN (which will alloc more memory as a "tracker" for each allocation). For e.g., on imx8qxp MEK, we need to change the kernel loadaddr in uboot:     0x80280000 --> 0xE0280000 through uboot env: setenv loadaddr 0xE0280000 After this, it supposed to be working.   KASAN related patches on L4.14.98: KASAN will do detection/sanitizing for any memory allocation/access. In case of L4.14.98 on i.MX8/8X, there're several "BUG" reported by KASAN in default BSP. The attached patches are a collection for these issues.    Note: not all "BUG" reported by KASAN are really bug. Most of them are just some programming rule related problems and may not really cause memory access violation.
View full article
  Anyone who want to use this solution should get reference design and firmware from Lontium. Hardware Here is the block diagram of LT9611UXC Demo Board. As the MIPI port of our EVK can provide 5V, 3V3 and 1V8.We can remove useless DC-DC chips from reference design. Below is the LT9611UXC Demo Board. Software Download the firmware into LT9611UXC. In Linux side, we need to drive the MIPI to output signals with standard timings of 1080P. Panel type diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts index 1732b5c72380..c6a829be541f 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts @@ -696,13 +716,17 @@ &ldb_phy { &mipi_dsi { status = "okay"; + panel@0{ + compatible = "nxp,lt9611uxc"; + reg = <0>; + status = "okay"; }; }; &snvs_pwrkey { diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 4f78bbf63f33..90d99f12515b 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -4997,6 +4997,34 @@ struct panel_desc_dsi { unsigned int lanes; }; +static const struct drm_display_mode lt9611_panel_mode = { + .clock = 148500, + .hdisplay = 1920, + .hsync_start = 1920 + 88, + .hsync_end = 1920 + 88 + 44, + .htotal = 1920 + 88 + 44 + 148, + .vdisplay = 1080, + .vsync_start = 1080 + 4, + .vsync_end = 1080 + 4 + 5, + .vtotal = 1080 + 4 + 5 + 36, +}; + +static const struct panel_desc_dsi lt9611_panel = { + .desc = { + .modes = &lt9611_panel_mode, + .num_modes = 1, + .bpc = 8, + .size = { + .width = 62, + .height = 110, + }, + .connector_type = DRM_MODE_CONNECTOR_DSI, + }, + .flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_NO_EOT_PACKET | MIPI_DSI_MODE_VIDEO_SYNC_PULSE, + .format = MIPI_DSI_FMT_RGB888, + .lanes = 4, +}; + static const struct drm_display_mode auo_b080uan01_mode = { .clock = 154500, .hdisplay = 1200, @@ -5201,6 +5229,9 @@ static const struct panel_desc_dsi osd101t2045_53ts = { static const struct of_device_id dsi_of_match[] = { { + .compatible = "nxp,lt9611uxc", + .data = &lt9611_panel, + },{ .compatible = "auo,b080uan01", .data = &auo_b080uan01 }, {
View full article
Some customer need to test ENET IEEE1588 1pps ouput signal. This article describe all i.MX8 serials test procedure, including normal ENET port and EQOS port(i.MX8MP & i.MX8DXL support EQOS).
View full article
On behalf of Gopise Yuan. A simple sharing for enabling some kernel options for using “lockdep”. It will be useful for detecting some deadlock (spinlock/mutex/…) issue. Validated on L4.14.x, and, found a lock violation…
View full article
On behalf of Gopise Yuan. In case some customer may make mistake in mechanical design, they may need to flip/mirror the screen. DPR in DPU can do this in a simple way. This patch demonstrate how to enable VFLIP and HFLIP in DPR to do a V+H flip (=180 rotate) of the screen
View full article