Hi All I make fsl-image-qt5 in yocto. make command: $ MACHINE=imx6slevk source fsl-setup-release.sh -b build -e fb $ bitbake fsl-image-qt5 However, I couldn't make meta-toolchin-qt5 in yocto. The error is as follows. > | WARNING: exit code 1 from a shell command. > | ERROR: Function failed: do_configure (log file is located at /opt/yocto_build/yocto_fsl-bsp-imx6slevk/fsl-release-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtdeclarative/5.3.2-r0/temp/log.do_configure.3411) > ERROR: Task 771 (/opt/yocto_build/yocto_fsl-bsp-imx6slevk/fsl-release-bsp/sources/meta-qt5/recipes-qt/qt5/qtdeclarative_5.3.2.bb, do_configure) failed with exit code '1' > NOTE: Tasks Summary: Attempted 1235 tasks of which 1234 didn't need to be rerun and 1 failed. > No currently running tasks (1234 of 3376) > > Summary: 1 task failed: >   /opt/yocto_build/yocto_fsl-bsp-imx6slevk/fsl-release-bsp/sources/meta-qt5/recipes-qt/qt5/qtdeclarative_5.3.2.bb, do_configure > Summary: There was 1 ERROR message shown, returning a non-zero exit code. How do you make toolchain include Qt5?

Minicom       It's a simple terminal program, easy to configure and use. Can be downloaded and installed from your Linux package distribution (Synaptic, apt-get, yum) or through this link.       Minicom is a terminal emulation that can access a remote serial console enabling the configuration of Bootloader or the flash file system of the board.   Configuring       Run Minicom calling it from Terminal:     $ minicom       Reach the cofiguration by typing CTRL-A Z Press key Z after releasing CTRL and A. Configure Minicom to work with i.MX, follow the procedure below.   Set the Serial Port       At the screen configuration, type O, choosing Configure Minicom In menu, choose Serial Port Setup Below, the configuration option:       +-----------------------------------------------------------------------+ | A - Serial Device  : /dev/ttyS0                            | | B - Lockfile Location  : /var/lock                          | | C - Callin Program  :                                          | | D - Callout Program  :                                        | | E - Bps/Par/Bits  : 115200 8N1                          | | F - Hardware Flow Control : No                          | | G - Software Flow Control : No                            | |                                                                        | | Change which setting?                                      | +-----------------------------------------------------------------------+       Type the letter of option to enable the modification. Remember to choose the right Serial Device. Screen       Another useful program to use with serial ports is screen. It is a screen manager with VT100/ANSI terminal emulation usually available in Linux distributions. To open serial device /dev/ttyS0, for example, using 115200 baudrate, simply use:     $ screen /dev/ttyS0 115200       To kill the screen manager, use Ctrl + a, k. For a list of useful parameters and commands, try:     $ man screen

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343178 

