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.

The patches are based on iMX53 L2.6.35_ER1109 BSP. In default linux BSP, the followed two pathes were supported in kernel driver mxc_v4l2_capture.c: CSI->IC->MEM CSI->MEM After appied these two patches, it can support the followed path: CSI->VDI->IC->MEM In this mode, the VDI de-interlace will be handled on the fly, so the whole system bandwidth will be reduced. Limitations: 1. Since the IC can only output resolution up to 1024*1024, so this is the limation on output. 2. Only VDI motion mode 2 was supported. mxc_v4l2_tvin_vdi_ic.zip: It is the test aplication, test command: "./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 2" "-i 2" means CSI->VDI->IC->MEM path.

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

The attached is the document and sample code for iMX5 system 80 interface LCD driver based on IPUV3. It is based on iMX51 2.6.31_09.12 BSP (SDK 1.7), tested on iMX53 3-Stack board. 1. Description This is Smartlcd driver for Freescale MX51 SDK1.7 release. (Kernel: 2.6.31_09.12.00/01)  2. File List -- Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch: SmartLCD panel support patch, and unit test code. -- Sample.config: the config file for reference. -- readme.txt: this file, please refer to it before use the package. -- SmartLCD Structure.pptx: the basic structure for smartlcd on IPUv3. 3. Requirement - MX51_3DS Green board(TO2.0) - No hardware rework needed, only need plug the giantplus GMA722A0 to J10. - MX51 SDK1.7 release package - L2.6.31_09.12.00_SDK_source.tar.gz                                - redboot_200952.zip 4. How to use 4.1 How to use demo -- Program default redboot.bin to board via ATKtools -- Copy attached zImage to tftp folder (assume /tftpboot) -- extract default rootfs to NFS folder (assume /nfsroot) -- COPY attached imx51_fb_test to ~/unit_test folder. -- Power on the board -- After redboot is boot up, use following command to boot up linux kernel    load -r -b 0x100000 zImage    exec -c "noinitrd console=ttymxc0 root=/dev/nfsroot rootfstype=nfsroot nfsroot=10.192.225.221:/nfsroot/rootfs rw ip=dhcp" -- Once the linux kernel launched, run following commands to test smartlcd panel.    cd /unit_tests    ./imx51_fb_test 4.2 How to use source code -- Current release code is based on L2.6.31_09.12.00_SDK_source.tar.gz. Extract the file to your working folder. -- Entering the working folder and type "./install", select a folder to install ltib. (such as .../ltib) -- Entering ltib folder and type "./ltib" to build Linux platform.  If you are not familiar with this setp, please refer to doc "i.MX_3Stack_SDK_UserGuide.pdf" for detail. -- Entering folder ".../ltib/rpm/BUILD/linux", copy "Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch" from release package to current folder    Run command "patch -p1 < Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch" -- When complete, run command "make ARCH=arm menuconfig", and you can refer to attached sample.config for detail.    * enable    Device Drivers ----> Graphics support ----> [*]   Asynchronous Panels                                            ----> [*] GiantPlus 240x320 Panel                                             * disable    Device Drivers ----> Graphics support ----> [ ]   Synchronous Panel Framebuffer                                         ----> Multimedia support    ----> [ ]   Video For Linux                                             -- Run command "make ARCH=arm" to build kernel.  4.3 How to do SMARTLCD driver test -- After Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch applied, there will be an folder "IMX51_TEST" under linux. -- Go to that folder, and run "make ARCH=arm", imx51_fb_test will be created. -- Copy imx51_fb_test to rootfs/unit_test. and run. 5. History N/A 6. Known Issue -- V4L2 not working yet.

