i.MX Processors Knowledge Base

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

i.MX Processors Knowledge Base

Discussions

Sort by:
Here are two patches to support BT656 and BT1120 output for i.MX6 ipuv3. With this patch, the i.MX6 can support the CVBS output on TV encoder. It is useful for a TV box. "L3.0.35_1.1.0_GA_bt656_output_patch.zip" is the patch for Freescale L3.0.35_1.1.0_GA_iMX6DQ BSP. "r13.4.1_bt656_output_patch.zip" is the patch for Freescale Android R13.4.1 BSP. 1. Features supported:     1) Support BT656(8 bits) and BT1120 (16 bits)interlaced output on display port.     2) Support both RGB and YUV frame buffer for BT656/BT1120 output.     3) Support PAL and NTSC mode.     4) Support on the fly switch between PAL and NTSC mode.     5) Support CVBS output based on adv7391 TV encoder. 2. Hardware link between iMX6 and adv7391 TV encoder chip.     IPU1_DI0_DISP_CLK connected to adv7391 CLKIN pin.     IPU1_DISP0_DAT_23~DISP0_DAT_16 connected to adv7391 P7~P0 pins.     IPU1_DI0_PIN2 connected to adv7391 HSYNC pin. (option)     IPU1_DI0_PIN4 connected to adv7391 VSYNC pin. (option)   - Android R13.4.1 kernel. 3. How to use -- Copy the two patch files to kernel folder.     $ git apply ./0001-Support-BT656-and-BT1120-output-for-iMX6-ipuv3.patch     $ git apply ./0002-Support-adv739x-TV-encoder-for-BT656-output.patch -- Select them in kernel config and build the new kernel image:                     Device Drivers  --->                       Graphics support  --->                           [*]   MXC BT656 and BT1120 output                           [*]   ADV7390/7391 TV Output Encoder -- Uboot parameters for video mode    Output BT656 NTSC data to display port with UVYV frame buffer mode:       "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=UYVY16"    Output BT656 NTSC data to display port with RGB565 frame buffer mode:       "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB565"    Output BT656 PAL data to display port with RGB24 frame buffer mode:       "video=mxcfb0:dev=bt656,BT656-PAL,if=BT656,fbpix=RGB24"    Output CVBS NTSC signal on adv7391 with UYVY frame buffer mode:       "video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16"    Output CVBS PAL signal on adv7391 with RGB565 frame buffer mode:       "video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565" -- Switch between PAL and NTSC    $ echo D:720x480i-60 > /sys/class/graphics/fb0/mode    $ echo D:720x576i-50 > /sys/class/graphics/fb0/mode 4. Note     1) For 8 bits BT656 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_16", it can also        be any other continued display data pins, for example if "DISP0_DAT_7~DISP0_DAT_0" are used, the        macro "BT656_IF_DI_MSB" in "kernel_imx/drivers/mxc/ipu3/ipu_disp.c" should be changed from "23"        to "7".     2) For 16 bits BT1120 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_8", it can also        be any other continued display data pins, the macro "BT656_IF_DI_MSB" should be modified if the        hardware pins are changed.     3) When bt656 interface is the second display for each IPU,1-layer-fb (it can be checked with command        "$ cat /sys/class/graphics/fbx/fsl_disp_propperty"), the frame buffer can only be YUV format. In this        case, the IPU DC channel was used for BT656 display, it has no CSC function, so RGB frame buffer was        not supported. 2013-08-09 updated: The new release package "L3.0.35_1.1.0_GA_bt656_output_patch_2013-08-09.zip" had fixed the BT656 dual display issue on iMX6S/DL. Removed the old release package. 2013-09-04 updated: The new release package "r13.4.1_bt656_output_patch_2013-09-04.zip" had fixed the BT656 dual display issue on iMX6S/DL. For default, the dual display was tested with HDMI + CVBS, HDMI is the main display and adv739x CVBS output is the second display. For iMX6DQ which has two IPUs, please assign dual display to two IPUs, for example adv739x is on IPU1 DI0, it is fixed, because hardware pins used for it is fixed. Then we can assign HDMI or LVDS to another IPU (IPU2). For iMX6S/DL which has only one IPU, since adv739x had used IPU1 DI0, another display should be IPU1 DI1. 2013-09-30 updated: Added patch for L3.0.35_4.1.0_GA BSP, the file is "L3.0.35_4.1.0_GA_bt656_output_patch_2013-09-30.zip". 2014-07-21 updated: Added patch for L3.10.17_1.0.0_GA BSP, the file is "L3.10.17_1.0.0_GA_bt656_output_patch_2014-07-21.zip". 2015-01-26 updated: Updated the IPU microcode for 1080i50 and 1080i60 BT1120 output, the parameters "N" for command BMA is a 8 bits parameters, so its max value is 255, but for 1080i50 and 1080i60 output, it needs more blank data in each line, the "N" will be bigger than 255, the updated IPU microcode can fix this limitation. The updated file is "IPU_Microcode_Update_for_BT1120_1080i_20150126.zip". You can update the macro "DC_MCODE_BT656_xxx"  and function _ipu_dc_setup_bt656_interlaced() to the old patch if you used BT1120 mode to support 1080i display. The verified 1080i display mode is: {    /* 1080I60 Interlaced output */   "BT1120-1080I60", 30, 1920, 1080, 13468,   20, 3,   20, 2,   280, 1,   FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,   FB_VMODE_INTERLACED,   FB_MODE_IS_DETAILED,}, {   /* 1080I50 Interlaced output */   "BT1120-1080I50", 25, 1920, 1080, 13468,   20, 3,   20, 2,   720, 1,   FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,   FB_VMODE_INTERLACED,   FB_MODE_IS_DETAILED,}, 2016-01-28 updated: Updated IPU microcode to align with BT656.4 specification for NTSC output. For other BSP version with NTSC format support, please reference to ipu_disp_update.c for the final microcode. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160128.zip"., Details, please reference to the readme.txt file in the package. 2016-06-24 update: Added BT656 and BT1120 progressive mode support. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160624.zip". Details, please reference to the readme.txt file in the package. The patch for 3.14.52 GA1.1.0 BSP will be released in next week. 2016-06-27 update: Add BT656 and BT1120 display patch for 3.14.52 BSP. File "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27.zip", details, please reference to the readme.txt in the package. 2017-03-10 update: Fixed a hard coding DC macro issue for progressive mode. Added patch "0008-Fixed-a-hard-coding-DC-macro-issue-for-progressive-m.patch" in L3.0.35_4.1.0_GA_bt656_output_patch_2017-03-10.zip. The code in patch "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27" is correct.
View full article
This patch made the display no interrupt from uboot to kernel to Android. The IPU and related hardware display interface will only be initialized once in Uboot, the kernel code will skip the IPU initialization.   1. Description     1) Support HDMI, LVDS and LCD output in UBoot.     2) Support UBoot logo keep from uboot to kernel to Android.     3) For HDMI, both 720P and 1080P mode were supported.     4) For LVDS, 1024x768 and 1080P dual channel panels were supported.     5) The logo file is a 32 bpp bmp file. 2. File List -- kernel_imx\0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch -- kernel_imx\0002-Bug-fix-for-uboot-logo-keep-patch.patch    Kernel patch to support the logo keep feature. -- uboot-imx\0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch    Uboot patch to support the logo display. -- logo.bmp    Example 32bpp logo file. -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - Android JB4.2.2_1.1.0-GA UBoot and kernel. 4. How to use -- Copy the two patch files to Android kernel_imx and uboot-imx folder and apply them.     $ cd ~/myandroid/kernel_imx/     $ git apply ./0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch     $ cd ~/myandroid/bootable/bootloader/uboot-imx/     $ git apply ./0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch     $ git apply ./0002-Bug-fix-for-uboot-logo-keep-patch.patch   -- Build the new uboot image:     $ cd ~/myandroid/bootable/bootloader/uboot-imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make mx6q_sabresd_android_config     $ make   -- Before build new UBoot image, the display type can be selected from file uboot-imx\include\configs\mx6q_sabresd.h // Select one of the output mode #define IPU_OUTPUT_MODE_HDMI //#define IPU_OUTPUT_MODE_LVDS //#define IPU_OUTPUT_MODE_LCD   -- Build the new kernel image:     $ cd ~/myandroid/kernel_imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make imx6_android_defconfig     $ make uImage   -- Before "make uImage", make menuconfig can be used to select the display type.                 System Type  --->                    Freescale MXC Implementations  --->                       MX6 clk setting for smooth UI transtion from bootloader to kernel  --->                           Select Display Interface                              ( )  Smooth UI transtion on LCD, IPU1, DI0                              ( )  Smooth UI transtion on LVDS, IPU1, DI1                              (X)  Smooth UI transtion on HDMI, IPU2, DI0   -- Uboot parameters for video mode    1080P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=148500000"      720P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=74250000"      1024x768 LVDS:       "video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666,bpp=32 fb0base=0x27b00000 fbmem=28M"      800x480 LCD:       "video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB565,bpp=32 fb0base=0x27b00000 fbmem=28M" -- dd the logo.bmp to SD card address 0x100000 and skip the 54 bytes bmp file header.    sudo dd if=logo.bmp of=/dev/sdc bs=1 seek=1048576 skip=54 5. Note     1) The logo.bmp file should be 32bpp or 16bpp, and it should be synced with video mode parameters "bpp=xx",          and uboot config file mx6q_sabresd.h (#define DISPLAY_BPP  xx).       2) The IPU number and DI number are hard coded in kernel file "board-mx6q_sabresd.c". static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {   .ipu_id = 1,   .disp_id = 0, }; static struct fsl_mxc_lcd_platform_data lcdif_data = {   .ipu_id = 0,   .disp_id = 0,   .default_ifmt = IPU_PIX_FMT_RGB565, }; static struct fsl_mxc_ldb_platform_data ldb_data = {   .ipu_id = 0,   .disp_id = 1,   .ext_ref = 1,   .mode = LDB_SEP1,   .sec_ipu_id = 0,   .sec_disp_id = 0, };       3) The IPU number and DI number are defined by Macro in Uboot file "include\configs\mx6q_sabresd.h" #define IPU_NUM   2  // 1 for IPU1, 2 for IPU2. #define DI_NUM   0  // 0 for DI0, 1 for DI1.       4) The display type used in uboot and kernel must be same, same type, same IPU number, same DI port and        same resolution.     [2015-06-29 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-06-29.zip Fix some LVDS issues for iMX6DL. Also given an example for LVDS0 with DI0. New Uboot patches:      0002-Updated-lvds-clock-source-to-pll2_pfd0.-Same-as-kern.patch      0003-Add-support-for-iMX6DL.patch   New kernel patches      0003-Skip-lvds-re-initialization-for-logo-keep.patch      0004-Add-examlpe-for-LVDS0-logo-keep.patch     [2015-08-07 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-08-07.zip Added the new Uboot patch 0004-Correct-the-sequence-to-set-LDB-clock.patch It can correct the LVDS clock set sequence whch is a known issue that caused no LVDS display sometimes.   [2015-09-18 Update]: JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip Added the patch for Android JB4.3_GA1.1.1 release. Updated clock usecount, after blank the display, the related clock can be gated off correctly. Support LVDS clock from PLL5.   [2015-12-21 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2015-12-21.zip. Verified on iMX6DL/Q SabreSD board. It supports LCD and LVDS panels, HDMI patch will be released later.   [2016-01-04 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2016-01-04.zip. Added HDMI display support. Now it supports LCD, LVDS and HDMI displays. Fixed the video playback issue for boot up.   [2016-05-18 Update]: 0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch An issue was founded, when dual channel 4 lanes LVDS panel was used, in uboot there will be no LVDS TX3 signa on one LVDS port, the attach "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip, for other BSP, please port it manually.   [2016-08-29 Update]: 0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch On some iMX6 chip, after reset the IPU in SRC Control Register, enable IPU at once will cause system hang up, to avoid such issue, software needs wait for IPU reset done by polling the SRC register. The attach "0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip + "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch", for other BSP, please port it manually.   [2017-01-06 Update] Added patch for L4.1.15_GA1.2.0 BSP and Android M6.0.1_GA2.1.0 BSP. Files: L4.1.15_GA1.2.0_uboot_logo_keep_patch_2017-01-06.zip; M6.0.1_2.1.0_uboot_logo_keep_patch_2017-01-06.zip
View full article
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 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 
View full article
This is a HW design checklist for customer's reference. Please read and fill it in carefully before requesting a schematic review. Rev3.1 @2016.10.19 -- 1. Add i.MX6DQP related contents.
View full article
This is the prototype demo to enable surround view demo on SabreSD.   The attached Files are HW&SW guides and demo video. Updating Notes: Add miniPCIE Surround View_Rev A design file (include schematic and layout) as attachement. Add Gerber file   i.MX6Q Surround view patch https://community.freescale.com/docs/DOC-95143 Original Attachment has been moved to: Gerber-file.zip Original Attachment has been moved to: miniPCIe-Surround-View_Rev-A.zip
View full article
It is based on L3.0.35_GA4.1.0 BSP.   In default Linux BSP, there are 3 kinds of de-interlace mode, motion =0,1,2 mode, motion mode 0 and 1 will use three fields for de-interlace, and motion mode 2 wil use one field for de-interlace, so the whole fps is 30. In this mode, for motion mode 0 and 1, field 1,2,3 was used for first VDI output frame of display; and field 3,4,5 was used for second VDI output frame of display; field 5,6,7 was used for third VDI output frame of display. One field data (such as 2,4,6) was used only once, so there is data lost.   After applied these patches, the VDI de-interlace output will be 60fps: for motion mode 0 and 1, field 0,1,2 was used for first VDI output frame of display; and field 1,2,3 was used for second VDI output frame of display; field 2,3,4 was used for third VDI output frame of display. So all field data will be used twice, there is no video data lost, the VDI quality was improved.   Kernel patches: 0001-Add-MEM-to-VDI-to-MEM-support-for-IPU.patch 0002-Add-IPU-IC-memcpy-support.patch 0003-IPU-VDI-support-switch-odd-and-even-field-in-motion-.patch 0004-IPU-VDI-correct-vdi-top-field-setting.patch   mxc_v4l2_tvin_imx6_vdi_60fps.zip: this is the test application sample code.   Test commands, parameter "-vd" means double fps VDI: ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 720 -oh 480 -m 0 -vd  
View full article
The document will introduce all steps for poring WM8960 audio codec to freescale android4.2.2 BSP. Attachments include : (1)Document for porting (2)Codec driver : wm8960.c (3)Machine driver: imx-wm8960.c (4)wm8960 schematic for reference (5)Android Audio HAL: config_wm8960.h (6)schematic: MX6QDL-PIANO-CNFV1.DSN (7)i.MX6DL BSP files mx6dl_piano.c mx6dl_piano.h mx6dl_piano_pmic_pfuse100.c (8)i.MX6Q BSP files mx6q_piano.c mx6q_piano.h mx6q_piano_pmic_pfuse100.c   Freescale TICS Team Weidong.sun
View full article
1. Description     1) Support HDMI interlaced display mode, the followed format had been verified.         CEA format 5: 1920x1080i @60Hz         CEA format 6&7: 720(1440)x480i @60Hz         CEA format 20: 1920x1080i @50Hz         CEA format 21&22: 720(1440)x576i @50Hz     2) Support LCD interface for interlaced display mode, 1920x1080i @50Hz(CEA format 20)        had been verified. 2. File List -- 0001-IPUv3-support-interlaced-display-mode.patch    Patch to support interlaced display output for iMX6 ipuv3. -- 0002-iMX6-HDMI-support-interlaced-display-mode.patch    Patch to support interlaced display mode for iMX6 HDMI driver. -- 0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch    Patch to support interlaced display mode for iMX6 LCD interface driver.    -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - L3.0.35_4.1.0_GA_iMX6DQ kernel. 4. How to use -- Copy the patch files to kernel folder.     $ cd ~/ltib/rpm/BUILD/linux-3.0.35/     $ git apply ./0001-IPUv3-support-interlaced-display-mode.patch     $ git apply ./0002-iMX6-HDMI-support-interlaced-display-mode.patch     $ git apply ./0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch -- Build the new kernel image:     $ cd ~/ltib/rpm/BUILD/linux-3.0.35     $ export CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi-     $ export ARCH=arm     $ make imx6_defconfig     $ make uImage -- Uboot parameters for video mode    Output 1080i50 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1920x1080Mi@25,if=RGB24,bpp=32"    Output 1080i60 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1920x1080Mi@30,if=RGB24,bpp=32"    Output 576i50 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1440x576Mi@25,if=RGB24,bpp=32"    Output 480i60 display mode on HDMI:       "video=mxcfb0:dev=hdmi,1440x480Mi@30,if=RGB24,bpp=32"    Output 1080i50 display mode on LCD interface:       "video=mxcfb0:dev=lcd,LCD-1080I50,if=RGB565,bpp=32"       -- Switch HDMI interlaced mode    $ echo S:1920x1080i-50 > /sys/class/graphics/fb0/mode    $ echo S:1920x1080i-60 > /sys/class/graphics/fb0/mode    $ echo S:1440x480i-50 > /sys/class/graphics/fb0/mode    $ echo S:1440x576i-60 > /sys/class/graphics/fb0/mode 5. Know issue     1) When the interlaced display and another display work on same IPU,        blank and unblank the interlaced display will get the followed IPU        warning, but the display still works due to IPU can revover from the error.     imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_5 = 0x00800000     imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00080000 2015-05-13 update: Replace the fourth patch to make interlace display mode follow CEA-861-specification The patch "0004-IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch" was fine tuned for CEA-861-D specification on interlaced mode display. Please use this patch to replace the old 0004 patch. 2016-05-20 Update: For 3.0.35 BSP, add patch 0005-IPU-update-interlaced-video-mode-parameters-to-align.patch      Align the interlaced video mode parameters to progressive mode. 0006-IPU-update-IDMAC-setting-for-interlaced-display-mode.patch      Udate the IDMAC setting for interlaced display mode, output odd field data from memory first, it aligns with IPU DI timing, odd field first. For 3.14.52 BSP, created the new patch L3.14.52_1.1.0_GA_HDMI_Interlaced_Mode_Patch_2016_05_20.zip.
View full article
The patches are based on iMX6 L3.10.53 and 3.14.52 GA BSP.   In default linux BSP, the followed two pathes were supported in kernel driver mxc_v4l2_capture.c: CSI->IC->MEM CSI->MEM   After appied these patches, it can support the followed path: CSI->VDI->IC->MEM CSI->VDI->MEM In this mode, the VDI de-interlace will be handled on the fly, so the whole system bandwidth will be reduced.   Limitations: 1. Since the IC can only output resolution up to 1024*1024, so this is the limation on output. 2. Only VDI motion mode 2 was supported.   mxc_v4l2_tvin.zip: It is the test aplication, test command for CSI->VDI->IC->MEM ("-i 2" means CSI->VDI->IC->MEM path.): ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 2 -g2d"   test command for CSI->VDI->MEM ("-i 3" means CSI->VDI->MEM path.): ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 3 -g2d"  
View full article
Here is a quick summary at building a bootloader, a kernel and a root filesystem for the i.MX 6 sabre sd platform, using buildroot. This assumes you have a "working" Linux development environment at hand (e.g. Debian). Buildroot is a fine build system, which makes deploying Linux on embedded platforms really easy. It is comparable to Yocto in spirit, but much simpler. Thanks to my colleague gillestalis, buildroot now has builtin support for the i.MX6 sabre sd platform. Get buildroot sources We will use git to fetch buildroot sources: $ git clone git://git.busybox.net/buildroot This should create a buildroot directory with all the latest sources (after a while). Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l '201*', and git checkout <the-desired-tag>. Compile The beauty of buildroot is that it will take care of everything for you, including preparing a cross compiler. You can download and build everything by doing: $ cd buildroot $ make freescale_imx6sabresd_defconfig $ make This should download and build everything, so it will take a while. buildroot detects the number of CPUs you have in your machine and builds with parallel jobs automatically; no need to specify any -j argument to make here. All build results fall under the output/images folder: output/images/ +- rootfs.ext2 +- rootfs.tar +- u-boot.bin `- uImage Format the SD card As for Debian, we need to format the SD card with two partitions; one small FAT partition to contain the Linux kernel, and one large ext4 partition, which will contain the root filesystem with the buildroot generated userspace. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout: +-----+------+--------+-----+---------------+----------------- | MBR |  ... | u-boot | ... | FAT partition | Linux partition ... +-----+------+--------+-----+---------------+----------------- 0     512    1024           1M              ~257M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk: Device    Boot      Start         End      Blocks   Id  System /dev/sdc1            2048      526335      262144    c  W95 FAT32 (LBA) /dev/sdc2          526336     8054783     3764224   83  Linux (units: 512B sectors) You can format the FAT boot partition with: # mkfs.vfat /dev/<your-sd-card-first-partition> Your SD card first partition is typically something in /dev/sd<X>1 or/dev/mmcblk<X>p1. You can format the Linux partition with: # mkfs.ext4 /dev/<your-sd-card-second-partition> Your SD card second partition is typically something in /dev/sd<X>2 or/dev/mmcblk<X>p2. Put on SD As explained here, u-boot should reside at offset 1024B of your SD card. Also, as buildroot generates an u-boot.bin (and not an u-boot.imx) we should skip its first KB, too. In summary, to put u-boot on your SD, do:   # dd if=output/images/u-boot.bin of=/dev/<your-sd-card> bs=1k seek=1 skip=1   # sync Your SD card device is typically something in /dev/sd<X> or /dev/mmcblk<X>. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. Similarly to what this post describes, you can copy the kernel to the FAT boot partition with: # mount /dev/<your-sd-card-second-partition> /mnt # cp output/images/uImage /mnt/ # umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or/dev/mmcblk<X>p1. And not unlike what is done in this post, You can install your generated root filesystem to the Linux partition with: # mount /dev/<your-sd-card-second-partition> /mnt # tar -C /mnt -xvf output/images/rootfs.tar # umount /mnt Your SD card second partition is typically something in /dev/sd<X>2 or/dev/mmcblk<X>p2. Boot! Your SD card is ready for booting. Insert it in the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. Like with Debian, u-boot default settings will not allow it to boot from the SD card, so we need to interrupt it by pressing enter at u-boot prompt for the first boot and setup u-boot environment to fix this: MX6Q SABRESD U-Boot > setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk1p2 rootwait' MX6Q SABRESD U-Boot > setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc dev 2; fatload mmc 2:1 ${loadaddr} ${kernel}; bootm' MX6Q SABRESD U-Boot > setenv bootcmd 'run bootcmd_mmc' MX6Q SABRESD U-Boot > saveenv Saving Environment to MMC... Writing to MMC(2)... done As this is saved in the SD card it need only to be done once at first boot. You can reboot your board or type boot; your buildroot system should boot to a prompt: (...) Welcome to Buildroot buildroot login: From there you may login as root. Enjoy! Tweak buildroot uses Linux kernel kconfig to handle its configuration. So, as for the Linux kernel, changes to the configuration can be done with e.g.: $ make menuconfig Most of the options can be tuned from there, including (most importantly) which packages get installed into the generated root filesystem. This is configuration section 'Filesystem images'. Further details are documented in buildroot manual. Tips ccache is natively supported by buildroot and can be easily enabled with configuration option BR2_CCACHE. If you only use the generated rootfs.tar as described in this post and do not care about the rootfs.ext2, you might as well save a few seconds of build by disabling its generation. This is done with configuration option BR2_TARGET_ROOTFS_EXT2. It is recommended to install an ssh server inside the target for further development. This is conveniently done with configuration option BR2_PACKAGE_OPENSSH. See also... Other root filesystems may make more sense for you; see this post for a Debian root filesystem, and this post for a minimal busybox filesystem. Freescale Yocto Project main page
View full article
                                                                                         Watch the Freescale i.MX team boot up Android 5.0 Lollipop in i.mx6 application processors—在线播放—优酷网,视频高清在线观看 The Freescale i.MX Android team has booted up Android 5.0 Lollipop in the SABRE platform for i.mx6 series. Google pushed all of the latest source for its Android release to AOSP on Nov. 5, and the Freescale Android Team started their work. With the previous 6 days to boot Android Lollipop up, the Freescale i.MX Android team enabled the basic features like connectivity, audio/video playback, sensors, inputs and display on day 7! You can see the some changes in the demo video at the beginning of the post. The Freescale i.MX Android team has closely followed almost every version of Android since it is released by AOSP and has good experience on it. Below are some snapshots and pictures for the Android Lollipop.
