The vbs file is a script file in mfgtool. In fsl android lollipop consolidate and later MFGTOOL version, You just need add a new vbs item for new board and have not need to change the ucl2.xml. The below is the example struct. Set wshShell = CreateObject("WScript.shell") wshShell.run "mfgtool2.exe -c ""linux"" -l ""SDCard-Android"" -s ""board=sabresd"" -s ""folder=sabresd"" -s ""soc=6dl"" -s ""mmc=2"" -s ""data_type=-f2fs""" Set wshShell = Nothing Explain for each option: -l: storage type      There three type for android: Nand-Android\eMMC-Android\SDCard-Android -s: extend variable      board: It is used to download uboot and dts in init system.      folder: there are three type: sabresd sabreauto evk                the android image is located in: files/android/%folder%/      soc: Used to define android image name. types: 6q, 6dl, 6sx, 6sl.      mmc: define the storage idex.      data_type: if the type of data partition is f2fs, need define data_type=-f2fs      ldo: if the board is 1.2G, need to define it to -ldo      plus: if the board is 6qp, need too define it to p

Downloading and building the V4L2 examples V4L2 examples - v0.1 are available at https://github.com/rogeriorps/v4l2-examples To download, just clone the project: $ git clone https://github.com/rogeriorps/v4l2-examples.git Available demos Example1: Display an image coming from camera using V4L2_BUF_TYPE_VIDEO_OVERLAY Example2: Display an image coming from camera using V4L2_BUF_TYPE_VIDEO_OUTPUT Known issues

This documents describes the neceesary steps to set up Qt Creator with the Qt5 toolchain that is available as part of the 3.14.28 BSP Release. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release L3.14.28 or higher. For this example we'll use the Freescale BSP Release L3.14.28 but you may use future BSP releases that include the Qt toolchain. - Freescale BSP Release Documentation L3.14.28 (login required) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20Information&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=gz&WT_ASSET=Documentation&fileExt=.gz&Parent_nodeId=1337637154535695831062&Parent_pageType=product&Parent_nodeId=1337637154535695831062&Parent_pageType=product 3) Qt5 Meta Toolchain (Poky 1.7 qt5 / L3.14.28 for our example but you may use the qt toolchain that corresponds to the BSP that will be used) For information on how to extract and install the meta toolchain please follow the steps on the next document but with the following command: $ bitbake meta-toolchain-qt5 https://community.freescale.com/docs/DOC-95122 Task #7 - Create the toolchain Then run the script. fsl-release-bsp/<BUILD_DIR>/tmp/deploy/sdk/poky-glibc-x86_64-meta-toolchain-qt5-cortexa9hf-vfp-neon-toolchain-1.7.sh Installing Qt Creator We will use the Open Source version of Qt Creator. Please make sure that your application does comply with the requirements of Open Source Software before installing. You may download Qt Creator Open Source for Linux from the following link: http://www.qt.io/download-open-source/ Once you downloaded the installer you will need to make sure that the file has permission to be executed. You can add this with the following command: $ chmod +x qt-unified-linux-x64-2.0.2-2-online.run Then run the installer $ ./ qt-unified-linux-x64-2.0.2-2-online.run After the information from the repositories has been fetched you will be asked where to install Qt Creator. Then you will be asked which components to install. We will install Qt 5.4 which is the one supported on the 3.14.28 BSP release. You will need to accept the License Agreement and then the installer will fetch and install the necessary files. Configuring Qt Creator Once it’s finished downloading, launch Qt Creator. You can do this with the following command: cd <INSTALATION_DIR>/Tools/QtCreator/bin $./qtcreator.sh Under the Tools top bar menu, chose Options… On the Options window’s left menu chose Build & Run and then the Compilers tab and select Add GCC. On the next screen chose a name for this Compiler (i.e. i.MX Qt5) and then select the Compiler path, which may vary depending on where you have it installed but by default should be in: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ It should then be detected as arm-linux on the ABI section. Next select the Qt Versions tab and click on Add… Look for the qmake on the toolchain path, which is by default: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake Finally, on the Kits tab add a new kit and select the sysroots from the toolchain, which is by default located in: /opt/poky/<VERSION>/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi Qt Creator is now configured for building for the i.MX6.

