Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 6/7 Family DDR Stress Test  The i.MX6/7 DDR Stress Test Tool is a PC-based software to fine-tune DDR parameters and verify the DDR performance on a non-OS, single-task environment(it is a light-weight test tool to test DDR performance). It performs write leveling, DQS gating and read/write delay calibration features. The tool described on this page cover the following i.MX 6/7 series SoCs: i.MX 6DQP (Dual/Quad Plus) i.MX 6DQ (Dual/Quad) i.MX 6DL/S (Dual Lite/Solo) i.MX 6SoloX i.MX 6SL i.MX 6SLL i.MX 6UL i.MX 6ULL/ULZ i.MX 7D/S i.MX 7ULP Note that the DDR Stress test tool supports the all of the above i.MX SoCs, however, some of the supported i.MX SoCs named in the tool support multiple i.MX SoCs as follows: MX6DQ – when selected, this supports both i.MX 6DQ and i.MX 6DQP (Plus) MX6DL – when selected, this supports both i.MX 6DL and i.MX 6S (i.MX 6DLS family) MX6ULL – when selected, this supports both i.MX 6ULL and i.MX6 ULZ MX7D – when selected, this supports both i.MX 7D and i.MX 7S The purpose of the i.MX 6/7 series DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.). This process equips the user to then proceed with the bring-up of a boot loader and an OS. Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface. The i.MX 6/7 series DDR Tools consist of: DDR Register Programming Aid (RPA): i.MX 6/7 Series DDR Tool Release DDR Stress test: Described below There are three options to run the DDR Stress test. Each of these options are provided in the attached zip files. The following is a high-level overview of each option along with the naming convention of the associated zip file: Option 1 GUI based: Run the GUI executable and connect your board to the host PC via USB Archive file: ddr_stress_tester_vX.xx.zip The tool will first need to run a DDR initialization script for the specified i.MX SoC (refer to Load Init Script in the GUI tool).  Example initialization scripts based on NXP's development boards can be found in this zip file under the script folder.  Note, these scripts may need to be modified for your custom board and memory.   Option 2 DDR Stress Tester: JTAG Interface A hardware debugger connected to the board via the JTAG interface is used to download an elf file into the i.MX SoC OCRAM (internal RAM) and then begin execution. Results are shown on the UART serial port (115200-8-n-1). Archive file: ddr_stress_tester_jtag_vX.xx.zip As with the GUI tool, the JTAG/debugger option will first need to run a DDR initialization script for the specified i.MX SoC. Refer to the GUI tool description above for the location of the example scripts (which are found in the ddr_stress_tester_vX.xx.zip file). Note that the scripts are available either in the RealView ICE format (.inc file) or the DS-5 DSTERAM format (.ds). For other debuggers, the user will have to modify the script's command syntax for their specific debugger. This is also true if converting from a RealView Ice (.inc) format to a DS-5 DSTREAM (.ds) format and vice versa. The DDR Stress Tester executable (starting with V2.20) has an auto UART detection feature. If a different UART port for the serial console has been chosen than used on the NXP development tool (EVK, SABRE) specific commands can be added to the DDR initialization script that allows you to configure for the specific UART and then load and run the elf executable. Refer to the FAQ section of this community post and the txt file found in the JTAG archive file for instructions.   Option 3 U-Boot: The boot loader u-boot is running and commands in u-boot are used to download the bin file into SoC OCRAM and begin execution. Results are shown on the UART serial port (115200-8-n-1) Archive file: ddr_stress_tester_uboot_vX.xx.zip When downloading the DDR Stress Tool by u-boot, please copy the ddr-test-uboot-jtag-mxxxx.bin to SD card and load it to IRAM using the 'fatload' u-boot command (see notes below when using newer versions of u-boot). For i.MX6, please load the binary to 0x00907000. For i.MX7D, please load the binary to 0x00910000.  It is imperative to first disable the I and D cache in u-boot as shown below as the DDR Stress Test re-configures and re-enables the cache and MMU page table. While this option allows the user to load and run the DDR stress test from u-boot, NXP highly recommends executing the GUI based version for system testing and debugging. The u-boot version is considered a “last resort” for systems in production which may not have USB or JTAG connectivity. The reasons behind this stance are: In the GUI version, the system starts “clean” and uninitialized, whereas u-boot initializes many SoC features outside the knowledge of the DDR stress test and may conflict with the stress test operation When running the u-boot version, the test will overwrite the contents of u-boot residing in DDR, hence the test will overwrite any data in DDR. Once the stress test is loaded and executed, u-boot itself will no longer be accessible. To return to the functionality of u-boot, a system re-boot is required. Newer versions on u-boot do not allow a direct loading of the DDR stress test code from the SD card (boot media) directly to the SoC internal OCRAM (aka IRAM). Hence, the procedure is updated to first load the DDR stress test code into DDR and then copy into OCRAM, as shown in the procedure below: u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000;go 0x00907000 As u-boot initializes many peripherals that may conflict with the operation of the DDR stress test, it is necessary to clock gate these peripherals prior to running the DDR stress test. Hence, it is highly recommended to augment the procedure above as follows: u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000; u-boot> mw 0x020c4068 0x00C0000F; u-boot> mw 0x020c406c 0x00000000; u-boot> mw 0x020c4074 0x3F300000; u-boot> mw 0x020c4078 0x0000F300; u-boot> mw 0x020c407c 0x0F000003; u-boot> mw 0x020c4080 0x000003FC; u-boot> go 0x00907000 Note, in the above procedure, it is recommended to write to each clock gate register in separate commands (refer to commands starting with “mw”). The SoC requires a finite amount of time to gate each clock hence performing this sequence with a new command line write ensures the SoC has time to gate the intended clocks.   Stress Test Revision Features Comments 3.00 Add i.MX 7ULP support in the GUI version Known issues: USB connection is unstable when under USB HUB or some PC environments 2.92 Minor correction with write leveling calibration code error check to avoid a corner case of flagging an error when none have occurred.    2.91 Resolved issue with write leveling calibration code where a race condition in the code may result in the calibration routine not being able to find any delay values.   Only applies to MX6 series SoCs that support DDR3.  2.90 Reserve write delay line register (MMDC_MPWRDLCTL) configuration as DDR script does when do write calibration. In previous releases, MMDC_MPWRDLCTL would be changed to 0x40404040 by default.      * Further details available in the release notes  _________________________________________________________________________________________________________________________________________    FAQ   Q. I see an error message that states "ERROR: DCD addr is out of valid range.", why is this and how do I resolve?   A. Sometimes, when using the register programming aid, there are registers writes that are not supported in the DCD range.  Try looking for the following items and comment them out from the DDR initialization script: wait = on setmem /16 0x020bc000 = 0x30 // disable watchdog (note the address for this may be different between i.MX6x devices)  Q. How do I select the "DDR Density" pull-down menu and what is the purpose of this?   A. The DDR Density pull-down menu gives the user the option of testing a DDR density smaller than what they actually have on their board.  The advantage of doing this is to speed up test time to allow the user to perform a "quick test" of their system.  IMPORTANT: it is imperative that the user not set this value higher than the supported density on their board, doing so will cause the stress test to fail and/or lock up. The DDR Density has a different meaning depending on the memory type being tested (DDR3 or LPDDR2): For DDR3, this is the density per CHIP SELECT.  So if your board has two chip selects, and each chip select has 512MB, you would simply select 512MB or lower.  The default setting will simply set this to the detected density per chip select. For LPDDR2, this is the density per CHANNEL.  This is only relevant for MX6 devices that support 2 channel LPDDR2 memories (MX6DQ, MX6DL).  For other MX6 devices that support only one LPDDR2 channel, then this is the total density (for the maximum setting) for that channel. Note that for LPDDR2, the number of chip selects (per channel) is irrelevant when selecting the density to test as the stress test combines both chip-selects into one combined density per channel.  For example, lets say you have a 2GB LPDDR2 device, which 2 channels and 2 chip-selects per channel.  That means you have 512MB per chip select, per channel.  Or, it also means you have 1GB per channel when combining both chip selects per channel.  In this case, you would choose (a maximum setting of) 1GB in the DDR Density drop down menu.  However, this is also the same setting as the default setting (which you are welcome to still choose 1GB to convince yourself that 1GB per channel is indeed being tested). Now let's assume you have only one channel (LPDDR2) and one chip select, with a density of 128MB; in this case, the maximum DDR Density you can select is 128MB. Let's assume you have one channel and two chip selects, each chip select is 128MB;  in this case, the maximum DDR Density you can select is 256MB (a combination of both chip selects).   Note, for the MX7D, an actual density needs to be entered. For the MX6x series, simply leaving this field as Default will cause the DDR stress test to ascertain the supported density from the DDR init script. As the MX7D DDR controller is different, this feature is not supported, hence it is required for the user to enter an actual density (for more details regarding MX7D usage of density and number of chip-selects, see the next FAQ on the DDR CS setting).   Q.  What is the purpose of the "DDR CS" pull-down option?   A.  The answer depends on which processor you are testing:   For the i.MX 6x series: This pull down menu gives you the option of testing one chip select (CS0) or ALL (both) chip selects *IF* you have a two-chip select configuration.  If you have a two-chip select configuration, then this allows you to test only one chip select for faster test time; else you can choose to test both chip selects.  Note that if you have a one-chip select configuration and you choose "ALL", the stress test will return an error.   For the iMX 7D: Because the MX7D DDR controller is different, the DDR stress test will need the user to supply the entire supported density found on their board. The chip select field should be left as is (0) as the test will naturally test one chip select to the next. For example, let’s assume you are using two chip selects, with each chip select being 512MB. In this case, you would enter 1GB for the DDR Density field ensuring that both chip selects will be tested. The user is allowed to enter a density less than the density found on their board (for quicker testing), but keeping in mind both chip selects may not be tested in this case.   Q. I run DDR calibration using the DDR Stress Test Tool to obtain the calibration results.  Are these calibration parameters are written to the uboot flash_header.S automatically or manually?   A. The calibration values obtained from the DDR Stress Test Tool will need to be manually updated in the flash_header.S file or any other DDR initialization script.   Q. When running the DDR stress test on MX7D and I try to perform calibration, I get an error stating that calibration is not supported, is this expected?   A. Yes, calibration is not supported or needed when using MX7.  The reason is, MX7 uses a different memory controller than the MX6 series.  The MX6 series memory controller has built-in support for calibration where the MX7 memory controller does not.   Q. When running the GUI version of the DDR stress test, on MX7 and I leave DDR Density as default, I get an error in the tool stating I must supply a density.  Why is this?   A. This is due to the fact that MX7 uses a different memory controller than the MX6 series.  In the MX6 series, it was possible to calculate the memory density from the memory controller register settings.  The MX7 memory controller is different and does not lend itself to easily calculate the supported density based on the register settings.  Instead, the user should verify the density on their board and selected this value in the DDR Density pull-down menu.    Q. I noticed that when I run write-leveling calibration I sometimes see a note that due to the write-leveling calibration value being greater than 1/8 clock cycle that WALAT must be set to 1.  What does this mean?   A. In the MMDC chapter of the reference manual for the specific i.MX 6 device, the need to set WALAT is described in the MDMISC register as follows: "The purpose of WALAT is to add time delay at the end of a burst write operation to ensure that the JEDEC time specification for Write Post Amble Delay (tWPST) is met (DQS strobe is held low at the end of a write burst for > 30% a clock cycle before it is released). If the value of any of the WL_DL_ABS_OFFSETn register fields are greater than ‘1F’, WALAT should be set to ‘1’ (cycle additional delay). WALAT should be further increased for any full-cycle delays added by the WL_CYC_DELn register fields." Therefore, if the write-leveling calibration routine detects any write-leveling delay value greater than 0x1F, it will note to the user that WALAT must be set and the user should update their DDR3 init script to ensure WALAT is set.  Sometimes, a user may find that the write-leveling delay value may fluctuate from one run to the next, which is quite normal.  If it is found that this delay is "borderline" meaning sometimes it is greater than 0x1F and sometimes it might be slightly less, then it is ok to go ahead and set WALAT permanently in your init script as there is no harm in doing so and will ensure you will stay within JEDEC's tWPST.   Q. I sometimes see that after running write-leveling calibration that delay values being reported back are zero'd out (0x00), and then at times I see a non-zero value being reported, why is this? A. It is quite normal to see slight variations in the delay value between write-leveling calibration runs.  The write-leveling calibration routine assumes a majority of users have designed their board such that the DDR3 memories are placed close to the i.MX 6 SoC. There’s a mechanism in NXP’s DDR Stress test write leveling calibration code that checks the returned write leveling value. If the write-leveling calibration routine detects that the returned delay value is greater than ¾ of a clock cycle, it will "zero out" the delay value. It does this because it assumes that such a large delay result is due to the fact that the DQS signal is already delayed relative to the SDCLK, and to align DQS with SDCLK requires the calibration routine to delay DQS even further to align it to the next SDCLK edge, something we ideally would like to avoid.  JEDEC specs that the DQS edge must be within 25% of a SDCLK cycle with respect to the SDCLK edge, so having DQS initially slightly delayed from SDCLK is actually ok, hence why the calibration routine “zero’s” this out when the returned value exceeds ¾ of a clock cycle.  In cases like this, the DQS edge and SDCLK edge are so close together that in some calibration runs, the DQS edge may slightly precede SDCLK (resulting in a very small write-leveling delay value) and other runs, it may be slightly delayed relative to the SDCLK (resulting in a very large write-leveling delay value that will try to align DQS to the next SDCLK edge, hence needs to be zero’d out).   Q. When using the JTAG version of the DDR stress test, how can I select a different UART port for my serial port?   A. Under the folder ddr_stress_tester_jtag_v2.52, there's a text file that describes how to add a different UART port by adding a few additional commands to your DDR init script.  The following is an outline of these commands: 1. Ungate UART module clocks (most NXP scripts ungate all of the peripheral clocks at the beginning of the script, so this part is already done) 2. Configure the IOMUX options for the pins you wish the UART to use (normally an IOMUX option for UART_TX and UART_RX, and a daisy chain option for the UART_RX input) 3. Enable the desired UART module via the register UCR1, bit UART_EN 4. Disable other UART modules (UCR1[UART_EN] = 0).  Normally disabling UART1 should be sufficient, but it doesn't hurt to disable all of the other un-used UART options for the purpose of the stress test.   Here's an example in the .ds file vernacular of a set up as follows: MX6DQ, UART4 on KEY_COL0 and KEY_ROW0 (assume clock is ungated to all peripherals): mem set 0x020E01F8 32 0x00000004   #// config_pad_mode(KEY_COL0, ALT4) mem set 0x020E01FC 32 0x00000004   #// config_pad_mode(KEY_ROW0, ALT4); mem set 0x020E0938 32 0x00000001   #// Pad KEY_ROW0 is involved in Daisy Chain. mem set 0x02020080 32 0x00000000   #//disable UART1 in UART1_UCR1 (Note, you can disable other UART modules as well) mem set 0x021F0080 32 0x00000001   #//enable UART4 in UART4_UCR1   Here's another example in the .inc file vernacular of a set up as follows: MX6SX, UART5 on SD4_DATA4 abd SD4_DATA5 (assume clock is ungated to all peripherals): setmem /32 0x020E0294 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA5, ALT2; UART5_TX_DATA setmem /32 0x020E0290 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA4, ALT2; UART5_RX_DATA setmem /32 0x020E0850 = 0x00000000 // IOMUXC_UART5_IPP_UART_RXD_MUX_SELECT_INPUT, daisy chain for UART5_RX input to use SD4_DATA4 setmem /32 0x021F4080 = 0x00000001 // Enable UART_EN in UCR1 of UART5 // Disable UART_EN in UCR1 of UART1, UART2, UART3, and UART4 setmem /32 0x02020080 = 0x00000000 // UART1 setmem /32 0x021F0080 = 0x00000000 // UART2 setmem /32 0x021EC080 = 0x00000000 // UART3 setmem /32 0x021E8080 = 0x00000000 // UART4     Related Resources Links: iMX 8M Mini Register Programming Aid DRAM PLL setting  i.MX 8/8X Series DDR Tool Release  i.MX 8M Family DDR Tool Release 

