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:
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
How to Test Yocto for i.MX6 i.MX Yocto Project: How Can I Collaborate on the Freescale Yocto Project? i.MX Yocto Project: How Can I Build the Freescale Yocto Images using bitbake? i.MX Yocto Project: How Can I Build the Freescale Yocto Images using hob? i.MX Yocto Project: What Can I Do if I Run Into a Compilation Error? i.MX Yocto Project: Are There Prebuilt Images Available? i.MX Yocto Project: How Can I Quicken the Compilation? i.MX Yocto Project: how can I conserve disk space during builds? i.MX Yocto Project: How do I add an existing package to an image? i.MX Yocto Project: Can I use a virtual machine to build? i.MX Yocto Project: How can I build an image with (latest) mainline kernel? i.MX Yocto Project: How can I (quickly) modify a package' source code and test it? i.MX Yocto Project: How can I find out the packages include on an image? i.MX Yocto Project: How can I compile the kernel manually? i.MX Yocto Project: How can I patch the kernel? i.MX Yocto Proyect: How can I create a new Layer? i.MX Yocto Project: How can I contribute to the community? i.MX Yocto Project: Where can I see current  BSP issues? i.MX Yocto Project: Where are the mainstream repositories hosted? Tutorials: Yocto Training - HOME http://www.slideshare.net/OtavioSalvador/yocto-training-in-english - Great tutorial created by the Community's maintainer (there is also a Portuguese version) i.MX Yocto Project: Freescale Yocto Project Tutorial - It covers some basic developing tasks Others: Useful bitbake commands i.MX Yocto Project: ltib versus bitbake
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
For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time. The attached patch can make the BSP support up to 4 cameras based on 3.10.53 GA 1.1.0 BSP.   The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI   For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel.   In this patch, we given the example driver for Maxim MAX9286, it was verified working on iMX6DQ SabreAuto board. The input to MAX9286 is four 720P30 cameras. The verified camera boards:     (1) Onsemi AR0140+AP0101+MAX9271 boards.     (2) OmniVision OV10635+MAX9271 boards.   The MIPI CSI2 CVBS camera surround view solution can be found at: iMX6DQ ISL79985/79987 MIPI CSI2 CVBS camera surround view solution for Linux BSP The MIPI CSI2 CVBS HD camera surround view solution can be found at: iMX6DQ TP2854 MIPI CSI2 720P CVBS camera surround view solution for Linux BSP   The kernel patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch      Updated IPU common code to support up to four cameras.   0002-Add-Max9286-support-on-SabreAuto-board-which-can-sup.patch      MAX9286 driver, it includes MAX9271, AP0101 and AR0140 drivers.   0003-Remove-the-page-size-align-requirement-for-v4l2-capt.patch      With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly.   0004-Max9286-skip-AP0101-camera-re-initialization.patch      If the camera board's power had been kept after initialized, this patch will bypass the re-initialization to reduce the start up time.   0005-Max9286-set-I2C-speed-to-400Kbps.patch     Set I2C to 400Kbps to reduce the AP0101+AR0140 initialization time.   0006-Max9286-add-retry-for-MAX9271-I2C-access.patch     Added retry for MAX9271 I2C access.   0007-Max9286-Add-support-for-OV10635-camera.patch     Updated code for OV10635 camera.   0008-Max9286-support-auto-detect-camera-number.patch     Make the Max9286 driver can detect the camera number automatically.     How to builld the kernel with MAX9286 support:       make imx_v7_defconfig       make menuconfig (In this command, you should select the MAX9286 driver:             Device Drivers  --->                   <*> Multimedia support  --->                         [*]   V4L platform devices  --->                               <*>   MXC Video For Linux Video Capture                                       MXC Camera/V4L2 PRP Features support  --->                                           <*>Maxim max9286 GMSL Deserializer Input support                                               Select Camera Sensor (OmniVision OV10635 camera sensor)  // Or (Onsemi AP0101 and AR0140 camera sensor)                                           <*>mxc VADC support                                           <*>Select Overlay Rounting (Queue ipu device for overlay library)                                           <*>Pre-processor Encoder library                                           <*>IPU CSI Encoder library)       make zImage       make dtbs   The built out image file:       arch/arm/boot/dts/imx6q-sabreauto.dtb       arch/arm/boot/zImage   "mxc_v4l2_tvin_max9286.tar.gz" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   Some hardware check point on AR0140+AP0101+MAX9271 camera board (Please get MAX9286 and OV10635 schematics from Maxim): 1. In this patch, MAX9286's I2C address is 0x4D, so ADD0 and ADD1 should be connected to high. AP0101's I2C address is 0xBA, so SADDR should be connected to high.   2. AP0101's DOUT0~DOUT7 should be connected to MAX9271's DIN7~DIN0, the order should be switched, MSB connected to LSB.   3. MAX9271's GPO pin should be connected to AP0101's FRAME_SYNC pin. The pull down resistance on FRAME_SYNC pin should not be 0 ohm.   Some known limitation: 1. AP0101's VSYNC invalid time, last video line's HSYNC to VSYNC porch's max value is 255 pixel clocks, it is not enough for MAX9286 to generate the Frame End MIPI packets for each camera. So in order to let iMX6DQ to capture 1280x720 video for each camera, we had let AP0101 output 1280*724 frame size, and iMX6 will only capture 720 lines, the remained video data and Frame End will be ignored. This solution will not impact the function, but there will be "Error matching Frame Start with Frame End for Virtual Channel x" error reported from iMX6 MIPI_CSI_ERR1 register. Maxim suggested to use MAX96705 to relace the MAX9271, it can delay the VSYNC invalid time, then the MIPI error will be fixed.     2015-11-17 update: Updated for OV10635 camera support. File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-11-17.zip   2015-12-04 update: File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-12-04.zip Added patch 0009-Max9286-updated-PCLK-edge-setting-for-OV10635.patch to correct the OV10635 PCLK edge setting     2016-03-07 update: File L3.14.38_GA_MAX9286_Surroundview_Patch_2016-03-07.zip Added kernel patch for L3.14.38 GA 1.1.0 BSP.   2016-07-26 update: Files: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.38_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.52_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip. Added gstreamer support. Added MAX96705 support. Added patch for L3.14.52_GA1.1.0.   2017-12-11 update: Added CVBS surround view link: iMX6DQ TP2854 MIPI CSI2 720P CVBS camera surround view solution for Linux BSP     2021-04-26 update: Some customer reported, when system loading is heavy, sometimes, some camera will flicker left and right. It is caused by SFMC FIFO data lost. The original patch used IDMAC 0 and IDMAC 1 for two cameras on one IPU, this is not the best setting.  IDMAC 1 is fixed to use 1/4 SMFC FIFO and it will cause IDMAC 0 to use 1/4 SMFC FIFO too. And another 1/2 of SMFC FIFO can't be used in this case. Some code update to improve it: For each IPU, please use IDMAC 0 and IDMAC 2 to capture the two cameras. This needs change the hard coding in "drivers\media\platform\mxc\capture\ipu_csi_enc.c", "CSI_MEM1" and "IPU_IRQ_CSI1_OUT_EOF" should be changed to "CSI_MEM2" and "IPU_IRQ_CSI2_OUT_EOF". In this case, all SMFC FIFO can be used. And in "ipu_common.c", function ipu_probe(), the followed code should be changed to make IDMAC2 use high priority too. /* Set sync refresh channels and CSI->mem channel as high priority */ - ipu_idmac_write(ipu, 0x18800003L, IDMAC_CHA_PRI(0)); + ipu_idmac_write(ipu, 0x1880000FL, IDMAC_CHA_PRI(0));
View full article
  Just sharing some experiences during the development and studying.   Although, it appears some hardwares, it focuses on software to speed up your developing on your  hardware.     杂记共享一下在开发和学习过程中的经验。    虽然涉及一些硬件,但其本身关注软件,希望这些能加速您在自己硬件上的开发。   02/07/2024 i.MX8X security overview and AHAB deep dive i.MX8X security overview and AHAB deep dive - NXP Community   11/23/2023 “Standalone” Compile Device Tree https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Standalone-Compile-Device-Tree/ta-p/1762373     10/26/2023 Linux Dynamic Debug https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Linux-Dynamic-Debug/ta-p/1746611   08/10/2023 u-boot environment preset for sdcard mirror u-boot environment preset for sdcard mirror - NXP Community   06/06/2023 all(bootloader, device tree, Linux kernel, rootfs) in spi nor demo imx8qxpc0 mek all(bootloader, device tree, Linux kernel, rootfs)... - NXP Community     09/26/2022 parseIVT - a script to help i.MX6 Code Signing parseIVT - a script to help i.MX6 Code Signing - NXP Community   Provide  run under windows   09/16/2022   create sdcard mirror under windows create sdcard mirror under windows - NXP Community     08/03/2022   i.MX8MM SDCARD Secondary Boot Demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MM-SDCARD-Secondary-Boot-Demo/ta-p/1500011     02/16/2022 mx8_ddr_stress_test without UI   https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/mx8-ddr-stress-test-without-UI/ta-p/1414090   12/23/2021 i.MX8 i.MX8X Board Reset https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8-i-MX8X-Board-Reset/ta-p/1391130       12/21/2021 regulator userspace-consumer https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/regulator-userspace-consumer/ta-p/1389948     11/24/2021 crypto af_alg blackkey demo crypto af_alg blackkey demo - NXP Community   09/28/2021 u-boot runtime modify Linux device tree(dtb) u-boot runtime modify Linux device tree(dtb) - NXP Community     08/17/2021 gpio-poweroff demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/gpio-poweroff-demo/ta-p/1324306         08/04/2021 How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709       07/14/2021 SWUpdate OTA i.MX8MM EVK / i.MX8QXP MEK https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/SWUpdate-OTA-i-MX8MM-EVK-i-MX8QXP-MEK/ta-p/1307416     04/07/2021 i.MX8QXP eMMC Secondary Boot https://community.nxp.com/t5/i-MX-Community-Articles/i-MX8QXP-eMMC-Secondary-Boot/ba-p/1257704#M45       03/25/2021 sc_misc_board_ioctl to access the M4 partition from A core side sc_misc_board_ioctl to access the M4 partition fr... - NXP Community     03/17/2021 How to Changei.MX8X MEK+Base Board  Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8X-MEK-Base-Board-Linux-Debug-UART/ba-p/1246779#M43     03/16/2021 How to Change i.MX8MM evk Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8MM-evk-Linux-Debug-UART/ba-p/1243938#M40       05/06/2020 Linux fw_printenv fw_setenv to access U-Boot's environment variables Linux fw_printenv fw_setenv to access U-Boot's env... - NXP Community     03/30/2020 i.MX6 DDR calibration/stress for Mass Production https://community.nxp.com/docs/DOC-346065     03/25/2020 parseIVT - a script to help i.MX6 Code Signing https://community.nxp.com/docs/DOC-345998     02/17/2020 Start your machine learning journey from tensorflow playground Start your machine learning journey from tensorflow playground      01/15/2020 How to add  iMX8QXP PAD(GPIO) Wakeup How to add iMX8QXP PAD(GPIO) Wakeup    01/09/2020 Understand iMX8QX Hardware Partitioning By Making M4 Hello world Running Correctly https://community.nxp.com/docs/DOC-345359   09/29/2019 Docker On i.MX6UL With Ubuntu16.04 https://community.nxp.com/docs/DOC-344462   09/25/2019 Docker On i.MX8MM With Ubuntu https://community.nxp.com/docs/DOC-344473 Docker On i.MX8QXP With Ubuntu https://community.nxp.com/docs/DOC-344474     08/28/2019 eMMC5.0 vs eMMC5.1 https://community.nxp.com/docs/DOC-344265     05/24/2019 How to upgrade  Linux Kernel and dtb on eMMC without UUU How to upgrade Linux Kernel and dtb on eMMC without UUU     04/12/2019 eMMC RPMB Enhance and GP https://community.nxp.com/docs/DOC-343116   04/04/2019 How to Dump a GPT SDCard Mirror(Android O SDCard Mirror) https://community.nxp.com/docs/DOC-343079   04/04/2019 i.MX Create Android SDCard Mirror https://community.nxp.com/docs/DOC-343078   04/02/2019: i.MX Linux Binary_Demo Files Tips  https://community.nxp.com/docs/DOC-343075   04/02/2019:       Update Set fast boot        eMMC_RPMB_Enhance_and_GP.pdf   02/28/2019: imx_builder --- standalone build without Yocto https://community.nxp.com/docs/DOC-342702   08/10/2018: i.MX6SX M4 MPU Settings For RPMSG update    Update slide CMA Arrangement Consideration i.MX6SX_M4_MPU_Settings_For_RPMSG_08102018.pdf   07/26/2018 Understand ML With Simplest Code https://community.nxp.com/docs/DOC-341099     04/23/2018:     i.MX8M Standalone Build     i.MX8M Standalone Build.pdf     04/13/2018:      i.MX6SX M4 MPU Settings For RPMSG  update            Add slide CMA Arrangement  Consideration     i.MX6SX_M4_MPU_Settings_For_RPMSG_04132018.pdf   09/05/2017:       Update eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 09/01/2017:       eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 08/30/2017:     Dual LVDS for High Resolution Display(For i.MX6DQ/DLS)     Dual LVDS for High Resolution Display.pdf 08/27/2017:  L3.14.28 Ottbox Porting Notes:         L3.14.28_Ottbox_Porting_Notes-20150805-2.pdf MFGTool Uboot Share With the Normal Run One:        MFGTool_Uboot_share_with_NormalRun_sourceCode.pdf Mass Production with programmer        Mass_Production_with_NAND_programmer.pdf        Mass_Production_with_emmc_programmer.pdf AndroidSDCARDMirrorCreator https://community.nxp.com/docs/DOC-329596 L3.10.53 PianoPI Porting Note        L3.10.53_PianoPI_PortingNote_151102.pdf Audio Codec WM8960 Porting L3.10.53 PianoPI        AudioCodec_WM8960_Porting_L3.10.53_PianoPI_151012.pdf TouchScreen PianoPI Porting Note         TouchScreen_PianoPI_PortingNote_151103.pdf Accessing GPIO From UserSpace        Accessing_GPIO_From_UserSpace.pdf        https://community.nxp.com/docs/DOC-343344 FreeRTOS for i.MX6SX        FreeRTOS for i.MX6SX.pdf i.MX6SX M4 fastup        i.MX6SX M4 fastup.pdf i.MX6 SDCARD Secondary Boot Demo        i.MX6_SDCARD_Secondary_Boot_Demo.pdf i.MX6SX M4 MPU Settings For RPMSG        i.MX6SX_M4_MPU_Settings_For_RPMSG_10082016.pdf Security        Security03172017.pdf    NOT related to i.MX, only a short memo
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
NOTE: Please suggest bitbake commands you find it useful! bitbake command Description bitbake <image> Bake an image (add -k to continue building even errors are found in the tasks execution) bitbake <package> -c <task> Execute a particular package's task. Default Tasks names: fetch, unpack , patch , configure , compile , install , package , package_write , and build. Example: To (force) compiling a kernel and then build, type: $ bitbake  linux-imx -f -c compile $ bitbake linux-imx bitbake <image > -g -u depexp Show the package dependency for image. Example: To show all packages included on fsl-image-gui $ bitbake fsl-image-gui -g -u depexp NOTE: This command will open a UI window, so it must be execute on a console inside the host machine (either virtual or native). bitbake <package> -c  devshell Open a new shell where with neccesary system values already defined for package hob bitbake frontend/GUI. bitbake <package> -c listtasks List all tasks for package bitbake virtual/kernel -c menuconfig Interactive kernel configuration bitbake <image> -c fetchall Fetch sources for a particular image bitbake-layers show-layers Show layers bitbake-layers show-recipes "*-image-*" Show possible images to bake. Without "*-images-*", it shows ALL recipes bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq Show image's packages bitbake -g <pkg> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq Show package's dependencies bitbake –v <image> 2>&1 | tee image_build.log Print (on console) and store verbose baking bitbake -s | grep <pkg> Check if certain package is present on current Yocto Setup
View full article
Chinese version of the paper had been published in July of China Integrated Circuit magazine. Please find Chinese version through following link. 飞思卡尔i.MX6平台DRAM接口高阶应用指导-DDR3篇
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 8M Family DDR Tools Overview The i.MX 8M Family DDR Tool is a Windows-based software to help users to do LPDDR4/DDR4/DDR3L training, stress test and DDR initial code generation for u-boot SPL. This page contains the latest releases for the i.MX 8M Family DDR Tools and cover the following SoCs : i.MX 8M Quad and its derivatives i.MX 8M Quadlite and i.MX 8M Dual i.MX 8M Mini Quad and its derivatives i.MX 8M Mini Quadlite/Dual/DualLite/Solo/SoloLite  i.MX 8M Nano Quad and its derivatives i.MX 8M Nano Quadlite/Dual/DualLite/Solo/SoloLite  i.MX 8M Plus   NOTE: For the i.MX 8/8X Family of DDR tools please refer to the: i.MX 8/8X Family DDR Tools Release   The purpose of the i.MX 8M Family 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 8M Family DDR Tools consist of: DDR Register Programming Aid (RPA) MSCALE DDR Tool   For more details regarding these DDR tools and their usage, refer to the i.MX 8M DDR Tools User Guide.   i.MX 8M Family DDR Tool    The i.MX 8M Family DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational for use with u-boot and OS bring-up. To install the DDR Stress Test, save and extract the zip file mscale_ddr_tool_vXXX_setup.exe.zip   (where 'xxx' is the current version number) and follow the on-screen installation instructions.     i.MX 8M Family DDR Tool Requirements   The tool requires access to the Windows registry, hence users must run it in administrator mode. When users design new i.MX 8M Family boards, please make sure to follow the rules outlined in the respective Hardware Developers Guide and the MSCALE_DDR_Tool_User_Guide, which can help users bring up DDR devices on their respective i.MX 8M boards.   i.MX 8M Family DDR Tool User Guide   The i.MX 8M DDR tool includes the document: MSCALE_DDR_Tool_User_Guide NOTE: Please read the MSCALE_DDR_Tool_User_Guide inside the package carefully before you use this tool.   i.MX8M DDR Tool Revision History   Rev Major Changes* (Features) Comments 3.31 Integration of the workaround for 8MQ ERR051273   3.30 Fix DBI enabled issue for all i.MX 8M series Automatically identify ROHM and PCA9450 PMICs on i.MX 8M Nano board Fix 4GB/8GB memory tester issues   3.20 Add support to i.MX 8M Plus   3.10 Fixe UART communication issues for some specific characters between the PC software and the target board. Fine-tune DDRPHY registers in generated C code.   3.00 Add support to i.MX8M-nano Add support to different PMIC or PMIC configuration Add support to stress test for all DDR frequency points RPA tools for Nano include support for DDR3L, DDR4, and LPDDR4.   Note that the DDR3L and LPDDR4 RPAs contain the name preliminary only to denote that these RPAs are based on internal NXP validation boards where the DDR4 RPA is based on the released EVK.   2.10 Change DDR4 capacity computing method   2.00 Add support to i.MX8M-mini   * Further details available in the release notes   Sample configuration in the .ds script for i.MX 8M debug UART2: ################step 0: configure debug uart port. Assumes use of UART IO Pads.   ##### ##### If using non-UART pads (i.e. using other pads to mux out the UART signals), ##### ##### then it is up to the user to overwrite the following IO register settings   ##### memory set 0x3033023C 32 0x00000000 #IOMUXC_SW_MUX_UART2_RXD memory set 0x30330240 32 0x00000000 #IOMUXC_SW_MUX_UART2_TXD memory set 0x303304A4 32 0x0000000E #IOMUXC_SW_PAD_UART2_RXD memory set 0x303304A8 32 0x0000000E #IOMUXC_SW_PAD_UART2_TXD memory set 0x303304FC 32 0x00000000 #IOMUXC_SW_MUX_UART2_SEL_RXD sysparam set debug_uart   1 #UART index from 0 ('0' = UART1, '1' = UART2, '2' = UART3, '3' = UART4)   Sample configuration in the front of the .ds script for i.MX 8M debug UART3  ################step 0: configure debug uart port. Assumes use of UART IO Pads.   ##### ##### If using non-UART pads (i.e. using other pads to mux out the UART signals), ##### ##### then it is up to the user to overwrite the following IO register settings   ##### memory set 0x30330244 32 0x00000000 #IOMUXC_SW_MUX_UART3_RXD memory set 0x30330248 32 0x00000000 #IOMUXC_SW_MUX_UART3_TXD memory set 0x303304AC 32 0x0000000E #IOMUXC_SW_PAD_UART3_RXD memory set 0x303304B0 32 0x0000000E #IOMUXC_SW_PAD_UART3_TXD memory set 0x30330504 32 0x00000002 #IOMUXC_SW_MUX_UART3_SEL_RXD sysparam set debug_uart   2 #UART index from 0 ('0' = UART1, '1' = UART2, '2' = UART3, '3' = UART4)   Sample configuration in the front of the .ds script for i.MX 8M Mini PMIC configuration: ##############step 0.5: configure I2C port IO pads according to your PCB design.   ##### ########### You can modify the following instructions to adapt to your board PMIC ####### memory set 0x30330214 32 0x00000010  #IOMUXC_SW_MUX_I2C1_SCL memory set 0x30330218 32 0x00000010  #IOMUXC_SW_MUX_I2C1_SDA memory set 0x3033047C 32 0x000000C6 #IOMUXC_SW_PAD_I2C1_SCL memory set 0x30330480 32 0x000000C6  #IOMUXC_SW_PAD_I2C1_SDA sysparam set pmic_cfg 0x004B #bit[7:0] = PMIC addr,bit[15:8]=I2C Bus. Bus index from 0 ('0' = I2C1, '1' = I2C2, '2' = I2C3, '3' = I2C4) sysparam set pmic_set 0x2F01 #bit[7:0] = Reg val, bit[15:8]=Reg addr. #REG(0x2F) = 0x01 sysparam set pmic_set 0x0C02   #REG(0x0C) = 0x02 sysparam set pmic_set 0x171E   #REG(0x17) = 0x1E sysparam set pmic_set 0x0C00   #REG(0x0C) = 0x00 sysparam set pmic_set 0x2F11    #REG(0x2F)=0x11     i.MX 8M Family DDR Register Programming Aid (RPA) The i.MX 8M DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization(in a separate Excel worksheet tab):   DDR Stress Test Script: This format is used specifically with the DDR stress test by first copying the contents in this worksheet tab and then pasting it to a text file, naming the document with the “.ds” file extension. The user will select this file when executing the DDR stress test. The How to Use Excel worksheet tab provides instructions on using the RPA   i.MX 8M Family DDR Register Programming Aid (RPA): Current Versions To obtain the latest RPAs, please refer to the following links (note, existing RPAs have been removed from this main page and moved to the SoC specific links below): i.MX 8M Quad : https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8M-m850D-DDR-Register-Programming-Aid-RPA/ta-p/1172441 i.MX 8M Mini : https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MMini-m845S-DDR-Register-Programming-Aid-RPA/ta-p/1172443 i.MX 8M Nano: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MNano-m815S-DDR-Register-Programming-Aid-RPA/ta-p/1172444 i.MX 8M Plus: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8MPlus-m865S-DDR-Register-Programming-Aids-RPA/ta-p/1235352   Processor Mask Revisions Memory Supported Latest RPA Version * i.MX 8M Quad & Derivatives All LPDDR4 Rev 33 i.MX 8M Quad & Derivatives All DDR4 Rev 18 i.MX 8M Quad & Derivatives All DDR3L Rev 9 i.MX 8M Mini & Derivatives A0 LPDDR4 Rev 22 i.MX 8M Mini & Derivatives A0 DDR4 Rev 21 i.MX 8M Mini & Derivatives A0 DDR3L Rev 10 i.MX 8M Nano & Derivatives A0 LPDDR4 Rev 9 i.MX 8M Nano & Derivatives A0 DDR4 Rev 12 i.MX 8M Nano & Derivatives A0 DDR3L Rev 6 i.MX 8M Plus & Derivatives A1 LPDDR4 Rev 9 i.MX 8M Plus & Derivatives A1 DDR4 Rev 9 * For the details about the updates, please refer to the Revision History tab of the respective RPA.    To modify the DRAM Frequency for a custom setting refer to iMX 8M Mini Register Programming Aid DRAM PLL setting    Related Resources Links: iMX 8M Mini Register Programming Aid DRAM PLL setting  i.MX 8/8X Series DDR Tool Release  i.MX 6/7 DDR Stress test GUI Tool i.MX 8M Application Processor Related Resources i.MX8M (m850D) DDR Register Programming Aid (RPA)  i.MX8MMini (m845S) DDR Register Programming Aid (RPA)  i.MX8MNano (m815S) DDR Register Programming Aid (RPA) i.MX 8MPlus (m865S) DDR Register Programming Aids (RPA)   i.MX 8ULP DDR tools: i.MX Software and Development Tools | NXP Semiconductors Scroll down to “Other Resources --> Tools --> DDR Tools”  
View full article
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 post describes the setup detail for installing Ubuntu based distro in any i.Mx6x NXP Boards. Details are described on: 1. Select your board, Setting the host, Download and compile uboot , dtb and and the Kernel version on your board. 2. Installing the Ubuntu core, Lubuntu graphics desktop version and/or Build your own Ubuntu rootfs with debootstrap. 3. Modify rootfs and Installing needed packages 4. Setting with SD image. 5. Setting Ubuntu on target 6. Adding GPU acceleration 1: Select your board, Setting the host, Download and compile uboot , dtb and and the Kernel version on your board. Supported NXP HW boards: i.MX 6QuadPlus SABRE-SD Board and Platform 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 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board Install host dependences (version tested 14.04): $ sudo apt-get install gparted git build-essential libncurses5 wget u-boot-tools zlib1g-dev ncurses-dev \ cmake libc-dev-armhf-cross pkg-config-arm-linux-gnueabihf build-essential checkinstall cmake \ pkg-config lzop libc6 libstdc++6 debootstrap qemu-user-static binfmt-support Download the compiler toolchain and extract it: $ cd ~/ $ wget -c https://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz $ tar xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz Create general variable environments: $ export target=mx6q (e.g. processor: mx6sx, mx6d, mx6dl,etc) $ export board=sabresd (e.g. sabresd, sabreauto) $ export ARCH=arm $ export CROSS_COMPILE=../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ unset LDFLAGS Download u-boot At the release of this document, latest uboot version was imx_3.14.52, it should work with other version as well, so please check the proper version for your board: $ cd ~/ $ wget –c http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/snapshot/uboot-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ tar -xf uboot-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ cd uboot-imx-rel_imx_3.14.52_1.1.0_ga $ make $targetboard_config    # e.g. mx6qsabresd_config $ make Linux Kernel, Firmware, headers, modules and DTS files $ cd ~/ $ wget –c http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/snapshot/linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ tar xf linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ make imx_v7_defconfig $ make menuconfig $ make -j4 zImage modules dtbs $ cd ~/ move your image to binary folder: $ sudo cp –v uboot-imx-rel_imx_3.14.52_1.1.0_ga/u-boot.imx binary/ $ sudo cp –v linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga/arch/arm/boot/zImage binary/ $ sudo cp –v linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga/arch/arm/boot/dts/i$target-$board.dtb binary/ Now you have the bootloader, device tree and kernel image of your board ready, let’s create the rootfs. 2: Installing the Ubuntu core, Lubuntu graphics desktop version and/or Build your own Ubuntu rootfs with debootstrap. Installing ubuntu core: $ cd ~/ $ sudo mkdir –p core /media/rootfs /media/kernel $ wget –c http://cdimage.ubuntu.com/ubuntu-core/releases/14.04/release/ubuntu-core-14.04.4-core-armhf.tar.gz $ sudo tar –xf ubuntu-core-14.04.4-core-armhf.tar.gz –C core $ sudo cp -vr core/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/rootfs folder. and you can pass to part 3 of this post. Installing ubuntu Linaro LXDE: $ cd ~/ $ sudo mkdir –p core /media/rootfs /media/kernel $ wget https://releases.linaro.org/14.10/ubuntu/trusty-images/alip/linaro-trusty-alip-20141024-684.tar.gz $ sudo tar -xf linaro-trusty-alip-20141024-684.tar.gz –C core $ sudo mv core/binary/* core/ $ sudo rm –rf core/binary $ sudo cp -vr core/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/rootfs folder. and you can pass to part 3 of this post. Installing with debootstrap $ cd ~/ $ target=rootfs $ distro=trusty $ sudo debootstrap --arch=armhf --foreign --include=ubuntu-keyring,apt-transport-https,ca-certificates,openssl $distro "$target" http://ports.ubuntu.com $ sudo cp /usr/bin/qemu-arm-static $target/usr/bin $ sudo cp /etc/resolv.conf $target/etc Now have a minimal Ubuntu rootfs - chroot to it and perform the 2nd stage install: $ sudo chroot $target  //Now we are in chroot # distro=trusty # export LC_ALL=C LANGUAGE=C LANG=C # /debootstrap/debootstrap --second-stage Edit the sources.list repositories # cat <<EOT > /etc/apt/sources.list deb http://ports.ubuntu.com/ubuntu-ports/ $distro main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ $distro-updates main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ $distro-security main restricted universe multiverse EOT # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 40976EAF437D05B5 # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 3B4FE6ACC0B21F32 # apt-get update # apt -y -f install # apt-get upgrade # apt-get install nano Now you should be able to login without password, then use passwd command to set one. If you like to add custom users: # passwd root # adduser <myuser> # usermod -a -G tty myuser # usermod -a -G dialout, adm, sudo, dip, plugdev myuser # visudo Under the line that looks like: root ALL=(ALL:ALL) ALL add the following (change user with your actual username) <myuser> ALL=(ALL) ALL your rootfs is ready, exit chroot # exit $ sudo rm $target/etc/resolv.conf $ sudo rm $target/usr/bin/qemu-arm-static $ sudo mv rootfs/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/root. 3: Modify Rootfs and Install needed packages Edit and verify the sources.list repositories $ cd /media/rootfs $ sudo cat <<EOT > etc/apt/sources.list deb http://ports.ubuntu.com/ubuntu-ports/ trusty main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ trusty-updates main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ trusty-security main restricted universe multiverse EOT Edit networks interfaces and append in the existing file: $ sudo nano etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp If you require Serial Console, remove and include an additional line at the end of the file for  ttymxc0 output as below, $ sudo nano etc/init/tty1.conf exec /sbin/getty -8 38400 tty1 exec /sbin/getty -L 115200 ttymxc0 If you like to change the localhostname: $ sudo nano etc/hostname and change to “your name” e.g. imx6Q. Set the date and time clock and update $ sudo nano /etc/rc.local  Add this: if [ `date +"%Y"` -eq "1970" ]; then                     date --set="2016-04-01" fi exit 0 (optional for Linaro rootfs) Edit passwd and remove the x in root and linaro lines $ sudo nano etc/passwd root:x:0:0:root:/root:/bin/bash linaro:x:0:0.. and change like this:                                   root::0:0:root:/root:/bin/bash linaro:::0:.. Now you are ready to program your sd image. 4: Setup microSD/SD card For these instructions, we are assuming: DISK=/dev/sdg on your HOST, cat /proc/partitions is very useful for determining the device id. $ cd ~/ $ export DISK=/dev/sdg Erase microSD/SD card: $ sudo dd if=/dev/zero of=${DISK} bs=1M count=10 Install Bootloader $ cd binary/ $ sudo dd if=u-boot.imx of=${DISK} bs=512 seek=2 $ sync Create Partition layout: $ cd ~/ $ sudo fdisk ${DISK} steps:        d ///delete all partitions currently on sd n // create new partition p // Primary partition 1 // partition number 1 2048 //default +1G // n // created 2d parition p 2 default default 1 // firts B // to be fat32 W // write partiotions $ sudo mkfs.vfat ${DISK}1 $ sudo mkfs.ext3  ${DISK}2 Mount ext3 SD partition to /media/rootfs: $ sudo mount ${DISK1} /media/kernel_target $ sudo mount ${DISK}2 /media/rootfs_target Copy Files on the SD. $ cd ~/ $ sudo cp –v binary/ i$target-$board.dtb /media/kernel_target $ sudo cp –v binary/zImage /media/kernel_target $ sudo mv /media/rootfs/* /media/rootfs_target Remove SD: $ sync $ sudo umount /media/kernel_target $ sudo umount /media/rootfs_target Boot the target, in console you should be login as root. root@imx6QSabreSD:~# 5: Setting Ubuntu on target Note: If you have issues with sudo on user UID, need to logout and log as root: imx6Q login: root Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.14.52 armv7l) root@imx6Q:~# chown root:root /usr/bin/sudo root@imx6Q:~# chmod 4755 /usr/bin/sudo root@imx6Q:~# exit Login with <user $> or root # # apt-get update # apt-get –f install # apt-get install locales dialog wget # dpkg-reconfigure locales # apt-get upgrade Optional – install some useful packages: # apt-get install openssh-server can-utils usbutils build-essential automake autoconf libtool Get and Install the BSP packages (EULA required) # cd /home/user # mkdir –p vpu_pack # cd vpu_pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//firmware-imx-5.3.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-vpu-5.4.32.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//libfslcodec-4.0.8.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-lib-5.1.tar.gz # chmod +x * # ./firmware-imx-5.3.bin --auto-accept --force # mkdir –p /lib/firmware/vpu # cp -ravf firmware-imx-5.3/firmware/* /lib/firmware/ # ./imx-vpu-5.4.32.bin --auto-accept --force # cd imx-vpu-* # make PLATFORM=IMX6Q all # make install # tar -xf imx-lib-5.1.tar.gz # cd  imx-lib-5.1/ # make -j1 PLATFORM="IMX6Q" # make PLATFORM="IMX6Q" install # cd .. # ./libfslcodec-4.0.8 --auto-accept –force # cd libfslcodec-* # ./autogent.sh --prefix=/usr --enable-fhw --enable-vpu # make # make install # mv /usr/lib/imx-mm/video-codec/* /usr/lib # mv /usr/lib/imx-mm/audio-codec/* /usr/lib # rm –rf /usr/lib/imx-mm/ # cd .. # mkdir –p gpu_pack # cd gpu_pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-gpu-viv-5.0.11.p7.4-hfp.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//xserver-xorg-video-imx-viv-5.0.11.p7.4.tar.gz # chmod +x * # ./imx-gpu-viv-5.0.11.p7.4-hfp –-auto-accept -–force # cd imx-gpu* # cp g2d/usr/include/* /usr/include/ # cp -d g2d/usr/lib/* /usr/lib/ # cp -Pr gpu-core/usr/* /usr # optional: install demos # cp -r gpu-demos/opt / # optional: install gpu tools # cp -axr gpu-tools/gmem-info/usr/bin/* /usr/bin/ # cd .. Installing gstreamer-imx, IPU, VPU and GPU support: Install build deps, gstreamer1.x, this step could take some time (~350MB): # apt-get install python pkg-config git gstreamer1.0-x gstreamer1.0-tools gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-alsa libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libgstreamer-plugins-good1.0-dev g++-multilib # git clone git://github.com/Freescale/gstreamer-imx.git # cd gstreamer-imx # ln –s /usr/lib/arm-linux-gnueabihf/gstreamer-1.0/ /usr/lib/gstreamer-1.0 # ./waf configure --prefix=/usr --kernel-headers=/include # ./waf # ./waf install # cd ../../ (optional) Install libimxvpuapi library: This library provides a community based open-source API to the NXP imx-vpu library (the low-level IMX6 VPU interface). # git clone git://github.com/Freescale/libimxvpuapi.git # cd libimxvpu* # ./waf configure –-prefix=/usr # ./waf # ./waf install # cd .. note './waf install' installs artifacts to its prefix + /lib/gstreamer-1.0 but they need to be installed to /usr/lib/arm-linux-gnueabihf/gstreamer-1.0 which is why we created a symlink above before installing note g2d lib required to build G2D note that x11 library is required to build EGL sink with Vivante direct textures (only needed for X11 support) note that libfslaudiocodec is required to build audio plugins Now you are ready to test gstreamer 6: Add GPU HW Acceleration for X11 NOTE: The original version of these build instructions can be found in the Gateworks wiki . Many thanks to them for writing this! IMX6 IPU, VPU, and GPU support via GStreamer and Gstreamer-imx plugins. Many of the pieces needed (firmware and source-code) are from NXP and not freely redistributable thus must be downloaded from their mirror and extracted from a shell script that forces you to read and agree to their End User License Agreement (EULA). The following instructions can be used on top of the debootstrap and should work on other sources of Ubuntu or other Linux distributions root filesystems as well You can easily add X11 support to a base image created with the debootstrap instructions above by adding a few package groups. You will need the following: X11 server - ie Xorg Display Manager - this controls the login to the X session Window Manager - manages window position, re-sizing, decorations, etc for X clients If in any case you have installed the Linaro LXDE rootfs, it includes the Xorg X11 server, the lxdm Display Manager, the openbox Window Manager, and others useful user applications including the Chromium browser, if you do not install linaro lxde and want to install it please do: this step could take some time (~650MB)   # apt-get install xinit lxde lxterminal lxappearance lxrandr lxshortcut lxinput xinit  xserver-xorg-dev mesa-utils mesa-utils-extra Notes: you will need to add a non-root user with adduser for Chromium browser to work. You may choose to set up auto-login for that user by editing /etc/lxdm/default.conf and setting the autologin property in the base section at the beginning of the config file. /etc/xdg/lubuntu/lxdm/lxdm.conf This document takes as based kernel version 3.14.52v, vivante 5.0.11p7.4 correspond to the kernel version used. you should check the BSP release notes in order to know which xserver and Vivante GPU files need to be downloaded from the NXP repos. $ sudo nano /etc/lxdm/default.conf    [base]    autologin=user To add hardware GPU acceleration to X11 you need to add some libraries and drivers provided by Freescale from the imx-gpu-viv package. This requires signing Freescales End User License Agreement (EULA). This package provides the following: libg2d - a documented low-level API to the GPU (used by things like libimxvpuapi for gstreamer-imx and the gpu-core drivers) gpu-core - provides all the various OpenGL libs (libGL, libGLESv1_CM, libGLESv1_CL, libGLESv2, libGLSLC, libCLC, libEGL, libGAL, libOpenCL, ls libOpenVG) typically provided by the mesa project. Note that several versions of libEGL/libGAL/libGLESv2/libVIVANTE are provided for different backend rendering systems: dfb, fb, wl, x11. # cd gpu_pack #cd imx-gpu-* # cp gpu-core/usr/lib/dri/vivante_dri.so /usr/lib/xorg/modules/drivers/ # chmod 644 /usr/lib/xorg/modules/drivers/vivante_dri.so # rm /usr/lib/arm-linux-gnueabihf/mesa/libGL.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libEGL.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libGLESv2.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libOpenVG.so* # cd ../../ # cd gpu-pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//xserver-xorg-video-imx-viv-5.0.11.p7.4.tar.gz # tar –xf xserver* # cd xserver-org-video-imx* #looks lik have to made #git init # ./fastbuild.sh  BUILD_HARD_VFP=1 XSERVER_GREATER_THAN_13=1 # cd.. # cd kernel-modu* # make Switch to gpu-core x11 backend: # backend=x11 # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so.1 # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so.1.0 # ln -sf libGAL-${backend}.so /usr/lib/libGAL.so # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so.2 # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so.2.0.0 # ln -sf libVIVANTE-${backend}.so /usr/lib/libVIVANTE.so # ln -sf libGAL_egl.dri.so /usr/lib/libGAL_egl.so # for i in egl glesv1_cm glesv2 vg; do         cp /usr/lib/pkgconfig/${i}_${backend}.pc/usr/lib/pkgconfig/${i}.pc     done #rm /usr/lib/*-dfb.so /usr/lib/*-fb.so /usr/lib/*-wl.so (Optional in case you deploy your kernel version with GPU as module) make vivante kernel module (GPU kernel driver) load on boot: # echo vivante >> /etc/modules # nano /etc/udev/rules.d/10-imx.rules KERNEL=="galcore",  MODE="0660", GROUP="video" KERNEL=="mxc_asrc",  MODE="0666" Create an xorg.conf configured for the Vivante fbdev driver: # nano /etc/X11/xorg.conf Section "Device"     Identifier "i.MX Accelerated Framebuffer Device"     Driver "vivante"     Option "fbdev" "/dev/fb0"     Option "vivante_fbdev" "/dev/fb0"     Option "HWcursor" "false" EndSection Section "ServerFlags"     Option "BlankTime"  "0"     Option "StandbyTime"  "0"     Option "SuspendTime"  "0"     Option "OffTime"  "0" EndSection # cd .. Make sure the files copied into the correct places. If all compiled and copied, you should now see a bunch of new libraries in /usr/lib! Congratulations! After you finish you can reboot your system and start playing. Testing Gstreamer examples: show gstreamer-imx plugins: # gst-inspect-1.0 | grep imx imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder imxvpu:  imxvpudec: Freescale VPU video decoder imxv4l2videosrc:  imxv4l2videosrc: V4L2 CSI Video Source imxg2d:  imxg2dcompositor: Freescale G2D video compositor imxg2d:  imxg2dvideotransform: Freescale G2D video transform imxg2d:  imxg2dvideosink: Freescale G2D video sink imxipu:  imxipucompositor: Freescale IPU video compositor imxipu:  imxipuvideosink: Freescale IPU video sink imxipu:  imxipuvideotransform: Freescale IPU video transform imxpxp:  imxpxpvideotransform: Freescale PxP video transform imxpxp:  imxpxpvideosink: Freescale PxP video sink imxipuvideosink: # gst-launch-1.0 videotestsrc ! imxipuvideosink imxg2dvideosink: # gst-launch-1.0 videotestsrc ! imxg2dvideosink The imxeglvivsink allows hardware accelerated display to a window on the X11 host # export DISPLAY=:0.0 # gst-launch-1.0 videotestsrc ! imxeglvivsink To test if you have graphics support you can run any glmark2 and/or mesa-utils or can run example of the next route: # cd /opt/viv_samples/vdk/ # ./tutorial1                                                                      //any example root@imx6Q:~# glxgears -info GL_RENDERER   = Vivante GC2000 GL_VERSION    = 2.1 2.0.1 GL_VENDOR     = Vivante Corporation GL_EXTENSIONS = WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_EXT_swap_control GL_EXT_texture_env_add GL_ARB_multitexture GL_ARB_multisample GL_ARB_texture_env_add GL_ARB_texture_compression GL_ARB_texture_env_combine GL_ARB_depth_texture GL_ARB_window_pos …. 1606 frames in 5.0 seconds = 321.130 FPS 1650 frames in 5.0 seconds = 329.834 FPS L_RENDERER   = Vivante GC2000 GL_VERSION    = 2.1 2.0.1 GL_VENDOR     = Vivante Corporation1629 frames in 5.0 seconds = 325.644 FPS 1621 frames in 5.0 seconds = 324.072 FPS 1650 frames in 5.0 seconds = 329.806 FPS 1651 frames in 5.0 seconds = 330.079 FPS
View full article
Introduction This is a sharing of my experience about porting the audio codec WM8960 in Linux BSP. I know this driver is not the perfect one.  If you find any place is not good in the driver, please let me know. This driver is modified base on the wm8960.c in L3.0.35 Linux BSP. This document is talking about how to modify the codec driver. The Audio Codec driver is located in linux/sound/soc/codec/wm8960.c. ALSA The Audio Codec driver is based on ALSA to setup up all the things. For details, please see : AlsaProject Advanced Linux Sound Architecture - Wikipedia, the free encyclopedia. kcontrols are defined in linux/include/sound/soc.h and soc-dapm.h. Audio controls and path in WM8960 Left and Right Input signal path Output signal path Base on the input and output signal diagrams, we can setup all the controls that we want in the driver. Such as switches, volume controls, PGA controls and so on. All the controls below can be used in the alsamixer. static const struct snd_kcontrol_new wm8960_snd_controls[] = { SOC_DOUBLE_R_TLV("PCM DAC Playback Volume", WM8960_LDAC, WM8960_RDAC, 0, 255, 0, dac_tlv), //LDACVOL , RDACVOL SOC_DOUBLE_R_TLV("PCM ADC Capture Volume", WM8960_LADC, WM8960_RADC, 0, 255, 0, adc_tlv), //LADCVOL, RADCVOL SOC_DOUBLE_R_TLV("Headphone Volume", WM8960_LOUT1, WM8960_ROUT1, 0, 127, 0, out_tlv), SOC_DOUBLE_R("Headphone ZC Switch", WM8960_LOUT1, WM8960_ROUT1,    7, 1, 0), SOC_DOUBLE_R_TLV("Speaker Volume", WM8960_LOUT2, WM8960_ROUT2, 0, 127, 0, out_tlv), SOC_DOUBLE_R("Speaker ZC Switch", WM8960_LOUT2, WM8960_ROUT2, 7, 1, 0), SOC_DOUBLE_R("Capture Volume ZC Switch", WM8960_LINVOL, WM8960_RINVOL, 6, 1, 0), SOC_SINGLE_TLV("Input Volume of LINPUT1", WM8960_LINVOL, 0, 63, 0, in_tlv),  //LINVOL SOC_SINGLE_TLV("Input Volume of RINPUT1", WM8960_RINVOL, 0, 63, 0, in_tlv),  //RINVOL SOC_SINGLE_TLV("Input Boost Volume LINPUT3", WM8960_INBMIX1, 4, 7, 0, boost_tlv),    //RIN3BOOST SOC_SINGLE_TLV("Input Boost Volume LINPUT2", WM8960_INBMIX1, 1, 7, 0, boost_tlv),    //RIN2BOOST SOC_SINGLE_TLV("Input Boost Volume RINPUT3", WM8960_INBMIX2, 4, 7, 0, boost_tlv),    //LIN3BOOST SOC_SINGLE_TLV("Input Boost Volume RINPUT2", WM8960_INBMIX2, 1, 7, 0, boost_tlv),    //LIN2BOOST SOC_SINGLE_TLV("PGA LB2LOVOL-Bypass from Left Boost", WM8960_BYPASS1, 4, 7, 1, bypass_tlv),    //LB2LOVOL SOC_SINGLE_TLV("PGA LI2LOVOL-Bypass from LINPUT3", WM8960_LOUTMIX, 4, 7, 1, bypass_tlv),    //LI2LOVOL SOC_SINGLE_TLV("PGA RB2ROVOL-Bypass from Right Boost", WM8960_BYPASS2, 4, 7, 1, bypass_tlv),    //RB2ROVOL SOC_SINGLE_TLV("PGA RI2ROVOL-Bypass from RINPUT3", WM8960_ROUTMIX, 4, 7, 1, bypass_tlv),    //RI2ROVOL SOC_SINGLE("Capture Mute (Left)", WM8960_LINVOL, 7, 1, 0), // LINMUTE SOC_SINGLE("Capture Mute (Right)", WM8960_RINVOL, 7, 1, 0), // RINMUTE SOC_SINGLE("PCM Playback -6dB Switch", WM8960_DACCTL1, 7, 1, 0), SOC_SINGLE("Speaker DC gain", WM8960_CLASSD3, 3, 5, 0), SOC_SINGLE("Speaker AC gain", WM8960_CLASSD3, 0, 5, 0), SOC_ENUM("ADC Polarity", wm8960_enum[0]), SOC_SINGLE("ADC High Pass Filter Switch", WM8960_DACCTL1, 0, 1, 0), SOC_ENUM("DAC Polarity", wm8960_enum[2]), SOC_SINGLE_BOOL_EXT("DAC Deemphasis Switch", 0, wm8960_get_deemph, wm8960_put_deemph), SOC_ENUM("3D Filter Upper Cut-Off", wm8960_enum[2]), SOC_ENUM("3D Filter Lower Cut-Off", wm8960_enum[3]), SOC_SINGLE("3D Depth", WM8960_3D, 1, 15, 0), SOC_SINGLE("3D", WM8960_3D, 0, 1, 0), SOC_ENUM("ALC Function", wm8960_enum[4]), SOC_SINGLE("ALC Max Gain", WM8960_ALC1, 4, 7, 0), SOC_SINGLE("ALC Target", WM8960_ALC1, 0, 15, 1), SOC_SINGLE("ALC Min Gain", WM8960_ALC2, 4, 7, 0), SOC_SINGLE("ALC Hold Time", WM8960_ALC2, 0, 15, 0), SOC_ENUM("ALC Mode", wm8960_enum[5]), SOC_SINGLE("ALC Decay", WM8960_ALC3, 4, 15, 0), SOC_SINGLE("ALC Attack", WM8960_ALC3, 0, 15, 0), SOC_SINGLE("Noise Gate Threshold", WM8960_NOISEG, 3, 31, 0), SOC_SINGLE("Noise Gate Switch", WM8960_NOISEG, 0, 1, 0), SOC_ENUM("Capture Left Boost", wm8960_enum[6]), //LMICBOOST SOC_ENUM("Capture Right Boost", wm8960_enum[7]), //RMICBOOT }; 1. SOC_SINGLE(xname, reg, shift, max, invert) To setup a simple switch, we can use SOC_SINGLE. e.g SOC_SINGLE("PCM Playback -6dB Switch", WM8960_DACCTL1, 7, 1, 0), - The name of this control is “PCM Playback -6dB Switch”. - The register in WM8960 is WM8960_DACCTL1 . (the register address is 0x5, defined in wm8960.h) - ‘7’ : The 7th bit in DACCTL1 register is used to enable/disable the DAC 6dB Attenuate. - ‘1’ : Only one enable or disable option. - ‘0’ : the value you set is not inverted. 2. SOC_SINGLE_TLV(xname, reg, shift, max, invert, tlv_array) To setup a switch with levels, we can use SOC_SINGLE_TLV. e.g. In this example, the left input volume control is from 000000(-17.25dB) to 111111(+30dB). Each step is 0.75dB. Total is 63 steps. SOC_SINGLE_TLV("Input Volume of LINPUT1", WM8960_LINVOL, 0, 63, 0, in_tlv), The scale of in_tlv declare like this: static const DECLARE_TLV_DB_SCALE(in_tlv, -1725, 75, 0); in_tlv : the name of the scale. -1725 : start from -17.25dB 75: each step is 0.75dB 0: the step is start from 0. For some volume control case the first step is "mute", then the step is start from 1 so change this number to 1. for example: The 0000 0000 of the DAC volume control is digital mute. static const DECLARE_TLV_DB_SCALE(dac_tlv, -12700, 50, 1); 3. SOC_DOUBLE_R(xname, reg_left, reg_right, xshift, xmax, xinvert) SOC_DOUBLE_R is a stereo version of SOC_SINGLE. You can control the left and right channel at the same time. e.g. SOC_DOUBLE_R("Headphone ZC Switch", WM8960_LOUT1, WM8960_ROUT1, 7, 1, 0), 4. SOC_DOUBLE_R_TLV(xname, reg_left, reg_right, xshift, xmax, xinvert, tlv_array) SOC_DOUBLE_R_TLV is the stereo version of SOC_SINGLE_TLV. e.g. SOC_DOUBLE_R_TLV("PCM DAC Playback Volume", WM8960_LDAC, WM8960_RDAC, 0, 255, 0, dac_tlv), 5. SOC_ENUM_SINGLE(xreg, xshift, xmax, xtexts) When the control option are some texts, we can use SOC_ENUM to enum the options. e.g. MIC boost 5.1. setup the array for the texts. static const char *wm8960_micboost[] = {"0dB","+13dB","+20dB","+29dB"}; 5.2. use the SOC_ENUM_SINGLE. static const struct soc_enum wm8960_enum[] = {      SOC_ENUM_SINGLE(WM8960_DACCTL1, 5, 4, wm8960_polarity),      SOC_ENUM_SINGLE(WM8960_DACCTL2, 5, 4, wm8960_polarity),      SOC_ENUM_SINGLE(WM8960_3D, 6, 2, wm8960_3d_upper_cutoff),      SOC_ENUM_SINGLE(WM8960_3D, 5, 2, wm8960_3d_lower_cutoff),      SOC_ENUM_SINGLE(WM8960_ALC1, 7, 4, wm8960_alcfunc),      SOC_ENUM_SINGLE(WM8960_ALC3, 8, 2, wm8960_alcmode),      SOC_ENUM_SINGLE(WM8960_LINPATH, 4, 4, wm8960_micboost),      SOC_ENUM_SINGLE(WM8960_RINPATH, 4, 4, wm8960_micboost), }; 5.3.  use SOC_ENUM to add the controls for MIC boost. SOC_ENUM("Capture Left Boost", wm8960_enum[6]), SOC_ENUM("Capture Right Boost", wm8960_enum[7]), After created all the controls, we can start to create the switches. The following switches created base on the input and output diagrams. I used the same name from datasheet of each switch. It will more easy to find out the proper switch in alsamixer. static const struct snd_kcontrol_new wm8960_lin[] = { SOC_DAPM_SINGLE("<- LMP2", WM8960_LINPATH, 6, 1, 0), //LMP2 SOC_DAPM_SINGLE("<- LMP3", WM8960_LINPATH, 7, 1, 0), //LMP3 SOC_DAPM_SINGLE("<- LMN1", WM8960_LINPATH, 8, 1, 0), //LMN1 }; static const struct snd_kcontrol_new wm8960_lin_boost[] = { SOC_DAPM_SINGLE("<- LMIC2B", WM8960_LINPATH, 3, 1, 0), //LMIC2B }; static const struct snd_kcontrol_new wm8960_rin[] = { SOC_DAPM_SINGLE("<- RMP2", WM8960_RINPATH, 6, 1, 0), //RMP2 SOC_DAPM_SINGLE("<- RMP3", WM8960_RINPATH, 7, 1, 0), //RMP3 SOC_DAPM_SINGLE("<- RMN1", WM8960_RINPATH, 8, 1, 0), //RMN1 }; static const struct snd_kcontrol_new wm8960_rin_boost[] = { SOC_DAPM_SINGLE("<- RMIC2B", WM8960_RINPATH, 3, 1, 0), //RMIC2B }; static const struct snd_kcontrol_new wm8960_loutput_mixer[] = { SOC_DAPM_SINGLE("<- LD2LO", WM8960_LOUTMIX, 8, 1, 0), //LD2LO SOC_DAPM_SINGLE("<- LI2LO", WM8960_LOUTMIX, 7, 1, 0), //LI2LO SOC_DAPM_SINGLE("<- LB2LO", WM8960_BYPASS1, 7, 1, 0), //LB2LO }; static const struct snd_kcontrol_new wm8960_routput_mixer[] = { SOC_DAPM_SINGLE("<- RD2RO", WM8960_ROUTMIX, 8, 1, 0), //RD2RO SOC_DAPM_SINGLE("<- RI2RO", WM8960_ROUTMIX, 7, 1, 0), //RI2RO SOC_DAPM_SINGLE("<- RB2RO", WM8960_BYPASS2, 7, 1, 0), //RB2RO }; static const struct snd_kcontrol_new wm8960_mono_out[] = { SOC_DAPM_SINGLE("<- L2MO", WM8960_MONOMIX1, 7, 1, 0), //L2MO SOC_DAPM_SINGLE("<- R2MO", WM8960_MONOMIX2, 7, 1, 0), //R2MO }; Then, create the inputs, ADC, DAC, mixers, PGA and outputs. static const struct snd_soc_dapm_widget wm8960_dapm_widgets[] = { SND_SOC_DAPM_INPUT("LINPUT1"), SND_SOC_DAPM_INPUT("RINPUT1"), SND_SOC_DAPM_INPUT("LINPUT2"), SND_SOC_DAPM_INPUT("RINPUT2"), SND_SOC_DAPM_INPUT("LINPUT3"), SND_SOC_DAPM_INPUT("RINPUT3"), SND_SOC_DAPM_MICBIAS("MICB", WM8960_POWER1, 1, 0), SND_SOC_DAPM_MIXER("Left Boost Mixer", WM8960_POWER1, 5, 0, wm8960_lin_boost, ARRAY_SIZE(wm8960_lin_boost)), SND_SOC_DAPM_MIXER("Right Boost Mixer", WM8960_POWER1, 4, 0, wm8960_rin_boost, ARRAY_SIZE(wm8960_rin_boost)), SND_SOC_DAPM_MIXER("Left Input PGA", WM8960_POWER3, 5, 0, wm8960_lin, ARRAY_SIZE(wm8960_lin)), SND_SOC_DAPM_MIXER("Right Input PGA", WM8960_POWER3, 4, 0, wm8960_rin, ARRAY_SIZE(wm8960_rin)), SND_SOC_DAPM_ADC("Left ADC", "Capture", WM8960_POWER1, 3, 0), SND_SOC_DAPM_ADC("Right ADC", "Capture", WM8960_POWER1, 2, 0), SND_SOC_DAPM_DAC("Left DAC", "Playback", WM8960_POWER2, 8, 0), SND_SOC_DAPM_DAC("Right DAC", "Playback", WM8960_POWER2, 7, 0), SND_SOC_DAPM_MIXER("Left Output Mixer", WM8960_POWER3, 3, 0, wm8960_loutput_mixer, ARRAY_SIZE(wm8960_loutput_mixer)), SND_SOC_DAPM_MIXER("Right Output Mixer", WM8960_POWER3, 2, 0, wm8960_routput_mixer, ARRAY_SIZE(wm8960_routput_mixer)), SND_SOC_DAPM_PGA("Left HP PGA", WM8960_POWER2, 6, 0, NULL, 0), SND_SOC_DAPM_PGA("Right HP PGA", WM8960_POWER2, 5, 0, NULL, 0), SND_SOC_DAPM_PGA("Left Speaker PGA", WM8960_POWER2, 4, 0, NULL, 0), SND_SOC_DAPM_PGA("Right Speaker PGA", WM8960_POWER2, 3, 0, NULL, 0), SND_SOC_DAPM_PGA("Right Speaker Output", WM8960_CLASSD1, 7, 0, NULL, 0), //SPK_OP_EN SND_SOC_DAPM_PGA("Left Speaker Output", WM8960_CLASSD1, 6, 0, NULL, 0), SND_SOC_DAPM_OUTPUT("SPK_LP"), SND_SOC_DAPM_OUTPUT("SPK_LN"), SND_SOC_DAPM_OUTPUT("HP_L"), SND_SOC_DAPM_OUTPUT("HP_R"), SND_SOC_DAPM_OUTPUT("SPK_RP"), SND_SOC_DAPM_OUTPUT("SPK_RN"), SND_SOC_DAPM_OUTPUT("OUT3"), }; Now, we can start to route the audio path. The path is from right to left , like : { “destination”, “switch”, “source” } So, lets take the LINPUT1 to ADC as an example: { "Left Input PGA", "<- LMN1", "LINPUT1" }, { "Left Boost Mixer", "<- LMIC2B", "Left Input PGA" }, { "Left ADC", NULL, "Left Boost Mixer" }, Another example is DAC to Headphone.                 { "Left Output Mixer", "<- LD2LO", "Left DAC" },                 { "Right Output Mixer", "<- RD2RO", "Right DAC" },                 { "Left HP PGA", NULL, "Left Output Mixer" },                 { "Right HP PGA", NULL, "Right Output Mixer" },                 { "HP_L", NULL, "Left HP PGA" },                 { "HP_R", NULL, "Right HP PGA" }, In linux, you can run "alsamixer" to turn on/off the switches and adjust the volumes. (this picture is an example of alsamixer of other codec, not for wm8960) In alsamixer, use 'M' to turn the switch on/off,  use arrow keys to control the volumes. wm8960_dai_ops is another important part in the driver. Here is the ops of the wm8960_dai. static struct snd_soc_dai_ops wm8960_dai_ops = {                 .hw_params = wm8960_hw_params,                 .digital_mute = wm8960_mute,                 .set_fmt = wm8960_set_dai_fmt,                 .set_clkdiv = wm8960_set_dai_clkdiv,                 .set_pll = wm8960_set_dai_pll, }; wm8960_hw_params : used to set the PCM format (16bit/24bit), set the deemph, alc_rates and etc. wm8960_mute:  used to mute the output wm8960_set_dai_fmt : used to set the Master/Slave mode, set the interface format (I2S, DSP, Left justified and Right justified) and set the clock inversion. wm8960_set_dai_clkdiv: used to set the CLK divider such as DACDIV, ADCDIV, BCLKDIV and so on. wm8960_set_dai_pll: used to calculate the proper PLL values. In the wm8960_set_dai_pll, we need to calculate the proper PLL values. Base on the table, if the MCLK >14.4, the sysclk prescale divider is 2. So, set the sysclk pre-divider to 2 before finding pll_factors. if (freq_in > 15000000 ) {                                 /* update sysclk div */                                 reg = snd_soc_read(codec, WM8960_CLOCK1) & 0x1f9;                                 snd_soc_write(codec, WM8960_CLOCK1, reg | 0x4);                                 clk_in = clk_in/2;                                 }                 if (freq_in && freq_out) {                                 ret = pll_factors(clk_in, freq_out, &pll_div);                                 if (ret != 0)                                                 return ret;                 } In the driver, there are two names are important. One is the name of codec dai. The name is “wm8960”. Make sure this codec dai name is the same codec dai name used in the imx-wm8960.c. static struct snd_soc_dai_driver wm8960_dai = {                 .name = "wm8960",                 .playback = {                                 .stream_name = "Playback",                                 .channels_min = 1,                                 .channels_max = 2,                                 .rates = WM8960_RATES,                                 .formats = WM8960_FORMATS,},                 .capture = {                                 .stream_name = "Capture",                                 .channels_min = 1,                                 .channels_max = 2,                                 .rates = WM8960_RATES,                                 .formats = WM8960_FORMATS,},                 .ops = &wm8960_dai_ops,                 .symmetric_rates = 1, }; Another name is the I2C device id. Make sure the I2C name is same as the name used in your_board.c file. static const struct i2c_device_id wm8960_i2c_id[] = {                 { "wm8960", 0 },                 { } }; MODULE_DEVICE_TABLE(i2c, wm8960_i2c_id); static struct i2c_driver wm8960_i2c_driver = {                 .driver = {                                 .name = "wm8960",                                 .owner = THIS_MODULE,                 },                 .probe =    wm8960_i2c_probe,                 .remove =   __devexit_p(wm8960_i2c_remove),                 .id_table = wm8960_i2c_id, }; Here is the name used in your_board.c static struct i2c_board_info mxc_i2c0_board_info[] __initdata = {     {         I2C_BOARD_INFO("wm8960", 0x1a),     }, } Machine driver imx-wm8960.c Basically, the machine driver is the connection between wm8960.c and the i.MX. It is modified base on the imx-wm8962.c. I didn't add the HP and MIC detection in this driver. If you need the HP and MIC detection, please take the imx-wm8962.c for reference. Here is an example of my_board.c. The following platform data pass to the machine driver from my board. static struct platform_device audio_wm8960_device = {     .name = "imx-wm8960", }; static struct mxc_audio_platform_data wm8960_pdata; static int wm8960_clk_enable(int enable) {     if (enable)         clk_enable(clko);     else         clk_disable(clko);     return 0; } static int mxc_wm8960_init(void) {     int rate;     clko = clk_get(NULL, "clko_clk");     if (IS_ERR(clko)) {         pr_err("can't get CLKO clock.\n");         return PTR_ERR(clko);     }     /* both audio codec and comera use CLKO clk*/     rate = clk_round_rate(clko, 24000000);     clk_set_rate(clko, rate);     wm8960_pdata.sysclk = rate;     return 0; } static struct mxc_audio_platform_data wm8960_pdata = {     .ssi_num = 1,     .src_port = 2,     .ext_port = 3,     .init = mxc_wm8960_init,     .clock_enable = wm8960_clk_enable, }; I attach the driver and the machine driver here. I hope this document is useful for you.
View full article
Building using Yocto 1 - Baking (building) the kernel When an image is built using Yocto (for more details about how to build an image, check the Yocto training home: https://community.nxp.com/docs/DOC-94849) the kernel is automatically built and the kernel image is located at /fsl-community-bsp/build/tmp/deploy/images/<your_target>/uImage If you want to build only the kernel, the following command can be used: $ bitbake linux-imx     2 - Configuring the kernel To call the kernel menuconfig, run the command: $ bitbake -c menuconfig linux-imx    A new terminal window will open with the kernel menuconfig. Make changes if needed, exit the configmenu and copy the .config generated file to defconfig as following: $ cp tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r33.10/git/.config ../sources/meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6/defconfig    Note that the kernel version, in this case "3.0.35-r33.10" may change. 3 - Cleaning and building again with the new configuration With the new defconfig saved on the correct folder (step 2), it's time to clear all previous kernel and build it again: $ bitbake -c cleansstate linux-imx $ bitbake <your_image>       or         $ bitbake linux-imx    The uImage will be under tmp/deploy/image Building without a BSP 1- Downloading the kernel source code Choose what kernel you will build. Usually, the NXP kernel or mainline (kernel.org) kernel: For NXP kernel (more details on https://source.codeaurora.org/external/imx/linux-imx/ ) use: $ git clone https://source.codeaurora.org/external/imx/linux-imx                 For Mainline kernel (more details on https://www.kernel.org/ ) use: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git                2 - Choose which branch will you use Once downloaded, check the available branches by using: $ git branch -a   master   remotes/origin/HEAD -> origin/master   remotes/origin/imx_4.9.123_imx8mm_ga   remotes/origin/imx_4.9.51_imx8_beta1   remotes/origin/imx_4.9.51_imx8_beta2   remotes/origin/imx_4.9.51_imx8m_beta   remotes/origin/imx_4.9.51_imx8m_ga   remotes/origin/imx_4.9.88_2.0.0_ga   remotes/origin/imx_4.9.88_imx8mm_alpha   remotes/origin/imx_4.9.88_imx8qxp_beta2   remotes/origin/master Make a local branch, based on a branch you choose from the list: $ git checkout -b local_branch origin/imx_4.9.88_2.0.0_ga *NOTES:      On command above my local branch name is "local_branch". You can choose this name as you prefer                     The chosen branch was origin/imx_4.9.88_2.0.0_ga. You can choose another one, always starting by origin/....... 3 - Setting the environment variables 3.1 - Using Yocto Toolchain If you're using the Yocto SDK (Check the Yocto training at NXP community: https://community.nxp.com/docs/DOC-94849 ), just execute the script to export the needed environment variables, e.g.: $ source /opt/poky/1.6+snapshot/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi  $ unset LDFLAGS      If you're using another toolchain, the common environment variables to set are the following: $ export PATH=$PATH:/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/ $ export TOOLCHAIN=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/ $ export CROSS_COMPILE=arm-none-linux-gnueabi- $ export ARCH=arm IMPORTANT: Change the variables above according your installed toolchain. 3.2 - Using Ubuntu Toolchain For 64-bits processors (i.MX8 family) Install the GCC toolchain for 64 bits: sudo apt-get install gcc-aarch64-linux-gnu Export the environment variables: $ export ARCH=arm64 $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- For 32-bits processors (i.MX2, i.MX3, i.MX5 and i.MX6 families) Install the GCC toolchain for 32 bits: sudo apt-get install gcc-arm-linux-gnueabi Export the environment variables: export ARCH=arm export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- 4 - Configuring the kernel If you're building for i.MX6 and i.MX5, configure the kernel options based on file imx_v7_defconfig: $ cp arch/arm/configs/imx_v7_defconfig .config $ make menuconfig  $ make If you're building for i.MX8 family, configure the kernel options based on file arm64/defconfig:       $ cp arch/arm64/configs/defconfig .config       $ make menuconfig       $ make 5 - Building the modules After step 4, only the kernel (uImage file) was generated. The kernel modules must be built and installed in a known path. First, build the modules: $ make modules             And install them: $ make modules_install INSTALL_MOD_PATH=/path_where_you_want_to_install            
View full article
The original implementation is from Frias Renato for Sabreauto board. How to define the booting time? The booting time we defined here is from the board be powered up to the main application working and main application be showed directly to the end user, for example: for the media play purpose board, the booting time count to the first video frame be shown on the screen. For minimizing the booting time, some methods be tried. Optimizing for performance. Remove unnecessary modules at boot time. Start main application at the first time after the kernel be boot up. Optimizing for performance: U-Boot:   1:Enable MMU and L2-Cache.   2:Optimizing memset and memcpy.   3:Implementation of SDMA, accelerate copying data from NOR flash to memory.   4:Implementation of uSDHC’s ADMA, improve performance for SD card read. Kernel:   1:Optimizing _memcpy_fromio function at  arch/arm/kernel/io.c Remove unnecessary modules: U-Boot:   1: Disable uart output at u-boot procedure and add quiet parameter to Kernel boot.   2: Remove boot up delay at u-boot.   3: Disable I2C, SPI, SPLASH_SCREEN at u-boot. Kernel: Below removing unnecessary modules just for Sabresd board boot up through SD card and MIPI camera overlay on LVDS screen application, for other special board and special board usage application please don’t use below directly.   1: Modify arch/arm/mach-mx6/board-mx6q_sabresd.c just keep necessary module initialization at  mx6_sabresd_board_init : iomux configuration, uart0, voda, ipu, ldb, v4l2, mipi-csi, i2c1, uSDHC1, pwm0, dvfs, mipi camera clock.   2: Update Linux kernel configuration file. Try to just keep necessary module and configuration to keep minim size. Build necessary modules from external to Kernel itself. Create uImage from Image instead of zImage to reduce Kernel self extraction time. Use ext4 file system on SD card to accelerate rootfs mounting.    Notice: Kernel configuration remove NETWORK support, it includes Unix Domain Socket, the udev mechanism need it, so this kernel configuration can't support rootfs udev dynamic /dev/ nodes and all /dev/ nodes must be created before boot up at rootfs. Start main application at the first time after the kernel boots up. As normal boot up procedure, the init process will handle sysinit script firstly, this script will do some initialization and preparation for most of the user process, But this script normally will be executed for about 1~5 seconds, so now try do main application before the sysinit, while the necessary preparation of main application will be handle by this application internally. See below example for MIPI camera overly on LVDS screen: /etc/inittab ::once:/unit_tests/mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -ot 0 -ol 0 -r 0 -t -1 -d 0 -fg -fr 30 ::once:/etc/rc.d/rcS ::once:/sbin/getty -L ttymxc0 115200 vt100 # GENERIC_SERIAL Test result of fast boot on Sabresd board for MIPI camera overly on LVDS screen: The main application be executed from the board be powered up is about 958ms.    Running Bootloader [0.356417 0.356417] [ 0.046637] _regulator_get: get() with no identifier [ 0.958425  0.602008] starting pid 21, tty '': '/unit_tests/mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -ot 0 -ol 0 -r 0 -t -^@ [0.969609 0.011184] starting pid 22, tty '': '/etc/rc.d/rcS' [0.973368 0.003759] g_display_width = 1024, g_display_height = 768 [0.977540 0.004172] g_display_top = 0, g_display_left = 0 [0.980927 0.003387] starting pid 23, tty '': '/sbin/getty -L ttymxc0 115200 vt100 ' [1.048454 0.067527] Mounting /proc and /sys [1.089526 0.041072] Setting the hostname to freescale [1.116635 0.027109] Mounting filesystems [1.527320 0.410685] sensor chip is ov5640_mipi_camera [1.530627 0.003307] sensor frame size is 640x480 [1.533482 0.002855] sensor frame format is UYVY [1.640221 0.106739] frame_rate is 30 [1.642249 0.002028] [1.642270 0.000021] frame buffer width 0, height 0, bytesperline 0 [1.989728 0.347458] [1.990761 0.001033] arm-none-linux-gnueabi-gcc (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) 4.6.2 20110630 (prerelease) [2.001161 0.010400] root filesystem built on Tue, 11 Sep 2012 11:43:24 +0800 [2.006249 0.005088] Freescale Semiconductor, Inc. [2.009394 0.003145] [2.009531 0.000137] freescale login: Please see below fast boot video. I also attached sample code for U-boot and kernel for your reference. Patch code based on L3.0.35_12.09.01_GA.
View full article
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  
View full article
Understanding and using the .sdcard format One very useful feature enabled by default in both the Yocto Communiy BSP and Release BSP is the option of generating the baked images in .sdcard format. If the .sdcard format is not selected by default it can be enabled on the conf/local.conf file by adding it with the IMAGE_FSTYPES as follow: IMAGE_FSTYPES="sdcard" It’s important to note that if this variable is specified only the file systems typed defined will be created. The default value used most often for this variable is: IMAGE_FSTYPES="tar.bz2 ext3 sdcard" The .sdcard format creates an image with all necessary partitions and loads the bootloader, kernel and rootfs to this image. You can just low level copy the data on this file to the SD card device using dd as on the following command example: $ sudo dd if=<image name>.sdcard of=/dev/sd<partition> bs=1M && sync Partitions used on the .sdcard file The .sdcard partitions looks as follow: IMAGE_ROOTFS_ALIGNMENT Unpartitioned space reserved for the bootloader BOOT_SPACE Kernerl and other data ROOTFS_SIZE The rootfs. Granting more free space on the RootFS partition The size of the .sdcard file will depend solely on the size of the rootfs. This means that the resulting file won’t partition all our SD Card capacity unless we add extra space to the rootfs partition. (Of course there is always the option of editing the partitions once loaded on the SD Card) In order to add more space you may use the IMAGE_ROOTFS_EXTRA_SPACE variable. You may add it to your local.conf file with the added free disk space in Kbytes. For example, if you would like to guarantee 1GB of extra space you may add the following line to your local.conf file. IMAGE_ROOTFS_EXTRA_SPACE = "1048576" It is important to note that this is space additional to the IMAGE_OVERHEAD_FACTOR variable which defines a multiplier that is applied to the initial image size. This is only applied when the multiplier times the By default, the build process uses a multiplier of 1.3 for this variable. This default value results in 30% free disk space added to the image when this method is used to determine the final generated image size. This would mean that there should be 30% of free disk space before post install scripts. If you wish for more space you may edit this variable as bellow: IMAGE_OVERHEAD_FACTOR = "1.5" Which would result in 50% free disk space added to the image, before post install scripts and without considering overhead that may come from the package management system. How the IMAGE_ROOTFS_SIZE is calculated This variable is also measured in Kbytes and it’s determined by the OpenEmbedded build system using an algorithm that considers the initial disk space used for the generated image, the requested size for the image (trough the overhead factor) and the additional free space to be added to the image (trough the extra space variable). The build system first runs a du (disk usage) command to determine the size of the rootfs directory tree. If the IMAGE_ROOTFS_SIZE current value is larger than the disk usage times the overhead factor only the extra space is added. If the IMAGE_ROOTFS_SIZE is smaller than the disk usage times the overhead factor then the disk usage is multiplied times the overhead factor prior to adding the extra space. IMAGE_ROOTFS_SIZE must be set on a default value which is usually very low as it’s just initialized and updated with the actual size requirements each time an image is baked. You may also use this variable directly in order to select the space you would like to allocate to the RootFS.For example setting the RootFS to 2GB would require the following addition to the local.conf file: IMAGE_ROOTFS_SIZE = “2097152” IMAGE_OVERHEAD_FACTOR = “1.0” In this example we would leave the overhead factor to 1 so no extra space is added since we’re specifying the rootfs size that we want.
View full article
The Guide is how to use Ubuntu filesystem with i.MX8 series platform.At present, I had try it on i.MX8QXP with 4.14.98 kernel with ubuntu16.04. The Document will be continuously updated with enable VPU, ubuntu18.04. The desktop we can chose Gnome or weston.  Because driver  support issue, gc7000 series gpu not support render Gnome destop but it can render weston destop.  Update 2019/7/31: Ubuntu-i.MX8-weston.pdf   Feature: weston + ubuntu18.04 + 4.14.98 kernel VPU (enable with gplay or gst-play)  GPU (could render desktop and run GPU demo under root privileges on Weston Desktop) I also try ubuntu with gnome desktop, ubuntu18.04 can not run gnome, need use ubuntu19.04. But Gnome Desktop just render by CPU.  ------------------------------------------------------------------------------------- Update 2020/3/6: Ubuntu-i.MX8M.pdf Just a simple guide for IMX8M series, will be  continuously updated. 
View full article
For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time.     The attached patch can make the BSP support up to 4 cameras based on 3.10.53 GA 1.1.0 BSP.   The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI   For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel.   In this patch, we given the example driver for Intersil ISL79985. The input to ISL79985 is four CVBS camera. There are four patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch      Updated IPU common code to support up to four cameras.   0002-Add-Intersil-ISL79985-MIPI-Video-Decoder-Driver-for-.patch      ISL79985 driver, which can support both 1 lanes and 2 lanes mode.   0003-Remove-the-page-size-align-requirement-for-v4l2-capt.patch      With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly.   0004-IPU-CSI-Drop-1-2-frame-on-MIPI-interface-for-interla.patch      This patch is option, it will drop one field data, so for each camera, the input will be 720*240 30 FPS.   For 720P HD solution, it is based on Maxim MAX9286: iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP   How to builld the kernel with ISL79985 support:       make imx_v7_defconfig       make menuconfig (In this command, you should select the ISL79985 driver:             Device Drivers  --->                   <*> Multimedia support  --->                         [*]   V4L platform devices  --->                               <*>   MXC Video For Linux Video Capture                                       MXC Camera/V4L2 PRP Features support  --->                                           <*>Intersil ISL79985 Video Decoder support                                           <*>mxc VADC support                                           <*>Select Overlay Rounting (Queue ipu device for overlay library)                                           <*>Pre-processor Encoder library                                           <*>IPU CSI Encoder library)       make zImage       make dtbs   The built out image file:       arch/arm/boot/dts/imx6q-sabresd.dtb       arch/arm/boot/zImage   "mxc_v4l2_tvin.zip" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   2015-10-10 Update: Updated the test application "mxc_v4l2_tvin_isl79985.tar.gz" to fix the Yocto build errors. Updated ISL79985 register setting "page5, isl79985_write_reg(0x07, 0x46)" in patch "0002-Add-Intersil-ISL79985-MIPI-Video-Decoder-Driver-for-.patch", which can fix the green line issue.   2016-01-25 Update: Added de-interlace support, L3.10.53_ISL79985_Surroundview_Patch_20160125.tar.gz New test capplication for de-interlance: mxc_v4l2_tvin_isl79985_vdi_20160125.tar.gz New test commands: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d -m & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d -m & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d -m & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d -m &   Note:  with the 0005-Add-interlaced-mode-capture-for-ISL79985.patch, the V4l2 capture driver will return 720x480 video size, but only odd lines have the video data, they are filled in line skip line mode.     2016-11-21 Update: Added ISL79987 support, L3.10.53_ISL7998x_Surroundview_Patch_20161121.zip New test capplication for de-interlance support: mxc_v4l2_tvin_isl7998x.tar.gz   Test commands (without de-interlace): /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   Test commands (with de-interlace, for ISL79987 only): /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -m 1 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -m 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -m 1 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -m 1 -g2d &     Now the same patch can support both ISL79985 and ISL79987, with NTSC CVBS camera, for ISL79985, it captures 60fps 720*240; for ISL79987, it captures 30fps 720*480.   2016-11-22 Update: Added patch for L4.1.15 BSP, it supports both ISL79985 and ISL79987, L4.1.15_ISL7998x_Surroundview_Patch_20161122.zip Test capplication mxc_v4l2_tvin_isl7998x.tar.gz is re-used.
View full article
Here is a quick summary at booting u-boot on the i.MX 6 sabre sd platform. This assumes you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). Get u-boot sources We will use git to fetch the U-Boot sources:   $ git clone git://git.denx.de/u-boot.git This should create a u-boot directory with all the latest sources. 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 'v2*', 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 u-boot   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make mx6qsabresd_config   $ make This should create a number of files, including u-boot.imx. Put on SD U-boot should reside at offset 1024B of your SD card. To put it there, do:   $ dd if=u-boot.imx of=/dev/<your-sd-card> bs=1k seek=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. 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, power up the platform and you should see something like:   U-Boot 2013.07-rc1-00014-g74771f4 (Jun 20 2013 - 19:05:09)   CPU:   Freescale i.MX6Q rev1.2 at 792 MHz   Reset cause: POR   Board: MX6Q-SabreSD   DRAM:  1 GiB   MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2   *** Warning - bad CRC, using default environment   In:    serial   Out:   serial   Err:   serial   Net:   FEC [PRIME]   Warning: FEC using MAC address from net device   Hit any key to stop autoboot:  0 Enjoy! See also... u-boot most common mission is to boot the Linux kernel. See this post for details on how to do it. If you plan to compile u-boot often, you might want to use a C compiler cache; see this post. Running a Script in U-boot u-boot on the Vybrid tower board in a few commands
View full article
i.MX6UL Hardware design checklist v0.1
View full article