First upload the U-Boot firmware using Network (Transferring file over network) or Serial (Transferring file over serial) This is a common serial transfer output: => loady ## Ready for binary (ymodem) download to 0xa0800000 at 115200 bps... CCmode, 1359(SOH)/0(STX)/0(CAN) packets, 9 retries ## Total Size      = 0x0002a388 = 172936 Bytes Unprotect the bootloader flash area: protect off C0000000 C003FFFF Erase the flash blocks: erase C0000000 C003FFFF Copy from RAM to Flash: If firmware has been thansfered over serial: cp.b A0800000 C0000000 2a388 If firmware has been transfered over tftp: cp.b 100000 C0000000 2a388 Installing U-Boot using BDI3000 You can use a BDI2000/3000 to write to the S71WS256 pSRAM: Get this config file. Thanks to the folks at Ultimate Solutions for being such a nice people and writing an almost ready file! Edit the [FLASH] section to this: [FLASH] CHIPTYPE              S29M32X16 CHIPSIZE                0x2000000 BUSWIDTH             16 FILE                        /home/lsantos/work/i.mx27/u-boot/u-boot-v2/uboot.bin ; change to you path FORMAT                 BIN 0xC0000000 ERASE                   0xC0000000 ERASE                   0xC0008000 ERASE                   0xC0018000 ERASE                   0xC0010000 ERASE                   0xC0020000 Don't forget to edit the [HOST] section to your machine's IP address. Telnet to the BDI - CONFIG: loading configuration file passed - CONFIG: loading register definition passed - TARGET: processing reset request - TARGET: BDI asserts TRST and RESET - TARGET: BDI removes TRST - TARGET: Bypass check 0x00000001 => 0x00000002 - TARGET: JTAG exists check passed - Core#0: ID code is 0x07926121 - TARGET: All ICEBreaker access checks passed - TARGET: BDI removes RESET - TARGET: BDI waits for RESET inactive - TARGET: resetting target passed - TARGET: processing target startup .... - TARGET: processing target startup passed Erase the first 128 KiB ADS>erase Erasing flash at 0xc0000000 Erasing flash at 0xc0008000 Erasing flash at 0xc0018000 Erasing flash at 0xc0010000 Erasing flash at 0xc0020000 Erasing flash passed Write the flash ADS>prog Programming /home/lsantos/work/i.mx27/u-boot/u-boot-v2/uboot.bin , please wait .... Programming flash passed Check everything went really well ADS>verify Verifying /home/lsantos/work/i.mx27/u-boot/u-boot-v2/uboot.bin , please wait .... Verifying target memory passed Now you can unplug the BDI and reset the board U-Boot 2.0.0-rc9-00136-gbf725a2-dirty (Jun 17 2009 - 15:45:23)  Board: Freescale i.MX27 ADS cfi_probe: cfi_flash base: 0xc0000000 size: 0x02000000  chip id: [2,882,1,01d] mpll:     265999329 Hz spll:     239999725 Hz arm:      177332886 Hz perclk1:    8866644 Hz perclk2:   17733288 Hz perclk3:   44333221 Hz perclk4:   17733288 Hz clkin26:   26000000 Hz ahb:       44333221 Hz ipg:       22166610 Hz Malloc space: 0xa7b00000 -> 0xa7f00000 (size  4 MB) Stack space : 0xa7af8000 -> 0xa7b00000 (size 32 kB) envfs: wrong magic on /dev/env0 no valid environment found on /dev/env0. Using default environment running /env/bin/init...  Hit any key to stop autoboot:  2  type update_kernel [<imagename>] to update kernel into flash type udate_root [<imagename>] to update rootfs into flash  uboot:/ Of course, this setup works with Redboot, just change the FILE entry at the [FLASH] section or use the prog command: ADS>prog 0xc0000000 /home/lsantos/work/i.mx27/redboot/build/install/bin/redboot.bin BIN Programming /home/lsantos/work/i.mx27/redboot/build/install/bin/redboot.bin , please wait .... Programming flash passed ADS>verify Verifying /home/lsantos/work/i.mx27/redboot/build/install/bin/redboot.bin , please wait .... Verifying target memory passed Rebooting ++... Read from 0x07ee0000-0x07f00000 at 0xc1fe0000: . ... Read from 0x07ed3000-0x07ed4000 at 0xc1fff000: . **Warning** FLASH configuration checksum error or invalid key Use 'fconfig -i' to [re]initialize database PMIC ID: 0x0000009b [Rev: 3.3] Ethernet FEC MAC address: is not set  Board Type: ADS Clock input: 26 MHz Booting from [NOR flash]  PHY ID 22 @ 1 FEC: [ HALF_DUPLEX ] [ disconnected ] [ 10M bps ]: Ethernet eth0: MAC address 00:04:9f:00:af:7a Can't get BOOTP info for device!  RedBoot(tm) bootstrap and debug environment [ROMRAM] Non-certified release, version FSL 200749 - built 19:37:28, Jun 17 2009  Platform: MX27 ADS/EVB (Freescale i.MX27 based) PASS 2.1 [x32 SDR] Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.  RAM: 0x00000000-0x07f00000, [0x00025260-0x07ed1000] available FLASH: 0xc0000000 - 0xc2000000, 256 blocks of 0x00020000 bytes each. RedBoot>

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