►Playbin2 provides a stand-alone everything-in-one abstraction for an audio and/or video player. •Audio sink and video sink can be specified by application •Supports subtitle for video files •Adjustable A/V offset •Selects audio/video/subtitle streams by input selector •Audio post-processing by audio convert, audio resample and volume • ►The pipeline is created by playbin2 dynamically: •Typefind checks the source type •Demuxer parses the source data and create pads for all the streams, respectively •Playbin2 searches for and creates decoders in element factory who have capability to decode specific format of audio/video •Playbin2 creates and connects audio sink chain and video sink chain Playbin2: interaction with application ►Set/get properties of playbin2 •“audio-sink”, “video-sink” •“current-audio”, “current-video”, “current-text” •“n-audio”, “n-video”, “n-text” (read only) •“uri”, “suburi”, “av-offset”, “volume”, “mute” ►Events •Bidirectional: flush start, flush end •Downstream: eos, new segment, tag •Upstream: qos, seek ►Queries •Position, duration, latency, rate, seeking, segment ►Messages •Eos, error, warning, info, tag, buffering, state changed, duration, latency, ►Signals •“video-changed”, “audio-changed”, “text-changed” •“video-tags-changed”, “audio-tags-changed”, “text-tags-changed” Playback: track selection                                               ►Pipeline for audio/video/subtitle multi-track file •Demuxer creates src pads for all the tracks, respectively •Each track has its own decoder and sink pad of input selector •One sink pad in input selector is activated to play corresponding track •Audio, video and subtitle have separated input selectors. •Take audio for example:                                                                                                                                                         ►Input selector •Only push the data from active sink pad to its src pad •The data from all the sink pads shall be synchronized, so that timestamps can be consecutive when switch to another track. Otherwise, there will be no sound or video for a long time after switching track. •If demuxer gets samples in file mode (need a large queue before decoder):              A lock is set for each inactive tracks to synchronize tracks. Otherwise, the inactive tracks would be decoded in full speed (usually much more faster than active track).              The lock compares the received timestamp with the last timestamp of active track. If larger, waits until the next timestamp (buffer) of acitived track arrives; if smaller, drop this buffer and get the next buffer. •If demuxer gets samples in track mode and the queue is small:             All tracks is synchronized by demuxer

The Compatibility Test Suite Verifier is a supplement to the Compatibility Test Suite. The main difference lies in that the verifier is developed for tests that cannot run on their own so they require user input in order to be tested. These tests would include the audio quality, the touchscreen, accelerometer, camera, etc. There is no “best verifier option”, one CTS complements the other. In this document we will focus on how to perform the Verifier test. Requirements: A PC with the Android SDK installed. Your “Device Under Test” (your development board) Optional >> A second android device with compatible Wifi and Bluetooth Setup Steps: Install de Android SDK on your PC Download the appropriate CTS Verifier APK. The list of APK’s can be found here: https://source.android.com/compatibility/downloads.html Make sure that your Device Under Test has its system date and time set correctly. Install the CTS Verifier APK on the Device Under Test* For more information regarding ADB commands, follow this link: https://community.freescale.com/docs/DOC-102514 Initialization: After the setup is done, you should see the application installed: You will see the list of available tests for manual verification: Video Link : 4502 For each test, you will see detailed instructions to run it, and a “pass” and “fail” buttons. Video Link : 4530 Once you run each test, you will have the posibility to choose the outcome. (in some cases, pass/fail outcome will be determined automatically). The list of tests (for CTS Verifier 5.1_r2) is: Camera: FOV Calibration, Formats, ITS, Intents, Orientation, Video. Car: Car Dock Test Clock: Alarms and Timers Test Device Administration: Policy serialization test, screen lock test. Features: Hardware/Software feature summary Hardware: USB Accessory Test Job Scheduler: Charging constraints, connectivity constraints, idle mode constraints. Location: Battery saving mode test, location mode off test Managed provisioning: BYOD managed provisioning, device owner provisioning Networking: Bluetooth test, Wi-Fi direct test Notifications: CA Cert notification, CA Cert notificacion on boot, notification attention management, notification listener, notificacion package priority Other: Data backup, screen pinning, widget framework Projection: Projection cube, projection multitouch, projection offscreen, projection scrolling, projection video playback, projection widget Security: Keyguard password verification, SUID file scanner. Sensors: Accelerometer mearument, CTS Sensor batching, CTS Sensor integration, CTS sensor test, CTS single sensor test, magnetic field measurement, sensor batching. Streaming: Streaming video quality verifier. Exporting test results: Tap the “save disk” icon. A pop-up will show the path of the report that was created. Video Link : 4531 With the board connected to the PC through USB, pull the report using ADB: To download all reports run : adb pull /mnt/sdcard/ctsVerifierReports/ .

