i.MX Processors Knowledge Base

Discussions

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

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.

OpenSSL is popular software library for applications that secure communications over computer networks against eavesdropping or need to identify the party at the other end. It is widely used in internet web servers, serving a majority of all web sites. OpenSSL contains an open-source implementation of the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols, it is a robust, commercial-grade, and full-featured toolkit for the SSL and TLS protocols. OpenSSL is also a general-purpose cryptography library. Its core library, written in the C programming language, implements basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available. More and more embeded systems, like IoT gateway, ePOS, based on i.MX use OpenSSL for their secure communications and cryptographic operations. But it's cryptography library is pure software implementation which need to occupy lots of CPU resouce and the perfermance is very weak than dedicated hardware IP (like CAAM). CAAM is the i.MX's cryptographic acceleration and assurance module, which serves as NXP's latest cryptographic acceleration and offloading hardware. It combines functions previously implemented in separate modules to create a modular and scalable acceleration and assurance engine. It also implements block encryption algorithms, stream cipher algorithms, hashing algorithms, public key algorithms (i.MX6UL/i.MX7D/S), and a hardware random number generator. The official Yocto release (L4.1.15_2.0.0-ga) of the i.MX only enable cryptodev for accelerating symmetric algorithms and hashing algorithms, not support asymmetric algorithms(RSA, ECC). And its engine in OpenSSL(version 1.0.2h) also miss some features which is used to support symmetric algorithms and hashing algorithms, for example, AES ECB, SHA224/256, etc. These patches in the post will close the above gaps for i.MX Linux system. The software environments as the belows: Linux kernel: imx_4.1.15_2.0.0_ga cryptodev: 1.8 OpenSSL: 1.0.2h The patches include the following key features: 1, Add public key cryptography part in CAAM driver, through protocol commands, to implement a number of public (and private) key functions. These are DSA and ECDSA sign/verify, Diffie-Hellman (DH) and ECDH key agreement, ECC key generation, DLC key generation, RSA encryption/decryption, RSA key-generation finalization. 2, Add big number operation and elliptic curve math in CAAM driver to implement addition, subtraction, multiplication, exponentiation, reduction, inversion, greatest common divisor, prime testing and point add, point double, point multiply. 3, Add API in cryptodev to support RSA encryption/decryption, DSA/ECDSA sign/verify, DH/ECDH key agreement, ECC & DLC & RSA key generation and big number operation and elliptic curve math. 4, Add public key cryptography functions, hardware rng, and missing hash symmetric algorithms in OpenSSL crytodev engine. Note: 1, You can refer to ecdhtest.c, ecdsatest.c, dhtest.c, dsatest.c, rsa_test.c for how to use crytodev engine in your applications based on libcryto.so. You can also find their executable programs in folder openssl-1.0.2h/test after compiling. 2, If you want to call crytodev API directly to accelerate public key cryptography operations, please refer to asymmetric_cipher.c in cryptodev-linux-1.8/tests. Current Limitation: 1, CAAM driver don't support AES GCM/CCM but hardware supporting. I plan to add the feature next version. 2, ECDSA sign/verify will fail on some binary curves (sect163r1, sect163r2, sect193r1, sect193r2, sect233r1, sect283r1, sect409r1, sect571r1 and X9.62 binary curves). I will try to find the root cause and fix it. ==================================== for some binary curves (sect163r1, sect163r2, sect193r1, sect193r2, sect233r1, sect283r1, sect409r1, sect571r1 and X9.62 binary curves) are rarely used, so i will try to find the root cause when i'm free. +++++++++++++++++++++++ updating for Linux-4.14.78-1.1.10 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux -4.14.78-1.1.10. The new software environments as the belows: Linux kernel: imx_4.14.78_1.1.10 cryptodev: 1.9 OpenSSL: 1.0.2p HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini, i.MX8/8X. The patches include the following new features: 1, support RSA key generation but defaultly use openssl build-in function (BN_generate_prime_ex) to create prime p, q for higher security. If need to use CAAM accelerating, please comment Macro USE_BUILTIN_PRIME_GENERATION, but don't confirm its security. 2, Add Manufacturing-protection feature, and you can refer to manufacturing_protection_test function in asymmetric_cipher.c. 3, Support AES GCM in cryptodev. 4, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-4.14.78-1.1.10 and copy meta-openssl-caam to folder <Yocto 4.14.78-1.1.10 dir>/sources/ 5, Run DISTRO=fsl-imx-wayland MACHINE=imx6ulevk source fsl-setup-release.sh -b build-imx6ulevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into /build-imx6ulevk/conf/bblayers.conf 6, bitbake fsl-image-validation-imx 7, Run the below command on your i.MX6UL EVK board. modprobe cryptodev openssl genrsa -f4 -engine cryptodev 512 -elapsed openssl speed dsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 1024 -elapsed openssl speed rsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 2048 -elapsed openssl speed ecdsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 3072 -elapsed openssl speed ecdh -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 4096 -elapsed openssl speed -evp sha256 -engine cryptodev -elapsed openssl speed -evp aes-128-cbc -engine cryptodev -elapsed openssl speed -evp aes-128-ecb -engine cryptodev -elapsed openssl speed -evp aes-128-cfb -engine cryptodev -elapsed openssl speed -evp aes-128-ofb -engine cryptodev -elapsed openssl speed -evp des-ede3 -engine cryptodev -elapsed openssl speed -evp des-cbc -engine cryptodev -elapsed openssl speed -evp des-ede3-cfb -engine cryptodev -elapsed +++++++++++++++++++++++ updating for Linux-4.14.98-2.3.3 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux -4.14.98-2.3.3. The new software environments as the belows: Linux kernel: imx_4.14.98-2.3.3 cryptodev: 1.9 OpenSSL: 1.0.2p HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano, i.MX8/8X. The patches include the following new features: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-4.14.98-2.3.3 and copy meta-openssl-caam to folder <Yocto 4.14.98-2.3.3 dir>/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source fsl-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into /build-imx8mmevk/conf/bblayers.conf 3, bitbake fsl-image-validation-imx 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl genrsa -f4 -engine cryptodev 512 -elapsed openssl speed dsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 1024 -elapsed openssl speed rsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 2048 -elapsed openssl speed ecdsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 3072 -elapsed openssl speed ecdh -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 4096 -elapsed openssl speed -evp sha256 -engine cryptodev -elapsed openssl speed -evp aes-128-cbc -engine cryptodev -elapsed openssl speed -evp aes-128-ecb -engine cryptodev -elapsed openssl speed -evp aes-128-cfb -engine cryptodev -elapsed openssl speed -evp aes-128-ofb -engine cryptodev -elapsed openssl speed -evp des-ede3 -engine cryptodev -elapsed openssl speed -evp des-cbc -engine cryptodev -elapsed openssl speed -evp des-ede3-cfb -engine cryptodev -elapsed +++++++++++++++++++++++ updating for Linux-4.19.35-1.1.2 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 4.19.35-1.1.2. Software environments as the belows: Linux kernel: imx_4.19.35-1.1.2 cryptodev: 1.10 OpenSSL: 1.1.1l HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-4.19.35-1.1.2 and copy meta-openssl-caam to folder <Yocto 4.19.35-1.1.2 dir>/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 4.19.35-1.1.2 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake fsl-image-validation-imx. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed +++++++++++++++++++++++ updating for Linux-5.4.70-2.3.4 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.70_2.3.4. Software environments as the belows: Linux kernel: imx_5.4.70_2.3.4 cryptodev: 1.10 OpenSSL: 1.1.1l HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-5.4.70-2.3.4 and copy meta-openssl-caam to folder <Yocto 5.4.70_2.3.4 dir>/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 5.4.70_2.3.4 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed +++++++++++++++++++++++ updating for Linux-5.10.52-2.1.0 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.10.52_2.1.0. Software environments as the belows: Linux kernel: lf-5.10.y cryptodev: 1.12 OpenSSL: 1.1.1l HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-5.10.52-2.1.0 and copy meta-openssl-caam to folder <Yocto 5.10.52_2.1.0 dir>/sources/ 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 5.10.52_2.1.0 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed +++++++++++++++++++++++ updating for Linux-5.15.71-2.2.0 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.15.71-2.2.0. Software environments as the belows: Linux kernel: lf-5.15.71-2.2.0 cryptodev: 1.12 OpenSSL: 3.1.0 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-5.15.71-2.2.0 and copy meta-openssl-caam to folder <Yocto 5.15.71_2.2.0 dir>/sources/ 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 5.15.71_2.2.0 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed sm2 openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed

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.