GStreamer has a simple feature to enable tracing, allowing the developer to do basic debugging. These can be done in two ways: Adding the parameter --gst-debug=LIST to the pipeline (a pipeline is a executed gst-launch command) Prepending the environment variable GST_DEBUG=LIST' LIST is a a comma-separated argument, indicating the GStreamer elements to trace. For example, if one needs to trace the sink element      $ GST_DEBUG=*sink*:5 gst-launch playbin2 uri=file:///sample.avi or      $ gst-launch playbin2 uri=file:///sample.avi --gst-debug=*sink*:5 Both commands produces the same log. In case want to trace for than one element, so can simple add the <element>:5, for example      $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi The number 5 indicates the log category, where 5 is the highest (the most verbose log you can get) and 0 produces no output (5=LOG, 4=DEBUG, 3=INFO, 2=WARN, 1=ERROR). Log can be huge in each pipeline run. One way to filter it is using the grep command. Before grepping, one needs to redirect the standard error to the standard output (GStreamer log goes always to stderr), so      $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi 2>&1 | grep <filter string> In case the log needs to be shared, it is important to remove the 'color' of the log, again, one just needs to add the parameter --gst-debug-no-color or prepend the env variable GST_DEBUG_NO_COLOR=1 ----- More shell variables that GStreamer react, can be found here https://developer.gnome.org/gstreamer/0.10/gst-running.html