Hello i.MX Community. Attached there is a guide on How to Use an Older Uboot version with 3.1x.xx Kernel Version I hope you find the document and Sample provided useful! Regards!

Hello i.MX Community. Attached there is a guide on how to install Ubuntu trusty on i.MX7D-SD board Basically it explains all steps to install and to have running ubuntu core 14.04 on the Freescale i.Mx7D-SDB: I hope you find the document and projects useful! Regards!

Display on LVDS0 or LVDS1 is normal, but some customer need  larger screen and they need the dual LVDS work on the same time. In another word, it is to use the dual 8 connection. Here I give the simple introduction on this. Environment Board: MCIMX6Q-SDP (Or the board customer design) BSP:  Linux or Android BSP provided by Freescale Screen: M190PW01-V8 19(Take this as example) Steps: 1\ Hardware connection Make sure the hardware connection is right. The 4 pairs of difference signals on both LVDS0 and LVDS1 work, but in our reference board MCIMX6Q-SDP only 3 pairs of difference signals work. To make this screen working well the connection must be proper connect. Take the screen M190PW01-V8 19 as a example, the connection is as follow: 2\ Software modify Here we can know the screen works on the RGB24 mode not the RGB666, as the connection is already right. So the next step is to modify the code. As customers use differently screens, they have to porting the screen driver first.  About porting customers need to modify the  ldb.c  according to the datasheet of the screen in BSP. The parameters and timing should be set right.  Also the board.c need to be modified, RGB24 mode should also be set. About the porting Lvds screen steps, details you can refer to the Porting LVDS LCD With Low Resolution to i.MX6  in our community. 3\ Command special in u-boot After porting success the LVDS  and build the BSP. The run the images built on the board then boot up the board. In the u-boot the command should be set, about the display section is : video=mxcfb0:dev=ldb,LDB-1080P60,if=RGB24 ldb=spl0. The default BSP provided by Freescale is support dual LVDS display, but the display mode should be right so it can work well. Hope this can give some help to you.

Q: Is there any guidelines document on 3G/4G modem integration with the iMX platforms running Android Lollipop versions ? A: Generally speaking, porting documents on 3G/4G should be provided by manufacture, For different 3G/4G module, porting steps are also distinct.The following steps are for ZTE 3G on android jb 4.2.2,  as a reference: ----Common steps: (1) linux USB driver In linux kernel, we should select GSM module in USB driver path. (2)Communication port for 3G After linux booting normally, you can find some communation port at path /dev/, like ttyUSB0,ttyUSB1,ttyUSB2... These tty ports are for AT commands & data transmitting, but which one is for data , or which one is for AT command, we should have to ask manufacture or get information for them. (3)dial script 3G manufacture will give the script to you, if not, ask for it. (4)Dynamic library(libreference-ril.so) 3G manufacture will give you the library to replace original one in android. (5)Add service for 3G in init.rc file according their documents ---As an example, let us see steps for ZTE 3G(CDMA) ** Replace original file with libreference-ril.so file that ZTE released. **Copy init.gprs-pppd file to system/etc/ppp directory **Modify init..rc like following: service ril-daemon /system/bin/rild -l /system/lib/libreference-ril.so -- -d /dev/ttyUSB2 -u /dev/ttyUSB0 class main socket rild stream 660 root radio socket rild-debug stream 660 radio system socket rild-ppp stream 660 radio system user root group radio cache inet misc audio sdcard_rw log service pppd_gprs /etc/ppp/init.gprs-pppd class main user root group radio cache inet misc disabled oneshot