Following docs(English or Chinese version) are also can be referred as a hand on guide. Freescale i.MX6 DRAM Port Application Guide-DDR3 飞思卡尔i.MX6平台DRAM接口高阶应用指导-DDR3篇 Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.Mx6DQSDL DDR3 Script Aid Please find i.MX6SX DDR3 Script Aid through below link.. i.MX6SX DDR3 Script Aid Any questions are welcome! Change History: 0.02 - Add total 1Gbit density supporting.

Host TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. U-Boot will download the Linux kernel and dtb file using tftp and then the kernel will mount (via NFS) its root file system on the computer hard drive. 1. TFTP Setup 1.1.1 Prepare the TFTP Service Get the required software if not already set up. On host for TFTP: Install TFTP on Host $ sudo apt-get install tftpd-hpa (Note: There are a number of examples in various forums, etc, of how to automatically start the TFTP service - but not all are successful on all Linux distro's it seems! The following may work for you.) Start the tftpd-hpa service automatically by adding a command to /etc/rc.local. $ vi /etc/rc.local Now, just before the exit 0 line edit below command then Save and Exit. $ service tftpd-hpa start Now, To control the TFTP service from the command line use: $ service tftpd-hpa restart To check the status of the TFTP service from the command line use: $ service tftpd-hpa status 1.1.1 Setup the TFTP Directories Now, we have to create the directory which will contain the kernel image and the device tree blob file. $ mkdir -p /imx-boot/imx6q-sabre/tftp Then, copy the kernel image and the device tree blob file in this directory. $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/zImage /imx-boot/imx6q-sabre/tftp $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/<dtb file> /imx-boot/imx6q-sabre/tftp OR we can use the default directory created by yocto {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/ The tftpd-hpa service looks for requested files under /imx-boot/imx6q-sabre/tftp The default tftpd-hpa directory may vary with distribution/release, but it is specified in the configuration file: /etc/default/tfptd-hpa. We have to change this default directory with our directory Edit default tftp directory $ vi /etc/default/tftpd-hpa Now, change the directory defined as TFTP_DIRECTORY with your host system directory which contains kernel and device tree blob file. Using created directory TFTP_DIRECTORY=”/imx-boot/imx6q-sabre/tftp” OR Using Yocto directory path TFTP_DIRECTORY=”{YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}” Restart the TFTP service if required $ service tftpd-hpa restart 1.2 NFS Setup 1.2.1 Prepare the NFS Service Get the required software if not already set up. On host for NFS: Install NFS on Host $ sudo apt-get install nfs-kernel-server The NFS service starts automatically. To control NFS services : $ service nfs-kernel-server restart To check the status of the NFS service from the command line : $ service nfs-kernel-server status 1.2.2 Setup the NFS Directories Now, we have to create the directory which will contain the root file system. $ mkdir -p /imx-boot/imx6q-sabre/nfs Then, copy the rootfs in this directory. $ cp -R {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs/* /imx-boot/imx6q-sabre/nfs OR we can use the default directory created by yocto. $ {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs 1.2.3 Update NFS Export File The NFS server requires /etc/exports to be configured correctly to access NFS filesystem directory to specific hosts. $ vi /etc/exports Then, edit below line into the opened file. <”YOUR NFS DIRECTORY”> <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex. If you created custom directory for NFS then, /imx-boot/imx6q-sabre/nfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex: /imx-boot/imx6q-sabre/nfs 192.168.*.*(rw,sync,no_root_squash,no_subtree_check) OR /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Now, we need to restart the NFS service. $ service nfs-kernel-server restart 2 Target Setup We need to set up the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters, setenv serverip 192.168.0.206 //This must be your Host IP address The path where the rootfs is placed in our host has to be indicated in the U-Boot, Ex. // if you choose default folder created by YOCTO setenv nfsroot /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs OR // if you create custom directory for NFS setenv nfsroot /imx-boot/imx6q-sabre/nfs Now, we have to set kernel image name and device tree blob file name in the u-boot, setenv image < zImage name > setenv fdt_file <dtb file name on host> Now, set the bootargs for the kernel boot, setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp' Use printenv command and check loadaddr and fdt_addr environment variables variables for I.MX6Q SABRE, loadaddr=0x12000000 fdt_addr=0x18000000 Also, check netboot environment variable. It should be like below, netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi; Now, set environment variable bootcmd to boot every time from the network, setenv bootcmd run netboot Now finally save those variable in u-boot: saveenv Reset your board; it should now boot from the network: U-Boot 2016.03-imx_v2016.03_4.1.15_2.0.0_ga+ga57b13b (Apr 17 2018 - 17:13:43 +0530) (..) Net: FEC [PRIME] Normal Boot Hit any key to stop autoboot: 0 Booting from net ... Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'zImage'. Load address: 0x12000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ########################################################### 2.1 MiB/s done Bytes transferred = 6578216 (646028 hex) Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'imx6q-sabresd.dtb'. Load address: 0x18000000 Loading: #### 1.8 MiB/s done Bytes transferred = 45893 (b345 hex) Kernel image @ 0x12000000 [ 0x000000 - 0x646028 ] ## Flattened Device Tree blob at 18000000 Booting using the fdt blob at 0x18000000 Using Device Tree in place at 18000000, end 1800e344 switch to ldo_bypass mode! Starting kernel ...

There are 8 UART ports on i.mx6ul and one uniform Linux driver for these UARTs. Form UART1~UART6, there is no special operation or attention to use them. But for UART7/UART8, there is a special rule to enable them. According to i.mx6ul RM, we can see UART7/8 RTS pins are muxed with ENET TX_CLK pins. When SION bit of ENET_TX_CLK is set, we need switch to other MUX mode as input signal for UARTx_RTS. Otherwise, UARTx_RTS will be interrupted by loopback ENET clock signal. So we should set IOMUXC_UART7_RTS_B_SELECT_INPUT and IOMUXC_UART8_RTS_B_SELECT_INPUT registers to 0x2/03 to avoid ENET clock's conflict no matter whether we enable UART7/8 RTS/CTS function or not. Let's summarize the different scenarios to enable UART7/8 as follows: 1. ENET driver is disabled and UART7/8 is enabled. There is no special operation to do, just use UART7/8 like other UARTs 2. ENET and UART7/8 are both enabled. There are two use models, RTS/CTS enabled or disabled. 2a. If we enable RTS/CTS feature and configure RTS/CTS pins in the device tree, of course, we should avoid the conflict between UART CTS/RTS pins and ENET TX_CLK pins. There is no special operation to do becuase your RTS/CTS device tree would automatically set IOMUXC_UART7_RTS_B_SELECT_INPUT/ IOMUXC_UART8_RTS_B_SELECT_INPUT register to correct value. 2b. If we don't enable RTS/CTS feature and no RTS/CTS pin configuration in devcie tree, we should manually add code to set IOMUXC_UART7_RTS_B_SELECT_INPUT/ IOMUXC_UART8_RTS_B_SELECT_INPUT register because the default value is 0x0(ENETx_TX_CLK_ALT1) Here is an example to show how to use UART7 on EVK board in scenario 2b. 1. modify imx6ul-14x14-evk.dts to enable UART7 a. remove all LCD settings to disable lcdif because we configure UART7 TX/RX pin pad to LCD data line b. add UART7 related settings &uart7 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart7>; status = "okay"; }; &iomuxc { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_hog_1>; .... pinctrl_uart7: uart7grp { fsl,pins = < MX6UL_PAD_LCD_DATA16__UART7_DCE_TX 0x1b0b1 MX6UL_PAD_LCD_DATA17__UART7_DCE_RX 0x1b0b1 >; }; 2. add code to set IOMUXC_UART7_RTS_B_SELECT_INPUT register in arch/arm/mach-imx/mach-imx6ul.c static void __init imx6ul_init_machine(void) { struct device *parent; void __iomem *iomux; struct device_node *np; ........... imx6ul_pm_init(); np = of_find_compatible_node(NULL,NULL,"fsl,imx6ul-iomuxc"); iomux = of_iomap(np, 0); writel_relaxed(0x2,iomux+0x650); } 3. build zImage and imx6ul-14x14-evk.dtb 4. Test in linux console root@imx6ulevk: ls /dev/ttymxc* //you can see ttymxc6 is in the list root@imx6ulevk: echo hello > /dev/ttymxc6 root@imx6ulevk:

Overview In latest i.MX6UL/i.MX6ULL EVK boards, Ethernet PHY chip is upgraded with new revsion ID (01) although the same part number KSZ8081RNBIA is used. The detailed change is as follows: Mark on old Ethernet PHY chip (Silicon Revision ID is 0, Mark is A2): KSZ8081 RNBIA 1439A2T M147J18M02 Mark on new Ethernet PHY chip (Silicon Revision ID is 1, Mark is A3) KSZ8081 RNBIA 1602SA3T M159S28M23 Software Patch Linux BSP requires to be updated to support this new Ethernet PHY because PHY setting is designed to be associated with silicon ID. See attached patch for the details (Please note: i.MX6ULL/i.MX6UL EVK shared the same board file.) The formal patch is also included into the releases starting from L4.1.15_2.0.1. See http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-bsp/recipes-kernel/linux/files?id=imx_4.1.15_2.0.1 If ethernet doesn't function on your i.MX6UL/i.MX6ULL EVK board in kernel, please check whether Silicon Revion Mark is A3 on the board and then apply for attached file for the test.

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#

GmSSL is an open source cryptographic toolbox that supports SM2 / SM3 / SM4 / SM9 and other national secret (national commercial password) algorithm, SM2 digital certificate and SM2 certificate based on SSL / TLS secure communication protocol to support the national security hardware password device , To provide in line with the national standard programming interface and command line tools, can be used to build PKI / CA, secure communication, data encryption and other standards in line with national security applications. For more information, please access GmSSL official website http://gmssl.org/english.html. Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga cryptodev: 1.9 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/MM, i.MX8QM/QXP. The patches include the following features: 1, Support SM2/SM9 encryption/decryption/sign/verify/key exchange, RSA encryption/decryption, DSA/ECDSA sign/verify, DH/ECDH key agreement, ECC & DLC & RSA key generation and big number operation and elliptic curve math by CAAM hardware accelerating. 2, run "git apply 0001-Enhance-cryptodev-and-its-engine-in-GmSSL-by-CAAM-s-.patch" under folder sources/poky, and "git apply 0001-Add-public-key-cryptography-operations-in-CAAM-drive.patch" under folder sources/meta-fsl-bsp-release for patch these codes. 3, GmSSL Build command: $ tar zxvf GmSSL-master-iMX.tgz $ cd GmSSL-master-iMX (For i.MX8M/MM, i.MX8QM/QXP) $ source /opt/arm-arch64/environment-setup-aarch64-poky-linux $ ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHW_ENDIAN_SWAP --prefix=~/install64 --openssldir=/etc/gmssl --libdir=/usr/lib no-saf no-sdf no-skf no-sof no-zuc -no-ssl3 shared linux-aarch64 $ make $ make install /*image and config file will be installed to folder ~/install64 */ (For i.MX6UL, i.MX7D/S) $ source /opt/arm-arch32/environment-setup-cortexa7hf-neon-poky-linux-gnueabi $ ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS --prefix=~/install32 --openssldir=/etc/gmssl --libdir=/usr/lib no-saf no-sdf no-skf no-sof no-zuc -no-ssl3 shared linux-armv4 $ make $ make install /*image and config file will be installed to folder ~/install32 */ 4, How to use GmSSL: copy image gmssl to /usr/bin on i.MX board; copy gmssl libcrypto.so.1.1 and libssl.so.1.1 to /usr/lib on i.MX board; copy folder etc/gmssl to /etc/ on i.MX board. copy test examples (dhtest, dsatest, rsa_test, ecdhtest, ecdsatest, eciestest, sm3test, sms4test, sm2test, sm9test) under GmSSL-master-iMX/test to U disk for running. You can run test examples by the following commands: #insmod /lib/modules/4.14.98-imx_4.14.98_2.0.0_ga+g5d6cbeafb80c/extra/cryptodev.ko #/run/media/sda1/dhtest #/run/media/sda1/dsatest #/run/media/sda1/rsa_test #/run/media/sda1/ecdhtest #/run/media/sda1/ecdsatest #/run/media/sda1/eciestest #/run/media/sda1/sm3test #/run/media/sda1/sms4test #/run/media/sda1/sm2test #/run/media/sda1/sm9test and speed test commands: #gmssl speed sm2 #gmssl genrsa -rand -f4 512 #gmssl speed dsa #gmssl genrsa -rand -f4 1024 #gmssl speed rsa #gmssl genrsa -rand -f4 2048 #gmssl speed ecdsa #gmssl genrsa -rand -f4 3072 #gmssl speed ecdh #gmssl genrsa -rand -f4 4096 ++++++++++++++++++++++++++++ updating at 2019-09-10 +++++++++++++++++++++++++++++++++++++++++++++ 0001-fix-the-bug-which-hash-and-cipher-key-don-t-use-DMA-.patch fix the issue which dismatching on key buffer between crytodev and caam driver. Crytodev uses stack's buffer for key storage and caam driver use it to dma map which cause flush cache failure. The patch need to apply on cryptodev-module in Yocto build. ++++++++++++++++++ updating at 2019-10-14 +++++++++++++++++++++++++++++++++++ This updating is for China C-V2X application. The meta-gmcrypto is Yocto layer which bases on GmSSL and Cryptodev. I add HW SM2 verification by dedicated CAAM job descriptor and enhanced SW SM2 verification by precomputed multiples of generator and ARMv8 assembler language to accelerate point operation. Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga cryptodev: 1.9 HW platform: i.MX8M/MM/MN, i.MX8QM/QXP. How to build: 1, You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-4.14.98_2.0.0. Copy meta-gmcrypto to folder (Yocto 4.14.98_2.0.0_ga dir)/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-cv2x and add BBLAYERS += " ${BSPDIR}/sources/meta-cv2x " into (Yocto 4.14.98_2.0.0_ga dir)/build-cv2x/conf/bblayers.conf and IMAGE_INSTALL_append += " gmssl-bin " into local.conf 3, Run bitbake fsl-image-validation-imx. 4, You can find cv2x-verify.c under (build dir)/tmp/work/aarch64-poky-linux/cryptodev-tests/1.9-r0/git/tests. It is example for using CAAM cryptdev interface to do C-V2X verification (includes SM2 p256, NIST p256 and brainpoolP256r1). cv2x_benchmark.c under (build dir)/tmp/work/aarch64-poky-linux/gmssl/1.0-r0/gmssl-1.0/test is the benchmark test program of C-V2X verifying. It includes HW, SW and HW+SW(one CPU) verifying for SM2 p256, NIST p256 and brainpoolP256r1. 5, Run the below command on your i.MX8QXP MEK board. modprobe cryptodev ./cv2x_benchmark Note: the udpated GmSSL also support projective coordinates and affine coordinates (CAAM only support affine coordinates). Affine coordinates is used by default. You can call EC_GROUP_set_coordinates() and EC_GROUP_restore_coordinates() to change coordinates and restore default. When you hope to use some EC APIs under expected coordinates, you need to call EC_GROUP_set_coordinates() before EC APIs and EC_GROUP_restore_coordinates() after them. Like the below example: orig_coordinate = EC_GROUP_set_coordinates(EC_PROJECTIVE_COORDINATES); group = EC_GROUP_new_by_curve_name(NID_sm2p256v1); EC_GROUP_restore_coordinates(orig_coordinate); ++++++++++++++++++++++++++++ updating at 2020-11-09 +++++++++++++++++++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.47_2.2.0. The meta-gmcrypto is Yocto layer which also support c-v2x feature in previous release. Software environments as the belows: Linux kernel: imx_5.4.47_2.2.0 cryptodev: 1.10 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-5.4.47-2.2.0. Copy meta-gmcrypto to folder (Yocto 5.4.47_2.2.0 dir)/sources/ 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-gmcrypto " into (Yocto 5.4.47_2.2.0 dir)/build-imx8mmevk/conf/bblayers.conf and IMAGE_INSTALL_append += " gmssl-bin " into local.conf 3, Run bitbake fsl-image-validation-imx. 4, You can find cv2x-verify.c under (build dir)/tmp/work/aarch64-poky-linux/cryptodev-tests/1.10caam-r0/git/tests. It is example for using CAAM cryptdev interface to do C-V2X verification (includes SM2 p256, NIST p256 and brainpoolP256r1). cv2x_benchmark.c under (build dir)/tmp/work/aarch64-poky-linux/gmssl/1.0-r0/gmssl-1.0/test is the benchmark test program of C-V2X verifying. It includes HW, SW and HW+SW(one CPU) verifying for SM2 p256, NIST p256 and brainpoolP256r1. 5, Run the below command on your i.MX8M Mini evk board. modprobe cryptodev ./cv2x_benchmark gmssl speed sm2 gmssl speed dsa gmssl speed rsa gmssl speed ecdsa gmssl speed ecdh gmssl genrsa -rand -f4 -engine cryptodev 4096 Note: 1, the udpated GmSSL also support projective coordinates and affine coordinates (CAAM only support affine coordinates). Affine coordinates is used by default. You can call EC_GROUP_set_coordinates() and EC_GROUP_restore_coordinates() to change coordinates and restore default. When you hope to use some EC APIs under expected coordinates, you need to call EC_GROUP_set_coordinates() before EC APIs and EC_GROUP_restore_coordinates() after them. Like the below example: orig_coordinate = EC_GROUP_set_coordinates(EC_PROJECTIVE_COORDINATES); group = EC_GROUP_new_by_curve_name(NID_sm2p256v1); EC_GROUP_restore_coordinates(orig_coordinate); 2, Yocto Zeus integrates openssl 1.1.1g, so I change library name of gmssl from libcrypto to libgmcrypto and from libssl to libgmssl to avoid name confliction with openssl 1.1.1g (lib name are also libcrypto.so.1.1 and libssl.so.1.1). You should use -lgmcrypto and -lgmssl when you link gmssl library instead of -lcrypto and -lssl. +++++++++++++++++++++++ updating at 2021-02-08 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.70_2.3.0. The package meta-gmcrypto is Yocto layer which also support c-v2x feature in previous release. You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-5.4.70-2.3.0. +++++++++++++++++++++++ updating for Linux-5.10.52-2.1.0 +++++++++++++++++++++++ This updating is for Yocto release of Linux 5.10.52_2.1.0. The package meta-gmcrypto is Yocto layer which also support c-v2x feature in previous release. 1, You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-5.10.52-2.1.0. Copy meta-gmcrypto to folder (Yocto 5.10.52_2.1.0 dir)/sources/. 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-gmcrypto " into (Yocto 5.10.52_2.1.0 dir)/build-imx8mmevk/conf/bblayers.conf and IMAGE_INSTALL_append += " gmssl-bin " into local.conf 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev gmssl speed sm2 gmssl genrsa -rand -f4 -engine cryptodev 512 gmssl speed dsa gmssl genrsa -rand -f4 -engine cryptodev 1024 gmssl speed rsa gmssl genrsa -rand -f4 -engine cryptodev 2048 gmssl speed ecdsa gmssl genrsa -rand -f4 -engine cryptodev 3072 gmssl speed ecdh gmssl genrsa -rand -f4 -engine cryptodev 4096 gmssl speed -evp sha256 -engine cryptodev -elapsed gmssl speed -evp aes-128-cbc -engine cryptodev -elapsed gmssl speed -evp aes-128-ecb -engine cryptodev -elapsed gmssl speed -evp aes-128-cfb -engine cryptodev -elapsed gmssl speed -evp aes-128-ofb -engine cryptodev -elapsed gmssl speed -evp des-ede3 -engine cryptodev -elapsed gmssl speed -evp des-cbc -engine cryptodev -elapsed gmssl speed -evp des-ede3-cfb -engine cryptodev -elapsed +++++++++++++++++++++++ updating for Linux-5.15.71-2.2.0 +++++++++++++++++++++++ This updating is for Yocto release of Linux 5.15.71-2.2.0. The package meta-gmcrypto is Yocto layer which also support c-v2x feature in previous release. 1, You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-5.15.71-2.2.0. Copy meta-gmcrypto to folder (Yocto 5.15.71-2.2.0 dir)/sources/. 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-gmcrypto " into (Yocto 5.15.71-2.2.0 dir)/build-imx8mmevk/conf/bblayers.conf and IMAGE_INSTALL:append = " gmssl-bin " into local.conf 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev gmssl speed sm2 gmssl genrsa -rand -f4 -engine cryptodev 512 gmssl speed dsa gmssl genrsa -rand -f4 -engine cryptodev 1024 gmssl speed rsa gmssl genrsa -rand -f4 -engine cryptodev 2048 gmssl speed ecdsa gmssl genrsa -rand -f4 -engine cryptodev 3072 gmssl speed ecdh gmssl genrsa -rand -f4 -engine cryptodev 4096 gmssl speed -evp sha256 -engine cryptodev -elapsed gmssl speed -evp aes-128-cbc -engine cryptodev -elapsed gmssl speed -evp aes-128-ecb -engine cryptodev -elapsed gmssl speed -evp aes-128-cfb -engine cryptodev -elapsed gmssl speed -evp aes-128-ofb -engine cryptodev -elapsed gmssl speed -evp des-ede3 -engine cryptodev -elapsed gmssl speed -evp des-cbc -engine cryptodev -elapsed gmssl speed -evp des-ede3-cfb -engine cryptodev -elapsed +++++++++++++++++++++++ Updating for Linux-6.1.55-2.2.0 +++++++++++++++++++++++ This updating is new GmSSL 3.1.1 and Yocto release of Linux 6.1.55-2.2.0. 主要特性超轻量：GmSSL 3 大幅度降低了内存需求和二进制代码体积，不依赖动态内存，可以用于无操作系统的低功耗嵌入式环境(MCU、SOC等)，开发者也可以更容易地将国密算法和SSL协议嵌入到现有的项目中。更合规：GmSSL 3 可以配置为仅包含国密算法和国密协议(TLCP协议)，依赖GmSSL 的密码应用更容易满足密码产品型号检测的要求，避免由于混杂非国密算法、不安全算法等导致的安全问题和合规问题。更安全：TLS 1.3在安全性和通信延迟上相对之前的TLS协议有巨大的提升，GmSSL 3 支持TLS 1.3协议和RFC 8998的国密套件。GmSSL 3 默认支持密钥的加密保护，提升了密码算法的抗侧信道攻击能力。跨平台：GmSSL 3 更容易跨平台，构建系统不再依赖Perl，默认的CMake构建系统可以容易地和Visual Studio、Android NDK等默认编译工具配合使用，开发者也可以手工编写Makefile在特殊环境中编译、剪裁。 More information, please refer to Readme Recipe file is the attached gmssl_3.1.1.bb.tar.gz

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

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 following document contains a list of document, questions and discussions that are relevant in the community based on amount of views. If you are having a problem, doubt or getting started in i.MX processors, you should check the following links to see if your doubt is in there. Yocto Project Freescale Yocto Project main page‌ Yocto Training - HOME‌ i.MX Yocto Project: Frequently Asked Questions‌ Useful bitbake commands‌ Yocto Project Package Management - smart How to add a new layer and a new recipe in Yocto Setting up the Eclipse IDE for Yocto Application Development Guide to the .sdcard format Yocto NFS & TFTP boot YOCTO project clean Yocto with a package manager (ex: apt-get) Yocto Setting the Default Ethernet address and disable DHCP on boot. i.MX x Building QT for i.MX6 i.MX6/7 DDR Stress Test Tool V3.00 i.MX6DQSDL DDR3 Script Aid Installing Ubuntu Rootfs on NXP i.MX6 boards iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP i.MX Design&Tool Lists Simple GPIO Example - quandry i.MX6 GStreamer-imx Plugins - Tutorial & Example Pipelines Streaming USB Webcam over Network Step-by-step: How to setup TI Wilink (WL18xx) with iMX6 Linux 3.10.53 Linux / Kernel Copying Files Between Windows and Linux using PuTTY Building Linux Kernel Patch to support uboot logo keep from uboot to kernel for NXP Linux and Android BSP (HDMI, LCD and LVDS) load kernel from SD card in U-boot Changing the Kernel configuration for i.MX6 SABRE Android The Android Booting process What is inside the init.rc and what is it used for. Others How to use qtmultimedia(QML) with Gstreamer 1.0

Overview As more and more communication required between online and offline, the QR code is widely used in the mobile payment, mobile small apps, industry things identification and etc. The i.MX6UL/ULL has the IP of CSI and PXP for camera connection and image CSC/FLIP/ROTATION acceleration. A LCDIF IP is supporting the display, but no 3D IP support. This means this low power and low end AP is very suitable for the industry HMI segment, which does not require a cool 3D graphic display, but a simple and straightforward GUI for interaction. QR code scanner is one of the use cases in the industry segment, which more and more customer are focusing on. The i.MX6UL CPU freq of i.MX6UL is about 500Mhz, and it does not have GPU IP, so a lightweight GUI and window system is required. Here we recommend the QT with wayland backend (without X11), which would make the window system small and faster than traditional X11 UI. Why chose QT is because of it has open source version, rich components, platform independent, good performance for embedded system and strong development staffs like QtCreator for creating application. How to enable the QT development environment, check this: Enable QT developement for i.MX6UL (v2) Here I made a QR code scanner demo based on QT5.6 + QZXing (QR/Bar code scan engine) running on the i.MX6UL EVK board with a UVC camera (at least 640x480 resolution is required) and 480x272px LCD. Source code is open here (License Apache2.0): https://github.com/muddog/QRScanner Implementation To do camera preview and capture, you must think on the gstreamer first, which is easy use and has the acceleration pads which implemented by NXP for i.MX6UL. Yes, it's very easy for you to enable the preview in console like: $ gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw,format=YUY2,width=640,height=320 ! imxvideoconvert_pxp ! video/x-raw,format=RGB16 ! waylandsink It works under the i.MX6UL EVK, with PXP IP to do color space convert from YUY2 -> RGB16 acceleration, also the potential scaling of the image. The CPU loading of this is about 20-30%, but if you use the component of "videoconvert" to replace the "imxvideoconvert_pxp", we do CSC and scale by CPU, then the loading would increase to 50-60%. The "/dev/video1" is the device node for UVC camera, it may different in your environment. So our target is clear, create such pipeline (with PXP acceleration) in the QT application, and use a appsink to get preview images, do simple "sink" to one QWidget by drawing this image on the widget surface for preview (say every 50ms for 20fps). Then in other thread, we fetch the preview buffer in a fixed frequency (like every 0.5s), then feed it into the ZXing engine to decode the strings inside this image. Here are the class created inside the source code: ScannerQWidgetSink It act as a gstreamer sink for preview rendering. Init the pipeline, create a timer with timeout every 50ms. In the timer handler, we use appsink to copy the camera buffer from gstreamer, and tell the ViewfinderWidget to do update (re-draw event). ViewfinderWidget This class inherit from the QWidget, which draw the preview buffer as a QImage onto it's own surface by using QPainter. The QImage is created at the very begining with the image buffer created by the ScannerQWidgetSink. Because QImage itself does not maintain the image buffer, so the buffer must be alive during it's usage. So we keep this buffer during the ScannerQWidgetSink life cycle, copy the appsink buffer from pipeline to it for preview. MainWindow Create main window, which does not have title bar and border. Start any animation for the red line scan bar. Create instance of DecoderThread and ScannerQWidgetSink. Setup and start them. DecoderThread A infinite loop, to wait for a available buffer released by the ScannerQWidgetSink every 0.5s. Copy the buffer data to it's own buffer (imgData) to avoid any change to the buffer by sink when doing decoding. Then feed this copy of buffer into ZXing engine to get decoder result. Then show on the QLabel. Screenshot under wayland (weston) desktop: Customize Camera instance Now I use the UVC camera which pluged in the USB host, which device node is /dev/video1. If you want to use CSI or other device, please change the construction parameters for ScannerQWidgetSink(): sink = new ScannerQWidgetSink(ui->widget, QString("v4l2src device=/dev/video1")); Image resolution captured and review Change the static member value of ScannerQWidgetSink class: uint ScannerQWidgetSink::CAPTURE_HEIGHT = 480; uint ScannerQWidgetSink::CAPTURE_WIDTH = 640; Preview fps and decoding frequency Find the "framerate=20/1" strings in the ScannerQWidgetSink::GstPipelineInit(), change to your fps. You also have to change the renderTimer start timeout value in the ::StartRender(). The decoding frequency is determined by renderCnt, which determine after how many preview frames showed to feed the decoder. Main window size It's fixed size of main window, you have to change the mainwindow.ui. It's easy to do in the QtCreate Designer. FAQ Why not use CSI camera in demo? Honestly, I do not have CSI camera module, it's also DNP when you buying the board on NXP.com. So a widely used UVC camera is preferred, it's also easy for you to scan QR code on your phone, your display panel etc. Why not use QCamera to do preview and capture? The QCamera class in the Qtmultimedia component uses the camerabin2 gstreamer plugin, which create a very long pipeline for different usage of viewfinder, image capture and video encoder. Camerabin2 would eat too much CPU and memory resource, take picture and recording are very very slow. The preview of 30fps would eat about 70-80% CPU loading even I hacked it using imxvideoconvert_pxp instread of software videoconvert. Finally I give up to implement the QRScanner based on QCamera. How to make sure only one instance of QT app is running? We can use QSharedMemory to create a share memory with a unique KEY. When second instance of app is started, it would check if the share memory with this KEY is created or not. If the shm is there, it means there's already one instance running, it has to exit(). But as the QT mentioned, the QSharedMemory can not be destroyed correctly when app crashed, this means we have to handle each terminate signal, and do delete by ourselves: static QSharedMemory *gShm = NULL; static void terminate(int signum) { if (gShm) { delete gShm; gShm = NULL; } qDebug() << "Terminate with signal:" << signum; exit(128 + signum); } int main(int argc, char *argv[]) { QApplication a(argc, argv); // Handle any further termination signals to ensure the // QSharedMemory block is deleted even if the process crashes signal(SIGHUP, terminate ); // 1 signal(SIGINT, terminate ); // 2 signal(SIGQUIT, terminate ); // 3 signal(SIGILL, terminate ); // 4 signal(SIGABRT, terminate ); // 6 signal(SIGFPE, terminate ); // 8 signal(SIGBUS, terminate ); // 10 signal(SIGSEGV, terminate ); // 11 signal(SIGSYS, terminate ); // 12 signal(SIGPIPE, terminate ); // 13 signal(SIGALRM, terminate ); // 14 signal(SIGTERM, terminate ); // 15 signal(SIGXCPU, terminate ); // 24 signal(SIGXFSZ, terminate ); // 25 gShm = new QSharedMemory("QRScannerNXP"); if (!gShm->create(4, QSharedMemory::ReadWrite)) { delete gShm; qDebug() << "Only allow one instance of QRScanner"; exit(0); } .....

1.- Set SW602 Boot mode pin settings to Serial Downloader mode 2.-Connect JTAG debug probe and turn on the board 3.-Run script to bring-up DRAM In Lauterbach this script is called 'mcimx6ul_sieve_dram.cmm' under the mcimx6ul folder, the scripts can be found here and are also attached (download the imx6ultralite package). If you are not using Lauterbach please ask your probe vendor for a similar script. NOTE: this u-boot image has been built to run off DRAM if your bootloader runs from OCRAM you might not need a script. While running the script you might be prompted with and error telling you there is a syntax error in the script system.cpu IMX6ULL simply edit the script and change the CPU name to IMX6ULTRALITE 4.- Load u-boot.srec to DRAM and start executing it The srec is being used in this case because it contains the addresses where the binary needs to be loaded and the entry point for the application is automatically recognised and set by Lauterbach. To load it simply issue 'data.load.S3record u-boot.srec' and then click on go to let it run. You should now be able to see the output from u-boot on the console hit any key on the console to stop the boot process. 5.- Load QuadSPI configuration to DRAM and flash it to the memory The Boot ROM on the i.MX6UL requires the configuration data for the QuadSPI memory to be stored at address 0x400 of the QuadSPI memory, the length of this configuration data is 512 bytes. Attached is a configuration binary that can be used for the NOR flash memory used in the i.MX6UL EVK. For more details on the configuration parameters please refer to chapter '8.6.3 QuadSPI Configuration Parameters' of the i.MX6UL Reference Manual. Stop the execution on T32 (Lauterbach's environment) and load the configuration to DRAM by issuing 'data.load.binary QSPI_cfg2.bin 0x90000000' and resume execution. On u-boot execute the 'sf probe' command (sf stands for Serial Flash) to detect the memory. You should see an output like the following: => sf probe SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB Now issue the sf erase command to erase the first sector (remember our erase size is of 4KiB): => sf erase 0x0 0x1000 SF: 4096 bytes @ 0x0 Erased: OK Now we are ready to write our configuration to address 0x400 => sf write 0x90000000 0x400 0x200 SF: 512 bytes @ 0x400 Written: OK 6.- Load u-boot.imx to DRAM and download it to memory. We will follow the same procedure to download the u-boot image to the memory. Stop execution on Lauterbach and load u-boot.imx to DRAM using 'data.load.binary u-boot_SPI.imx 0x90000000' and resume execution (u-boot.imx contains the IVT header which basically stores all the information the device needs to boot u-boot.bin and u-boot.imx). The boot ROM expects to find the IVT header at address 0x1000 of the SPI NOR Flash memory. We will load u-boot.imx to this address by issuing 'sf update 0x90000000 0x1000 0x57830'(the size of u-boot.imx is 358448 bytes) this will erase and write the memory. => sf update 0x90000000 0x1000 0x57830 358448 bytes written, 0 bytes skipped in 23.741s, speed 15458 B/s If you want to verify that the image was flashed correctly you can read from QuadSPI to DRAM by issuing 'sf read 0x90000000 0x1000 0x57830 ' and verify the data. 7.- Now we can end our debug session and turn off our board Set SW602 to Internal boot mode (ON/OFF) and SW601 to select boot from QuadSPI (all OFF) Turn on the board again and you should be able to see u-boot's output on your terminal. This procedure can be used with other boards/i.MX6 derivatives, I am just posting the setup in which I tested it.

Most common issues with bringup and memory stability come down to memory/system setup during startup phase of i.MX device. This Python script allows you to dump IVT/DCD tables and data from a i.MX binary (either generated as result of build process or a simple dump of SD/NOR/NAND... content) and analyze them in an easier way. Should work with i.MX 6 and i.MX53 binaries. Parser for i.MX 6 will also try to print out register values it recognizes, and also parse specific register fields, helping to analyze the data faster. This can be extended if needed to other registers/values. imxbin.py works with Python3.x and imxbin_2x.py with Python 2.x, so choose appropriate version. Vladan

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)

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

i.MX 6/7 DDR Stress Test Tool

i.MX Design&Tool Lists

Patch to support MPU 8080 LCD on iMX6UL and iMX7D

i.MX 6/7 Series DDR Tool Release

Bring up i.MX6 via JTAG

Enhance cryptodev and its engine in OpenSSL by CAAM's public key cryptography operations

repo issue "def print(self, *args, **kwargs):"

I.MX6UL DDR3 Script Aid

Boot I.MX6q SABRE over the Network using TFTP and NFS

How-To use UART7/8 on i.MX6UL

Patch to support Ethernet PHY KSZ8081 (Rev1) on i.MX6UL/i.MX6ULL EVK board

Linux L4.14.98_2.0.0_GA; SDK2.5.2_8QXP/8QM_PostGA, SDK2.5.1_7ULP_GA3 Release Announcement

移植国密密码工具箱GmSSL到i.MX平台Enable GmSSL which supports OSCCA Algorithm Toolbox on i.MX

Getting Android5.1.1 Source Code (For China only)

Linux L4.9.88_2.0.0 Rocko, i.MX7ULP1 Linux/SDK2.4 RFP(GA) Release Announcement

Useful documents and threads of i.MX Processors

QRScanner QT demo running on i.MX6UL

Flashing QuadSPI (NOR Flash) via JTAG with u-boot on i.MX6UL

Tool to dump and analyze IVT/DCD data in i.MX binaries

移植实时Linux方案Xenomai到i.MX ARMv7平台 (Enable real-time Linux Xenomai on i.MX ARMv7 Platform)