About this document This document describe the setup detail for Interfacing, Installing, programming (basis) and testing depth cameras with MX6QDL based boards using the Robotic Operating System (ROS). If you are not using ROS you can also install the proper drivers and compile, in your Ubuntu system as explained on document:  https://community.freescale.com/docs/DOC-330278 1. Software & Hardware requirements Supported NXP HW boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board Depth sensors tested: Microsoft Kinect, ASUS Xtion. Software:   Gcc, Ubuntu 14.04v, OpenCV, Openni, Python, ROS. 2. Installation on ROS For installation steps of ROS on iMX6 boards in your board, please follow up: https://community.freescale.com/docs/DOC-3301478 Before you can use ROS, you will need to initialize rosdep. It enables you to easily install system dependencies for source you want to compile and is required to run some core components in ROS. $ sudo rosdep init $ rosdep update There are many different libraries and tools in ROS - not all compile fully on ARM. In this case we already have installed the ROS Base, however any other packages need to be installed individually. First install the following dependencies, which will take some time and space (~1.4 GB): $ sudo apt-get install --no-install-recommends freeglut3-dev libfreenect-dev libusb-1.0-0-dev libudev-dev ros-indigo-camera-info-manager ros-indigo-dynamic-reconfigure ros-indigo-image-transport ros-indigo-image-proc ros-indigo-depth-image-proc ros-indigo-tf ros-indigo-openni-launch ros-indigo-freenect-* ros-indigo-depthimage-to-laserscan ros-indigo-image-view ros-indigo-camera-info-manager ros-indigo-dynamic-reconfigure libudev-dev doxygen graphviz openjdk-6-jdk ros-indigo-openni2-camera ros-indigo-openni2-launch ros-indigo-rqt-common-plugins ros-indigo-rqt-graph There is no any additional installation to run kinect with ROS, If you are using kinect you can pass to part 4. However the packages used to run the PrimeSense / Asus Xtion on the i.Mx6 are not available over apt yet, so they need to be compiled from source. To use OpenNI2 with ROS, we only need the shared OpenNI2 libraries and the Drivers. Clone OpenNI2 $ git clone https://github.com/OpenNI/OpenNI2 $ cd OpenNI2 Edit ThirdParty/PSCommon/BuildSystem/Platform.Arm $ nano ThirdParty/PSCommon/BuildSystem/Platform.Arm and replace CFLAGS += -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp #-mcpu=cortex-a8 with CFLAGS += -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard Add support for pthread library: $ nano ThirdParty/PSCommon/BuildSystem/CommonCppMakefile Search the line 95 and add the code between the two lines: OUTPUT_NAME = $(EXE_NAME)                                                   # We want the executables to look for the .so's locally first:     LDFLAGS += -Wl,-rpath ./ +   ifneq ("$(OSTYPE)","Darwin") +       LDFLAGS += -lpthread +   endif     OUTPUT_COMMAND = $(CXX) -o $(OUTPUT_FILE) $(OBJ_FILES) $(LDFLAGS) endif Save the file and exit Then run make to compile the OpenNI2 drivers and libraries $ PLATFORM=Arm make ALLOW_WARNINGS=1 Once the compilation is done, run the linux install script $ cd Packaging/Linux $ sudo ./install.sh Copy libraries and includes to the system paths $ cd ../../ $ sudo cp -r Include /usr/include/openni2 $ sudo cp -r Bin/Arm-Release/OpenNI2 /usr/lib/ $ sudo cp Bin/Arm-Release/libOpenNI2.* /usr/lib/ Create a package config file $ sudo nano /usr/lib/pkgconfig/libopenni2.pc and fill it with this: prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include/openni2 Name: OpenNI2 Description: A general purpose driver for all OpenNI cameras. Version: 2.2.0.0 Cflags: -I${includedir} Libs: -L${libdir} -lOpenNI2 -L${libdir}/OpenNI2/Drivers -lDummyDevice -lOniFile -lPS1080.so This will enable ubuntu to find the location of the drivers, libraries and include files. To make sure it is correctly found, run $ pkg-config --modversion libopenni2 Which should give the same version as defined in the file above (2.2.0.0). Now the Xtion is ready to be used. Plug it in (if it is already, unplug it first), then run the sample program $ ./Bin/Arm-Release/SimpleRead Then create a catkin workspace as described here, and check out the following packages in the src folder of the catkin workspace: $ cd ~/catkin_ws/src $ git clone https://github.com/ros-drivers/openni2_camera $ git clone https://github.com/ros-drivers/openni2_launch $ git clone https://github.com/ros-drivers/rgbd_launch Now the ros packages checked out above to the catkin workspace can be compiled with catkin_make $ cd ~/catkin_ws $ catkin_make Once the packages are compiled, the Xtion is ready for use with ROS with 3. Testing The Installation Kinect. Open at least 3 bash terminals: Terminal 1: Run ROS $ roscore Terminal 2:  launch the Freenect $ roslaunch freenect_launch freenect.launch Terminal 3: run the image capture $ rosrun image_view image_view image:=camera/rgb/image_color or: $ rosrun image_view image_view image:=camera/rgb/image_rect_mono or: $ rosrun image_view disparity_view image:=camera/depth/disparity It will open a new terminal with the rgb points, mono  and depth images  from the Kinect. Xtion.  Terminal 1: Run ROS $ roscore Terminal 2:  launch Openni2 $ roslaun openi2_launch openni2.launch Terminal 3: you can use rqt or Rviz session to visualize the sensor e.g: $ rqt or $ rosrun rqt_graph rqt_graph In the “rqt” window select “Plugins” -> “Visualization” -> “Image View“                                                             (optional) Install PySide, in any case you get an error with python rqt graph: $ pip install PySide $ cd ~/ Note: rqt and Rviz demand a lot of i.MX GPU work, so general graphic functionality will be affected. For this case is suggested to run rviz in a remote Network ROS session. References: -       www.ros.org -     https://dobots.nl/2014/05/05/asus-xtion-using-openni2-and-ros-on-udoo/

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 ...

If your target system does not have an Ethernet port it is possible to transfer files, such as the kernel image over serial port, using ymodem. On minicom: RedBoot> load -r -b 0x100000 -m ymodem zImage Where "zImage" is the file to be transferred. On minicom press "CTRL + a" and "s", choose ymodem and select the file to be transferred.