1. INTRODUCTION:      This document explains the general and basic steps to customize U-Boot for your own board. The board used in this document it is a working and stable board, the UDOO board (http://udoo.org). 2. REQUIREMENTS:     Install Yocto Project. See the Freescale Yocto Project User's Guide.     Generate and install the meta-toolchain. Follow this great training to do so  Yocto Training - HOME     Generate core-image-minimal of L3.14.28 of FSL BSP obtained from https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_iMX6QDLS_BUNDLE&appType=license&location=null&Parent_no…   3. ADDING i.MX6 CUSTOM BOARD SUPPORT FOR U-BOOT.     This section follows the steps found in Chapter 1 of the i.MX6 BSP Porting Guide of the Yocto documentation (L3.14.28) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20In… . Obtain U-Boot Source Code. After having installed Yocto project and generate a valid imx6 image, the U-Boot code should be located at <build directory>/tmp/work/<machine>-poky-linuxgnueabi/u-boot-imx/<version>/git. Prepare the Code. Choose a board as reference, this board should be as similar as possible to your custom board. Copy the board directory :                $ cp -R board/freescale/mx6sabresd/ board/freescale/mx6_udoo Copy the existing mx6sabresd.h configuration file as mx6_udoo.h                $ cp include/configs/mx6sabresd.h include/configs/mx6_udoo.h Create one entry in boards.cfg. Add a configuration entry in the boards.cfg file. Active  arm  armv7  mx6  freescale  mx6_udoo mx6_udoo mx6_udoo:IMX_CONFIG=board/freescale/mx6_udoo/mx6dl_4x_mt41j128.cfg,MX6Q,DEFAULT_FDT_FILE="imx6q-udoo.dtb",DDR_MB=1024 Rename <board>.c file. Rename board/freescale/mx6sabresd/mx6sabresd.c   to   board/freescale/mx6_udoo/mx6_udoo.c Modify Makefile. Change the line of COBJS to your custom board at  board/freescale/mx6_udoo/:      obj-y  := mx6sabresd.o Create a Shell script. Create a script to compile your new configuration. The script for this example is shown below and its name is build_u-boot.sh: #!/bin/bash export ARCH=arm export CROSS_COMPILE=/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi- make distclean; make mx6_udoo_config make Run the script to verify if the new configuration is correct.      $./build_u-boot.sh 4. CUSTOMIZING BOARD CODE      The fist part to customize is the DCD table. The DCD table contains configuration data for the DDR controller and memory. The DCD is read by the BootROM code in the iMX family and executed before copying the Uboot image to DDR. The DCD is built in the .cfg file pointed in the new entry we just added in the boards.cfg file (mx6dl_4x_mt41j128.cfg). Below you can find an example of the data that can be found in this file: /* * Device Configuration Data (DCD) * * Each entry must have the format: * Addr-type           Address        Value * * where: *      Addr-type register length (1,2 or 4 bytes) *      Address   absolute address of the register *      value     value to be stored in the register */ DATA 4, 0x020e0774, 0x000C0000 DATA 4, 0x020e0754, 0x00000000 DATA 4, 0x020e04ac, 0x00000030 DATA 4, 0x020e04b0, 0x00000030 DATA 4, 0x020e0464, 0x00000030 DATA 4, 0x020e0490, 0x00000030 DATA 4, 0x020e074c, 0x00000030 DATA 4, 0x020e0494, 0x00000030 DATA 4, 0x020e04a0, 0x00000000 The .cfg files used in this example were taken from an old U-Boot version (2009) non dtb capable. The used files are found in the attached .zip file. The specific initialization code for each board is found in mx6<customer board>.c in board/freescale/mx6<customer board>.c  in this case board/freescale/mx6_udoo/mx6_udoo.c file. Below it is explained the needed changes to route the serial console to the correct UART module, disable an external watchdog, configure and initialize the Ethernet PHY, change the lvds clock and configure the correct USDHC module.        U-Boot calls already defined functions from a function pointer array that takes care of the board initialization at different stages. For example the board_early_init_f() is called at an        early phase where we can disable the wdog and initialize the uart pins; board_init() and board_late_init() are called after board_early_init_f(). The UDOO board features an external watchdog that needs to be disabled with a GPIO, otherwise U-Boot resets after a few seconds:          The WDOG pins need to be configured and in the mx6_udoo.c file a global struct configuration for those pins is declared, as well as macros for each pin #define WDT_EN  IMX_GPIO_NR(5, 4) #define WDT_TRG IMX_GPIO_NR(3, 19) iomux_v3_cfg_t const wdog_pads[] = {         MX6_PAD_EIM_A24__GPIO5_IO04 | MUX_PAD_CTRL(NO_PAD_CTRL),         MX6_PAD_EIM_D19__GPIO3_IO19, }; static void setup_iomux_wdog(void) {         imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads));         gpio_direction_output(WDT_TRG, 0);         gpio_direction_output(WDT_EN, 1);         gpio_direction_input(WDT_TRG); } This configuration needs to be called at some point of the board_early_init_f() int board_early_init_f(void) {         setup_iomux_wdog();         This way the board_early_init_f() calls the iomux for the external wdog and disables it. The UART console is routed to UART2, EIM_D26/UART2_TXD and EIM_D27/UART2_RXD. A different structure is defined with the pin configuration for the UART2.      iomux_v3_cfg_t const uart2_pads[] = {         MX6_PAD_EIM_D26__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),         MX6_PAD_EIM_D27__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), }; This configuration should be called at early stage too. static void setup_iomux_uart(void) {         imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads)); } int board_early_init_f(void) {         setup_iomux_wdog();         setup_iomux_uart(); Also the UART BASE register has to be defined as well as the console device. This is defined in the include/configs/mx6_udoo.h file. #define CONFIG_MXC_UART_BASE   UART2_BASE #define CONFIG_CONSOLE_DEV      "ttymxc1" The UDOO board features only one micro SD slot to boot and U-Boot environment storage. It uses only 4 bits and it has to be configured too. In the include/configs/mx6_udoo.h file the USDHC module has to be defined and the MMC environment device. #define CONFIG_SYS_FSL_USDHC_NUM   3 #define CONFIG_SYS_MMC_ENV_DEV       0     /* SDHC3 */          The USDHC3 pin configuration has to be defined:      iomux_v3_cfg_t const usdhc3_pads[] = {         MX6_PAD_SD3_CLK__SD3_CLK   | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_CMD__SD3_CMD   | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_NANDF_D0__GPIO2_IO00    | MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */ }; struct fsl_esdhc_cfg usdhc_cfg[1] = {         {USDHC3_BASE_ADDR, 0, 4}, }; This must be called and configured from the board_mmc_init() function: int board_mmc_init(bd_t *bis) {         s32 status = 0;         imx_iomux_v3_setup_multiple_pads(         usdhc3_pads, ARRAY_SIZE(usdhc3_pads));         usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);                 status |= fsl_esdhc_initialize(bis, &usdhc_cfg[0]);         return status; } The Ethernet PHY is configured in the board_eth_init() function. This function should initialize the pins for the external ethernet phy, mdio and phy configuration.  Just a piece of code is shown below: iomux_v3_cfg_t const enet_pads1[] = {         MX6_PAD_ENET_MDIO__ENET_MDIO            | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_ENET_MDC__ENET_MDC              | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TXC__RGMII_TXC       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD0__RGMII_TD0       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD1__RGMII_TD1       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD2__RGMII_TD2       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD3__RGMII_TD3       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL      | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_ENET_REF_CLK__ENET_TX_CLK       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RXC__RGMII_RXC       | MUX_PAD_CTRL(ENET_PAD_CTRL),         /* RGMII reset */         MX6_PAD_EIM_D23__GPIO3_IO23              | MUX_PAD_CTRL(NO_PAD_CTRL),         /* alimentazione ethernet*/         MX6_PAD_EIM_EB3__GPIO2_IO31              | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 32 - 1 - (MODE0) all */         MX6_PAD_RGMII_RD0__GPIO6_IO25            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 31 - 1 - (MODE1) all */         MX6_PAD_RGMII_RD1__GPIO6_IO27            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 28 - 1 - (MODE2) all */         MX6_PAD_RGMII_RD2__GPIO6_IO28            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 27 - 1 - (MODE3) all */         MX6_PAD_RGMII_RD3__GPIO6_IO29            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 33 - 1 - (CLK125_EN) 125Mhz clockout enabled */         MX6_PAD_RGMII_RX_CTL__GPIO6_IO24         | MUX_PAD_CTRL(NO_PAD_CTRL), }; static iomux_v3_cfg_t const enet_pads2[] = {         MX6_PAD_RGMII_RD0__RGMII_RD0       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD1__RGMII_RD1       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD2__RGMII_RD2       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD3__RGMII_RD3       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL      | MUX_PAD_CTRL(ENET_PAD_CTRL), }; static void setup_iomux_enet(void) {         imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));         udelay(20);         gpio_direction_output(IMX_GPIO_NR(2, 31), 1); /* Power on enet */         gpio_direction_output(IMX_GPIO_NR(3, 23), 0); /* assert PHY rst */         gpio_direction_output(IMX_GPIO_NR(6, 24), 1);         gpio_direction_output(IMX_GPIO_NR(6, 25), 1);         gpio_direction_output(IMX_GPIO_NR(6, 27), 1);         gpio_direction_output(IMX_GPIO_NR(6, 28), 1);         gpio_direction_output(IMX_GPIO_NR(6, 29), 1);         udelay(1000);         gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* deassert PHY rst */         /* Need delay 100ms to exit from reset. */         udelay(1000 * 100);         gpio_free(IMX_GPIO_NR(6, 24));         gpio_free(IMX_GPIO_NR(6, 25));         gpio_free(IMX_GPIO_NR(6, 27));         gpio_free(IMX_GPIO_NR(6, 28));         gpio_free(IMX_GPIO_NR(6, 29));         imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2)); }           Let's notice that the external PHY is not the same as the SABRESD AR8031. The UDOO features the MICREL KSZ9031 PHY. The latter needs to be defined and the former undefined in the include/configs/mx6_udoo.h file. #undef  CONFIG_PHY_ATHEROS #define CONFIG_PHY_MICREL #define CONFIG_PHY_MICREL_KSZ9031 Besides the PHY address has to be changed. #define CONFIG_FEC_MXC_PHYADDR  6 At this point, the serial console, SD card saving arguments and ethernet should be working. The last point is to configure the LVDS display. The LVDS display of the UDOO board is connected in the same port as the SABRE-SD board, but the operation frequency is different and it has to be modified to work at ~ 33.26MHz for the 7 inches LVDS display.      The mx6_udoo.c file contains a setup_display function that configures the LDB module. This functions is called in the board_early_init_f(). With the current clock configuration is not possible to get  the 33.2MHz for the LVDS and a different clock source for the LDB module must be chosen. The backlight and lvds power signals must be on.           The current configuration uses the mmdc_ch1 clock and to get closer to 33.26MHz the PLL2_PFD0 is chosen.        gpio_direction_output(IMX_GPIO_NR(1, 2), 1); /* LVDS power On */         gpio_direction_output(IMX_GPIO_NR(1, 4), 1); /* LVDS backlight On */         imx_iomux_v3_setup_multiple_pads(di0_pads, ARRAY_SIZE(di0_pads));         enable_ipu_clock();         imx_setup_hdmi();         /* Turn on4LDB0, LDB1, IPU,IPU DI0 clocks */         reg = readl(&mxc_ccm->CCGR3);         reg |=  MXC_CCM_CCGR3_LDB_DI0_MASK | MXC_CCM_CCGR3_LDB_DI1_MASK;         writel(reg, &mxc_ccm->CCGR3);         /* set LDB0, LDB1 clk select to 011/011 */         reg = readl(&mxc_ccm->cs2cdr);         reg &= ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK                  | MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);         reg |= (1 << MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_OFFSET)               | (1 << MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);         writel(reg, &mxc_ccm->cs2cdr); With this changes you can compile the new U-Boot image with ./build_u-boot.sh and then just copy the uboot.imx file to your sd: # sudo cp if=uboot.imx of=/dev/sdX bs=512 seek= 2 && sync 5. TESTING YOUR CHANGES Inser the sd with the U-Boot image to micro sd slot and power up the board. You should get the U-Boot serial console like shown below. In the console you can test the ethernet and phy configuration with the PING command: I hope you find these basic steps useful for different boards.

1) rtsp gst-launch-1.0 rtspsrc location=rtsp://192.168.0.105:10000 name=source ! queue ! rtph264depay ! vpudec ! overlaysink source. ! queue ! rtpmp4gdepay ! aacparse ! beepdec ! alsasink pc side: open vlc, choose media , then choose stream and rtsp, then choose the port to 10000 2)udp imx side: gstream 0.1 version: gst-launch udpsrc do-timestamp=false uri=udp://192.168.0.255:10000 caps="video/mpegts" ! aiurdemux streaming_latency=400 name=d d. ! queue ! vpudec low-latency=true ! queue ! mfw_v4lsink sync=true d. ! queue ! beepdec ! alsasink sync=true gstream 1.0 version: gst-launch-1.0 udpsrc do-timestamp=false uri=udp://192.168.0.255:10000 caps="video/mpegts" ! aiurdemux streaming-latency=400 name=d d. ! queue ! vpudec ! queue ! overlaysink sync=true d. ! queue ! beepdec ! pulsesink sync=true pc side: open vlc , then choose media, then choose stream and add the ts file, then choose dup(legacy) in the destinationsetup, then set the same broadcasting address as the gstreamer command set, then streaming.