Use the EPDC Unit Test to exercise your EPD panel 1.  Introduction The i.MX 6Solo/6DualLite and i.MX 6SoloLite processors contain an Electrophoretic Display Controller (EPDC) designed to drive E-INK(TM) EPD panels supporting a wide variety of TFT backplanes. Detailed information about the EPDC is available in the i.MX 6Solo/6DualLite and i.MX 6SoloLite Reference Manuals. Information about programming the EPDC and integrating support for a particular panel into the Linux BSP is provided in the Linux BSP Reference Manual. Now that you have your panel hardware and software integrated, how can you tell if it is all working? Or perhaps you're using a standard panel that doesn't seem to be working - how can you test it at the lowest level? The answer is the EDPC Unit Test. 2. Running the EPDC Unit Test Most i.MX processor hardware modules have an associated unit test in the unit_tests directory of the root file system image. The basics of running the EPDC unit test are simple. After logging in as root on the debug console, change to the unit tests directory and execute the test as follows: $ cd /unit_tests $ ./mxc_epdc_fb_test.out Without any arguments, the unit test runs thirteen individual tests and takes about 8 minutes to complete. You will get a lot of output on the panel and it may not be obvious that the images are displaying correctly. Running the unit test with no arguments is a nice automated way to make sure your panel is at least displaying something, and is not causing a crash or hang. But to really verify correctness each test should be run individually and the output carefully reviewed. This can be accomplished by passing a test number option as follows: $ ./mxc_epdc_fb_test.out -n 1 To show a list of all the available options, as well as a list of the individual test numbers, use the "-h" argument. The helpful output is shown below. $ ./mxc_epdc_fb_test.out -h EPDC framebuffer driver test program. Usage: mxc_epdc_fb_test [-h] [-a] [-p delay] [-u s/q/m] [-n ]         -h        Print this message         -a        Enabled animation waveforms for fast updates (tests 8-9)         -p        Provide a power down delay (in ms) for the EPDC driver                   0 - Immediate (default)                   -1 - Never                    ms - After ms milliseconds         -u        Select an update scheme                   s - Snapshot update scheme                   q - Queue update scheme                   m - Queue and merge update scheme (default)         -n        Execute the tests specified in expression                   Expression is a set of comma-separated numeric ranges                   If not specified, tests 1-13 are run Example: ./mxc_epdc_fb_test.out -n 1-3,5,7 EPDC tests: 1 - Basic Updates 2 - Rotation Updates 3 - Grayscale Framebuffer Updates 4 - Auto-waveform Selection Updates 5 - Panning Updates 6 - Overlay Updates 7 - Auto-Updates 8 - Animation Mode Updates 9 - Fast Updates 10 - Partial to Full Update Transitions 11 - Test Pixel Shifting Effect 12 - Colormap Updates 13 - Collision Test Mode 14 - Stress Test In addition to "-n" to run individual tests, the "-a" and "-u" options are provided to set animation mode and waveform used, respectively. These options make sense only for some of the individual tests, as noted in the next section. The "-u s" (snapshot) mode purposely does not allow pending updates, so some of the tests will cause the driver to issue the following warning in snapshot mode: imx_epdc_fb: No free intermediate buffers available. The "-p" (power down delay) option allows you to specify how soon the device driver automatically powers down the controller after all pending updates have completed. The default is 0 (zero), meaning power down immediately. Use "-1" to disable power down (i.e. never power down). Sidebar: You can use another unit test, "dump-clocks.sh", to view the state of the EPDC clocks (i.e. the power state of the module). In the example below, a "1" in the third column indicates that the clock is running; a "0" indicates the clock is gated: $ ./dump-clocks.sh | grep epdc epdc_pix_clk             pll5_video_main_clk       1   26666667 epdc_axi_clk             pll2_pfd2_400M             1  198000000 3.  Individual Test Details Important! The notes below assume you are running the version of the unit test binary in the tar file attached to this How-to. Please extract the file mxc_epdc_fb_tests.out from the tar file into your rootfs unit_tests directory before running the test. Most tests begin with a screen blank operation (all white pixels). Each test works with all three update schemes (snapshot, queue, queue and merge) unless otherwise noted. 3.1 Test 1: Basic Updates Draws the following patterns: Crosshatch Squares Text Ginger image Colorbar 3.2 Test 2: Rotation Updates Draws text, squares, crosshatch, and square outlines in all rotation modes: No rotation Clockwise (90 degrees) Upside down (180 degrees) Counterclockwise (270 degrees) The square outlines are drawn first in RGB format and then in Y8 format. 3.3 Test 3: Grayscale Framebuffer Updates Draws a top half black screen and then a colorbar, rotated clockwise. First draws in normal Y8 format and then in inverted Y8 format. 3.4 Test 4: Auto-waveform Selection Updates Draws several small squares using auto-waveform selection. Note: unlike the i.MX508 EPDC driver, the i.MX 6 driver does not report the final waveform selection to user-level applications. This test also verifies that squares at non-8-bit aligned pixels can be drawn. 3.5 Test 5: Panning Updates Draws a colorbar to an off-screen region. Draws the Ginger image to the frame buffer. Sets the focus (pan) to the colorbar, then updates portions of the screen. You should see the colorbar poke through. Slowly pans from Ginger to the entire colorbar. Use pan to flip between black and white buttons. Flashes buttons using pixel inversion. Flashes buttons using panning. 3.6 Test 6: Overlay Updates Switches between the frame buffer (FB) and the alternate (overlay) frame buffer as follows: Draws Ginger to the FB. Draws the colorbar to the alternate frame buffer. Shows the FB (Ginger). Shows the alternate FB (colorbar). Shows FB again (Ginger). Shows half FB, half alternate FB. Shows cutout region of alternate FB. Shows cutout in upper corner. Shows black screen. Shows clockwise-rotated text overlay in center. 3.7 Test 7: Auto-Updates Important! The auto-update mechanism must be enabled in the kernel configuration for this test to work. Enable it using the LTIB Kernel configuration menu item "Device Drivers->Graphics support->E-Ink Auto-update Mode Support." Also, please check the Linux BSP Release Notes for any issues with this feature. 3.8 Test 8: Animation Mode Updates Shows how normal (gray level) and monochrome (black and white) updates compare in appearance and performance. Quickly flashes back and forth between black and white screens. Draws normal squares. Draws black and white squares. Draws Ginger in gray scale and monochrome. Draws colorbar in gray scale and monochrome. Draws normal Y8 colorbar and monochrome colorbar. Draws inverted normal Y8 colorbar and inverted monochrome colorbar. You can run this test in animation mode using the "-a" command line option. Animation mode only updates monochrome pixels, so you will notice a drawing speed improvement. Also, you will see the implementation of one of the "rules" of using this mode: The screen must be blanked (all white or all black) when switching in and out of animation mode. 3.9 Test 9: Fast Updates Animates a square across the screen and down one side. This test can also be run in animation mode using "-a". See the animation mode notes in the Test 8 description above. 3.10 Test 10: Partial to Full Update Transitions Draws small gray squares using separate updates in partial update mode (only pixels that change are updated). Then re-draws the entire screen in one update using full update mode. In full update mode, you will notice the entire screen transition from black to the final grey value. 3.11 Test 11: Test Pixel Shifting Effect Draws a short, two pixel line and then sends two updates one pixel apart in distance and 5 seconds apart in time. Nothing much to see here; just verifies that a one pixel update shift works. 3.12 Test 12: Colormap Updates Creates a colormap and uses it to draw full screen blanks and to draw a color bar. In this test, you should follow along with the text printed in the debug console and verify each state: Screen should be black. Screen should be white now. Screen should still be white. Should be inverted color bar (white to black, left to right). Colorbar again, with no CMAP (black to white, left to right). Posterized colorbar. In the above output, "CMAP" means colormap and "Posterized colorbar" is a colorbar drawn from only black and white components. 3.13 Test 13: Collision Test Mode Draws two overlapping rectangles. Tests for collision on the first rectangle, which should result in the message: Collision test result = 0 Then draws the same overlapping rectangles, this time testing for collision on the second rectangle. The result should be: Collision test result = 1 Note: This test cannot be run using the snapshot scheme. If you try to use "-u s" it will print a message and return. 3.14 Test 14: Stress Test Draws thousands of random rectangles on the screen in different rotations. Runs for about 8 minutes. This test must be explicitly specified on the command line; it does not run by default. For example: $ ./mxc_epdc_fb_test.out -n 14 Note: This test cannot be run using the snapshot scheme. If you try to use "-u s" it will print a message and return. 4. Customizing A great way to know what's really going on in each test is to look at the source code. You may want to customize the source as well - say to add a new test that exercises some cool feature of your panel. Fortunately, the source is included in the BSP distribution so you can extract, customize, and rebuild it as needed. The magic of LTIB is beyond the scope of this article, but here are some hints: # Extract the unit test source from the imx-test package: $ ./ltib -m prep -p imx-test # Source is now in rpm/BUILD/imx-test-12.08.00/test/mxc_fb_test/mxc_epdc_fb_test.c (your package version number my be different). # Build from source: $ ./ltib -m scbuild -p imx-test # Deploy all unit test binaries to ltib rootfs directory: $ ./ltib -m scdeploy -p imx-test # Alternatively you can copy just the epdc unit test binary as follows: $ sudo cp rpm/BUILD/imx-test-12.08.00/platform/IMX6S/mxc_epdc_fb_test.out rootfs/unit_tests/ As noted in the Individual Test Details section, you should replace the file mxc_epdc_fb_test.c referenced above with the one found in the tar file attached to this How-to. 5. Something is wrong! Of course there are many things that can go wrong that are beyond the scope of this article, but assuming your hardware is working and the panel options are correctly configured in the BSP (again, beyond our scope), here are some things to check: Is the kernel configured correctly for EPDC support? Check that the following item is enabled in the LTIB Kernel configuration menu: "Device Drivers->Graphics support->E-Ink Panel Framebuffer." Are the U-boot kernel command line arguments set correctly for EPDC? For example, "video=mxcepdcfb:E060SCM consoleblank=0". The "consoleblank=0" command is useful to prevent entering low power suspend mode while you are testing. Does the "Tux" image display correctly on your panel after system boot? If so, the EPDC driver was a least able to perform the initial framebuffer update to your panel. Note: for Tux to display at boot, you need to disable LCDIF support at "Device Drivers->Graphics support->Support MXC ELCDIF framebuffer." Are there any EPDC-related error messages in the kernel log after boot? You can check with "dmesg | grep epdc".