Design Check Lists: HW Design Checking List for i.MX6DQSDL HW Design Checking List for i.Mx53 Hardware Design Checklist for i.MX28 HW_Design_Checking_List_for_i.MX6SoloX i.MX6UL Hardware design checklist   DDR Design Tool: I.MX53 DDR3 Script Aid imx53 DDR stress tester V0.042 i.Mx6DQSDL DDR3 Script Aid MX6DQP DDR3 Script Aid i.Mx6DQSDL LPDDR2 Script Aid i.Mx6SL LPDDR2 Script Aid i.MX6SX DDR3 Script Aid I.MX6UL DDR3 Script Aid i.MX6UL_LPDDR2_Script_Aid i.MX6ULL_DDR3_Script_Aid  i.MX6ULL_LPDDR2_Script_Aid  MX6SLL_LPDDR2_Script_Aid  MX6SLL_LPDDR3_Script_Aid  i.MX6 DDR Stress Test Tool V1.0.3 i.MX6/7 DDR Stress Test Tool V3.00 i.MX8MSCALE DDR Tool Release  i.MX8M DDR3L register programming aid  i.MX 8/8X Family DDR Tools Release   Application Notes: MX_Design_Validation_Guide I.MX6 series USB Certification Guides

1. Description     These patches are used to support MPU 8080 LCD on L3.14.52_1.1.0_GA BSP.     They are based on ELCDIF hardware module, iMX6UL and iMX7D is the reference platform.   2. File List -- 0001-Add-ST7789S-MPU-LCD-support-for-iMX6UL-board.patch    Patch to support MPU display for iMX6UL, ST7789S 240*320 panel is the example.   -- 0002-Add-ST7735R-MPU-LCD-support-for-iMX7D-board.patch    Patch to support MPU display for iMX7D, ST7735R 128*128 panel is the example.   -- readme.txt    this file, please refer to it before use the patches   3. Requirement - iMX6UL EVK board or iMX7D SabreSD board. - L3.14.52_1.1.0_GA kernel.   4. How to use -- Copy the patch files to kernel folder.     $ cd ~/L3.14.52_GA1.1.0/build-imx7dsabresd-X11/tmp/work/imx7dsabresd-poky-linux-gnueabi/linux-imx/3.14.52-r0/git     $ git apply ./0001-Add-ST7789S-MPU-LCD-support-for-iMX6UL-board.patch     $ git apply ./0002-Add-ST7735R-MPU-LCD-support-for-iMX7D-board.patch   -- Build the new kernel image:     $ cd ~/L3.14.52_GA1.1.0/build-imx7dsabresd-X11/tmp/work/imx7dsabresd-poky-linux-gnueabi/linux-imx/3.14.52-r0/git     $ export CROSS_COMPILE=~/L3.14.52_GA1.1.0/build-imx7dsabresd-X11/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-     $ export ARCH=arm     $ make imx_v7_defconfig     $ make zImage     $ make dtbs   5. How to add a new MPU panel     1) in dts file, such as imx6ul-14x14-evk-i80lcd.dts, update the panel name "lcd_panel",        update the PINs in "pinctrl_lcdif_dat" and "pinctrl_lcdif_ctrl" for the new panel,        the reset and rs PINs can be from GPIO pin, lcd_reset_gpio and lcd_rs_gpio. &lcdif { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lcdif_dat        &pinctrl_lcdif_ctrl>; display = <&display0>; status = "okay"; display0: display {   mpu-mode;   lcd_reset_gpio = <&gpio3 14 0>;   lcd_panel = "ST7789S-QVGA"; }; };       2) Reference to "mxsfb_st7789s_qvga.c", add a new panel driver code.       3) Add the new panel support in Makefile and Kconfig under "drivers/video/mxc/"       4) Add the new panel support in file "mxsfb.c" and "mxsfb.h"       5) Add the new panel support in default kernel config file "imx_v7_defconfig"   Note: mpu_lcd_fb_test.tar.gz is the test application, for 8080 display, it is not sync display, so software need call ioctl to refresh the LCD.     2016-08-02: Add the uboot reference patch for iMX7D. File: L3.14.52_Uboot_mpu_display.patch  