There are several vulnerabilities been found recently as below: ZIMPERIUM’s report: http://jiveon.jivesoftware.com/mpss/c/7gA/PDcDAA/t.1p4/5z0zjG0pTd2TX1EnZDdFDQ/h3/hAMy2Th8Lsdoz-2BI-2B-2B4FlQpxshE-2Fm9XH3UWXhoYdrt6y4Crt0q1GUsW8pizm7YGWnxGc52SR4U4vCgooHeqoe1S9fu9dc4l1m2ew0Kz-2BSCbA-3D     They are reported as CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828 and CVE-2015-3829.   Trendmicro’s  report:http://blog.trendmicro.com/trendlabs-security-intelligence/trend-micro-discovers-vulnerability-that-renders-android-devices-silent/   All above vulnerabilities are related with stagefright’s stackoverflow, which exist all android version since JellyBean 4.2. The stagefright is the default Multimedia framework in Android’s AOSP source code.   To avoid attacking toward stagefright, it is recommended to have patches in this attach, which should be applied to myandroid/frameworks/av.   Reference: https://github.com/WhisperSystems/TextSecure/issues/381   This document was generated from the following discussion: Android vulnerability related with stagefright   Created by Hui Fang

It is based on L3.0.35_GA4.1.0 BSP.   In default Linux BSP, there are 3 kinds of de-interlace mode, motion =0,1,2 mode, motion mode 0 and 1 will use three fields for de-interlace, and motion mode 2 wil use one field for de-interlace, so the whole fps is 30. In this mode, for motion mode 0 and 1, field 1,2,3 was used for first VDI output frame of display; and field 3,4,5 was used for second VDI output frame of display; field 5,6,7 was used for third VDI output frame of display. One field data (such as 2,4,6) was used only once, so there is data lost.   After applied these patches, the VDI de-interlace output will be 60fps: for motion mode 0 and 1, field 0,1,2 was used for first VDI output frame of display; and field 1,2,3 was used for second VDI output frame of display; field 2,3,4 was used for third VDI output frame of display. So all field data will be used twice, there is no video data lost, the VDI quality was improved.   Kernel patches: 0001-Add-MEM-to-VDI-to-MEM-support-for-IPU.patch 0002-Add-IPU-IC-memcpy-support.patch 0003-IPU-VDI-support-switch-odd-and-even-field-in-motion-.patch 0004-IPU-VDI-correct-vdi-top-field-setting.patch   mxc_v4l2_tvin_imx6_vdi_60fps.zip: this is the test application sample code.   Test commands, parameter "-vd" means double fps VDI: ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 720 -oh 480 -m 0 -vd  

The document includes the following contents: (1)document how to port ov5646 to android jb4.2.2 (2) ov5645 driver for Linux 3.0.35 (3) ov5645 schematic based on i.MX6Q/DL (4)ov5645 for android camera HAL   [Note:]      P5V29A-0JG is a camera module based on OV5645, and PAO532-0JG is based on OV5640, both manufactured by NINGBO SUNNY OPOTECH CO.LTD (China), If customer wants to use them on i.MX6 platform, can send me email to ask for datasheets of P5V29A & PAO532 , or discuss corresponding questions on porting.   Email: [email protected]