(   converted from discussion created by Alfred Latypov   IMX6 PCI with external cloks  )    Hello, I had a problem, to launch a board with an imx6 solo processor with a pci-express, and with external clock. I'll tell you my decision. On my motherboard there is a pci-switch PI7C9X2G606 from Pericom with 4 endpoints of Intel type 82574 ethernet controller. I used the Linux kernel version 4.9.16 In the device-tree file, I used the following options to enable external clocks for CLK1 input gate (100MHz). Sorry, I had to change the root imx6 device tree file. See attached (imx6*.dtsi) files. From ..kernel/arch/arm/boot/dts/.. Add anatop external clock source for clocks section, and change clk source for pcie-phy. ... anaclk1 {             compatible = "fixed-clock";             reg = <0>;             #clock-cells = <0>;             clock-frequency = <100000000>;  /* 100MHz */         }; ... Change pcie section ...         pcie: pcie@0x01000000 {             compatible = "fsl,imx6q-pcie", "snps,dw-pcie";             reg = <0x01ffc000 0x04000>,                   <0x01f00000 0x80000>;             reg-names = "dbi", "config";             #address-cells = <3>;             #size-cells = <2>;             device_type = "pci";             ranges = <0x81000000 0 0          0x01e00000 0 0x00100000 /* downstream I/O */                   0x82000000 0 0x01000000 0x01000000 0 0x00e00000>; /* non-prefetchable memory */             /* ranges = <0x81000000 0 0          0x01f80000 0 0x00010000                   0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; */             num-lanes = <1>;             interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;             interrupt-names = "msi";             #interrupt-cells = <1>;             interrupt-map-mask = <0 0 0 0x7>;             interrupt-map = <0 0 0 1 &gpc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,                             <0 0 0 2 &gpc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,                             <0 0 0 3 &gpc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,                             <0 0 0 4 &gpc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;             clocks = <&clks IMX6QDL_CLK_PCIE_AXI>,                  <&clks IMX6QDL_CLK_LVDS1_IN>,                  <&clks IMX6QDL_CLK_SATA_REF_100M>;             clock-names = "pcie", "pcie_bus", "pcie_phy";             status = "disabled";         }; ... and add new source clocks dependencies: .... &clks {         assigned-clocks = <&clks IMX6QDL_PLL6_BYPASS_SRC>,                           <&clks IMX6QDL_PLL6_BYPASS>;                                   assigned-clock-parents = <&clks IMX6QDL_CLK_LVDS1_IN>,                                  <&clks IMX6QDL_PLL6_BYPASS_SRC>;         assigned-clock-rates = <100000000>, <100000000>; }; .... for your board dtsi. I could not start the pcie-bus with the function Gen2. Next, I needed to change the bus driver (pci-imx6.c), for fine tuning the bus clock frequency. I add MPLL frequency services functions (Thanks for Charle Powe i.MX6Q: Using an external reference for PCIe 😞 ... static void imx_pcie_override_phy_mpll(struct pcie_port *pp, u32 mpll_multiplier, u32 ref_clkdiv2) {     u32 ref_usb2_en;     u32 reg1;               pr_info("Overriding PCIe PHY MPLL config: multiplier = %d, clkdiv2 = %d\n",         mpll_multiplier, ref_clkdiv2);                   // set MPLL to disabled     ////pcie_phy_write(pp->dbi_base, PCIE_PHY_MPLL_OVRD_IN_LO, 0x0001);          // set MPLL multiplier         pcie_phy_write(pp->dbi_base, PCIE_PHY_MPLL_OVRD_IN_LO,             (0x0001<<9 | (mpll_multiplier<<2)) & 0x03fc);          /*      * set the ref_clkdiv2.  when this override is enabled it      * overrides both ref_clkdiv2 and ref_usb2_en.  make sure      * the overriden ref_usb2_en reflects the original value.      */          pcie_phy_read(pp->dbi_base, PCIE_PHY_ATEOVRD, &reg1);          ref_usb2_en = (reg1 >> 1) & 0x1;        /* set the current value of ref_usb2_en as the override */          /* set the ref_clkdiv2 override  */          /* enable the ref_clkdiv2 override */          pcie_phy_write(pp->dbi_base, PCIE_PHY_ATEOVRD,             (ref_usb2_en << 1) | ref_clkdiv2 | (0x1 << 2));             /* enable MPLL */         ///pcie_phy_write(pp->dbi_base, PCIE_PHY_MPLL_OVRD_IN_LO, 0x0003);          } ... call this function in pcie_hos_init ... static void imx6_pcie_host_init(struct pcie_port *pp) {     imx6_pcie_assert_core_reset(pp);            imx6_pcie_init_phy(pp);            imx6_pcie_deassert_core_reset(pp);        imx_pcie_override_phy_mpll(pp, 50, 1); /* tune this */          dw_pcie_setup_rc(pp);     imx6_pcie_establish_link(pp);      if (IS_ENABLED(CONFIG_PCI_MSI))         dw_pcie_msi_init(pp); } ... See documentation for p.p. IMX6DLRM 50.5.1.2. Tune <pci_hotplug_mem_size> global variable for optimal pci window sizes enumeration. See for my imx6_add_pcie_port call. If you use a FEC module, it will stop working. You must use an external clock as specified in the documentation (http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf ). Changes are shown in the attached dtsi file. For clocks segment ... rmii_clk: clock@0 {             compatible = "fixed-clock";             reg = <0>;             #clock-cells = <0>;             clock-frequency = <50000000>;  /* 50MHz */         }; ... and for fec: ... fec: ethernet@02188000 {                 compatible = "fsl,imx6q-fec";                 reg = <0x02188000 0x4000>;                 interrupts-extended =                     <&intc 0 118 IRQ_TYPE_LEVEL_HIGH>,                     <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;                 clocks = <&clks IMX6QDL_CLK_ENET>,                      <&clks IMX6QDL_CLK_ENET>,                      <&rmii_clk>;                 clock-names = "ipg", "ahb", "ptp";                 status = "disabled";             }; ... If they are not required, disable this editing this file. Thanks for all. Sorry for my bad English. Alfred <[email protected]> This document was generated from the following discussion: IMX6 PCI with external cloks