The i.MX Android N7.1.1_1.0.0 release is now available on Web Site (i.MX6 BSP Updates and Releases -> Android).   Files available: # Name Description 1 android_N7.1.1_1.0.0_docs.tar.gz i.MX Android N7.1.1_1.0.0 BSP Documentation 2 android_N7.1.1_1.0.0_source.tar.gz Source Code of Android N7.1.1_1.0.0 BSP (4.1 kernel) for i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo  i.MX 6Sololite, i.MX6SX and i.MX7D 3 android_N7.1.1_1.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_N7.1.1_1.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_N7.1.1_1.0.0_image_6slevk.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_N7.1.1_1.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_N7.1.1_1.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_N7.1.1_1.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 7Dual 9 android_N7.1.1_1.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for N7.1.1_1.0.0   Supported Hardware SoC/Boards: MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform MX 6SoloLite EVK platform MX 6SoloX SABRE-SD board and platforms MX 6SoloX SABRE-AI board and platforms MX 7Dual SABRE-SD board and platform   Changes: Compared to the M6.0.1_2.1.0 release, this release has the following major changes: Upgraded the Android platform version to Android 7.1. Upgraded the U-Boot and Linux Kernel Code base from the L4.1.15_1.0.0 release to the L4.1.15_1.2.0-ga release. Added support for the i.MX 7Dual SABRE-SD board. Upgraded the GPU driver from 5.0.11p8 to 6.2.0.p2.   Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.

Symptoms   Trying to initialize a repo, for example:  $repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml we have the below log: File "/home/username/bin/repo", line 51 def print(self, *args, **kwargs): ^ SyntaxError: invalid syntax   Workaround (1)   The first workaround consist in change the python alternatives (caused when you have installed two or more python versions). NOTE: in my case, the python version that i want to change as first priority is python3.8 $sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.8 1   Then we run: $sudo update-alternatives --config python    To verify if your python priority was changed successfully try: $python --version   You should see the version configured as priority number 1.     Workaround (2)   The workaround is very simple, only we need modify the repo file $ nano ~/bin/repo   and we will change the python interpreter in the first line (from python to python3): ORIGINAL FILE   EDITED FILE   After to do this change, repo will works fine again.     I hope this can helps to you!   Best regards.