Here we show how to generate a minimal root filesystem fairly quickly with BusyBox, for the i.MX6 sabre sd platform. This document assumes you are able to boot a Linux kernel on your platform already. See this post for details on how to do it. This implies you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). busybox is so small that we will go for a ramdisk as our main root filesystem. Get busybox sources We will use git to fetch busybox sources:   $ git clone git://git.busybox.net/busybox This should create a busybox directory with all the latest sources. Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l, and git checkout <the-desired-tag>. Compile Assuming your cross compiler is called e.g. arm-linux-gnueabihf-gcc, you can compile by doing:   $ cd busybox   $ export ARCH=arm   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make defconfig   $ sed -i.orig 's/^#.*CONFIG_STATIC.*/CONFIG_STATIC=y/' .config   $ make   $ make install This should create an _install folder hierarchy containing binaries and links. Note that we force the build of a static binary with the sed command. Configure the root filesystem We need to add some more configuration into the _install folder before we can call it a minimal filesystem. Create some folders We need to create some mountpoints and folders:   $ mkdir _install/dev   $ mkdir _install/proc   $ mkdir _install/sys   $ mkdir -p _install/etc/init.d Add some configuration files and scripts We need to prepare the main init configuration file, _install/etc/inittab, with this contents:   ::sysinit:/etc/init.d/rcS   ::askfirst:/bin/sh   ::ctrlaltdel:/sbin/reboot   ::shutdown:/sbin/swapoff -a   ::shutdown:/bin/umount -a -r   ::restart:/sbin/init This is very close to the default behavior busybox init has with no inittab file. It just suppresses some warnings about missing tty. We need to add some more configuration to mount a few filesystems at boot for convenience. This is done with an _install/etc/fstab file containing:   proc     /proc proc     defaults 0 0   sysfs    /sys  sysfs    defaults 0 0   devtmpfs /dev  devtmpfs defaults 0 0 We also need to actually trigger the mount in the _install/etc/init.d/rcS script, which is called from the inittab. It should contain:   #!/bin/sh   mount -a And we need to make it executable:   $ chmod +x _install/etc/init.d/rcS Generate the ramdisk contents Now that we have adapted the root filesystem contents, we can generate a busybox ramdisk image for u-boot with the following commands:   $ (cd _install ; find |cpio -o -H newc |gzip -c > ../initramfs.cpio.gz)   $ mkimage -A arm -T ramdisk -d initramfs.cpio.gz uInitrd This results in a uInitrd file, suitable for u-boot. Prepare a boot script The default u-boot commands are not sufficient to boot our system, so we need to edit a boot.txt file with the following contents:   run loaduimage   run loadfdt   setenv rdaddr 0x13000000   fatload mmc ${mmcdev}:$mmcpart $rdaddr uInitrd   setenv bootargs console=${console},${baudrate} rdinit=/sbin/init   bootm $loadaddr $rdaddr $fdt_addr Then we generate a boot.scr script, which can be loaded by u-boot with:   $ mkimage -A arm -T script -d boot.txt boot.scr Put on SD card Assuming you have prepared your SD card with u-boot and Linux as explained in this post, you have a single FAT partition on your card with your kernel and dtb. Our boot script and ramdisk image should be copied alongside:   $ mount /dev/<your-sd-card-first-partition> /mnt   $ cp uInitrd boot.scr /mnt/   $ umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or /dev/mmcblk<X>p1. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do achmod a+w as root on the SD card device node to grant permissions to users. Boot! Your SD card is ready for booting. Insert it in the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. Your busybox system should boot to a prompt:   ...   Freeing unused kernel memory: 292K (806d5000 - 8071e000)   Please press Enter to activate this console. After pressing enter you should have a functional busybox shell on the target. Enjoy! See also... For a more featured root filesystem you might want to try a Debian filesystem in a second SD card partition, as explained in this post, or generate your filesystem with Buildroot. If you plan to compile busybox often, you might want to use a C compiler cache; see this post.

on Host: libx11-dev libpng-dev libjpeg-dev libxext-dev x11proto-xext-dev qt3-dev-tools-embedded libxtst-dev On Target (i.MX device) alsa-utils libpng tslib

U-Boot is a bootloader, which supports some i.MX SoCs. Configuring U-Boot LTIB Creating Uimage Uboot U-boot FW Printenv FW Env File Add New i.MX5x Board on LTIB i.MX25 PDK I.MX25 PDK U-boot SplashScreen I.MX25 PDK U-boot SDCard i.MX27 ADS Board Compiling U-Boot for i.MX27ADS i.MX31 ADS Board I.MX31ADS Installing Uboot Blink i.MX31 PDK LEDs Using U-Boot i.MX51 EVK Board i.MX51 EVK U-boot i.MX51 EVK Compiling U-boot i.MX51 EVK Changing Env I.MX51EVK Install U-Boot i.MX53 Board i.MX53 USB Eth NFS i.MX53 ARD Dual LVDS i.MX53 QSB Board Get Started Additional Resources Script to Flash a Linux System into a SD card All Boards U-boot All Boards LTIB Creating Uimage Uboot Configuring U-Boot Running a Script in U-boot Transferring File Over Serial Transferring file over network U-boot.bin