1) rtp linux side: gst-launch mfw_v4lsrc fps-n=30 ! vpuenc codec=6 ! queue ! rtph264pay ! udpsink host=192.168.0.105 port=5000 –v pc side: open the attached H264.sdp file using VLC. Then you can find the picture from camera on mx6 board, pls don’t forget to load camera module 2) Receive Pipeline from Board to PC: gst-launch -v gstrtpbin name=rtpbin udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=96' port=5000 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! queue ! ffdec_h264 ! queue ! autovideosink sync=false  udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 sync=false rtpbin.send_rtcp_src_0 ! udpsink port=5005 sync=false async=false Output: Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:send_rtcp_src_0: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:send_rtcp_src: caps = application/x-rtcp /GstPipeline:pipeline0/GstUDPSink:udpsink0.GstPad:sink: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:send_rtcp_src_0.GstProxyPad:proxypad2: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:recv_rtp_sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_sink_0: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_sink_0.GstProxyPad:proxypad1: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:recv_rtp_src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpPtDemux:rtpptdemux0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_src_0_2621786612_96.GstProxyPad:proxypad4: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96 /GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:src: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstQueue:queue1.GstPad:sink: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstQueue:queue1.GstPad:src: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage.GstPad:sink: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0.GstGhostPad:sink: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = video/x-raw-yuv, width=(int)352, height=(int)288, framerate=(fraction)25/1, format=(fourcc)I420, interlaced=(boolean)false /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:sync_src: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_sink: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_src_-1673180684: caps = application/x-rtcp /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink_rtcp: caps = application/x-rtcp ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... Execution ended after 26282965149 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... /GstPipeline:pipeline0/GstUDPSink:udpsink0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstXvImageSink:autovideosink0-actual-sink-xvimage.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0.GstGhostPad:sink: caps = NULL /GstPipeline:pipeline0/GstQueue:queue1.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstQueue:queue1.GstPad:sink: caps = NULL /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:src: caps = NULL /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_src_0_2621786612_96: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:send_rtcp_src_0: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpPtDemux:rtpptdemux0.GstPad:src_96: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpPtDemux:rtpptdemux0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink_rtcp: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:src: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_src_-1673180684: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:src_-1673180684: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:sync_src: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:send_rtcp_src: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:recv_rtp_src: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0.GstPad:recv_rtp_sink: caps = NULL /GstPipeline:pipeline0/GstRtpBin:rtpbin.GstGhostPad:recv_rtp_sink_0: caps = NULL /GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps = NULL Setting pipeline to NULL ... Freeing pipeline ...