Building on the success of low-cost, high-performance application development kits, Freescale introduces the i.MX27 Lite Kit. Once again, Developed in Logic Product Development and Freescale have worked together to deliver a product-ready software and hardware platform for OEMs, ODMs, IDHs and independent developers and a price point that's quite appealing. The i.MX27 Lite Kit enables rapid design of embedded products targeting the medical, industrial, wireless, consumer markets and general purpose markets. Leverage the power of the i.MX27 multimedia processor in this cost-effective development solution. Features The Freescale i.MX27 SOM-LV is based on the i.MX27 multimedia applications processor running up to 400 MHz. Click here for the full list of i.MX27 SoC features: Includes i.MX27 SOM-LV module Standard peripheral connectors supporting: Ethernet, LCD, audio in/out, serial, CompactFlash®, MMC/SD, USB host, USB OTG, ATA LogicLoader™ (bootloader/monitor) in executable format GNU Cross-Development Toolchain (compiler, linker, assembler, debugger) included Kit contents: i.MX27 SOM-LV Application baseboard Expansion header breakout board Null-modem serial cable Ethernet crossover cable USB A to mini-B cable 5 volt power supply with power adapters (Europe, Japan, UK, and US) Logic Starter CD QuickStart Guide Zoom™ LV baseboard (146.1 x 158.8 x 17.1 mm) RoHS compliant