Hi All, The new Android JB4.2.2_1.0.0-GA release is now available on www.freescale.com ·         Files available Name Description IMX6_JB422_100_ANDROID_DOCS i.MX 6Quad, i.MX 6Dual, and   i.MX 6DualLite Android jb4.2.2_1.0.0 BSP Documentation. Includes Release   Notes, User's Guide, QSG and FAQ Sheet. IMX6_JB422_100_ANDROID_SOURCE i.MX 6Quad, i.MX 6Dual, and   i.MX 6DualLite Android jb4.2.2_1.0.0 BSP, Documentation and Source Code for   BSP and Codecs. IMX6_JB422_100_ANDROID_DEMO i.MX 6Quad, i.MX 6Dual, and   i.MX 6DualLite Android jb4.2.2_1.0.0 BSP Binary Demo Files ·         Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board ·         Release Description i.MX Android jb4.2.2_1.0.0-ga is GA release for Android 4.2.2 Jelly Bean(JB) on i.MX6Q SABRE SD, i.MX6DL SABRE SD and i.MX6Q/DL SABRE AI platform with key features integrated. i.MX Android jb4.2.2_1.0.0-ga release includes all necessary codes, documents and tools to assist users in building and running Android 4.2.2 on i.MX6Q and i.MX6DL hardware board from the scratch. The prebuilt images are also included for a quick trial on Freescale i.MX6Q, i.MX6DL SABRE SD and i.MX6Q/DL SABRE AI boards. Most of deliveries in this release are provided in source code with the exception of some proprietary modules/libraries from third parties. ·         Features Feature i.MX6Q   SABRE SD i.MX6DL   SABRE SD i.MX6   SABRE AI Comments Linux 3.0.35  kernel Y Y Y Based on Linux BSP   L3.0.35_4.0.0 GA release Google JellyBean   4.2.2 release Y Y Y Based on   android-4.2.2_r1 release Bootup with Android Y Y Y Boot source eMMC& External SD eMMC& External SD SD&Nand Default Nand chip   been support is Micron MT29F8G08ABABAWP Splash Screen for   LVDS Y Y N UI (input) Multi-touch on LVDS   panel Multi-touch on LVDS panel Multi-touch on LVDS   panel UI (display) LVDS panel, HDMI   display LVDS panel, HDMI   display LVDS panel, HDMI   display UI (dual display,   LVDS+HDMI, UI mirror displayed on second device) Y Y Y UI (brightness   control) Y Y Y UI (LiveWallpaper) Y Y Y Storage - External   Media Y Y Y SD, External SD and   UDisk Storage - MTP   (Media Transfer Protocol) Y Y Y Connectivity -   Ethernet Y Y Y Connectivity - BT     Y Y     N Hardware: ·           Atheros AR3001 ·           Atheros AR3002 Profiles: ·           A2DP ·           HID ·           OPP ·           PBAP Connectivity - WiFi Y Y     Y Hardware: ·           Atheros AR6103 SDIO card Features: ·           AP mode ·           Wake on Wireless Connectivity -   3G Y Y   N Hardware: ·           HUAWEI EM770W modem ·           Infinion Amazon 1 modem ·           ZTE FM210 modem Connectivity -   GPS Y Y N Connectivity - USB Tethering Y Y Y Support WIFI and   Ethernet as upstream Internet - SIP   voice call N N N Internet - VPN Y Y Y Power - Battery   status report Y Y N/A Known limitations   about the accuracy in some use cases Power - CPU Freq Y Y Y Power - Bus Freq Y Y Y Media - Music Play Y Y Y Media - Sound Record Y Y Y Media - Video Play Y Y Y Media - Camera Y Y N Media - TVIN N/A N/A Y PAL/NTSC Media - Dual Camera Y Y Y Hardware for SABRE SD: ·           Front Camera: OV5642 CSI camera ·           Rear Camera: OV5640 MIPI camera Hardware   for SABRE AI: ·           Front Camera: UVC camera ·           Rear Camera: TV IN Media - Camcorder Y Y N Media - USB Camera Y Y Y Logitech: ·           C250 ·           E3500 Media - USB Micro Y Y Y Media - Movie   Studio Y Y Y Media - HDMI audio output Y Y Y Graphic - HW 3D   acceleration Y Y Y OpenGLES 1.1/2.0   via GC2000 or GC800 3D core Graphic - HW   accelerated UI surface composition Y Y Y Misc - ADB over USB Y Y Y Misc - Fastboot   utility Y Y Y Misc - SW update   and factory reset Y Y Y Sensor - Magmatic Y Y N Sensor -   Accelerometer Y Y N Sensor - Light Y Y N NTFS-3G File System Y Y Y For external   Storage NAND N N Y Tested NAND chip: - Micro 29F8G08ABABA ·         Change List The below section lists the big changes in JellyBean which need the user’s attention when comparing to Freescale ICS version: o   Default Android multiple display implementation in JellyBean o   Display resolution change in Setting is not been supported o   New camera hal implementation based on JellyBean libcamera2 o   Add NTFS file system support for external storage ·         Known issues For known issues and limitations please consult the release notes

