i.MXプロセッサ ナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX Processors Knowledge Base

ディスカッション

ソート順:
Hi, this is a smart server called Duckbill in a thumb-drive format based on the i.MX283. It's a really low cost solution usable with or without casing. It is intended to be set up as a small home-server for automation purposes. It comes with Debian Linux as operation system but without any specific user programs.  The stick can be operated either at a USB power adaptor or at a USB port of your router.  Since Duckbill runs Linux you are totally free in software development. The internal connectors can be used as UART, SPI, I2C, ADC or GPIO. So it's up to everyone to develop his own expansion board. 1. Duckbill without casing (top) 2. Duckbill without casing (bottom) 3. Duckbill with casing 4. Duckbill for development purposes 5. Duckbill with integrated EnOcean module If you want to know more about this product: http://www.i2se.com/homeautomation.html
記事全体を表示
This document describes the i.MX 8MQ EVK HDMI output and mini-SAS connectors features on Linux and Android use cases, covering the supported daughter-board, the process to change Device Tree (DTS) files or Boot Images, and enable these different display options on the board.
記事全体を表示
In order to get Redboot running on i.MX35 PDK without a flashing procedure, a little modification in the binary file is needed. After that it can be loaded into RAM memory using the ATK tool. The Redboot Header To execute the binary Redboot file a header of 32 bytes long must be added: ddccbbaa0000000000000000hhggffee00000000000000000000000000000000 Where ddccbbaa is the 4-byte start address and hhggffee is the start address (all in Hexadecinal format) modified by the following procedure: value - 0x20 (or 32 decimal) + 0x08 (or 8 decimal) Note that in this header the values are placed from LSB to MSB bytes, so if the start address for MX35PDK is 0x87F00000 then the header should looks like: Start Address    --> 0x87F00000                                               --> 0000F087 Modified Address --> 0x87F00000 - 0x20 + 0x08 = 0x87EFFFE8 --> E8FFEF87 Header --> 0000F0870000000000000000E8FFEF8700000000000000000000000000000000 Now, this header must be appended to the beginning of the redboot.bin file.
記事全体を表示
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).  
記事全体を表示
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-344485 
記事全体を表示
The iMX8QM LVDS has followed work mode, (There are two LVDS modules in IMX8QM): Single mode (LVDS panel connects to one channel) panel 1 and panel 2 can be different panels: Dual channel split mode (The panel needs two LVDS channels, CH0 for 1,3,5,7,... pixels and CH1 for 2,4,6,8,... pixels): Mirror dual mode (The two panels on same LDB PHY should be same panels on pixel clock and resolution, panel 1 and panel 2 are same; panel 3 and panel 4 are same): The reference patch is based on L5.4.3_GA1.0.0 BSP. LVDS single mode and dual channel split mode are supported in default Linux BSP. Patch 0002 can be used to test this dual mode on MEK board, some rework is needed on MEK board:     R194, R195, R208, R209, R213, R214 should be mounted. And the I6263 board can't be connected to LVDS0_CH0 and LVDS0_CH1 at the same time. The I6263 board can't be connected to LVDS1_CH0 and LVDS1_CH1 at the same time too. Note: for iMX8QXP, there is no mirror dual mode support, because its two LVDS ports are from two different LDB modules, there are no CH1 for them: Note: for iMX8QXP dual channel split mode (The pixel order can be switched: LDB1_CH0 for 1,3,5,7,... pixels and LDB2_CH0 for 2,4,6,8,... pixels; or LDB2_CH0 for 1,3,5,7,... pixels and LDB1_CH0 for 2,4,6,8,... pixels), iMX8QM LVDS has no such feature.
記事全体を表示
Several customers met uuu failure because their board doesn't use same CC logic (ptn5110) of i.MX8MM EVK. For this problem it's able to disable CC logic and to force device mode of u-boot. Shared the patch based on 4.14.78 for reference.
記事全体を表示
since we have already released the patch for 3.10, this patch is for kernel 3.14
記事全体を表示
The document descript how to use the win32diskimager to create bootable sdcard.  How to resize sdcard mirror rootfs partition. Ex: fsl-image-validation-imx-imx6qpdlsolox.sdcard
記事全体を表示
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-342837 
記事全体を表示
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.
記事全体を表示
The i.MX53 family of processors represents Freescale's next generation of advanced multimedia and power-efficient implementation of the ARM Cortex™-A8 core with core processing speeds up to 1.2 GHz. It is optimized for both performance and power to meet the demands of high-end, advanced applications. Ideal for a broad range of applications in the consumer, automotive, medical and industrial markets, the i.MX53 includes an integrated display controller, full HD capability, enhanced graphics and connectivity features. i.MX Family Comparison Product Information on Freescale.com i.MX534 Multimedia Applications Processor i.MX535 Multimedia Applications Processor i.MX536 Multimedia Applications Processor i.MX537 Multimedia Applications Processor Evaluation/Development Boards and Systems i.MX53 Quick Start Board Android How to enable WIFI support for iMX53 QSB Android IMX53 QSB android recovery mode Linux I.MX53 QSB Board Get Started How to flash a 4GB SD Card with the image used in training Enabling Dual Display in UBUNTU with the iMX53 QSB @running_dual_display SABRE Platform for Tablets based on i.MX53 Linux i.MX53 ARD Dual LVDS Enabling Dual LVDS panels i.MX53 USB Eth NFS Using an USB/Eth adapter to boot NFS User Applications i.MX53 Qt LVDS display Touch on Qt with LVDS display Embedded Software and Tools Android OS for i.MX Applications Processors i.MX53 Current Software Updates and Releases Partners / 3rd-Party Development Tools Rainbow-G11D:  i.MX53 Development Kit (iWave Embedding Intelligence) STKa53:  Starterkit STKa53 (Technology in Quality) DS-5:  ARM Development Studio 5 (ARM) Additional Resources Board Bring-up and DDR Initialization Tools Building QT5 for i.MX53 Change AUDMUX src_port causes "imx_ssi_irq mxc_ssi SISR 8003a3 SIER 180100 fifo_errs=XXXX" ConnectCore® i.MX53 / Wi-i.MX53 by Digi International Develop a Simple OpenVG Application Under Linux: Tutorial Embedded i.MX5x Application Development Kit for Android -$199 HDMI Audio Setting How to Enable the souphttpsrc Plugin on i.MX53 i.MX53 ARD Dual LVDS Imx53-fastboot-example i.MX53 Memory Calibration Script (AN4466) i.MX53 QSB Android Recovery Mode I.MX53 QSB Board Get Started i.MX53 QSB Board Video IMX53 QSB enable WIFI android i.MX53 QSB Ubuntu Dual Display i.MX53 Quick Start Board IMX53 SABRE AI i.MX53 Start-R Lab Exercise - Prof. Massimo Violante Politecnico of Torino i.MX53 Start-R Lab Exercise - Developing a loadable kernel module to manage GPIOs in i.MX53QSB i.MX53 USB Eth NFS i.MX53 Qt LVDS Display NOVPEK i.MX53 by NovTech Running Dual Display on i.MX53QSB bin2txt.pyw (U-boot splash screen support)
記事全体を表示
The document to descript change the u-boot environment variables under the Linux rootfs.  Also provide a demo on i.MX6ull evk of sdcard mirror.  Linux fw_printenv fw_setenv to access U-Boot's environment variables.pdf  --- the document fw_printenv_fw_setenv_demo_iMX6ullevk_L4.14.98_2.0.0_ga.sdcard  --- demo sdcard mirror
記事全体を表示
When working with an evaluation kit you will be provided with a System Controller Firmware (SCFW) binary included in your BSP. This scfw binary has been tailored for that specific board and you might need to modify some board dependencies to fit your specific hardware. This document aims to provide an overview on the SCFW porting process, for detailed information please refer to the System Controller Porting guide (sc_fw_port.pdf).   Setting up the system The SCFW is built on a Linux host. The steps to set-up your system are the following: Download the GNU ARM Embedded Toolchain: 6-2017-q2-update June 28, 2017 from the ARM website: Select a directory to untar the file unto, for instance: mkdir ~/gcc_toolchain cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ cd ~/gcc_toolchain/ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   Set TOOLS environment variable to the directory containing the tool chain, "~/gcc_toolchain" on the example above, .bash_profile can also be modified to export this environment variable: export TOOLS=~/gcc_toolchain/ srec_cat is also necessary for the build, this is usually contained in the srecord package, on ubuntu you can do: sudo apt-get update sudo apt-get install srecord Now you can change to the porting kit directory (e.g. scfw_export_mx8qm) and build the scfw. System Controller Firmware Porting kit  The SCFW porting kit contains source files and object files that will allow you to modify the SCFW to work with your board. You can get the latest System Controller Firmware Porting kit from the i.MX Software and development webpage: Once you obtain the porting kit untar it: tar xvzf imx-scfw-porting-kit-1.1.tar.gz‍ You will see the following file structure: The porting kit is contained under packages, the README contains the instructions to extract the porting kit, basically: cd packages/ chmod a+x imx-scfw-porting-kit-1.1.bin ./imx-scfw-porting-kit-1.1.bin‍‍‍ You will be prompted to accept an End User License Agreement: Once you accept the agreement the porting kit will be extracted in a new folder, the folder structure is as follows: All documentation regarding SCFW is under doc/pdf or in html format if preferred, it is recommended to go over sc_fw_port.pdf. The porting kits for different SoC variants (QM A0, QM B0 and QXP B0) are under src packaged as tar.gz, all other files are SCFW libraries for different software packages, such as Linux, QNX, FreeRTOS, U-boot, ARM Trusted Firmware, etc...   If you will be working with several SoC variants (working with both QXP and QM) it is recommended to extract all porting kits into a single directory, that way you will be able to build for any variant from this directory, the command to do this is: cd imx-scfw-porting-kit-1.1/ cd src/ find scfw_export_mx8*.gz -exec tar --strip-components 1 --one-top-level=scfw_export_mx8 -xzvf {} \;‍‍‍ A scfw_export_mx8 folder will be created, from here you will be able to build SCFW for any supported variant. Or you can just extract the package for the variant you are interested on and use that. cd scfw_export_mx8/‍ All the build folders contain the results of building the SCFW and platform is where the source of the SCFW is stored.   All the code that is specific to a board configuration is under "platform/board/mx8<derivative>_<board_name>" where derivative is the i.MX8 silicon family such as QXP or QM, and board name is the name of the board the SCFW package is for. The first step in porting the SCFW to your board is to create a folder for your i.MX8 derivative and board, you can take one of the available board examples and rename the folder, that will provide you a project to get started with, for instance: cp -r platform/board/mx8qm_val/ platform/board/mx8qm_myBoard/‍‍‍‍‍‍‍‍‍‍ The board in this example will be called "myBoard" and it is for an i.MX8QM B0 device. To build a SCFW for this board simply call: make qm R=B0 B=myBoard‍‍‍‍‍‍‍‍‍‍‍‍ If the target is an i.MX8QXP simply take a board based on this device and change the call to "make qx". Additional information such as build options and in detailed boot information can be found in the SCFW porting guide (sc_fw_port.pdf), chapter 2 of this document is a great introduction to the porting process.   Overview and useful information Configuring the PMIC overview and board.c common modifications The main file that needs to be altered (if not the only) is the "board.c" file, it is located at "platform/board/mx8X_board/". The board.c file contains most of the board related information such as SCU UART ports, PMIC initialization routines, PMIC temperature alarms settings and you can also modify it to configure LDOs voltages and communicate with the PMIC in general. All functions in the board.c file are executed by the SCU itself and this gives you access to the I2C interface that is used to communicate with the PMIC. SoC resources that are powered by an external supply (PMIC LDO for instace) such as AP cores and GPUs are powered off/on by board_set_power_mode, the mapping of the resource to an specific PMIC supply happens in board_get_pmic_info, for instance in our i.MX8QM validation board using the A53 subsystem is powered by SW2 of the third PMIC (PMIC_2_ADDR addresses start at PMIC_0) on the PF100 PMIC card and by SW5 of the first PMIC (PMIC_0_ADDR) on the PF8100 PMIC card. case SC_SUBSYS_A53: pmic_init(); if (pmic_card == PF100) { pmic_id[0] = PMIC_2_ADDR; pmic_reg[0] = SW2; *num_regs = 1; } else {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1; } break; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The voltages of SoC resources that are powered by an external supply (AP cores, GPUs, etc...) are managed by board_set_voltage in the board.c file. The mapping of resource to power supply occurs in board_get_pmic_info as in the example above. Eight "board resources" (SC_R_BOARD_R0, ... SC_R_BOARD_R7) are available, these resources allow you to define components in your board that the SCU can manage, for instance a sensor on your board powered by one of the PMIC LDOs can be mapped to a board resource and the board.c file can be modified to power on/off the sensor as well as modifying its voltage. Modifying the voltage on a board resource can be either be done by modifying the voltage at board_trans_resource_power (see below) or if the voltage needs to change at run time the function board_set_control can be modified to change the voltage whenever a miscellaneous call (more details in the Miscellaneous Service 101) is made on that resource. For instance to change the voltage on SC_R_BOARD_R7 you would have the following case to board_set_control: case SC_R_BOARD_R7: if (ctrl == SC_C_VOLTAGE) { /* Example only PMIC_X_ADDR and PMIC_SUPPLY need to match an actual device */ pmic_interface.pmic_set_voltage(PMIC_X_ADDR, PMIC_SUPPLY, val, step); } else return SC_ERR_PARM; break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The case above will be executed by the SCU every time the application calls the function below: sc_misc_set_control( ipc, SC_R_BOARD_R7, SC_C_VOLTAGE, voltage_val);‍‍‍‍‍‍‍‍ Powering on/off a board resource happens at board_trans_resource_power in the board.c file. For instance in NXP's validation board the PTN5150 on the board is managed through a board resource 0, and the power on/off is managed as follows: case BRD_R_BOARD_R0 : /* PTN5150 (use SC_R_BOARD_R0) */ if (pmic_ver.device_id == PF100_DEV_ID) { if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_2_ADDR, VGEN6, 3300, SW_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_ON); } else { pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_OFF); } } else {/* PF8100_dual Card */ if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_1_ADDR, PF8100_LDO1, 3300, REG_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_EN_STBY_EN); } else { pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_OFF_STBY_OFF); } } break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Whenever the function below is called from the application side the SCU will execute the code above: sc_pm_set_resource_power_mode(ipc, SC_R_BOARD_R0, SC_PM_PW_MODE_ON/OFF);‍‍‍‍‍‍‍‍ board_config_sc is used to mark resources that the SCU needs, such as the I2C module and pads used to communicate with the PMIC, any resource needed by the board.c functions to work should be marked in this function as not movable, for instance to keep the SCU I2C module the following line is added: rm_set_resource_movable(pt_sc, SC_R_SC_I2C, SC_R_SC_I2C, false);‍‍‍‍‍‍‍‍‍ The following pads are part of the SCU and the application will not be able to access them: - SC_P_SCU_PMIC_MEMC_ON - SC_P_SCU_WDOG_OUT - SC_P_PMIC_EARLY_WARNING - SC_P_PMIC_INT_B - SC_P_SCU_BOOT_MODE0 through SC_P_SCU_BOOT_MODE5 board_system_config is where early resource management occurs, this function is only called when the alt_config flag is set in the image, and it can create partitions and allocate resources to it. More details are found in the resource management service 101. board_get_pcie_clk_src defines the clock that the PCIe uses, it can be either BOARD_PCIE_PLL_EXTERNAL or BOARD_PCIE_PLL_INTERNAL. board_print is very useful to debug your changes the syntax is as follows: board_print(3, "Debug printout %d\n", val);‍‍‍‍‍‍‍ Where the first parameter is the Debug Level and from there on it works as a standard printf. The output will only be visible on the SCU debug output whenever the SCU is built with the corresponding debug level, in the case above the SCFW needs to be built as follows in order to see the output: make qm B=myBoard‍‍‍‍ DL=3 or higher (debug level goes from 0 to 5)‍‍‍‍‍‍‍   Usage examples The following utility shows how to make System Controller Firmware requests and provides a way to make such requests through command line interface on both QNX and Linux System Controller Firmware Command Line Utility for Linux and QNX   System Controller Firmware 101  
記事全体を表示
The KTV Demo is a common user case for KTV OEM. In this charpter, we will see what it is and how to use it. HW Platform imx6qp-sabresd SW Platform 3.14.52_1.0.0-ga, fb backend Display Connection LVDS0 XGA 1024*768 RGB666                          - IPU1 DI0 HDMI Display1920*1080@60                              - IPU0 DI1 HDMI Display1920*1080@56 via sii902x            - IPU0 DI0 LVDS1 XGA 1024*768 RGB666                          - IPU1 DI1 User case The demo has following output: Display # UI Video Stream Output Resolution DISP0-LVDS0 3D Cube@60fps 1920x1080@24fps (overlay) XGA(1024x768,RGB666) DISP1-HDMI 3D Cube@60fps 720p@20fps (overlay) 1080P@60(1920x1080,RGB24) DISP2-SII902X 3D Cube@60fps N/A 1080P@56(1920x1080,RGB24) DISP3-LVDS1 N/A 720p@20fps XGA(1024x768,RGB666) The DISP0 and DISP1 has overlay framebufffer, so output UI to bottom framebuffer and output video stream to overlay framebuffer. Run Demo The customer can refer to following script: #!/bin/sh echo "KTV demo start!" # Set environment variables export FB_FRAMEBUFFER_0=/dev/fb0 export FB_FRAMEBUFFER_1=/dev/fb2 export FB_FRAMEBUFFER_2=/dev/fb4 export FB_FRAMEBUFFER_3=/dev/fb5 # Run cube on DISP0,DISP1, DISP3 echo 0 > /sys/class/graphics/fb0/blank ./cube display=0 & sleep 1 echo 0 > /sys/class/graphics/fb2/blank ./cube display=1 & sleep 1 echo 0 > /sys/class/graphics/fb4/blank ./cube display=2 & echo "Open DISP0(LVDS0)" gst-launch-1.0 playbin \   uri=file:///home/root/ktv_demo/1080p_24fps.mp4 \   video-sink="imxv4l2sink device=/dev/video17" & sleep 3 echo "Open DISP1(HDMI)" gst-launch-1.0 playbin \   uri=file:///home/root/ktv_demo/720p_20fps.mp4 \   video-sink="imxv4l2sink device=/dev/video19" & #sleep 3 echo "Open DISP3(LVDS1)" gst-launch-1.0 playbin \   uri=file:///home/root/ktv_demo/720p_20fps.mp4 \   video-sink="imxv4l2sink device=/dev/video21" & sleep 3 The demo image can be downloaded at: \\10.193.102.186\public_share\ZhengTao\KTV Demo​ VPU frequency The vpu can run at 352MHz or  266MHz. We run it at 352MHz in this demo. The customer can configure the VPU frequcency from Linux kernel Kconfig options. Performance Utilization: 33% Overall Bus Load: 71% For 1080p@24fps, the real fps can only up to 13.319fps. The GPU may influence VPU performance.
記事全体を表示
Qt framework Qt is a cross-platform complete development framework with tools designed to streamline the creation of stunning native applications and amazing user interfaces for desktop, embedded and mobile platforms. Qt's cross-platform full framework and tools enables developers to target various desktop, embedded, mobile and real-time operating systems with one code base. Qt brings freedom to the developer saving development time, adding efficiency and ultimately shortening time to market. Building Qt Compile Qt for i.MX28 Building QT5 for i.MX53 Building QT for i.MX6 Qt on iMX6 Installing tools Installing and Configuring QT Creator (Ubuntu) Qt5 with Qt3D over Wayland rootfs Demos Qt5 Cinematic Experience Demo on i.MX6 Video - IMx 53 Qt5 qt3d demo Qt5 with Qt3D over Wayland rootfs Information Qt5 on i.MX6  DO's and DONT's Best Practices for QML
記事全体を表示
Make boot SD Card for imx-android-r13.4-20121128 1. Extract imx-android-r13.4-20121128 2. Check mount device  @Disk Util     My case SD Card : /dev/sdb 3. Insert the uSD Card    Use 16GByte SD Card Cat10 4. Android/imx-android-r13.4-20121128$./device/boundary/mksdcard.sh /dev/sdb 5. Wait about 5 minutes. Finish!
記事全体を表示
Overview In this doc, I will try to give you a brief of the Linux kernel changes between 4.x and 5.4 (5.0/5.1/5.2/5.3/5.4), which related to i.MX users/developers: Important bug fix and improvements according to my experiences New features you should keep an eye on Interfaces changes may impact applications i.MX up-streaming I cannot make sure every single change's description is 100% correct. Either, I cannot list all of the impacts to the i.MX platform due to my limited knowledge and experiences. I hope this doc can help you on developing kernel drivers, user applications or debugging issues of 5.x i.MX kernel release. Changes Subsystem/Modules Detail changes Comments References Kernel Cores binder: new binderfs, a pseudo-filesystem for the Android Binder IPC driver which can be mounted per-ipc namespace allowing to run multiple instances of Android Hmm... that may imply we can run multi-instance Android without Hypervisor? sysctl: add panic_print sysctl to configure which information to print at panic time, w/ replay option So we can define the panic information for better debugging the crash issue. Also option for users to configure the "panic_print" to replay all dmesg in buffer, some of which they may have never seen due to the loglevel setting, which will help panic debugging How to use boot: Add boot option ( driver_async_probe=... ) to specify drivers to be async probed Asynchronous driver probing can help much on kernel fastboot, and this option can provide a flexible way to optimize and quickly verify async driver probe. Asynchronous device/driver probing support [LWN.net]  swiotlb: add debugfs to track swiotlb buffer usage The device driver will not be able to do dma operations once swiotlb buffer is full, either because the driver is using so many IO TLB blocks inflight, or because there is memory leak issue in device driver. Export buffer usage in debugfs can help. Please note, almost all of the dma buffers on i.MX8 platform comes from swiotlb. aarch64 Linux Kernel Memory Management  New mount syscall API The kernel supports a wide variety of filesystem types, and each has its own, often extensive set of options. As a result, the mount() system call is complex. This makes application code who need mount FS more clear. Six (or seven) new system calls for filesystem mounting [LWN.net]  New APIs to support pidfs clone return pidfs, new syscall pidfd_send_signal(2), which uses file descriptors from /proc/<pid> as stable handles on struct pid.  Toward race-free process signaling [LWN.net]  locking: rwsem improvement unification and simpler micro-optimizations, performance improvement of this locking primitive. Preparations for PREEMPT_RT It's excited that community decided to merge the PREEMPT_RT kernel changes into mainline. It's well known as rt-patch for hard real-time use cases like industry. Index of /pub/linux/kernel/projects/rt/  Memory management KASAN: Improved the KASAN performance for arm64 KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides a fast and comprehensive solution for finding use-after-free and out-of-bounds bugs. It's useful when debugging kernel drivers and modules memory issue. The Kernel Address Sanitizer (KASAN) — The Linux Kernel documentation  Fragmentation avoidance improvements, reducing fragmentation events by over 90%. With this change, the page allocator would spread allocations across zones before introducing fragmentation.  We can always found customer's product memory fragment in some use cases in old kernel. Which would cause kmalloc or cma alloc failure and system stop. Balance between zones (i.MX8 we have DMA/NORMAL zones) to avoid fragment is very helpful. patch intro One of customer case(fixed by not using kmalloc): https://jira.sw.nxp.com/browse/MLK-23220  Increase success rates and reduce latency of compaction (physical memory defragmentation) Memory compaction is the way to avoid memory fragment. Memory compaction [LWN.net]  Improve Out Of Memory (OOM) reports, include victim's memcg More clear kernel OOM report may help lot Remove the ancient OOM killer heuristic that preferred to kill children of the "worst" process rather than the process itself Improve the OOM efficiency zram improvements, which can help estimate wasted memory, and perform writeback that will free it zram is actually used very widely in the Android system as backup swap for physical memory. Swap performance is very important. Low RAM Configuration  |  Android Open Source Project  Simplify some of the early memory allocations by replacing usage of older memblock APIs with newer and shinier ones memblock API changes. If you used memblock in your drivers, then need to check. Boot time memory management — The Linux Kernel documentation  psi: Improves the Pressure Stall Information resource monitoring With this mechanism, Android can monitor for, and ward off, mounting memory shortages before they cause problems for the user. For example, using memory stall, monitors in userspace like the low memory killer daemon (lmkd) can detect mounting pressure and kill less important processes. Supported in Android10, replace the vmpressure. Low Memory Killer Daemon (lmkd)  |  Android Open Source Project  Pressure stall monitors [LWN.net]  Improve vmap allocation Speed up the vmalloc https://lkml.org/lkml/2018/10/19/786  Introduce madvise() flags MADV_COLD, MADV_FREE, MADV_PAGEOUT MADV_COLD marks pages as inactive (thus more easily reclaimed under memory pressure), but doesn't discard the contents like MADV_FREE does, and MADV_PAGEOUT , which reclaims pages immediately. Android would use this flags for better memory management kernel/git/torvalds/linux.git - Linux kernel source tree  memcg: from v1->v2 shrink all memcg caches for the slab cache Throttle allocators when reclaim cannot keep up with v2 memory.high limit Introduce gradual reclaim pressure..... Control Group v2 — The Linux Kernel documentation  Block layer Boot to a device-mapper device without initramfs DM is widely used, you can not bootup to DM rootfs directly. Android 10 would use dynamic partition by creating super partition for /system, /vendor of dm-linear Implementing Dynamic Partitions  |  Android Open Source Project  Tracing and Perf Perf: lots of improvement TBD Security security: Create "kernel hardening" config area Help mitigate kernel vulnerabilities and find bugs in kernel drivers, like Stack buffer overflow mitigation, Hardened usercopy Kernel Hardening  |  Android Open Source Project  LSM: Add kernel lockdown functionality When enabled, the new "lockdown" feature will restrict some kernel functionality, even for the root user, making it harder for compromised root accounts to compromise the rest of the OS Kernel lockdown in 4.17? [LWN.net]  Networking Enable MSG_ZEROCOPY for udp sockets Improve the UDP sending performance. Pay attention that the zero copy UDP sockets only limit to the send operations, not receive. Also require application code change, not efficient at small MTU. Zero-copy networking [LWN.net]  ARM/ARM64 New SoCs: i.MX7ULP with EVK i.MX8MQ with EVK i.MX8MM  i.MX8QXP perf vendor events: Add Cortex-A57 and Cortex-A72 events  support all ARMv8 recommended events Make CONFIG_ZONE_DMA32 configurable commit Which means you can remove the DMA zone, and use only one single normal zone in kernel. Drivers drm: Initial merge of timeline sync objects Timeline syncobj gives user more flexibility and convenience to do sychronization. Android does not used. Staging driver: i.MX7 MIPI CSI subdev NXP QuadSPI driver Introduce Sound Open Firmware (SOF) for audio DSP devices Big changes to the current HiFi4 DSP (in i.MX8QM/QXP) infrastructure. The SOF is an open source audio DSP firmware and SDK that provides audio firmware infrastructure and development tools. Also integrated with current kernel alsa subsystem.  Home - Sound Open Firmware  Firmware - AlsaProject  How to build i.MX8 HiFi4 firmware Add NXP SJA1105 DSA network driver with ptp support Used for networking switch Add TJA11xx PHY driver Add lpspi driver support fsl_lpuart: add imx8qxp support Add SCU watchdog/RTC support regmap: add i3c bus support commit Means we can have i3c bus support in regmap now. References Linux_Kernel_Newbies - Linux Kernel Newbies  Welcome to LWN.net [LWN.net]  kernel/git/torvalds/linux.git - Linux kernel source tree 
記事全体を表示
Attached is a chunk of the filesystem for the Linux Image https://community.freescale.com/docs/DOC-93887
記事全体を表示
This is a tool can generate LPDDR2 script easily for i.MX6SLL.
記事全体を表示