This document explains how to bring-up u-boot & Linux via JTAG This procedure has been tested on: i.MX6 Solo X Sabre SD i.MX6UL EVK Prerequistes: Get the latest BSP for your board. This procedure was tested with L4.1.15. Build the 'core-image-minimal' image to bring-up your board (Detailed steps here) Optional- Build a meta-toolchain for your device 1.- Set board to boot from Serial dowloader mode or set it to boot from the SD card and remove the sd card We basically want the board to stall in boot ROM to attach to the target. 2.- Connect JTAG probe and turn on the board The device should stall trying to establish a connection to download an image, this will allow us to attach to the target. 3.- Load Device Configuration Data In 'normal' boot sequence the boot ROM takes care of reading the DCD and configuring the device accordingly, but in this case we are skipping this sequence and we need to configure the device manually. The script used by Lauterbach to parse and configure the device is called dcd_interpreter.cmm and can be found here. Search for the package for your specific device. The DCD configuration for your board should be on your u-boot directory: yocto_build_dir/tmp/work/<your board>imx6ulevk/u-boot-imx/<u-boot_version>2016.03-r0/git under board/freescale/<name of your board>mx6ul_14x14_evk/imximage.cfg This file (imximage.cfg) contains all the data to bring up DRAM among other early configuration options. 4.- Load U-boot If an SREC file of U-boot is not present build it (meta-toolchain installed required) the SREC file contains all the information required by the probe to load it and makes this process easier. To build the SREC simply type: make <your board defconfig>mx6ul_14x14_evk_defconfig  (all supported boards are found under u-boot_dir/configs) make If you cannot build an SREC or do not want to, you can use the u-boot.imx (located under yocto_build_dir/tmp/deploy/images/<your board name>/) or u-boot.bin files but you will need to figure out the start address and load address for these files, this can be done by examining the IVT on u-boot.imx (here is a useful document explaining the structure of the IVT). Let U-boot run and you should see its output on the console I will try to boot from several sources but it will fail and show you the prompt. 5.- Create RAMDisk After building the core-image-minimal you will have all the required files under yocto_build_dir/tmp/deploy/images/<your board name>/ You will need: zImage.bin - zImage--<Linux Version>--<your board>.bin Device tree blob - zImage--<Linux Version>--<your board>.dtb Root file system - core-image-minimal-<your board>.rootfs.ext4 We need to create a RAMDisk out of the root file system we now have, these are the steps to do so: Compress current Root file system using gzip: gzip core-image-minimal-<your board>.rootfs.ext4 If you want to keep the original file use: gzip -c core-image-minimal-<your board>.rootfs.ext4 > core-image-minimal-<your board>.rootfs.ext4.gz Create RAMDisk using mkimage: mkimage -A arm -O linux -T ramdisk -C gzip -n core-image-minimal -d core-image-minimal-<your board>.rootfs.ext4.gz core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot Output: Image Name: core-image-minimal Created: Tue May 23 11:28:55 2017 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3017939 Bytes = 2947.21 kB = 2.88 MB Load Address: 00000000 Entry Point: 00000000 Here are some details on mkimage usage Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) mkimage -V ==> print version information and exit 6.- Modify U-boot's environment variables Now we need to modify U-boot's bootargs as follows: setenv bootargs console=${console},${baudrate} root=/dev/ram rw We need to find out the addresses where u-boot will expect the zImage, the device tree and the initial RAMDisk, we can do it as follows: => printenv fdt_addr fdt_addr=0x83000000 => printenv initrd_addr initrd_addr=0x83800000 => printenv loadaddr loadaddr=0x80800000 Where: fdt_addr -> Device tree blob load address initrd_addr -> RAMDisk load address loadaddr -> zImage load address 7.- Load zImage, DTB and RAMDisk Now we know where to load our zImage, device tree blob and RAMDisk, on Lauterbach this can be achieved by running the following commands: Stop the target and execute: data.load.binary zImage.bin 0x80800000 data.load.binary Your_device.dtb 0x83000000 data.load.binary core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot 0x83800000 Let the device run again and deattach from the device in lauterbach this is achieved by: go SYStem.mode.NoDebug start the boot process on u-boot as follows: bootz ${loadaddr} ${initrd_addr} ${fdt_addr} You should now see the Linux kernel boot process on your terminal: After the kernel boots you should see its prompt on your terminal: Since we are running out of RAM there is no way for us to save u-boot's environment variables, but you can modify the source and compile u-boot with the new bootargs, by doing so you can create a Load script that loads all the binaries hits go and the boot process will continue automatically. One way to achieve this is to modify the configuration file under U-boot_dir/include/configs/<your board>.h find the mfgtool_args and modify accordingly. The images attached to this thread have been modified as mentioned.

Some Chinese customers using i.MX series SoC maybe encounter some issues when they download android , u-boot & kernel source code by 'git' command, the following steps will show customer how to get them: 1. Getting repo --No.1 methord # cd ~ # mkdir myandroid # mkdir bin # cd bin # git clone git://aosp.tuna.tsinghua.edu.cn/android/git-repo.git/ <if git failed, use : git clone https://aosp.tuna.tsinghua.edu.cn/android/git-repo.git/> # cd git-repo # cp ./repo ../ --No.2 methord # cd ~ # mkdir bin # curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo # chmod a+x ~/bin/repo [Note]Customers can select one of above to get "repo" 2. Modifying repo File Open ~/bin/repo file with 'gedit' and Change google address From        REPO_URL = 'https://gerrit.googlesource.com/git-repo' To        REPO_URL = 'git://aosp.tuna.tsinghua.edu.cn/android/git-repo'        like following: ## repo default configuration ## REPO_URL = 'git://aosp.tuna.tsinghua.edu.cn/android/git-repo' REPO_REV = 'stable' 3、Setting email address # cd ~/myandroid # git config --global user.email "weidong.sun@nxp.com" # git config --global user.name "weidong.sun" [ Email & Name should be yours] 4、Getting manifest # ~/bin/repo init -u https://aosp.tuna.tsinghua.edu.cn/android/platform/manifest -b android-5.1.1_r1 # cd ~/myandroid/.repo # gedit manifest.xml        Then change the value of fetch to " git://aosp.tuna.tsinghua.edu.cn/android/ ", like following: <manifest>   <remote name="aosp"            fetch="git://aosp.tuna.tsinghua.edu.cn/android/" />   <default revision="refs/tags/android-5.1.1_r1" ...... [Note] android-5.1.1_r1 is version of branch,customer can change it to another. 5、# ~/bin/repo sync          [Note] During runing repo sync, maybe errors will occur like the following: ...... * [new tag]         studio-1.4 -> studio-1.4 error: Exited sync due to fetch errors          Then 'repo sync' exits. But don't worry about it, continue to run the command please ! " ~/bin/repo sync", downloading source code will be continous. 6、Getting Cross Compiler # cd ~/myandroid/prebuilts/gcc/linux-x86/arm # git clone https://aosp.tuna.tsinghua.edu.cn/android/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6 # cd arm-eabi-4.6 # git checkout android-4.4.3_r1 7、Getting linux kernel source code        Probably, customer can't normally get linux kernel by using "git clone" command, she can download it directly from the following weblink:        http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/        At first, create a temperary directory, then download kernel into the directory. see following steps: # cd ~ /Downloads # mkdir linux-kernel   Atfer downloading l5.1.1_2.1.0-ga.tar.gz, use 'tar zxvf l5.1.1_2.1.0-ga.tar.gz' command to decompress it.        Then you can find a subdirectory name " l5.1.1_2.1.0-ga" is created, linux source code is in the directory, we should copy all files in the directory to ~/myandroid/kernel_imx/ # cd ~/myandroid # mkdir kernel_imx # cd kernel_imx # cp -a ~ /Downloads/linux-kernel/l5.1.1_2.1.0-ga ./ 8、Getting uboot source code               Probably, customer can't normally get linux kernel by using "git clone" command, she can download it directly from the following weblink:       http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/        We can use similar way to that of linux kernel to get u-boot source code: # cd ~ /Downloads # mkdir u-boot        Download l5.1.1_2.1.0-ga.tar.gz file, and save it in ~ /Downloads/ u-boot, then decompress it, then u-boot source code will be in ~ /Downloads/ u-boot / l5.1.1_2.1.0-ga/, we should copy all file in the path to ~/myandroid/bootable/bootloader/uboot-imx/ # cd ~/myandroid/bootable/bootloader # mkdir uboot-imx # cd uboot-imx # cp -a ~ /Downloads/u-boot/l5.1.1_2.1.0-ga/* ./ 9、Patch android BSP source code        android_L5.1.1_2.1.0_consolidated-ga_core_source.gz is the name of patch. Run following command to patch android. # copy android_L5.1.1_2.1.0_consolidated-ga_core_source.gz /opt/ # tar zxvf android_L5.1.1_2.1.0_consolidated-ga_core_source.gz # cd /opt/ android_L5.1.1_2.1.0_consolidated-ga_core_source/code/ # tar zxvf L5.1.1_2.1.0_consolidated-ga.tar.gz # cd ~/myandroid # source /opt/ android_L5.1.1_2.1.0_consolidated-ga_core_source/code/ L5.1.1_2.1.0_consolidated-ga/ and_patch.sh # help # c_patch /opt/ android_L5.1.1_2.1.0_consolidated-ga_core_source/code/ L5.1.1_2.1.0_consolidated-ga/ imx_L5.1.1_2.1.0-ga        If everything is OK, the following logs will display on console:               **************************************************************        Success: Now you can build the Android code for FSL i.MX platform               ************************************************************** 10、Patch Freescale extended feathures code        Please refer to chapter 3.3 of Android_User's_Guide.pdf to patch another 2 files:        (1) android_L5.1.1_2.1.0_consolidated-ga_omxplayer_source.gz        (2) android_L5.1.1_2.1.0_consolidated-ga_wfdsink_source.gz [Note]       As for other steps, such as compiling etc, please refer to Android_User's_Guide.pdf that released by NXP. TICS team Weidong Sun 04/01/2016