D1 Capture - kernel 2.6.22 diff --exclude CVS -uNr linux-2.6.22/include/asm-arm/arch-mxc/memory.h linux-2.6.22.modified/include/asm-arm/arch-mxc/memory.h --- linux-2.6.22/include/asm-arm/arch-mxc/memory.h     2009-07-16 16:29:45.000000000 -0300 +++ linux-2.6.22.modified/include/asm-arm/arch-mxc/memory.h     2009-07-15 15:38:34.000000000 -0300 @@ -28,6 +28,7 @@     /* Size of contiguous memory for DMA and other h/w blocks */     #define CONSISTENT_DMA_SIZE     SZ_16M    +     /*!      * @defgroup Memory_MX27 Memory Map      * @ingroup MSL_MX27 @@ -48,7 +49,7 @@     #ifdef CONFIG_DMA_ZONE_SIZE     #define MXC_DMA_ZONE_SIZE     ((CONFIG_DMA_ZONE_SIZE * SZ_1M) >> PAGE_SHIFT)     #else    -#define MXC_DMA_ZONE_SIZE     ((12 * SZ_1M) >> PAGE_SHIFT)   +#define MXC_DMA_ZONE_SIZE     ((20 * SZ_1M) >> PAGE_SHIFT)     #endif      static inline void __arch_adjust_zones(int node, unsigned long *zone_size, diff --exclude CVS -uNr linux-2.6.22/drivers/media/video/mxc/capture/mxc_v4l2_capture.c linux-2.6.22.modified/drivers/media/video/mxc/capture/mxc_v4l2_capture.c ---    linux-2.6.22/drivers/media/video/mxc/capture/mxc_v4l2_capture.c     2009-07-16 16:29:43.000000000 -0300 +++ linux-2.6.22.modified/drivers/media/video/mxc/capture/mxc_v4l2_capture.c     2009-07-16 16:08:02.000000000 -0300 @@ -1650,9 +1650,9 @@                  /* setup cropping */                 cam->crop_bounds.left = 0; -             cam->crop_bounds.width = 640; +             cam->crop_bounds.width = 800;                 cam->crop_bounds.top = 0; -             cam->crop_bounds.height = 480; +             cam->crop_bounds.height = 600;                 cam->crop_current = cam->crop_defrect = cam->crop_bounds;                 ipu_csi_set_window_size(cam->crop_current.width,                                                       cam->crop_current.height); @@ -1663,7 +1663,7 @@                 cam->standard.id = V4L2_STD_UNKNOWN;                 cam->standard.frameperiod.denominator = 30;                 cam->standard.frameperiod.numerator = 1; -             cam->standard.framelines = 480; +             cam->standard.framelines = 600;                 cam->streamparm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;                 cam->streamparm.parm.capture.timeperframe =                 cam->standard.frameperiod; cam->streamparm.parm.capture.capability = V4L2_CAP_TIMEPERFRAME; diff --exclude CVS -uNr linux-2.6.22/drivers/media/video/mxc/capture/ov2640.c linux-2.6.22.modified/drivers/media/video/mxc/capture/ov2640.c ---    linux-2.6.22/drivers/media/video/mxc/capture/ov2640.c     2009-07-16 16:29:45.000000000 -0300 +++ linux-2.6.22.modified/drivers/media/video/mxc/capture/ov2640.c     2009-07-16 16:07:03.000000000 -0300 @@ -698,12 +698,12 @@     #endif                            g_cam->streamparm.parm.capture.capturemode = 1;                 } else { -          out_width = 640; -          out_height = 480; +          out_width = 800; +          out_height = 600;                 g_cam->crop_bounds.left = 0; -          g_cam->crop_bounds.width = 640; +          g_cam->crop_bounds.width = 800;                 g_cam->crop_bounds.top = 0; -          g_cam->crop_bounds.height = 480; +          g_cam->crop_bounds.height = 600;                 g_cam->crop_current = g_cam->crop_defrect = g_cam->crop_bounds;     #ifdef CONFIG_ARCH_MX3                              ipu_csi_set_window_size(g_cam->crop_current.width ,

Question: Did we tested active PCIe components while the Cortex-A9 was in Sleep Mode (suspend to memory)? Answer: It's a known issue that PCIe can't support suspend/resume. And can't be built in kernel image if the system want suspend/resume. I think PCIe will be active while core is in sleep more. Is it different scenario? No, the pcie core is not active, it is in L2 state after suspend, and it can't resume back to L0 state when system resume is called. So, DO NOT let pcie do suspend operation right now. BTW, the tested device: * INTEL x1 1000M CT network card. * INTEL iwl wifi cards. * x1 pcie to usb3.0 card Yes, this patch had been tested on imx_3.0.35_4.0 release, and would be merged into next 3.0.35 release. TO1.2 is used. We tested the Patch against imx_3.0.35_4.0 release

We use flash header which will be access by ROM code to do the NAND boot or secure boot. This is a document introduce the flash header.