View full article
Here is a quick summary at booting Linux on the i.MX 6 sabre sd platform. This assumes you already have u-boot working on your platform as described here. This implies you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). Get Linux sources We will use git to fetch Linux sources:   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git This should create a linux directory with all the latest sources (after a while). Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l 'v*', and git checkout <the-desired-tag>. Compile Assuming your cross compiler is called e.g. arm-linux-gnueabihf-gcc, you can compile by doing:   $ cd linux   $ export ARCH=arm   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make imx_v6_v7_defconfig   $ make You then need to supply a LOADADDR (as joowonkim pointed out); do:   $ make uImage LOADADDR=0x10008000 This should create a number of files, including arch/arm/boot/uImage and arch/arm/boot/dts/imx6q-sabresd.dtb. Put on SD We need a proper FAT partition on the SD card, from which u-boot will be able to load the kernel and dtb. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout:   +-----+------+--------+-----+----------------   | MBR |  ... | u-boot | ... | FAT partition ...   +-----+------+--------+-----+----------------   0     512    1024           1M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk:   Device    Boot      Start         End      Blocks   Id  System   /dev/sdc1            2048     8054783     4026368    c  W95 FAT32 (LBA) (units: 512B sectors) You can format the FAT partition, mount, copy and unmount with:   $ mkfs.vfat /dev/<your-sd-card-first-partition>   $ mount /dev/<your-sd-card-first-partition> /mnt   $ cp arch/arm/boot/uImage arch/arm/boot/dts/imx6q-sabresd.dtb /mnt/   $ umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or /dev/mmcblk<X>p1. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. Also, be sure to have u-boot on the SD card as explained in this post. Boot! That's it; u-boot already knows how to deal with your kernel by default so you are good to go. Insert the SD card into the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. You should see u-boot messages:   U-Boot 2013.07-rc1-00014-g74771f4 (Jun 21 2013 - 16:27:39) u-boot should load the uImage and dtb from SD card and boot the kernel:   (...)   reading uImage   4215344 bytes read in 449 ms (9 MiB/s)   Booting from mmc ...   reading imx6q-sabresd.dtb   22818 bytes read in 22 ms (1012.7 KiB/s)   ## Booting kernel from Legacy Image at 12000000 ...      Image Name:   Linux-3.10.0-rc6      Image Type:   ARM Linux Kernel Image (uncompressed)      Data Size:    4215280 Bytes = 4 MiB      Load Address: 10008000      Entry Point:  10008000      Verifying Checksum ... OK   ## Flattened Device Tree blob at 11000000      Booting using the fdt blob at 0x11000000      Loading Kernel Image ... OK   OK      Using Device Tree in place at 11000000, end 11008921   Starting kernel ... The kernel should boot:   Booting Linux on physical CPU 0x0   Linux version 3.10.0-rc6 (vstehle@debian) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Fri Jun 21 18:09:26 CEST 2013 By default, the kernel will try to mount a root filesystem from the SD card second partition, as can be read in the default kernel command line:   (...)   Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw ...but we did not prepare a root filesystem partition, so after a number of boot messages the kernel will wait indefinitely:   (...)   mmc1: new SDHC card at address b368   (...)    mmcblk0: p1   (...)   Waiting for root device /dev/mmcblk1p2... We will see in another post how to prepare this root filesystem on the second SD card partition. Enjoy! See also... If you plan to compile Linux often, you might want to use a C compiler cache; see this post. Once you have Linux booting on your platform the next step is to give it a root filesystem. See this post for a Debian root filesystem, this post for a minimal busybox filesystem and this post for generating a root filesystem with buildroot.
View full article
The i.MX Android O8.0.0_1.0.0 GA release is now available from IMX_SW page. Overview -> BSP Updates and Releases -> Android 8.0.0 Oreo (O8.0.0_1.0.0, 4.9 kernel)   Files available: # Name Description 1 android_O8.0.0_1.0.0_docs.tar.gz i.MX Android O8.0.0_1.0.0 BSP Documentation 2 imx-o8.0.0_1.0.0_ga.tar.gz i.MX Android O8.0.0_1.0.0 proprietary surce code for i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo  i.MX 6Sololite, i.MX6SX and i.MX7D 3 android_O8.0.0_1.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_O8.0.0_1.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_O8.0.0_1.0.0_image_6slevk.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_O8.0.0_1.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_O8.0.0_1.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_O8.0.0_1.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android O8.0.0_1.0.0 BSP - SABRE Board based on i.MX 7Dual 9 fsl_aacp_dec_O8.0.0_1.0.0.tar.gz AAC Plus Codec for O8.0.0_1.0.0 10 android_O8.0.0_1.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for O8.0.0_1.0.0   Supported Hardware SoC/Boards: i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform i.MX 6SoloLite EVK platform i.MX 6SoloX SABRE-SD board and platforms i.MX 6SoloX SABRE-AI board and platforms i.MX 7Dual SABRE-SD board and platform   Changes: Compared to the N7.1.2_2.0.0 release, this release has the following major changes: Upgraded the Android code base from android-7.1.2_r9 to android-8.0.0_r25. Removed the device partition and added the vendor partition. Enabled ION-based gralloc and EGL. Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.
View full article
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.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.MX53 DDR3 Script Aid i.MX8M DDR3L register programming aid  i.MX6 DDR Stress Test Tool V1.0.3 imx53 DDR stress tester V0.042 i.MX6/7 DDR Stress Test Tool V3.00 i.MX8MSCALE DDR Tool Release  Application Notes: MX_Design_Validation_Guide I.MX6 series USB Certification Guides
View full article
The i.MX Android N7.1.2_2.0.0 GA release is now available on IMX_SW page.   Files available: # Name Description 1 android_N7.1.2_2.0.0_docs.tar.gz i.MX Android N7.1.2_2.0.0 BSP Documentation 2 android_N7.1.2_2.0.0_source.tar.gz Source Code of Android N7.1.2_2.0.0 BSP (4.1 kernel) for i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo i.MX 6Sololite, i.MX6SX and i.MX7D 3 android_N7.1.2_2.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_N7.1.2_2.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_N7.1.2_2.0.0_image_6slevk.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_N7.1.2_2.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_N7.1.2_2.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_N7.1.2_2.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE Board based on i.MX 7Dual 9 fsl_aacp_dec.tar.gz AAC Plus Codec for N7.1.2_2.0.0 10 android_N7.1.2_2.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for N7.1.2_2.0.0   Supported Hardware SoC/Boards: i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform i.MX 6SoloLite EVK platform i.MX 6SoloX SABRE-SD board and platforms i.MX 6SoloX SABRE-AI board and platforms i.MX 7Dual SABRE-SD board and platform   Changes: Compared to the N7.1.1_1.0.0 release, this release has the following major changes: Upgraded the Android code base from android-7.1.1_r13 to android-7.1.2_r9. Upgraded U-Boot from v2015.04 to v2017.03. Upgraded the kernel from v4.1.15 to v4.9.17. Upgraded the GPU driver from 6.2.0.p2 to 6.2.2.p1. Upgraded the Wi-Fi BCMDHD release version to 1.141.100.6. Refine the Gralloc and HWC HAL. Enable the GPT partition to replace the MBR partition.   Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.
View full article
   The purpose of this article is to describe how to join together the Processor Expert and ARM GCC toolchain under Eclipse environment.    Freescale provides the Processor Expert, which contains the Pin Settings Tool to support an easy way to configure pin signals, from multiplexing to the electrical properties of pins. With such Tool all the pins can be configured with a graphical user interface, and then generate C code, in order to use it as an example in applications. Please refer to the following Web for more details. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PROCESSOR-EXPERT-IMX   The Processor Expert Software for i.MX Processors (Version 1.0) does not include a compiler or linker. Customers should merge the generated code into a build system.   However, it is possible to use common Eclipse-based IDE for the Processor Expert (V 1.0) and GNU ARM “C” toolchains. In particular, the following sequence may be implemented for both Linux and Windows hosts. 1. Install Eclipse (Kepler release) IDE for C/C++ Developers. https://eclipse.org/downloads/packages/eclipse-ide-cc-developers/keplersr2 2. Add Eclipse Processor Expert plug-in, as recommended in the documentation. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PROCESSOR-EXPERT-IMX https://community.freescale.com/docs/DOC-101470 3.  Add GNU ARM Eclipse, which contains configurations for different toolchains, including Linux ones. http://gnuarmeclipse.livius.net/blog/plugins-install/ 4. Install appropriate toolchain. For bare-metal applications Sourcery CodeBench Lite for ARM is sutable one. Sourcery CodeBench Lite Edition including ARM GCC IDE - Mentor Graphics Please use Getting Started Guide document from the CodeBench Lite package, that explains how to install and build applications with the CodeBench Lite.    As an example, let’s consider minimal startup code for i.MX6Q (LED flickering project on i.MX6Q SDB / SDP). Assuming Eclipse IDE with the Processor Expert and GNU ARM tools is installed, we should create new “C” project under Eclipse : New -> C Project. Select “Empty Project” and “Cross ARM GCC”, enter “Project name”. Then : select “Advanced settings” -> C/C++ Build -> Settings Tab “Target Processor” : ARM Family : cortex – a9 Architecture : armv7-a Instruction set : ARM (-marm) Endianness : Little endian (-mlittle-endian) FloatABI : Library with FP (softfp) FPU Type : neon Unaligned access : Disabled (-mno-unaligned-access) “Cross ARM GNU Create Flash Image” : General : Raw binary. TAB “Toolchains” : Name : Sourcery CodeBench Lite for ARM EABI (arm-none-eabi-gcc) (If needed customers can select appropriate toolchain) Architecture : ARM (AArch32) Prefix : arm-none-eabi Check “Use global toolchain path” or select the required path directly.  Source codes may added via Eclipse : File -> Import -> File System -> From directory Example source is enclosed. After sources as included in the project, let’s configure linker options via project properties, C/C++ Build -> Settings -> Tool Settings -> Cross ARM C Linker -> General. Add script file “mx6dq.ld”, uncheck “Remove unused section”, check “Do not use standard start files”.   Note, the article of Miro Samek is very helpful in clarifying of startup code and linker script. Please refer to “Building Bare-Metal ARM Systems with GNU”. Article Published online at www.Embedded.com,  July/August 2007. So, now we can build the project : Project -> Build Project. Two executable file will be generated : test.elf (for JTAG debugger) and test.bin, which may be used to create bootable SD card, using cfimager-imx.exe utility : CMD> cfimager-imx -o 0 -f test.bin -d g: Please use readme files in the enclosed for more details.