Some customers often use LVDS LCD with low resolution on i.MX6 platform, such as 320x240, but by defualt , linux bsp doesn't support low frequency pixel clock for LVDS module input. Question:     When we port LVDS LCD with 320x240 resolution to android4.2.2, we found pixel clock is not correct, it always output 38.9MHz, it is no probem for big resolution , for example 1024x768, but the clock we need for 320x240 LCD is 6.4MHz.     According to the quesiton, Let us check IPU & LDB clock in i.MX6 datasheet at first : From above table, if ldb clock is from IPU, we will not get 6.4MHz pixel clock, so we will have to adjust its source clock: The following steps are procedure that ports LVDS LCD with 320x240 resolution to i.MX6Q. 1. Adding LVDS LCD timing structure to ldb.c static struct fb_videomode ldb_modedb[] = { {       "LDB-XGA", 60, 320, 240, 155914,       38, 20,       15, 4,       30, 3,       0,       FB_VMODE_NONINTERLACED,       FB_MODE_IS_DETAILED, }, {      "LDB-1080P60", 60, 1920, 1080, 7692,      100, 40,      30, 3,      10, 2,      0,      FB_VMODE_NONINTERLACED,      FB_MODE_IS_DETAILED,}, }; 2.Modifying clock source of ldb module Checking /arch/arm/mach-mx6/clock.c, we can find there are 3 ldb's clock source : &pll5_video_main_clk, &pll2_pfd_352M, &pll2_pfd_400M, static int _clk_ldb_di1_set_parent(struct clk *clk, struct clk *parent) {        u32 reg, mux;        int rev = mx6q_revision();        reg = __raw_readl(MXC_CCM_CS2CDR)               & ~MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK;        mux = _get_mux6(parent, &pll5_video_main_clk,               &pll2_pfd_352M, &pll2_pfd_400M,               (rev == IMX_CHIP_REVISION_1_0) ?                &pll3_pfd_540M :       /* MX6Q TO1.0 */                &mmdc_ch1_axi_clk[0],     /* MX6Q TO1.1 and MX6DL */               &pll3_usb_otg_main_clk, NULL);        reg |= (mux << MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);        __raw_writel(reg, MXC_CCM_CS2CDR);        return 0; } By default, pll2_pfd_352M is configured as the clock source of ldb: clk_set_parent(&ldb_di0_clk, &pll2_pfd_352M);        clk_set_parent(&ldb_di1_clk, &pll2_pfd_352M); We should change the clock source to be pll5_video_main_clk clk_set_parent(&ldb_di0_clk, &pll5_video_main_clk,);        clk_set_parent(&ldb_di1_clk, &pll5_video_main_clk,); 3. Configuring initial clock in board-mx6q_sabresd.c static struct ipuv3_fb_platform_data sabresd_fb_data[] = {        { /*fb0*/        .disp_dev = "ldb",        .interface_pix_fmt = IPU_PIX_FMT_RGB666,        .mode_str = "LDB-XGA",        .default_bpp = 16,        .int_clk = false,        .late_init = false, } int_clk=false means LDB clock is from PLL2_PFD_352 or pll5_video_main_clk; int_clk=true mean LDB clock if from IPU. OK, after doing above steps, LVDS LCD with low resolution should normally work. Freescale TICS team Weidong.sun 2015-08-18

Fix cdc_ether connection over usb0 stalls and cannot recover after transmitting few MByte data The patch is modified from ENGR00278073.

Garz & Fricke GmbH - new software releases - Embedded Linux System Yocto

The new i.MX 6 Platform SDK 1.1 release is now available on the http://www.freescale.com/ site. NOTICE: The Platform SDK is no longer available and is unsupported. Please contact your Sales team for assistance. ·      Files available i.MX 6Series Platform SDK Bare-metal SDK for the i.MX 6 series, including reusable drivers and tests for many peripherals, and much example code. Also includes register definition headers files, and register definitions for debuggers. BSD open source license. New features and fixes - Fixed EIM test failure on sabre_ai board. - Added obds application. - Improved FAT filesystem cache. - Improved uSDHC API to allow access to entire 4GB card. - Added stream benchmark application. - Moved filesystem read/write performance test to be a new app. - New cpu_workpoint API in sdk/drivers/cpu_utility. - Improved menu API in sdk/utility/menu.h. - Fixed bug in D-cache invalidate and clean routines. - If an application returns from main(), _sys_exit() will now be called automatically. - Fixed a DDR region overflow linker error when using version 4.5.2 of the toolchain. - Removed smbus driver, as no i.MX6 boards have compatible devices and thus was untested. - Improved GIC driver by making it easier to init with new gic_init() API. - Implemented support for CSI test mode. - Converted SATA driver to use standard register definition macros. - Improvements to PWM driver. - Completely removed use of hw_module_t struct throughout SDK. Driver APIs that previously used this struct have been updated to take the relevant parameters, such as the peripheral instance, directly. Affected drivers: i2c, epit, uart, snvs, gpt, timer, flexcan. - The SDK build system now supports parallel builds. - Added jump_to_sdp() API in system_util.h to enter ROM Serial Download Protocol mode. - Static initialization of C++ objects now works as expected. - Fixed BCH ECC encoded reads and writes in GPMI driver. - Updated DCDs and debugger init scripts to the most recent versions. - Added GpioPin class in gpio driver. See sdk/drivers/gpio/gpio_pin.h. - Added classes for I2C and SPI devices. See sdk/drivers/i2c/i2c_device.h and sdk/drivers/spi/spi_device.h. - Added class to provide a software I2C port. See sdk/drivers/i2c/software_i2c_port.h. - Added gpio_set_gpio() API to gpio driver which configures the pin mux for a GPIO pin. - Added lwIP open source TCP/IP stack to the SDK. - Added two demo applications for lwIP: ping and httpd. - Implemented some minor improvements to ENET and FEC driver APIs. - Changed ENET driver so that it no longer puts the PHY into external loopback mode. A new API is added to enable loopback for the ENET unit test. - Added set_card_access_mode() API to uSDHC driver to replace some global variables that were used to configure DMA and interrupt mode. - Added read_input_string() and read_int() APIs to system_util.h. - Fixed ESAI driver so that it no longer always outputs each sample 3 times. - New arm_set_interrupt_state() API in cortex_a9.h. - Versions of all debugger init scripts are now provided for ARM DS-5. - Fixed a compiler warning generated by gcc 4.7.2 in the gpmi driver. - New version 3.4.0.4 of the IOMux Tool. - New driver for the MMA8451 accelerometer. - Added a full-featured USB Device stack under sdk/common/usb_stack. - Normalized line ending style to Unix (LF) for a few source files. - Created new APIs to manage starting up and shutting down secondary CPU cores. See cpu_start_secondary() and cpu_disable() in sdk/drivers/cpu_utility/cpu_utility.h. - Converted the multicore_demo application to a unit test under sdk/drivers/cpu_utility/test. - Added smp_primes multicore example application. - Improved spinlock API to work correctly in SMP situations. - Many small changes and improvements. - The startup code leaves interrupts disabled, and platform_init() now explicitly enables them. - Added readme files for all applications. - Changed how the makefiles archive objects in .a libraries. The timestamps of objects are compared with their copies in the archive, rather than being compared with the timestamps of the archive itself. This is to work around certain older Linux systems that do not save fractions of a second in file timestamps. One side effect of this is that the ar tool is invoked once per object that needs updating, where previously it was invoked to update a number of files at once. To reduce build log clutter, the archive messages are no longer shown.

      Minicom is a terminal emulation that can access a remote serial console enabling the configuration of RedBoot or the flash file system of the board.   Configuring       Reach the configuration by typing CTRL-A Z       Press key Z after releasing CTRL and A!       Configure Minicom to work with i.MX by following the procedures below.     Set the Serial Port       At the screen configuration, type O, choosing cOnfigure Minicom       In menu, choose Serial Port Setup       Below, the configuration option:   +-----------------------------------------------------------------------+   | A - Serial Device  : /dev/ttyS0                             |   | B - Lockfile Location  : /var/lock                          |   | C - Callin Program  :                                          |   | D - Callout Program  :                                        |   | E - Bps/Par/Bits  : 115200 8N1                           |   | F - Hardware Flow Control : No                           |   | G - Software Flow Control : No                           |   |                                                                        |   | Change which setting?                                      |   +-----------------------------------------------------------------------+   Type the letter of option to enable the modification.   Remember to choose the right Serial Device

In an earlier topic (Linux fast boot on i.MX6 Sabresd board.) about Linux fast boot on i.MX6 SabreSD board, the demo showed an application startup procedure including u-boot boot, Linux kernel boot, rootfs mount, demo application load and run. Additionally, this demo shows a live video on a LVDS screen from board CSI camera. Its total boot up time is about 1.x seconds. Now, based on Linux fast boot, we integrate it with another demo application: surround view, this demo shows 4 different live videos on LVDS screen from 4 UDP data sockets. In this demo video is drawn by GPU to screen, that means the frame buffers decode by video decoder directly pass to GPU, which is not same as previous demo. The encode video format is also MJPEG in this demo. This demo creates 4 different threads every thread handle one UDP socket, receive buffer, push this buffer to video decoder, get frame buffer from video decoder, pass this buffer to GPU, start GPU render, command GPU draw the render buffer to the screen; this thread needs to occupy one ARM processor to show every video smoothly. So we need a i.MX 6DQ board in this demo. Hardware: i.MX 6DQ SabreSD board Software: 12.09 GA BSP Difference with previous fast boot demo: U-boot difference with previous fast boot demo. 1: Add logo show. (For remove CSI2, V4L2, Capture modules ) Kernel different with previous fast boot demo. 1: Add SMP support. 2: Add Network support. (IPV4, PHY, network driver(FEC)) 3: Remove CSI2, V4L2, Capture. (Remove this need in U-boot procedure Freescale logo show on the screen! ) 4: Add GPU support in kernel. Rootfs difference with previous fast boot demo: 1: Keep rc.s firstly run, while in previous fast boot demo, demo is the firstly running program on rootfs. 2: Get rid of almost all service in rc.conf just keep “mount /proc and /sys” service. Network performance on this demo Software : The default network receive buffer is about 128KB. This default size is too small for this demo; the demo application can't fetch receive buffer in time while kernel network stack will discard some UDP packets if we don't enlarge it. We enlarge this receive buffer through command in inittab before demo running. Hardware: i.MX6 DQ TOI less than 1.2 version has some Ethernet mac layer issue, this issue will also cause some UDP packets lost. So please ensure the SabreSD board i.MX6 DQ chip TOI version is equal 1.2 or more. Attached are some files for your reference. Below patches assume this SabreSD board boot from SD3 and default display port is LVDS1. 1: U-boot and kernel patches based on 12.09. 2: Demo application based on 12.09 vpu test program and vpu test program running configure file. 3: Rootfs startup scripts.

INTRODUCTION REQUIREMENTS HARDWARE CONNECTIONS IMPLEMENTATION AND TESTING 1. INTRODUCTION This document explains how to generate and compile a custom Linux application on the UDOO NEO board  for using the GPIO headers to connect a 16x2 LCD. 2. REQUIREMENTS First of all, the Linux image used is UDOObuntu 2 RC1 (Ubuntu 14.04), available for download from the following link:      Downloads - UDOO​ For creating a bootable SD card and other basic setup please refer to the following guidelines:      Very First Start Then, it is required to install the proper drivers to ensure connectivity, including USB communication with Linux terminal of the target board. Please refer to the link below:      Usb Direct Connection The LCD driver of this document was already implemented on a previous application, and could be found on the following document: Customizing MQX applications on i.MX6SX. 3. HARDWARE CONNECTIONS Now, the hardware connection considers a 4-bit interface to the LCD plus the Register Select (RS) and Enable (E) pins, so, six GPIO are used. For this example, digital input/output pins are used as shown on the following figure (purple rectangle): Where: NEO GPIO GPIO148 GPIO105 GPIO149 GPIO140 GPIO141 GPIO142 LCD pin E RS DB7 DB6 DB5 DB4 4. IMPLEMENTATION AND TESTING After booting Linux, a text editor like nano should be used to generate the program. The three main configurations for GPIOS are the following (using the E pin as example): Export the GPIO. echo 148 > /sys/class/gpio/export Configure the direction of the GPIO (as output). echo out > /sys/class/gpio/gpio148/direction Set the GPIO value to Low or High: echo 0 > /sys/class/gpio/gpio148/value echo 1 > /sys/class/gpio/gpio148/value So, based on these configurations and the LCD driver already implemented on the document mentioned on Requirements section, the complete C application for Linux could be generated (find it attached). The GCC compiler already included on the UDOObuntu image could be used to generate the executable application. The picture below shows the terminal of the UDOO NEO board including the text editor, compilation and execution commands of the application. The used commands are the following: $ nano lcd16x2_imx6sx.c $ sudo gcc lcd16x2_imx6sx.c -o lcd $ sudo ./lcd Finally, the following image shows the LCD with the application working on the UDOO NEO board, connecting the LCD using a proto shield: NOTE: Ensure that M4 core is not running or using the same pins, in order to avoid unexpected behavior on GPIOs.

To get the FSL amrdecoder building and running on imx53 in 11.09 BSP: TIP: During debug for creation of these patches -> On the target, I had to make sure I had all the amr decoder libraries present, or it just wouldn't work. I narrowed those down by deleting "rm /root/.gstreamer-0.10/registry.arm.bin" and rerunning gst-inspect to rescan the plugins. With GST_DEBUG=3 I could see what libraries were missing and copied them over. But once everything was in place, it just worked. gst-launch playbin2 uri=file:////media/sd/media_file_with_amr_audio_encoding.3gp Attached are the new .spec files and patch files to get this to work. Regards, Randy

In some customers’ design they use the different DRAM from the one used on our reference board. So customers need to customize the DRAM to make it work well on their design. About the i.MX6x hardware design customers can refer to IMX6DQ6SDLHDG.pdf and the section 5 DRAM interface requirements for migration on AN4397. After finishing the hardware design there are two tools important for the DRAM boot up and debug: DRAM Register Programming aid And DRAM Stress Test 1\DRAM Register Programming aid Our expert team create the script to make it easier to work on DDR initialization. You can see all the scripts on different chips and the link is: i.MX Design&amp;Tool Lists The script include 3 sections, when you open it you can see the details. Run basic DDR initialization and test memory and open a debugger memory window pointing to the DDR memory map starting address. Try writing a few words and verify if they can be read correctly. If not, re-check the DDR initialization sequence and if the DDR has been correctly soldered onto the board. It is also recommended to re-check the schematic to ensure the DDR memory has been connected to the SoC correctly. In some cases, a DRAM calibration routine may need to be executed. About the details use and introduction on this script you can refer to Freescale i.MX6 DRAM Port Application Guide-DDR3 After configure the DRAM, you need to use the DRAM Stress Test to perform calibrations the performance and then regulate some parameters. 2\DRAM Stress Test DDR_Stress_Tester is a software application for fine tuning DDR parameters and verifying DDR performance on i.MX6 boards. It performs write leveling, DQS gating, read/write delay calibration on the target board to match the layout of the board and archive the best DDR performance. In addition, the stress test can help the user to verify the DDR performance on their boards. The DDR stress test tool serves two purposes. First, it can perform calibrations for DDR3 to match the MMDC PHY delay settings with PCB for optimal DRAM performance. The process is fully automatic, and therefore the customers can get there DDR3 working in much shorter time. In addition, the tool can run a memory stress test to verify the DDR3 functionality as well as the reliability. The stress test can help verifying the hardware connections, MMDC registers parameters, and DDR3 mode registers setting. The most important purpose of the test is that it allows the customers to verify that the DDR3 operations are stable on their board. The newest version  of DRAM Stress Test tool you can see in our community: i.MX6/7 DDR Stress Test Tool V2.51 And the old version you can see in the follow link: i.MX6 DDR Stress Test Tool V1.0.3 About how to use this tool you can read the use guide. Besides , you also can refer to the Freescale i.MX6 DRAM Port Application Guide-DDR3 By the way, if customers use the different DRAM from our reference design when the use the mfgtool to download the images, they need to build manufacturing images for mfgtool. Take the Linux 3.14.52 BSP as an example: $ bitbake fsl-image-mfgtool-initramfs Hope this can help you.

    Gigabit Ethernet should be one of most beautiful features in our imx6 platform which will bring more colorful dreams to many customers. But recently,many people responsed that there were great performance gaps between using Android and Linux. Now let me give an exploration here.     Same hardware, same kernel, different performance,why?     In linux, its data throughput can reach 400Mbps.In JB, it can only get to 200Mbps.     From the below info, we can see it should be related with frames dropping.      root@android:/ # busybox ifconfig eth0      eth0      Link encap:Ethernet  HWaddr 00:04:9F:02:6C:E1                inet addr:192.168.0.100  Bcast:192.168.0.255  Mask:255.255.255.0                inet6 addr: fe80::204:9fff:fe02:6ce1/64 Scope:Link                UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1                RX packets:7382672 errors:71828 dropped:789 overruns:71828 frame:71828                TX packets:4147006 errors:0 dropped:0 overruns:0 carrier:0                collisions:0 txqueuelen:1000                RX bytes:2568845018 (2.3 GiB)  TX bytes:284789020 (271.5 MiB)      In TCP stack, there are three buffers involved in iperf test case:tcp_mem; tcp_rmem; tcp_wmem.      All of them are described by three variables which will influence a lot for iperf test result.      In linux,I got a snapshot for them:      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_mem      18240      24320     36480      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_rmem      4096       87380     778240      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_wmem      4096       16384     778240      In Android,I also got them to compare to:      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_mem      9285      12380     18570      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_rmem      4096       87380     396160      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_wmem      4096       16384     396160      The tcp_mem varibles define how the TCP stack should behave in kernel memory management.The first value tells the kernel the low threshold. The second value tells the kernel at which point to start pressuing memory usage down. The third one tells the kernel how many memory pages it may use maximally. If it is reached,TCP streams and packets start geting dropped until to a safe level.      In tcp_rmem, the first value defines the minimum receive buffer for each TCP connection and this buffer is always allocated to a TCP socket.The second one defines the default receive buffer size. The third one specifies the maximum receive buffer that can be allocated for a TCP socket.      In tcp_wmem, three varibles also be given to describle the TCP send buffer for each TCP socket.      We can check how these values come from in kernel code.There is an algorithm in kernel_imx/net/ipv4/sysctl_net_ipv4.c +450.     limit = nr_free_buffer_pages() / 8;     limit = max(limit, 128UL);     sysctl_tcp_mem[0] = limit / 4 * 3;     sysctl_tcp_mem[1] = limit;     sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 2;     /* Set per-socket limits to no more than 1/128 the pressure threshold */     limit = ((unsigned long)sysctl_tcp_mem[1]) << (PAGE_SHIFT - 7);     max_wshare = min(4UL*1024*1024, limit);     max_rshare = min(6UL*1024*1024, limit);     sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;     sysctl_tcp_wmem[1] = 16*1024;     sysctl_tcp_wmem[2] = max(64*1024, max_wshare);     sysctl_tcp_rmem[0] = SK_MEM_QUANTUM;     sysctl_tcp_rmem[1] = 87380;     sysctl_tcp_rmem[2] = max(87380, max_rshare);      From the above algorithm, we can see tcp_mem,tcp_wmem[2],tcp_rmem[2] all related with nr_free_buffer_pages() which stands for amount of free RAM allocatable within ZONE_DMA and ZONE_NORMAL.      So here, we can find the root cause of performance gap between Android and Linux. There is big gaps in free RAM while running different OS. In fact, in android, Google has introduced one mechanism to tune these values through propertity. Now we are using default AOSP's values, you can refer to them in device/fsl/imx6/etc/init.rc.For wifi and Ethernet, they are both using net.tcp.buffersize.wifi. # Define TCP buffer sizes for various networks #   ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax,     setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208     setprop net.tcp.buffersize.wifi    524288,1048576,2097152,262144,524288,1048576     setprop net.tcp.buffersize.lte     524288,1048576,2097152,262144,524288,1048576     setprop net.tcp.buffersize.umts    4094,87380,110208,4096,16384,110208     setprop net.tcp.buffersize.hspa    4094,87380,262144,4096,16384,262144     setprop net.tcp.buffersize.hsupa   4094,87380,262144,4096,16384,262144     setprop net.tcp.buffersize.hsdpa   4094,87380,262144,4096,16384,262144     setprop net.tcp.buffersize.hspap   4094,87380,1220608,4096,16384,1220608     setprop net.tcp.buffersize.edge    4093,26280,35040,4096,16384,35040     setprop net.tcp.buffersize.gprs    4092,8760,11680,4096,8760,11680     setprop net.tcp.buffersize.evdo    4094,87380,262144,4096,16384,262144 I tried to change the above values but unfortunately got no obvious improvement.Hi,why???? so another topic,how tcp_mem and tcp_rmem cowork in kernel? In android, we only have way to tuning tcp_rmem or tcp_wmem settings but not tc_mem. Take "iperf -c" for example, tcp_rmem will be filled up according to the frequency of Gigabit ethernet clock. And then it will be repacked acoording to the size of tcp_mem.If tcp_mem is smaller, more times will be triggered and if it has exceeds the max value dropping frames will be triggered. Then retransport will be launched in TCP. At last, performance will downgrade. It is just like go surfing using Gigabit but with a rubbish notebook. You still can't enjoy good performance of Gigabit ethernet. Why kernel calculate tcp_mem like this in ipv4? Maybe they consider the balance between single high-bandwidth and multiple connections. You can imagine if we change the tcp_mem to use a solid big value, it may cause the board deny connections because of a lack of memory allocation in tcp init. Here I will give out several method to improve our android ethernet performance. Enlarge your memory size in board design phase.      I have double checked it by testing in our SabreAuto board whose memory is 2G whose download speed can reach to 270 Mbps about 50Mbps over Sabresd. Try to use older version android, if you can use ICS, you can abandon JB4.3. Compared with newer android version, old version will take less memory and there will leave more free memory to use. Using ICS, we can reach 380 Mbps downloading while in JB4.3, it can only get to 210 Mbps. If you are using sabresd's Gigabit ethernet for a very important case, you can balance it if you can throw other memory eaters like GPU. I have checked it if we disable GPU, the performance can reached to 340 Mbps in JB4.3 with about 50% improvement. Change tcp_mem algorithm to enlarge its max value threshold. Like you can change  "sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 2" to "sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 3" above. You can see there won't be framedropping any more. Or you can also refer to How To: Network / TCP / UDP Tuning to hard code it. But like its author said in it, it is not recommended for those support multiple users or multiple connections. for it maybe cause the board to deny connections because of a lack of memory allocation. Tune tcp_rmem and tcp_wmem through the following patches in android. you will get bidirectional 320Mbps. But if you use ifconfig tool to set static ip you will not get these parameters set. For AOSP's framework only support DHCP now. For this case, you can manually echo these parameters in console before doing test.                Gerrit Code Review                Gerrit Code Review Change kernel's scheduler policy config.      Disable CONFIG_FAIR_GROUP_SCHED and only enable CONFIG_RT_GROUP_SCHED will contribute some enhancement.      With the above changes, I have tested on Sabresd RevC1 using android4.3GA, the bidirection speed can both reach 390~400Mbps.

    On latest iMX8QXP MEK board, the hardware connected the SCU_GPIO0_00 and SCU_GPIO0_01 pins for SCU debug UART, and customer can enable "#define ALT_DEBUG_SCU_UART" from "imx-scfw-porting-kit-1.1/src/scfw_export_mx8qx_b0/platform/board/mx8qx_mek/board.c" to open the SCFW debug UART for early board bring up.     And if customer enabled "#define ALT_DEBUG_UART" from board.c, then SCFW will use ADC_IN2 and ADC_IN3 pins for debug UART.     In this document, it is another choice, SCFW can also use UART0_RX and UART0_TX pins as SCU debug UART for early board bring up. It is based on released "imx-scfw-porting-kit-1.1.tar.gz".     That means on early MEK boards and customer boards which haven't reserved debug UART for SCU, they can also check the SCFW boot log from UART0 port. "scfw-porting-kit-1.1-sc_uart-on-uart0.patch" is the reference patch for such modification. Enable "#define ALT_DEBUG_SCU_UART_ON_UART0" to make it work. Note: since UART0 pins had been used in SCFW, they can't be used in UBoot and linux kernel at the same time, so when debuging UBoot and Linux kernel, you need disable "ALT_DEBUG_SCU_UART_ON_UART0" in SCFW, or you can use other UART port and pins.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-341566 

Before reading: only a personal works and sharing, not any form of "release". I didn't find any confidential information from the packages. So, I'm publishing it here. This is only for testing purpose. Do NOT use it for building a product. Use it at your own risk!! Yocto is flexible and powerful, and also, big and slow (when building). Sometimes we only need to build uboot or kernel or some piece of testing code. It's really a waste of time to build-up the whole Yocto environment which may cost over 50GB disk space and over 3 hours of building. I've made some scripts and sum them up to form a toolset for building uboot, kernel and some testing code out of Yocto environment. It's only a simple container and expect to use with uboot and kernel source code from formal Freescale release and a SDK built from Yocto project. GitHub source repo:       https://github.com/gopise/gopbuild What’s made off (a full package, not only the container): 1.    Some scripts and configurations files. 2.    SDK built from Yocto. 3.    Uboot/kernel from specific version. 4.    A hello-world to demonstrate how to build app in this environment. 5.    A slimmed rootfs binary from specific BSP pre-built as base. Will customize base on the source under “rootfs” folder. Only a placeholder in the container-only version. How to use it: Several common used board configurations have been included in the script: 6qsabresd/6qsabreai/6qpsabreai. You can add more into the “gopbuild” script easily. The “sabresd” has been set as default.      If you want to build all for sabresd (First of all, de-compress the package): cd <de-compressed-folder> source envsetup [It will prompt for selecting board configuration to be built. Choose one by input corresponding number or click <ENTER> for default board.] gmk ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍      If you want to build specific module for default board, such as uboot: gmk uboot ‍‍‍‍‍‍‍‍‍      Build kernel for sabreai board instead of default device: gmk kernel sabreai ‍‍‍‍‍‍‍‍‍      Clean everything? gmk all clean ‍‍‍‍‍‍‍‍‍ After a successfully full build, you will get everything under “output” folder, including a log folder contains full build log:      “u-boot.imx/zImage/rootfs.tar.bz2/*.dtb”, can be used with MFG or uuu.      “fsl-image.sdcard”, can be burn into SD card directly. "Ready-for-building" Package: The "gopbuild" itself is a "container-only" package which doesn't contain any source or SDK. I've also made some packages based on latest BSP release for i.MX6/i.MX7/i.MX8. These packages are "ready-for-build" package which you can de-compress and build it directly. -------------------------------------------------------------------------------------------------- URL：https://pan.baidu.com/s/1Xlh1OBGsTRXez_NQw-Rjxg Password: gdc9 -------------------------------------------------------------------------------------------------- Note: 1. To build for i.MX8 (8QM/8MQ/8QXP), you need L4.14.* or above. 2. To build for i.MX8, please download the SCFW from i.MX software page       i.MX Software and Development Tools | NXP      After download, decompress corresponding package for specific chip and put it under "/platform/scfw/". Take i.MX8QXP for example:             /platform/scfw/scfw_export_mx8qx/ All material (uboot/kernel/test code and SDK) are from official Yocto release. Thanks!