A new version of the Pins Tool for i.MX Application Processors has been released and is available for download as desktop tool from Pins Tool for i.MX Application Processors|NXP. The pins Tool for i.MX Application Processors is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations, with the following main features: Desktop application Muxing and pin configuration with consistency checking Multicore support ANSI-C initialization code Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Selection of Pins and Peripherals Package with IP blocks Routed pins with electrical characteristics Registers with configured and reset values Power Groups with assigned voltage levels Source code for C/C++ applications Documented and easy to understand source code CSV Report and Device Tree File Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE What's New Added Label support to give signals a name Added ‘Log’ and ‘Problems’ view to report conflicts between settings Added support for templates to store user configurations as starting point for new configurations Added ability to download and share data for devices, especially for off-network host machines i.MX header files are now automatically part of the device data Import of legacy Processor Expert .pe files Export of register defines Various bug fixes and documentation improvements The release notes of the desktop application are attached to this article. Import Processor Expert Files A new importer has been added to import legacy Processor Expert for i.MX files: Labels Signals can now have user defined labels: Templates, Kits, Boards and Processors When creating a new configuration, it offers Templates, Boards and Processors. Custom configurations can be stored as templates and then used for new configurations. Board Specific Functions With the provided board and kit configurations, there are now pre-configured initialization functions for major blocks on the board: Export Data To simplify downloading the device specific data for the desktop tool, the 'Export' function can be used to download and export the data. The data can be copied that way to another machine or all data for a set of devices can be loaded. Export Registers With the Export command the registers can be exported as text/source: This is used to store the register values: /*FUNCTION********************************************************************** * * Function Name : init_audmux_pins * Description   : Configures pin routing and optionally pin electrical features. * *END**************************************************************************/ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT_VALUE            0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT_VALUE         0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT_VALUE          0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19 */ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ We hope you will find this new release useful. Thanks for designing with NXP! 

The Linux L4.9.11_1.0.0 RFP(GA) for i.MX6 release files are now available on www.nxp.com    Files available: # Name Description 1 L4.9.11_1.0.0-ga_images_MX6QPDLSOLOX.tar.gz i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo, i.MX 6Solox Linux Binary Demo Files 2 L4.9.11_1.0.0-ga_images_MX6SLEVK.tar.gz i.MX 6Sololite EVK Linux Binary Demo Files 3 L4.9.11_1.0.0-ga_images_MX6UL7D.tar.gz i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 4 L4.9.11_1.0.0-ga_images_MX6SLLEVK.tar.gz i.MX 6SLL EVK Linux Binary Demo Files 5 L4.9.11_1.0.0-ga_images_MX7ULPEVK.tar.gz i.MX 7ULP EVK Linux Binary Demo Files  6 L4.9.11_1.0.0-ga_mfg-tools.tar.gz i.MX Manufacturing Toolkit for Linux L4.9.11_1.0.0 BSP 7 L4.9.11_1.0.0-ga_gpu-tools.tar.gz L4.9.11_1.0.0 i.MX VivanteVTK file 8 bcmdhd-1.141.100.6.tar.gz The Broadcom firmware package for i.MX Linux L4.9.11_1.0.0 BSP. 9 imx-aacpcodec-4.2.1.tar.gz Linux AAC Plus Codec for L4.9.11_1.0.0 10 fsl-yocto-L4.9.11_1.0.0.tar.gz L4.9.11_1.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide.   Target boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6QuadPlus SABRE-AI Board i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloLite EVK Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board i.MX 7Dual SABRE-SD Board i.MX 6UltraLite EVK Board i.MX 6ULL EVK Board i.MX 6SLL EVK Board i.MX 7ULP EVK Board (Beta Quality)   What’s New/Features: Please consult the Release Notes.   Known issues For known issues and more details please consult the Release Notes.   More information on changes, see: README: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/README?h=imx-morty ChangeLog: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/ChangeLog?h=imx-morty

meta-avs-demos Yocto layer meta-avs-demos is a Yocto meta layer (complementary to the NXP BSP release for i.MX) published on CodeAurora that includes the additional required packages to support  Amazon's Alexa Voice Services SDK (AVS_SDK) applications. The build procedure is the described on the README.md of the corresponding branch. We have 2 fuctional branches now: imx-alexa-sdk: Support for Morty based i.mx releases imx7d-pico-avs-sdk_4.1.15-1.0.0: legacy support for Jethro releases The master branch is only used to collect manifest files, that used with repo init/sync commands will fetch the whole environment for the 2 special supported boards: i.MX7D Pico Pi and i.MX8M EVK. However the meta-avs-demos can be used with any i.MX board either. Recipes to include Amazon's Alexa Voice Services in your applications. The meta-avs-demos provides the required recipes to build an i.MX image with the support for running Alexa SDK. The imx-alexa-sdk branch is based on Morty and kernel 4.9.X and it supports the next builds: i.MX7D Pico Pi i.MX8M EVK Generic i.MX board For the i.MX7D Pico Pi and i.MX8M EVK there is an extended support for additional (external) Sound Cards like: TechNexion VoiceHat: 2Mic Array board with DSPConcepts SW support Synaptics Card: 2 Mic with Sensory WakeWord support The Generic i.MX is for any other regular i.MX board supported on the official NXP BSP releases. Only the default soundcard (embedded) on the board is supported. Sensory wakeword is currently only enabled for those with ARMV7 architecture. To support any external board like the VoiceHat or Synaptics is up to the user to include the additional patches/changes required. Build Instructions Follow the corresponding README file to follow the steps to build an image with Alexa SDK support README-IMX7D-PICOPI.md README-IMX8M-EVK.md README-IMX-GENERIC.md

The i.MX Android O8.0.0_1.0.0 GA release is now available from IMX_SW page. Overview -> BSP Updates and Releases -> Android 8.0.0 Oreo (O8.0.0_1.0.0, 4.9 kernel)   Files available: # Name Description 1 android_O8.0.0_1.0.0_docs.tar.gz i.MX Android O8.0.0_1.0.0 BSP Documentation 2 imx-o8.0.0_1.0.0_ga.tar.gz i.MX Android O8.0.0_1.0.0 proprietary surce code for i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo  i.MX 6Sololite, i.MX6SX and i.MX7D 3 android_O8.0.0_1.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_O8.0.0_1.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_O8.0.0_1.0.0_image_6slevk.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_O8.0.0_1.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_O8.0.0_1.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_O8.0.0_1.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE Board based on i.MX 7Dual 9 fsl_aacp_dec_O8.0.0_1.0.0.tar.gz AAC Plus Codec for O8.0.0_1.0.0 10 android_O8.0.0_1.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for O8.0.0_1.0.0   Supported Hardware SoC/Boards: i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform i.MX 6SoloLite EVK platform i.MX 6SoloX SABRE-SD board and platforms i.MX 6SoloX SABRE-AI board and platforms i.MX 7Dual SABRE-SD board and platform   Changes: Compared to the N7.1.2_2.0.0 release, this release has the following major changes: Upgraded the Android code base from android-7.1.2_r9 to android-8.0.0_r25. Removed the device partition and added the vendor partition. Enabled ION-based gralloc and EGL. Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.