View full article
Here we show how to bootstrap the Debian Linux distribution from a PC to the i.MX6 sabre sd platform. While bootstrapping Debian on any architecture "natively" is pretty straightforward, "cross-bootstrapping" requires some techniques that we will explain. This document assumes you are able to boot a Linux kernel on your platform already. See this post for details on how to do it. Also, this document assumes you are using a Debian PC for preparing your SD card. You will require the following packages to be installed: binfmt-support qemu-user-static debootstrap Note: all the commands found in the following steps need to be run as root. Formatting the SD card We need to format the SD card with two partitions; one small FAT partition to contain the Linux kernel and its dtb, and one large ext4 partition, which will contain the root filesystem with the Debian userspace. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout:   +-----+------+--------+-----+---------------+-----------------   | MBR |  ... | u-boot | ... | FAT partition | Linux partition ...   +-----+------+--------+-----+---------------+-----------------   0     512    1024           1M              ~257M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk:   Device    Boot      Start         End      Blocks   Id  System   /dev/sdc1            2048      526335      262144    c  W95 FAT32 (LBA)   /dev/sdc2          526336     8054783     3764224   83  Linux (units: 512B sectors) You can format and mount the Linux partition with:   # mkfs.ext4 /dev/<your-sd-card-second-partition>   # mount /dev/<your-sd-card-second-partition> /mnt Your SD card second partition is typically something in /dev/sd<X>2 or /dev/mmcblk<X>p2. Do not forget to install u-boot and a Linux kernel as explained in those posts. Bootstrapping Debian First stage The first stage of Debian bootstrapping is done with:   # debootstrap --foreign --arch=armhf testing /mnt This will retrieve the base Debian packages from the internet, and perform a first stage of installation:   I: Retrieving Release   I: Retrieving Release.gpg   I: Checking Release signature   I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553)   I: Validating Packages   I: Resolving dependencies of required packages...   I: Resolving dependencies of base packages...   I: Found additional required dependencies: insserv libbz2-1.0 libcap2 libdb5.1 libsemanage-common libsemanage1 libslang2 libustr-1.0-1   I: Found additional base dependencies: libee0 libept1.4.12 libestr0 libgcrypt11 libgnutls-openssl27 libgnutls26 libgpg-error0 libidn11 libjson-c2 liblognorm0 libmnl0 libnetfilter-acct1 libnfnetlink0 libp11-kit0 libsqlite3-0 libtasn1-3 libxapian22   I: Checking component main on http://ftp.us.debian.org/debian...   (...)   I: Extracting util-linux...   I: Extracting liblzma5...   I: Extracting zlib1g... At this point, the necessary tools for second stage of installation are under /mnt/debootstrap/. Second stage The second stage needs to run natively; on an arm platform, that is. But we can use the combination of two techniques to perform this stage on the PC anyway:   # cp /usr/bin/qemu-arm-static /mnt/usr/bin/   # chroot /mnt /debootstrap/debootstrap --second-stage Those commands copy an arm emulator on the target filesystem, and use the chroot command to execute the second stage of the installation into the SD card, on the PC, with transparent emulation:   I: Installing core packages...   I: Unpacking required packages...   I: Unpacking libacl1:armhf...   I: Unpacking libattr1:armhf...   I: Unpacking base-files...   (...)   I: Configuring tasksel...   I: Configuring tasksel-data...   I: Configuring libc-bin...   I: Base system installed successfully. You can now remove /mnt/usr/bin/qemu-arm-static, or keep it for later, subsequent chroot under emulation. Finetuning the root filesystem For development it is handy to remove the root password on the target by removing the '*' from /mnt/etc/shadow on the SD card:   root::15880:0:99999:7::: Also, we can add the following line in /mnt/etc/inittab to obtain a login prompt on the UART:   T0:23:respawn:/sbin/getty -L ttymxc0 115200 vt100 You can now unmount the filesystem with:   # umount /mnt Boot! Your SD card is ready for booting. Insert it in the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. At the time of writing u-boot tells the kernel to boot from the wrong partition by default, so we need to interrupt by pressing enter at u-boot prompt for the first boot and setup u-boot environment to fix this:   U-Boot > setenv mmcroot /dev/mmcblk0p2 rootwait rw   U-Boot > saveenv   Saving Environment to MMC...   Writing to MMC(1)... done As this is saved in the SD card it need only to be done once at first boot. You can reboot your board or type boot; your Debian system should boot to a prompt:   (...)   [ ok ] Starting periodic command scheduler: cron.   [ ok ] Running local boot scripts (/etc/rc.local).   Debian GNU/Linux jessie/sid debian ttymxc0   debian login: From there you may login as root. It is recommended to setup the network connection and install an ssh server inside the target for further development. Enjoy! See also... With the amounts of memory we have today in the systems, it is even possible to boot Debian in a ramdisk. See this post about busybox for the ramdisk generation. Another way of generating a root filesystem is by building it with buildroot. See and this post for details.
View full article
    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    