For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time.     The attached patch can make the BSP support up to 4 cameras based on 3.10.53 GA 1.1.0 BSP.   The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI   For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel.   In this patch, we given the example driver for Intersil ISL79985. The input to ISL79985 is four CVBS camera. There are four patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch      Updated IPU common code to support up to four cameras.   0002-Add-Intersil-ISL79985-MIPI-Video-Decoder-Driver-for-.patch      ISL79985 driver, which can support both 1 lanes and 2 lanes mode.   0003-Remove-the-page-size-align-requirement-for-v4l2-capt.patch      With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly.   0004-IPU-CSI-Drop-1-2-frame-on-MIPI-interface-for-interla.patch      This patch is option, it will drop one field data, so for each camera, the input will be 720*240 30 FPS.   For 720P HD solution, it is based on Maxim MAX9286: iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP   How to builld the kernel with ISL79985 support:       make imx_v7_defconfig       make menuconfig (In this command, you should select the ISL79985 driver:             Device Drivers  --->                   <*> Multimedia support  --->                         [*]   V4L platform devices  --->                               <*>   MXC Video For Linux Video Capture                                       MXC Camera/V4L2 PRP Features support  --->                                           <*>Intersil ISL79985 Video Decoder support                                           <*>mxc VADC support                                           <*>Select Overlay Rounting (Queue ipu device for overlay library)                                           <*>Pre-processor Encoder library                                           <*>IPU CSI Encoder library)       make zImage       make dtbs   The built out image file:       arch/arm/boot/dts/imx6q-sabresd.dtb       arch/arm/boot/zImage   "mxc_v4l2_tvin.zip" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   2015-10-10 Update: Updated the test application "mxc_v4l2_tvin_isl79985.tar.gz" to fix the Yocto build errors. Updated ISL79985 register setting "page5, isl79985_write_reg(0x07, 0x46)" in patch "0002-Add-Intersil-ISL79985-MIPI-Video-Decoder-Driver-for-.patch", which can fix the green line issue.   2016-01-25 Update: Added de-interlace support, L3.10.53_ISL79985_Surroundview_Patch_20160125.tar.gz New test capplication for de-interlance: mxc_v4l2_tvin_isl79985_vdi_20160125.tar.gz New test commands: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d -m & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d -m & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d -m & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d -m &   Note:  with the 0005-Add-interlaced-mode-capture-for-ISL79985.patch, the V4l2 capture driver will return 720x480 video size, but only odd lines have the video data, they are filled in line skip line mode.     2016-11-21 Update: Added ISL79987 support, L3.10.53_ISL7998x_Surroundview_Patch_20161121.zip New test capplication for de-interlance support: mxc_v4l2_tvin_isl7998x.tar.gz   Test commands (without de-interlace): /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   Test commands (with de-interlace, for ISL79987 only): /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -m 1 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -m 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -m 1 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -m 1 -g2d &     Now the same patch can support both ISL79985 and ISL79987, with NTSC CVBS camera, for ISL79985, it captures 60fps 720*240; for ISL79987, it captures 30fps 720*480.   2016-11-22 Update: Added patch for L4.1.15 BSP, it supports both ISL79985 and ISL79987, L4.1.15_ISL7998x_Surroundview_Patch_20161122.zip Test capplication mxc_v4l2_tvin_isl7998x.tar.gz is re-used.

The document will introduce all steps for poring WM8960 audio codec to freescale android4.2.2 BSP. Attachments include : (1)Document for porting (2)Codec driver : wm8960.c (3)Machine driver: imx-wm8960.c (4)wm8960 schematic for reference (5)Android Audio HAL: config_wm8960.h (6)schematic: MX6QDL-PIANO-CNFV1.DSN (7)i.MX6DL BSP files mx6dl_piano.c mx6dl_piano.h mx6dl_piano_pmic_pfuse100.c (8)i.MX6Q BSP files mx6q_piano.c mx6q_piano.h mx6q_piano_pmic_pfuse100.c   Freescale TICS Team Weidong.sun

There developed the controller uses i.MX53 + Linux. Has developed a solution for building distributed information and control systems. Prototmpy been in operation for over a year. Examples: - Control Electromagnetic stirring (mixer) http://ontecom.com/en/catalog/ems / Rusal, Krasnoyarsk. - Moniroring and management of pumping stations. - Monitoring and control of climate control systems. You can create a smart home systems and iot. There is experience with PLC (Power Line Communication) Qualcomm/Atheros. In my spare time I develop a budget solution for PLC (Power Line Communication) control / monitoring components smart home. Based on the standard IEC 61131-3 developed software - distributed information management system. The solution is cross-platform. In a single system may be computers of different architectures and various operating systems. Such signals are synchronized controller ARM / Linux, and x86 server (Win, Linux, VMS, ...) Uses wxWidgets. Articles on this subject is, but in Russian.

i.MX6UL Hardware design checklist v0.1