This guide is created for introducing how to do DDR3 calibration for mass production. Please read carefully and understand clearly before following it. To be update!

  IMX6 S/DL for consumer has both PXP and IPU. Automotive and Industrial versions doesn't have PXP. As IMX6 also has IPU, the Linux framebuffer driver uses IPU and not PXP. Note : “pxp_v4l2_test.out” from unit_tests was made for processors (i.MX6 SL), that have only PXP and its framebuffer driver applies PXP to accelerate image processing. “pxp_v4l2_test.out” should not be used with i.MX6 S/DL. To test PXP device with i.MX6 S/DL users have to try “pxp_test.out”.

On default i.MX6UL EVK board, it supports three boot device: SD Card boot in main board, micro-SD card boot in CPU board and QSPI-FLASH in CPU board. As we know, i.MX6UL supports NAND device boot and there are NAND device footprint in the EVK board. If customer wants to use NAND boot, there is something to rework in both hardware and software. Hardware Modification NAND device boot mode is conflict with micro-SD card and QSPI-FLASH device boot modes. 1. Remove U303 in CPU board and DO NOT insert micro-SD card into J301 2. Solder U302 NAND FLASH on EVK board Software Modification In Yocto-Linux BSP standard release, NAND device boot is not supported. We need add support in u-boot, linux DTB and MFGTool. 1. u-boot-imx modification and build Replace u-boot-imx/include/configs/mx6ul_14x14_evk.h with the same file in the attachment Copy mx6ul_14x14_evk_nand_defconfig in the attachment to u-boot-imx/configs/ Build the new u-boot.imx: make distclean; make mx6ul_14x14_evk_nand_defconfig;make Rename u-boot.imx to u-boot-imx6ulevk_nand.imx 2. Linux DTB modification and build Copy imx6ul-14x14-evk-gpmi-weim.dts in the attachment to kernel/arch/arm/boot/dts/ Build imx6ul-14x14-evk-gpmi-weim.dtb: make imx6ul-14x14-evk-gpmi-weim.dtb Rename imx6ul-14x14-evk-gpmi-weim.dtb to zImage-imx6ul-14x14-evk-gpmi-weim.dtb 3. MFGTOOL modification Copy mfgtool2-yocto-mx6ul-evk-nand.vbs in the attachment to MFGTOOL root direcory Copy u-boot-imx6ulevk_nand.imx and zImage-imx6ul-14x14-evk-gpmi-weim.dtb to MFGTOOL\Profiles\Linux\OS Firmware\firmware\ Copy u-boot-imx6ulevk_nand.imx and zImage-imx6ul-14x14-evk-gpmi-weim.dtb to MFGTOOL\Profiles\Linux\OS Firmware\files\ Congratulations!!!  You can burn NAND image to i.MX6UL-EVK board with mfgtool2-yocto-mx6ul-evk-nand.vbs script now!!

       The document will introduce all steps for poring BCM4330/BCM43362 WIFI module to freescale android4.2.2 BSP, it includes these contents: --Hardware & Software Environment --Hardware Design Based on BCM43362 module --i.MX6 BSP configuration for WIFI module --BCM4330/BCM43362 dirver for linux 3.0.35 --Integrated to Android4.2.2    If customer has some questions with the porting, contact me , please ! my email address: [email protected] Freescale TICS team Weidong.sun 2015-08-20

I've done some research in Android boot optimization in the past months and have some getting. This page is for recording and sharing purpose only. It's target to provide some hints and directions for Android optimization. It's NOT a Freescale official document or patch release. The code/doc inside is only for reference. Background:      1. I've used SabreSD + Android KK 4.4.2 GA 1.0 as a reference platform.      2. I'm not doing some popular optimization way such as "hibernation", "suspend". I'm trying to "optimize" the boot process by re-arranging the boot process and make GUI related process run earlier and fine tune some boot code for running faster.      3. It's target to the Android IVI product. So, some features that will never be used in a IVI environment will be disabled or removed. Minor of them. I've come out with a patch package (latest is milestone 4 which is "_m4" in the version for short) and  a training document. I didn't find any confidential information from the patch or doc, so I'm open the sharing here. Updated on 2016/01/08 for new version (milestone m5): --------------------------------------------------------------------------------------- Change log against previous (milestone 4) version:      1. BSP base changed to Android KK 4.4.3 GA 2.0 which has a Linux kernel 3.10.53      2. Linux kernel and uboot optimization added. Kernel boot time (POR -> Android init entry) is less than 1.5s.      3. Some bug fixes.      4. Document updated accordingly. Total boot time tested on SabreSDP is about 8s.