View full article
It is based on 3.0.35 GA 4.1.0 BSP.   0001-Correct-mipi-camera-virtual-channel-setting-in-ipu_c.patch It is the updated IPU code for MIPI ID and SMFC setting in ipu_capture.c. These setting should not be combined with MIPI virtual channel value, they shoule be fixed with ID 0.   0002-Use-virtual-channel-3-for-ov5640-mipi-camera-on-iMX6.patch The sample code to modify ov5640_mipi camera to use virtual channel 3 on SabreSD board.   The followed command can be used to verify the mipi camera function after booted into Linux: $ gst-launch mfw_v4lsrc capture-mode=1 device=/dev/video1 ! mfw_v4lsink     2014-09-30 update: Added the patch for 3.10.17_GA1.0.0 BSP. "L3.10.17_1.0.0_mipi_camera_virtual_channel_3.zip"  
View full article
There is GPU SDK for i.MX6D/Q/DL/S: IMX_GPU_SDK.  This is to share the experience when compiling the example code from the SDK with Linux BSP release: L3.0.35_1.1.0_121218 and  L3.0.35_4.0.0_130424 . Minimal profile is using and have been verified on both i.MX6Q SDP and i.MX6DL SDP. To start: Please make sure “gpu-viv-bin-mx6q” has been selected in the Package list and compiled to your rootfs. After finished the compilation of the rootfs, you should find some newly added libraries for GLES1.0, GLES2.0, OpenVG and EGL in <ltib>/rootfs/usr/lib However, you should find libOpenVG.so is actually copied from libOepnVG_3D.so: vmuser@ubuntu:~/ltib_src/ltib/rootfs/usr/lib$ ls -al libOpen* -rwxr-xr-x 1 root root 115999 2013-06-06 18:31 libOpenCL.so -rwxr-xr-x 1 root root 515174 2013-06-06 18:31 libOpenVG_355.so -rwxr-xr-x 1 root root 272156 2013-06-06 18:31 libOpenVG_3D.so -rwxr-xr-x 1 root root 272156 2013-06-06 18:31 libOpenVG.so So, in this way, i.MX6D/Q will no use libOpenVG_355.so in the build. Also, if you run NFS, the libOpenVG.so will change to symbolic link:           For example, run on i.MX6Q SDP, it will link to /usr/lib/libOpenVG_355.so                          For example, run on i.MX6DL SDP, it will link to /usr/lib/libOpenVG_3D.so                Then, when you compile the OpenVG example code, it is becoming very confusing.  Thus, it needs to pay attention when doing the compilation.  For example, delete the symbolic link and make copy of the corresponding library: For i.MX6D/Q, please do this: $ sudo /bin/rm libOpenVG.so $ sudo cp libOpenVG_355.so libOpenVG.so For i.MX6S/DL, please do this: $ sudo /bin/rm libOpenVG.so $ sudo cp libOpenVG_3D.so libOpenVG.so To compile the sample code in the GPU SDK, you could refer to iMXGraphicsSDK_OpenGLES2.0.pdf or iMXGraphicsSDK_OpenGLES1.1.pdf in ~/gpu_sdk_v1.00.tar/Documentation/Tutorials to set up the cross compilation environment; which is assuming the LTIB and the rootfs is ready. $ export ROOTFS=/home/vmuser/ltib_src/ltib/rootfs $ export CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi- For OpenVG: $ cd ~/gpu_sdk_v1.00/Samples/OpenVG $ make -f Makefile.fbdev clean $ make -f Makefile.fbdev $ make -f Makefile.fbdev install The executable will then be copied to this directory: ~/gpu_sdk_v1.00/Samples/OpenVG/bin/OpenVG_fbdev For GLES2.0 $ cd ~/gpu_sdk_v1.00/Samples/ GLES2.0 $ make -f Makefile.fbdev clean $ make -f Makefile.fbdev $ make -f Makefile.fbdev install The executable will then be copied to this directory: ~/gpu_sdk_v1.00/Samples/ GLES2.0/bin/GLES20_fbdev For GLES1.1, please modify the Makefile.fbdev to remove the compilation of example codes "18_VertexBufferObjects" and "19_Beizer" that are not exist. Then, $ cd ~/gpu_sdk_v1.00/Samples/ GLES1.1 $ make -f Makefile.fbdev clean $ make -f Makefile.fbdev $ make -f Makefile.fbdev install The executable will then be copied to this directory: ~/gpu_sdk_v1.00/Samples/ GLES1.1/bin/GLES11_fbdev Finally, you could copy the executable to the rootfs and test on i.MX6Q SDP/SDB or i.MX6DL SDP board. NOTE: the newly added makefiles.tgz contains Makefile.x11 hacked from GLES2.0 example code to make OpenVG to compile and run on Ubuntu 11.10 rootfs.
View full article