Question: If the i.mx6’s internal real time clock is not used,  instead an external I2C device is used,  does this create a problem with using any of the i.mx6’s security features? Answer: iMX6 Secure features uses and internal real time counter (SRTC) which if enabled and reaches the maximum value it generates an interrupt informing a security violation. External RTC can't be used in security iMX6 context. I2C external RTC for applications is needed, but for security features SNVS uses the internal SRTC. Question: If I'm interpreting your comments correctly - The customers external RTC can't be used in the context of iMX6 security but can still used be used for their applications needs.  To utilize the security features of the SNVS Module (RM Chp. 60), it must use the internal SRTC.  Disabling or otherwise not implementing the requirements the SNVS module has a cascading effect on many other security features such as High-Assurance Boot (HAB) and CAAM operation.  So it seems that if the customer must have an external RTC, they should still implement the requirements of the internal SNVS/SRTC. Answer: That's the case if secure features are needed they will end up using the internal SRTC, actually I don't think is possible to be used in other scenario as is part of SNVS. Question: To better understand the implications of not having battery backup for the SNVS supply as it pertains to security, if it is normally powered all the time via either a local AC supply or POE+ and is never powered down except for service, and reboots are done with a pushbutton. Given this, can you list what types of security features cannot be implemented or will be problematic? Answer: ???

The default FSL android BSP support 1 SD card slot. If customer need to support more sd slot in android.Please reference below steps. There are two steps need to set up. 1 device/fsl.git NOTE: 1  change the fstab. 2194000 is the address of usdhc2.             2  change the mount point in storage_list.xml diff --git a/sabresd_6dq/fstab.freescale b/sabresd_6dq/fstab.freescale index 7f23edb..1529a27 100644 --- a/sabresd_6dq/fstab.freescale +++ b/sabresd_6dq/fstab.freescale @@ -4,6 +4,7 @@ # specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK /devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host /mnt/media_rw/extsd vfat defaults voldmanaged=extsd:auto +/devices/soc0/soc.0/2100000.aips-bus/2194000.usdhc/mmc_host /mnt/media_rw/extsd_expand vfat defaults voldmanaged=extsd_expand:auto /devices/soc0/soc.0/2100000.aips-bus/2184000.usb/ci_hdrc.0  /mnt/media_rw/udisk vfat defaults voldmanaged=udisk:auto /dev/block/mmcblk3p5    /system      ext4    ro,barrier=1                                                                               wait,verify /dev/block/mmcblk3p4    /data        ext4    nosuid,nodev,nodiratime,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic    wait,encryptable=/dev/block/mmcblk3p9 diff --git a/sabresd_6dq/overlay/frameworks/base/core/res/res/xml/storage_list.xml b/sabresd_6dq/overlay/frameworks/base/core/res/res/xml/storage_list.xml index 3639bdc..c3f5105 100644 --- a/sabresd_6dq/overlay/frameworks/base/core/res/res/xml/storage_list.xml +++ b/sabresd_6dq/overlay/frameworks/base/core/res/res/xml/storage_list.xml @@ -41,6 +41,10 @@               android:storageDescription="@string/storage_sd_card"               android:primary="false"               android:removable="true" /> +    <storage android:mountPoint="/storage/extsd_expand" +             android:storageDescription="@string/storage_sd_card" +             android:primary="false" +             android:removable="true" />      <storage android:mountPoint="/storage/udisk" 2  system/core.git NOTE: mkdir the mount point. build@scmbld2:~/maddev_lp5.1_consolidate_ga_10_30/system/core/rootdir$ git diff diff --git a/rootdir/init.rc b/rootdir/init.rc index 2211cc2..fac37c2 100644 --- a/rootdir/init.rc +++ b/rootdir/init.rc @@ -72,7 +72,9 @@ on init      mkdir /storage 0751 root sdcard_r      mkdir /mnt/media_rw/extsd 0755 system system +    mkdir /mnt/media_rw/extsd_expand 0755 system system      symlink /mnt/media_rw/extsd /storage/extsd +    symlink /mnt/media_rw/extsd_expand /storage/extsd_expand      mkdir /mnt/media_rw/udisk 0755 system system

►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

Fixing Redboot RAM bug (CSD1 not activated) Introduction i.MX 35 PDK board has 256 MB of RAM, due to a bug in Redboot bootloader compiled for the board effectively there is only 128 MB available.This procedure fixes this bug to be able to use 256 MB of RAM. Redboot supporting 256 MB of RAM 1. Download the attached Redboot256.bin file. 2. Flash the new redboot image instead of the old one: Configuring RedBoot