Using a RAW NAND is more difficult compared to eMMC, but for lower capacity it is still cheaper. Even with the ONFI (Open NAND Flash Interface) you can face initialization issue you can find by measure performance. I will take example of a non-well supported flash, I have installed on my evaluation board (SABRE AI). I wanted to do a simple performance test, to check roughly the MB/s I can expected with this NAND. One of a simplest test is to use the dd command: root@imx6qdlsolo:~# time dd if=/dev/mtd4 of=/dev/null 851968+0 records in 851968+0 records out 436207616 bytes (436 MB, 416 MiB) copied, 131.8884 s, 3.3 MB/s ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ As my RAW was supposed to work in EDO Mode 5, I could expect more than 20MB/s. To check what was wrong, read you kernel startup log: Booting Linux on physical CPU 0x0 Linux version 4.1.15-2.0.0+gb63f3f5 (bamboo@yb6) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Fri Sep 16 15:02:15 CDT 2016 CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: Freescale i.MX6 DualLite/Solo SABRE Automotive Board [...] Amd/Fujitsu Extended Query Table at 0x0040 Amd/Fujitsu Extended Query version 1.3. number of CFI chips: 1 nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xdc nand: Macronix MX30LF4G18AC nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 gpmi-nand 112000.gpmi-nand: mode:5 ,failed in set feature. Bad block table found at page 262080, version 0x01 Bad block table found at page 262016, version 0x01 nand_read_bbt: bad block at 0x00000a7e0000 nand_read_bbt: bad block at 0x00000dc80000 4 cmdlinepart partitions found on MTD device gpmi-nand Creating 4 MTD partitions on "gpmi-nand":‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ On line 13 you can read "mode:5, failed in set feature", meaning you are not in mode 5... so you have the "relaxed" timing you have at boot. After debuging your code (I have just remove the NAND back reading security check), you can redo the test: root@imx6qdlsolo:~# time dd if=/dev/mtd4 of=/dev/null 851968+0 records in 851968+0 records out 436207616 bytes (436 MB, 416 MiB) copied, 32.9721 s, 13.2 MB/s‍‍‍‍‍‍‍‍‍‍‍‍ So you multiplied the performances by 4! Anyway, you have a better tool to measure your NAND performance, it is mtd_speedtest, but you have to rebuild your kernel. In Yocto, reconfigure your kernel (on your PC of couse!): bitbake virtual/kernel -c menuconfig‍‍‍ Choose in the menu "Device Drivers" -> "Memory Technology Device (MTD) support" -> "MTD tests support", even it it not recommended! bitbake virtual/kernel -f -c compile bitbake virtual/kernel -f -c build bitbake virtual/kernel -f -c deploy‍‍‍‍‍‍‍‍‍ Then reflash you board (kernel + rootfs as tests are .ko files): Then you can do more accurate performance test: insmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko dev=2 ================================================= mtd_speedtest: MTD device: 2 mtd_speedtest: MTD device size 16777216, eraseblock size 131072, page size 2048, count of eraseblocks 128, pages per eraseblock 64, OOB size 64 mtd_test: scanning for bad eraseblocks mtd_test: scanned 128 eraseblocks, 0 are bad mtd_speedtest: testing eraseblock write speed mtd_speedtest: eraseblock write speed is 4537 KiB/s mtd_speedtest: testing eraseblock read speed mtd_speedtest: eraseblock read speed is 16384 KiB/s mtd_speedtest: testing page write speed mtd_speedtest: page write speed is 4250 KiB/s mtd_speedtest: testing page read speed mtd_speedtest: page read speed is 15784 KiB/s mtd_speedtest: testing 2 page write speed mtd_speedtest: 2 page write speed is 4426 KiB/s mtd_speedtest: testing 2 page read speed mtd_speedtest: 2 page read speed is 16047 KiB/s mtd_speedtest: Testing erase speed mtd_speedtest: erase speed is 244537 KiB/s mtd_speedtest: Testing 2x multi-block erase speed mtd_speedtest: 2x multi-block erase speed is 252061 KiB/s mtd_speedtest: Testing 4x multi-block erase speed mtd_speedtest: 4x multi-block erase speed is 256000 KiB/s mtd_speedtest: Testing 8x multi-block erase speed mtd_speedtest: 8x multi-block erase speed is 260063 KiB/s mtd_speedtest: Testing 16x multi-block erase speed mtd_speedtest: 16x multi-block erase speed is 260063 KiB/s mtd_speedtest: Testing 32x multi-block erase speed mtd_speedtest: 32x multi-block erase speed is 256000 KiB/s mtd_speedtest: Testing 64x multi-block erase speed mtd_speedtest: 64x multi-block erase speed is 260063 KiB/s mtd_speedtest: finished =================================================‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You can now achieve almost 16MB/s, better than the dd test. Of course you cannot achieve more than 20MB/s, but you are not that far, and the NAND driver need optimizations. To redo the test: rmmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko insmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko dev=2 To check your NAND is in EDO mode 5, you can check your clock tree: /unit_tests/dump-clocks.sh clock          parent   flags    en_cnt pre_cnt      rate [...] gpmi_bch_apb   ---      00000005   0       0       198000000 gpmi_bch       ---      00000005   0       0       198000000 gpmi_io        ---      00000005   0       0        99000000 gpmi_apb       ---      00000005   0       0       198000000‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The IO are clocked now at 99MHz, thus you can read at 49.5MHz (20ns in EDO mode 5 definition).

    Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab       I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARMv7 and tested on imx6ulevk/imx6ull14x14evk/imx6qpsabresd/imx6dlsabresd/imx6sxsabresdimx6slevk boards. I also did stress test by tool stress-ng on some boards.      You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm.git, and git checkout Linux-4.19.35-1.1.0. (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" DISTRO_FEATURES_remove = "optee" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" DISTRO_FEATURES_remove = "optee" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command (/usr/xenomai/demo/cyclictest -p 50 -t 5 -m -n -i 1000 😞 //Mecury on 6ULL with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 128M --metrics-brief policy: fifo: loadavg: 6.08 2.17 0.81 8/101 534 T: 0 (  530) P:99 I:1000 C:  74474 Min:     23 Act:  235 Avg:   77 Max:    8278 T: 1 (  531) P:99 I:1500 C:  49482 Min:     24 Act:   32 Avg:   56 Max:    8277 T: 2 (  532) P:99 I:2000 C:  36805 Min:     24 Act:   38 Avg:   79 Max:    8170 T: 3 (  533) P:99 I:2500 C:  29333 Min:     25 Act:   41 Avg:   54 Max:    7069 T: 4 (  534) P:99 I:3000 C:  24344 Min:     24 Act:   51 Avg:   60 Max:    7193   //Cobalt on 6ULL with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 128M --metrics-brief policy: fifo: loadavg: 7.02 6.50 4.01 8/100 660 T: 0 (  652) P:50 I:1000 C: 560348 Min:      1 Act:   10 Avg:   15 Max:      71 T: 1 (  653) P:50 I:1500 C: 373556 Min:      1 Act:    9 Avg:   17 Max:      78 T: 2 (  654) P:50 I:2000 C: 280157 Min:      2 Act:   14 Avg:   20 Max:      64 T: 3 (  655) P:50 I:2500 C: 224120 Min:      1 Act:   12 Avg:   15 Max:      57 T: 4 (  656) P:50 I:3000 C: 186765 Min:      1 Act:   31 Avg:   19 Max:      53   //Cobalt on 6qp with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --metrics-brief policy: fifo: loadavg: 8.11 7.44 4.45 8/156 1057 T: 0 (  917) P:50 I:1000 C: 686106 Min:      0 Act:    3 Avg:    5 Max:      53 T: 1 (  918) P:50 I:1500 C: 457395 Min:      0 Act:    3 Avg:    5 Max:      49 T: 2 (  919) P:50 I:2000 C: 342866 Min:      0 Act:    2 Avg:    4 Max:      43 T: 3 (  920) P:50 I:2500 C: 274425 Min:      0 Act:    3 Avg:    5 Max:      58 T: 4 (  921) P:50 I:3000 C: 228682 Min:      0 Act:    2 Avg:    6 Max:      46   //Cobalt on 6dl with stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief policy: fifo: loadavg: 3.35 4.15 2.47 1/122 850 T: 0 (  729) P:50 I:1000 C: 608088 Min:      0 Act:    1 Avg:    3 Max:      34 T: 1 (  730) P:50 I:1500 C: 405389 Min:      0 Act:    0 Avg:    4 Max:      38 T: 2 (  731) P:50 I:2000 C: 304039 Min:      0 Act:    1 Avg:    4 Max:      45 T: 3 (  732) P:50 I:2500 C: 243225 Min:      0 Act:    0 Avg:    4 Max:      49 T: 4 (  733) P:50 I:3000 C: 202683 Min:      0 Act:    0 Avg:    5 Max:      38   //Cobalt on 6SX stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M  --metrics-brief policy: fifo: loadavg: 7.51 7.19 6.66 8/123 670 T: 0 (  598) P:50 I:1000 C:2314339 Min:      0 Act:    3 Avg:    8 Max:      60 T: 1 (  599) P:50 I:1500 C:1542873 Min:      0 Act:   15 Avg:    8 Max:      72 T: 2 (  600) P:50 I:2000 C:1157152 Min:      0 Act:    4 Avg:    9 Max:      55 T: 3 (  601) P:50 I:2500 C: 925721 Min:      0 Act:    5 Avg:    9 Max:      57 T: 4 (  602) P:50 I:3000 C: 771434 Min:      0 Act:    6 Avg:    6 Max:      41   //Cobalt on 6Solo lite stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M  --metrics-brief policy: fifo: loadavg: 7.01 7.04 6.93 8/104 598 T: 0 (  571) P:50 I:1000 C:3639967 Min:      0 Act:    9 Avg:    7 Max:      60 T: 1 (  572) P:50 I:1500 C:2426642 Min:      0 Act:    9 Avg:   11 Max:      66 T: 2 (  573) P:50 I:2000 C:1819980 Min:      0 Act:   11 Avg:   10 Max:      57 T: 3 (  574) P:50 I:2500 C:1455983 Min:      0 Act:   12 Avg:   10 Max:      56 T: 4 (  575) P:50 I:3000 C:1213316 Min:      0 Act:    7 Avg:    9 Max:      43   //Cobalt on 7d with stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief policy: fifo: loadavg: 5.03 5.11 5.15 6/107 683 T: 0 (  626) P:50 I:1000 C:6842938 Min:      0 Act:    1 Avg:    2 Max:      63 T: 1 (  627) P:50 I:1500 C:4561953 Min:      0 Act:    4 Avg:    2 Max:      66 T: 2 (  628) P:50 I:2000 C:3421461 Min:      0 Act:    0 Avg:    2 Max:      69 T: 3 (  629) P:50 I:2500 C:2737166 Min:      0 Act:    3 Avg:    2 Max:      71 T: 4 (  630) P:50 I:3000 C:2280969 Min:      0 Act:    2 Avg:    1 Max:      33   //////////////////////////////////////// Update for Yocto L5.10.52 2.1.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.52 2.1.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm and git checkout xenomai-5.10.52-2.1.0. Updating: 1, Upgrade Xenomai to v3.2 2, Enable Dovetail instead of ipipe. Copy xenomai-arm to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. //////////////////////////////////////// Update for Yocto L5.15.71 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.15.71 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm and git checkout xenomai-5.15.71-2.2.0. Updating: 1, Upgrade Xenomai to v3.2.2 Copy xenomai-arm to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch.   ///////// Later update for Later Yocto release, please refer to the following community post //////////// 移植实时Linux方案Xenomai到i.MX ARM64平台 (Enable real-time Linux Xenomai on i.MX ARM64 Platform)   

The Linux L4.9.88_2.0.0 Rocko, i.MX7ULP Linux/SDK2.4 RFP(GA) release files are now available. Linux on IMX_SW web page, Overview -> BSP Updates and Releases ->Linux L4.9.88_2.0.0 SDK on https://mcuxpresso.nxp.com/ web page.   Files available: Linux:  # Name Description 1 imx-yocto-L4.9.88_2.0.0.tar.gz L4.9.88_2.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 L4.9.88_2.0.0_images_MX6QPDLSOLOX.tar.gz i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo, i.MX 6Solox Linux Binary Demo Files 3 L4.9.88_2.0.0_images_MX6SLEVK.tar.gz i.MX 6Sololite EVK Linux Binary Demo Files 4 L4.9.88_2.0.0_images_MX6UL7D.tar.gz i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 L4.9.88_2.0.0_images_MX6SLLEVK.tar.gz i.MX 6SLL EVK Linux Binary Demo Files 6 L4.9.88_2.0.0_images_MX8MQ.tar.gz i.MX 8MQuad EVK Linux Binary Demo files 7 L4.9.88_images_MX7ULPEVK.tar.gz i.MX 7ULP EVK Linux Binary Demo Files  8 L4.9.88_2.0.0-ga_mfg-tools.tar.gz Manufacturing Toolkit for Linux L4.9.88_2.0.0 iMX6,7 BSP 9 L4.9.88_2.0.0_mfg-tool_MX8MQ.tar.gz Manufacturing Toolkit for Linux L4.9.88_2.0.0 i.MX8MQ BSP 10 imx-aacpcodec-4.3.5.tar.gz Linux AAC Plus Codec for L4.9.88_2.0.0   SDK:   On https://mcuxpresso.nxp.com/, click the Select Development Board to customize the SDK based on your configuration then download the SDK package.    Target board: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6QuadPlus SABRE-AI Board i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloLite EVK Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board i.MX 7Dual SABRE-SD Board i.MX 6UltraLite EVK Board i.MX 6ULL EVK Board i.MX 6SLL EVK Board i.MX 7ULP EVK Board i.MX 8MQ EVK Board   What’s New/Features: Please consult the Release Notes.   Known issues For known issues and more details please consult the Release Notes.   More information on changes of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-rocko ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-rocko

The i.MX Android N7.1.2_2.0.0 GA release is now available on IMX_SW page.   Files available: # Name Description 1 android_N7.1.2_2.0.0_docs.tar.gz i.MX Android N7.1.2_2.0.0 BSP Documentation 2 android_N7.1.2_2.0.0_source.tar.gz Source Code of Android N7.1.2_2.0.0 BSP (4.1 kernel) for i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo i.MX 6Sololite, i.MX6SX and i.MX7D 3 android_N7.1.2_2.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_N7.1.2_2.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_N7.1.2_2.0.0_image_6slevk.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_N7.1.2_2.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_N7.1.2_2.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_N7.1.2_2.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE Board based on i.MX 7Dual 9 fsl_aacp_dec.tar.gz AAC Plus Codec for N7.1.2_2.0.0 10 android_N7.1.2_2.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for N7.1.2_2.0.0   Supported Hardware SoC/Boards: i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform i.MX 6SoloLite EVK platform i.MX 6SoloX SABRE-SD board and platforms i.MX 6SoloX SABRE-AI board and platforms i.MX 7Dual SABRE-SD board and platform   Changes: Compared to the N7.1.1_1.0.0 release, this release has the following major changes: Upgraded the Android code base from android-7.1.1_r13 to android-7.1.2_r9. Upgraded U-Boot from v2015.04 to v2017.03. Upgraded the kernel from v4.1.15 to v4.9.17. Upgraded the GPU driver from 6.2.0.p2 to 6.2.2.p1. Upgraded the Wi-Fi BCMDHD release version to 1.141.100.6. Refine the Gralloc and HWC HAL. Enable the GPT partition to replace the MBR partition.   Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.

Purpose:  Introduce how to debug M4 using trace32 and the difference with general debug case.If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool. Firmware: Here we using Freertos as the example, but not limited to this. There is one small difference with general debug case to M4 in 6sx, which when you attach M4 and break M4, it may impact the peripheral that A9 is using. You may have found when you break M4, A9 uart console also was frozen at the same time. This is caused by that when M4 enter debug mode, the debug_req will also assert in the peripherals which you are using on the A9 system. So,need configure the peripherals to keep running when the debug_req is assert when do the M4/A9 debug separately. Need configure the DBGEN (*) register in the related peripherals to allow the eripherals not going into debug mode and keep running even if debug_req is HIGH. The peripherals we need take care are: CAN, UART, EPIT,GPT, ENET, PWM. Note: For the CAN, the register bit is called FRZ Here is the details of uart dbgen in the RM: So if we want debug M4 separately,we should disable this bit, as A9 was using this peripheral. Here we take Freertos as the example to illuminate how to debug M4 step by step: Enable DBGEN case: Load M4 image into memory and kick off M4. (You can refer to  for the details)           =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000               ##Starting auxiliary core at 0x9FF00000                ... Attach M4 using the m4.cmm file(attached): Note:  You can find the elf file at the same folder of binary: So now you can debug your code step by step.If you go back to A9 side uart console, you would find the console have been frozen. Disable DBGEN case at A9 side: Load M4 image into memory and kick off M4. (You can refer to  for imx6sx user guide  the details)           =>mm 0x20200b4                              020200b4:00000020 ? 0x820           =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000                ##Starting auxiliary core at 0x9FF00000                ... Attach M4 using the m4.cmm file(attached) In this case you will the A9 uart console still can work, after you break M4. Disable DBGEN case at M4 side: Load M4 image into memory and kick off M4.   =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                     reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000          ##Starting auxiliary core at 0x9FF00000 Attach M4 using the m4_disable_dbgen.cmm  file(attached) In this case you will the A9 uart console still can work, after you break M4.   Notes: For more trace32 usage, please refer to http://www.lauterbach.cn/           For more imx6sx information, please refer to i.MX 6SoloX Family of Applications Processors|NXP.

NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. NOTE: See this link to instrument a board with a Smart Sensor. Overview The i.MX Power Profiler system consists of one to fourteen "smart" current sensors, an aggregator shield, and a Kinetis FRDM board (the FRDM-KL25 has been used in prototyping but the FRDM-K64F and FRDM-K66F should also be fully compatible). One of the biggest improvements of this system over its preceeding dual-range measurement system is that the microcontroller on each sensor board allows near-simultaneous measurement of all instrumented rails on a board. The dual range profiler has only a single MCU for all sensors, so only one measurement can be made at a time.  It is intended to be used to instrument one to fourteen rails of a target i.MX appliation board. Ideally, the target board will have been designed with a matching/mating power sense footprint for each rail to be measured.  Each smart sensor can sense current in three ranges with three current sense amplifiers. They are "smart" because each sensor board has a Kinetis KL05Z on it to control the switching FETs and to digitize the analog signals (the sense amplifier outputs and the target's power supply rail voltage). A 1% voltage regulator on each smart sensor provides a good voltage reference right next to the KL05Z to ensure better ADC accuracy. Each smart sensor board communicates via I2C. The aggregator shield has three I2C bus extenders (PCA9518) which essentially provide a dedicated I2C bus for each of the connected smart sensors. The FRDM board's I2C is also connected to one of the bus extenders ports. Individual GPIO lines are routed to each smart sensor's connected along with a ganged reset and trigger line for all of the connected smart sensors. A boost regulator generates almost 12V from the FRDM board's 5V supply, which is used for all the switching FETs on the smart sensor boards. The FRDM board's 5V rail is also routed to each smart sensor, which is regulated down to 3.3V locally on each connected smart sensor. Here is a photo of the very first prototypes after moving to 10-pin 0.05" spaced headers and ribbon cables instead of FFC: The smart sensor is intended to mate with through-hole current sense tap points on the target i.MX application board. Three holes spaced at 0.05" each. When not instrumented with sensor, a short needs to be placed across the outer two pins so that the board will function normally. The through hole connections provide physical protection to the target board, keeping traces from getting ripped off. The ground connection in the center provides a reference for meauring the rail voltage on the target board. A partial layout example of the implementation of the current sense footprint is below, where two 0805 shorting resistors in parallel are placed on each side of the holes. The top trace connects to the regulator output and the bottom to the load, usually an i.MX power supply rail. To include the current sense footprint into a board during the design phase, it should be configured as in the following partial schematic:  Every effort should be made to place the feedback on the i.MX side of the sense points so that the regulator compensates for the additional series resistance of the smart sensor, which effectively eliminates the additional series resistance the smart sensor adds. The Feedback should be before the smart sensor if the switching supply won't tolerate the additional series resistance (i.e., output becomes unstable).

Instrumenting A Board To instrument a board, the connection between the power supply and the target device needs to be broken, usually via a series resistor that's placed on the board. Sometimes the inductor needs to be lifted if no series resistor was included on the rail by the board's designer. In the ideal case, through-hole connections were also provided on the board for the connection of these off-board sensors. Here are three close-up photos that show several boards that have been instrumented: In all three cases, the sensors stand in place via the two outer current carrying wires. The middle and right used insulated wires where as the one on the left used bare wires. In all three cases, the sensor's + connection needs to go towards the power supply and the - connection goes to the target device. The outer wires here are 24-26 gauge. (The relatively heavy gauge wire is used to keep the series resistance of inserting a smart sensor to a minimum.) The ground connection is the middle hole of the smart sensor. In the left and middle photos, a 30 gauge wire connects to the middle hole ground connection on the  board. In the right photo, the ground wire was more conveniently added to a big cap just below the bottom of edge of the photo. Here are wider angle view photos of two of the boards above: The sensors on the left are free-standing since the current carrying wires are stiff enough to hold them upright. Care must be taken since too much flexing will cause a wire to break. Too much bending can also cause a short to the board (and that's why insulated wires were used on these boards). The board on the right has the sensors laying parallel to the board. They are not affixed to the board, but a wire is wrapped around the bundle of ribbon cables out of view past the right edge of the photo. For boards without the through hole connections, the smart sensors need to be immobilized to keep from pulling the SMT pads off the board. If there is room on the board or sides of connectors or large components, the sensors may be attached down with foam double-sticky tape (see photo below, sensor affixed on top i.MX7ULP): For boards where there are no convenient unpopulated areas or there are too many sensors, some other means needs to be devised to immoblize the smart sensors. In the left photo below, two inductors per sensor have been flipped and the two sensors inserted to instrument the two rails. The solder pads on the inductors would easily be broken off by any movement of the smart sensors, so a cage with clamps to hold the ribbon cables was 3D printed. On the back side, there is room for the aggregator to be zip tied to the bottom plate, so the instrumented board can be moved as a single unit with minimal flexing of the ribbon cables.

The Linux L4.14.98_1.0.0_GA; and SDK2.5 for 8QM/8QXP Post GA, SDK2.5.1 for 7ULP GA3 release are now available. Linux on IMX_SW web page, Overview -> BSP Updates and Releases -> Linux L4.14.98_2.0.0 SDK on https://mcuxpresso.nxp.com Files available: Linux:  # Name Description 1 imx-yocto-L4.14.98_2.0.0_ga.zip L4.14.98_2.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 L4.14.98_2.0.0_ga_images_MX6QPDLSOLOX.zip i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo, i.MX 6Solox Linux Binary Demo Files 3 L4.14.98_2.0.0_ga_images_MX6SLLEVK.zip i.MX 6SLL EVK Linux Binary Demo Files 4 L4.14.98_2.0.0_ga_images_MX6UL7D.zip i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 L4.14.98_2.0.0_ga_images_MX7DSABRESD.zip i.MX 7Dual SABRESD Linux Binary Demo Files  6 L4.14.98_2.0.0_ga_images_MX7ULPEVK.zip i.MX 7ULP EVK Linux Binary Demo Files  7 L4.14.98_2.0.0_ga_images_MX8MMEVK.zip i.MX 8MMini EVK Linux Binary Demo Files  8 L4.14.98_2.0.0_ga_images_MX8MQEVK.zip i.MX 8MQuad EVK Linux Binary Demo files 9 L4.14.98_2.0.0_ga_images_MX8QMMEK.zip i.MX 8QMax MEK Linux Binary Demo files 10 L4.14.98_2.0.0_ga_images_MX8QXPMEK.zip i.MX 8QXPlus MEK Linux Binary Demo files 11 imx-scfw-porting-kit-1.2.tar.gz System Controller Firmware (SCFW) porting kit of L4.14.98_2.0.0 12 imx-aacpcodec-4.4.5.tar.gz Linux AAC Plus Codec v4.4.5 13 VivanteVTK-v6.2.4.p4.1.7.8.tgz Vivante Tool Kit v6.2.4.p4.1.7.8   SDK: On https://mcuxpresso.nxp.com/, click the Select Development Board, EVK-MCIMX7ULP//MEK-MIMX8QM/MEK-MIMX-8QX to customize the SDK based on your configuration then download the SDK package.  Target board: MX 8 Series MX 8QuadXPlus MEK Board MX 8QuadMax MEK Board MX 8M Quad EVK Board MX 8M Mini EVK Board MX 7 Series MX 7Dual SABRE-SD Board MX 7ULP EVK Board MX 6 Series MX 6QuadPlus SABRE-SD and SABRE-AI Boards MX 6Quad SABRE-SD and SABRE-AI Boards MX 6DualLite SDP SABRE-SD and SABRE-AI Boards MX 6SoloX SABRE-SD and SABRE-AI Boards MX 6UltraLite EVK Board MX 6ULL EVK Board MX 6ULZ EVK Board MX 6SLL EVK Board What’s New/Features: Please consult the Release Notes.   Known issues For known issues and more details please consult the Release Notes.   More information on changes of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-sumo ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-sumo#

The LMEM Base address is 0xE0082000u rather than 0xE0002000u.So please apply the patch to FreeRTOS_BSP_1.0.0_iMX6SX to enable the M4 cache, or the cache was not be enabled by default.It may have the big impact to your product performance. diff --git a/platform/devices/MCIMX6X/include/MCIMX6X_M4.h b/platform/devices/MCIMX6X/include/MCIMX6X_M4.h index 31d6eb2..3b9d240 100644 --- a/platform/devices/MCIMX6X/include/MCIMX6X_M4.h +++ b/platform/devices/MCIMX6X/include/MCIMX6X_M4.h @@ -25584,7 +25584,7 @@ typedef struct { /* LMEM - Peripheral instance base addresses */ /** Peripheral LMEM base address */ -#define LMEM_BASE                                (0xE0002000u) +#define LMEM_BASE                                (0xE0082000u) /** Peripheral LMEM base pointer */ #define LMEM                                   ((LMEM_Type *)LMEM_BASE) #define LMEM_BASE_PTR                            (LMEM)