You can but building times will take much longer (approximately 2 times longer for the core-image-minimal) compared to a build done on a native machine. In case you can not do the build on a native machine, make sure your virtual has enough hard-disk room (at least 50GB). For example, these are the build folders sizes after baking core-image-minimal: build$ du -h --max-depth=1 1.3G    ./sstate-cache 3.2M    ./cache 12K    ./.hob 32K    ./conf 22G    ./tmp 23G    . The tmp folder is by far the largest (containing building statistics, source code, deployed images, etc.) build/tmp$ tree -L 2 -d . ├── buildstats │   ├── cogl-imx6qsabresd │   ├── fsl-image-gui-imx6qsabresd │   ├── fsl-image-gui-sdk-imx6qsabresd │   ├── mesa-dri-imx6qsabresd │   ├── mesa-imx6qsabresd │   └── pseudo-native-imx6qsabresd ├── cache │   └── default-eglibc ├── deploy │   ├── images │   ├── licenses │   └── rpm ├── log │   ├── cleanlogs │   └── cooker ├── pkgdata │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   └── imx6qsabresd-poky-linux-gnueabi ├── sstate-control ├── stamps │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   ├── work-shared │   └── x86_64-linux ├── sysroots │   ├── imx6qsabresd │   ├── imx6qsabresd-tcbootstrap │   └── x86_64-linux ├── work │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   └── x86_64-linux └── work-shared     └── gcc-4.7.2-r13

UPDATE: Note that this document describes eIQ Machine Learning Software for the NXP L4.14 BSP release. Beginning with the L4.19 BSP, eIQ Software is pre-integrated in the BSP release and this document is no longer necessary or being maintained. For more information on eIQ Software in these releases (L4.19, L5.4, etc), please refer to the "NXP eIQ Machine Learning" chapter in the Linux User Guide for that specific release.  Original Post: eIQ Machine Learning Software for iMX Linux 4.14.y kernel series is available now. The NXP eIQ™ Machine Learning Software Development Environment enables the use of ML algorithms on NXP MCUs, i.MX RT crossover processors, and i.MX family SoCs. eIQ software includes inference engines, neural network compilers, and optimized libraries and leverages open source technologies. eIQ is fully integrated into our MCUXpresso SDK and Yocto development environments, allowing you to develop complete system-level applications with ease. Source download, build and installation Please refer to document NXP eIQ(TM) Machine Learning Enablement (UM11226.pdf) for detailed instructions on how to download, build and install eIQ software on your platform. Sample applications To help get you started right away we've posted numerous howtos and sample applications right here in the community. Please refer to eIQ Sample Apps - Overview. Supported platforms eIQ Machine learning software for i.MX Linux 4.14.y supports the L4.14.78-1.0.0 and L4.14.98-2.0.0 GA releases running on i.MX 8 Series Applications Processors. For more information on artificial intelligence, machine learning and eIQ Software please visit AI & Machine Learning | NXP.

Extending to the impact produced by being the First to release WEC7 on i.MX6 Development Platform, iWave Systems adds yet another accomplishment by announcing the availability of Windows Embedded Compact 7 (WEC7) reference BSP for Freescale’s i.MX6x SABRE SDB/SDP. The Freescale’s i.MX6x SABRE SDB/SDP Platform is powered with Freescale’s i.MX6 Quad/Dual Lite 1GHz, MMPF0100 Freescale PMIC. The WEC7 BSP release supports SATA II, Standard SD/SDIO, Gigabit Ethernet, LVDS, Touch Panel, HDMI port and also necessary hardware codecs supported by the CPU. Debugging tools like KITL and CETK are also supported. All the latest features that WEC7 offers such as Silverlight 3.0, MPEG-4 HD, Expression Blend, Active Sync and also Adobe Flash10.1 are made available.                                                                                                                                                                 Benefits: WEC7 Source code can be easily customized with respect to the target hardware platform Simple and low cost integration for any Freescale i.MX6x based platform       Quick time to market Highlights: Ideal for Quick Proof of concept (POC) development Shortens up to 60% of the new product development life cycle                                       Quick customization services in a very short period Features: Standard Features: i.MX6 Quad/Dual Lite 1GHz CPU MMPF0100 Freescale PMIC 1 GB DDR3 RAM Serial console SD boot SATA II SD/SDIO HDMI Gigabit Ethernet USB OTG Audio LVDS display Touch Optional Features: PCIe Camera CAN GPS VPU (HD Coding and Decoding supported) GPU (Open GL, Open VG, Direct3DM and DirectDraw) Target Applications: Automotive IVI Telematics Interactive POS Industrial HMI Medical Click Here for more details on WEC7 BSP Support for Freescale's i.MX6x Sabre SDB/SDP by iWave Click Here for more details on WEC7 BSP Support for various other i.MX processors