Overview As more and more communication required between online and offline, the QR code is widely used in the mobile payment, mobile small apps, industry things identification and etc. The i.MX6UL/ULL has the IP of CSI and PXP for camera connection and image CSC/FLIP/ROTATION acceleration. A LCDIF IP is supporting the display, but no 3D IP support. This means this low power and low end AP is very suitable for the industry HMI segment, which does not require a cool 3D graphic display, but a simple and straightforward GUI for interaction. QR code scanner is one of the use cases in the industry segment, which more and more customer are focusing on. The i.MX6UL CPU freq of i.MX6UL is about 500Mhz, and it does not have GPU IP, so a lightweight GUI and window system is required. Here we recommend the QT with wayland backend (without X11), which would make the window system small and faster than traditional X11 UI. Why chose QT is because of it has open source version, rich components, platform independent, good performance for embedded system and strong development staffs like QtCreator for creating application. How to enable the QT development environment, check this: Enable QT developement for i.MX6UL (v2)  Here I made a QR code scanner demo based on QT5.6 + QZXing (QR/Bar code scan engine) running on the i.MX6UL EVK board with a UVC camera (at least 640x480 resolution is required) and 480x272px LCD. Source code is open here (License Apache2.0): https://github.com/muddog/QRScanner  Implementation To do camera preview and capture, you must think on the gstreamer first, which is easy use and has the acceleration pads which implemented by NXP for i.MX6UL. Yes, it's very easy for you to enable the preview in console like: $ gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw,format=YUY2,width=640,height=320 ! imxvideoconvert_pxp ! video/x-raw,format=RGB16 ! waylandsink It works under the i.MX6UL EVK, with PXP IP to do color space convert from YUY2 -> RGB16 acceleration, also the potential scaling of the image. The CPU loading of this is about 20-30%, but if you use the component of "videoconvert" to replace the "imxvideoconvert_pxp", we do CSC and scale by CPU, then the loading would increase to 50-60%. The "/dev/video1" is the device node for UVC camera, it may different in your environment. So our target is clear, create such pipeline (with PXP acceleration) in the QT application, and use a appsink to get preview images, do simple "sink" to one QWidget by drawing this image on the widget surface for preview (say every 50ms for 20fps). Then in other thread, we fetch the preview buffer in a fixed frequency (like every 0.5s), then feed it into the ZXing engine to decode the strings inside this image. Here are the class created inside the source code: ScannerQWidgetSink It act as a gstreamer sink for preview rendering. Init the pipeline, create a timer with timeout every 50ms. In the timer handler, we use appsink to copy the camera buffer from gstreamer, and tell the ViewfinderWidget to do update (re-draw event). ViewfinderWidget This class inherit from the QWidget, which draw the preview buffer as a QImage onto it's own surface by using QPainter. The QImage is created at the very begining with the image buffer created by the ScannerQWidgetSink. Because QImage itself does not maintain the image buffer, so the buffer must be alive during it's usage. So we keep this buffer during the ScannerQWidgetSink life cycle, copy the appsink buffer from pipeline to it for preview. MainWindow Create main window, which does not have title bar and border. Start any animation for the red line scan bar. Create instance of DecoderThread and ScannerQWidgetSink. Setup and start them. DecoderThread A infinite loop, to wait for a available buffer released by the ScannerQWidgetSink every 0.5s. Copy the buffer data to it's own buffer (imgData) to avoid any change to the buffer by sink when doing decoding. Then feed this copy of buffer into ZXing engine to get decoder result. Then show on the QLabel. Screenshot under wayland (weston) desktop: Customize Camera instance Now I use the UVC camera which pluged in the USB host, which device node is /dev/video1. If you want to use CSI or other device, please change the construction parameters for ScannerQWidgetSink(): sink = new ScannerQWidgetSink(ui->widget, QString("v4l2src device=/dev/video1")); Image resolution captured and review Change the static member value of ScannerQWidgetSink class: uint ScannerQWidgetSink::CAPTURE_HEIGHT = 480; uint ScannerQWidgetSink::CAPTURE_WIDTH = 640; Preview fps and decoding frequency Find the "framerate=20/1" strings in the ScannerQWidgetSink::GstPipelineInit(), change to your fps. You also have to change the renderTimer start timeout value in the ::StartRender(). The decoding frequency is determined by renderCnt, which determine after how many preview frames showed to feed the decoder. Main window size It's fixed size of main window, you have to change the mainwindow.ui. It's easy to do in the QtCreate Designer. FAQ Why not use CSI camera in demo? Honestly, I do not have CSI camera module, it's also DNP when you buying the board on NXP.com. So a widely used UVC camera is preferred, it's also easy for you to scan QR code on your phone, your display panel etc. Why not use QCamera to do preview and capture? The QCamera class in the Qtmultimedia component uses the camerabin2 gstreamer plugin, which create a very long pipeline for different usage of viewfinder, image capture and video encoder. Camerabin2 would eat too much CPU and memory resource, take picture and recording are very very slow. The preview of 30fps would eat about 70-80% CPU loading even I hacked it using imxvideoconvert_pxp instread of software videoconvert. Finally I give up to implement the QRScanner based on QCamera. How to make sure only one instance of QT app is running? We can use QSharedMemory to create a share memory with a unique KEY. When second instance of app is started, it would check if the share memory with this KEY is created or not. If the shm is there, it means there's already one instance running, it has to exit(). But as the QT mentioned, the QSharedMemory can not be destroyed correctly when app crashed, this means we have to handle each terminate signal, and do delete by ourselves: static QSharedMemory *gShm = NULL; static void terminate(int signum) {    if (gShm) {       delete gShm;       gShm = NULL;    }    qDebug() << "Terminate with signal:" << signum;    exit(128 + signum); } int main(int argc, char *argv[]) {    QApplication a(argc, argv);    // Handle any further termination signals to ensure the    // QSharedMemory block is deleted even if the process crashes    signal(SIGHUP, terminate ); // 1    signal(SIGINT, terminate ); // 2    signal(SIGQUIT, terminate ); // 3    signal(SIGILL, terminate ); // 4    signal(SIGABRT, terminate ); // 6    signal(SIGFPE, terminate ); // 8    signal(SIGBUS, terminate ); // 10    signal(SIGSEGV, terminate ); // 11    signal(SIGSYS, terminate ); // 12    signal(SIGPIPE, terminate ); // 13    signal(SIGALRM, terminate ); // 14    signal(SIGTERM, terminate ); // 15    signal(SIGXCPU, terminate ); // 24    signal(SIGXFSZ, terminate ); // 25    gShm = new QSharedMemory("QRScannerNXP");    if (!gShm->create(4, QSharedMemory::ReadWrite)) {       delete gShm;       qDebug() << "Only allow one instance of QRScanner";       exit(0);    } .....

When configuring i.MX6 IPU IDMAC CPMEM parameters or debugging it, it's hard to find the value of a parameter inside the 160 bits word. This web tool separates the 160 bits words into parameters making it easier to check their values. Link: i.MX Tools 

Two IPUs are supported in i.MX6Q SoC, each IPU supports 1920x1080 resolution, and 4 kinds of interfaces on i.MX6Q PADs can be used to connect display devices: HDMI, Digital RGB24, LVDS1+LVDS2, MIPI DSI. In the documents, we will discuss how to expand VGA port with digital RGB and realize dual-display via HDMI & VGA, The solution has been validated on Android4.2.2 and Android4.4.2 BSP released by NXP. 1.  Expanding VGA port based on digital RGB24 interface with ADV7125 Schematic is in attachments. 2. Configurations of envionment variables in u-boot The following settings are for booting via NFS, users can adjust them to boot via Flash on board. setenv ipaddr 192.168.1.103 setenv serverip 192.168.1.102 setenv gateway 192.168.1.1 setenv ethaddr 00:04:9f:00:ea:d3 setenv bootargs_base 'setenv bootargs console=ttymxc0,115200' setenv bootargs_android 'setenv bootargs ${bootargs} init=/init androidboot.console=ttymxc0 androidboot.hardware=freescale' setenv bootargs_nfs 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gateway}:${netmask}::eth0 off root=/dev/nfs nfsroot=${serverip}:${nfsroot}' setenv bootargs_disp 'setenv bootargs ${bootargs} video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 video=mxcfb1:dev=lcd,1920x1080M@60,if=RGB24,bpp=32 video=mxcfb2:off fbmem=32M vmalloc=400M' setenv bootcmd_net 'run bootargs_base bootargs_android bootargs_nfs bootargs_disp;tftpboot ${loadaddr} uImage;bootm' 3. Configurations in BSP file (1)IOMUX of DISP0 port (in header file)     MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,     MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15,        /* DE */     MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2,        /* HSync */     MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3,        /* VSync */     MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0,     MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1,     MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2,     MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3,     MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4,     MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5,     MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6,     MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7,     MX6Q_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8,     MX6Q_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9,     MX6Q_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10,     MX6Q_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11,     MX6Q_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12,     MX6Q_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13,     MX6Q_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14,     MX6Q_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15,     MX6Q_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16,     MX6Q_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17,     MX6Q_PAD_DISP0_DAT18__IPU1_DISP0_DAT_18,     MX6Q_PAD_DISP0_DAT19__IPU1_DISP0_DAT_19,     MX6Q_PAD_DISP0_DAT20__IPU1_DISP0_DAT_20,     MX6Q_PAD_DISP0_DAT21__IPU1_DISP0_DAT_21,     MX6Q_PAD_DISP0_DAT22__IPU1_DISP0_DAT_22,     MX6Q_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23,     MX6Q_PAD_NANDF_D4__GPIO_2_4,        /* ADV7125 Power on / off (2) Frame buffer static struct ipuv3_fb_platform_data qcorein_fb_data[] = { /*    {     .disp_dev = "ldb",     .interface_pix_fmt = IPU_PIX_FMT_RGB666,     .mode_str = "LDB-WXGA",     .default_bpp = 16,     .int_clk = false,     .late_init = false,     }, */     {     .disp_dev = "hdmi",     .interface_pix_fmt = IPU_PIX_FMT_RGB24,     .mode_str = "1920x1080M@60",     .default_bpp = 32,     .int_clk = false,     .late_init = false,     },     {     .disp_dev = "lcd",     .interface_pix_fmt = IPU_PIX_FMT_RGB24,     .mode_str = "1920x1080",     .default_bpp = 32,     .int_clk = false,     }, }; (3) Settings about IPUs /* HDMI -- IPU1_DI0 */ static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {     .ipu_id = 1,     .disp_id = 1, }; /* RGB24 DISP0 LCD(Here is RGB24-->VGA via ADV7125 -- IPU0_DI0 */ static struct fsl_mxc_lcd_platform_data lcdif_data = {     .ipu_id = 0,     .disp_id = 0,     .default_ifmt = IPU_PIX_FMT_RGB24, }; (4) Adding LCD data in board_init() funtion static void __init mx6_qcorein_board_init(void) { .... imx6q_add_lcdif(&lcdif_data); ... } (5) Adding mxc_lcd.c driver to linux kernel When using make menuconfig to configure kernel, don't forget to add LCD driver to kernel.  Note: If users are using other version of android BSP, she can do porting according to above thinking. Weidong Sun NXP TIC team

MIPI can support video streaming over 1, 2, 3 and 4 lanes. On i.MX6 Sabre boards, the OV5640 camera supports 1 or 2 lanes and the NXP Linux Kernel uses 2 lanes as default. In order to use only one lane, follow the steps below: 1 - Change the board Device Tree on Linux Kernel. On file <linux kernel folder>/arch/arm/boot/dts/imx6qdl-sabresd.dtsi, find the entry "&mipi_csi" and change lanes from 2 to 1. 2 - Configure OV5640 to use only one lane instead of two. On file <linux kernel folder>/drivers/media/platform/mxc/capture/ov5640_mipi.c, change the register 0x300e value from 0x45 to 0x05. This register setup is located at struct ov5640_init_setting_30fps_VGA. 3 - Build the kernel and device tree files. 4 - Test the camera. Unit test can be used to test the video capture: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 5 - Checking if it's really using one lane. MIPI_CSI_PHY_STATE resgister (address 0x021D_C014) provides the status of all data and clock lanes. During video streaming using 2 lanes, the register value constantly changes its value between 0x0000_0300 and 0x0000_0330. When using only one lane, this register value constantly changes its value between 0x0000_0300 and 0x0000_0310. To read the register value during the stream, run the video test with &: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 & Now, run the memtool: /unit_tests/memtool -32 0x021dc014 1 i.MX6DL running mxc_v4l2_overlay.out with only one lane:

Hardware connection: there are two board-to-board connectors on E-INK daughter card IMXEBOOKDC4, while there is only one on i.MX7D Sabre board, as the picture below. This might be a bit confusing to connect the two: Checked with internal, the original design was trying to wire both eLCDIF and EPDC bus out to one daughter card, add the flexibility to have different configurations on one display daughter card(LCD/EPD). On i.MX7D Sabre board, only one connector is available for EPDC bus. Here is how we connect i.MX7D Sabre and IMXEBOOKDC4: Software setup: here we use pre-build L3.14.38_6UL7D_Beta Linux as our boot-image, steps to setup/boot/test EPDC: 1. download and decompress BSP pre-build image package "L3.14.38_beta_images_MX6UL7D.tar.gz", you should be able to find the SD image in it -- "fsl-image-gui-x11-imx7dsabresd.sdcard" 2. program the SD image on your SD card(>800 MBytes) with command(I'm running this in Ubuntu): "dd if=fsl-image-gui-x11-imx7dsabresd.sdcard of=/dev/sdb;sync" 3. insert SD card to the slot(J6) on i.MX7D Sabre board, connect debug-UART and power-on the board 4. modify the u-boot environment variables as below:      a.) setenv fdt_file imx7d-sdb-epdc.dtb           (originally this is "fdt_file=imx7d-sdb.dtb")      b.) setenv mmcargs 'setenv bootargs console=${console},${baudrate} root=${mmcroot} epdc video=mxcepdcfb:E060SCM,bpp=16'           (originally this is "mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot}") 5. boot into Linux kernel, run unit-test: "/unit_tests/mxc_epdc_fb_test.out", should be able to have test patterns running on EPD.

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

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.

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  

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.

By default Linux BSP will work with LVDS screen on i.MX 6SoloX SABRE board. To enable MCIMX28LCD on the board, following need to be modified in u-boot: setenv panel 'MCIMX28LCD' setenv fdt_file 'imx6sx-sdb-lcdif1.dtb' #add video=mxc_lcdif:SEIKO-WVGA,bpp=16 to kernel command line you’re using #For example, when booting from MMC it will be: #  setenv mmcargs 'setenv bootargs console=${console},${baudrate} root=${mmcroot} video=mxc_lcdif:SEIKO-WVGA,bpp=16' saveenv

                                                                                         Watch the Freescale i.MX team boot up Android 5.0 Lollipop in i.mx6 application processors—在线播放—优酷网，视频高清在线观看 The Freescale i.MX Android team has booted up Android 5.0 Lollipop in the SABRE platform for i.mx6 series. Google pushed all of the latest source for its Android release to AOSP on Nov. 5, and the Freescale Android Team started their work. With the previous 6 days to boot Android Lollipop up, the Freescale i.MX Android team enabled the basic features like connectivity, audio/video playback, sensors, inputs and display on day 7! You can see the some changes in the demo video at the beginning of the post. The Freescale i.MX Android team has closely followed almost every version of Android since it is released by AOSP and has good experience on it. Below are some snapshots and pictures for the Android Lollipop.

It is based on 3.0.35 GA 4.1.0 BSP.   0001-Correct-mipi-camera-virtual-channel-setting-in-ipu_c.patch It is the updated IPU code for MIPI ID and SMFC setting in ipu_capture.c. These setting should not be combined with MIPI virtual channel value, they shoule be fixed with ID 0.   0002-Use-virtual-channel-3-for-ov5640-mipi-camera-on-iMX6.patch The sample code to modify ov5640_mipi camera to use virtual channel 3 on SabreSD board.   The followed command can be used to verify the mipi camera function after booted into Linux: $ gst-launch mfw_v4lsrc capture-mode=1 device=/dev/video1 ! mfw_v4lsink     2014-09-30 update: Added the patch for 3.10.17_GA1.0.0 BSP. "L3.10.17_1.0.0_mipi_camera_virtual_channel_3.zip"  

If someone wants to use the OpenGL ES 2.0 extension "GL_OES_vertex_array_object", the macro "GL_GLEXT_PROTOTYPES" must be defined in his program first. Then he can get the extension program location by calling the API eglGetProcAddress.  Here is an example to use this extension. #define GL_GLEXT_PROTOTYPES PFNGLGENVERTEXARRAYSOESPROC glGenVertexArraysOESv; PFNGLBINDVERTEXARRAYOESPROC glBindVertexArrayOESv; PFNGLDELETEVERTEXARRAYSOESPROC glDeleteVertexArraysOESv; glGenVertexArraysOESv = (PFNGLGENVERTEXARRAYSOESPROC)eglGetProcAddress ( "glGenVertexArraysOES" ); glBindVertexArrayOESv = (PFNGLBINDVERTEXARRAYOESPROC)eglGetProcAddress ( "glBindVertexArrayOES" ); glDeleteVertexArraysOESv = (PFNGLDELETEVERTEXARRAYSOESPROC)eglGetProcAddress ( "glDeleteVertexArraysOES" ); After these steps, the new alias glGenVertexArraysOESv, glBindVertexArrayOESv, glDeleteVertexArraysOESv can be use to call the VAO operation function in OpenGL ES 2.0 extensions.

This is a How-To documentation for OpenCL on i.MX6 using LTIB, there are all necessary steps and sample code to create,  build and run a HelloWorld application.

When working with IPU applications, sometimes image format converter is needed to check images generated by IPU that are not readable by PC (e.g. RGB565, common i.MX framebuffer format -> png or jpg) or generate a RGB picture from an encoded file to be read by IPU (e.g. png -> RGB565 framebuffer). There are some useful tools on Linux and some also available on Windows that can perform these conversions. I listed 5 tools with some usage examples below. IMAGEMAGICK // Display a 800x600 rgb image display -size 800x600 -depth 8 rgb:output.rgb // Show information of output.rgb identify -size 1296x972 -depth 8 output.rgb // Convert a 640x480 grayscale raw rgb file to png convert -size 640x480 -depth 8 imagefile.rgb image.png // To list all available color formats identify -list format For more information about Imagemagick and its format support. access: http://www.imagemagick.org/script/formats.php FFMPEG // List available formats for ffmpeg ffmpeg -pix_fmts // Convert raw rgb565 image to png ffmpeg -vcodec rawvideo -f rawvideo -pix_fmt rgb565 -s 1024x768 -i freescale_1024x768.raw -f image2 -vcodec png screen.png // Convert png to raw rgb565 ffmpeg -vcodec png -i image.png -vcodec rawvideo -f rawvideo -pix_fmt rgb565 image.raw // Convert a 720x480 NV12 (YUV 420 semi-planar) image to png ffmpeg -s 720x480 -pix_fmt nv12 -i image-nv12.yuv -f image2 -pix_fmt rgb24 image-png.png // Convert a 640x480 uyvy422 image to png ffmpeg -s 640x480 -pix_fmt uyvy422 -i image-uyvy422.yuv -f image2 -pix_fmt rgb24 image-uyvy422.png MENCODER http://www.mplayerhq.hu/DOCS/HTML/en/encoding-guide.html TRANSCODING http://www.transcoding.org/cgi-bin/transcode?Examples GRAPHICSMAGICK http://www.graphicsmagick.org/

This patch made the display no interrupt from uboot to kernel to Android. The IPU and related hardware display interface will only be initialized once in Uboot, the kernel code will skip the IPU initialization.   1. Description     1) Support HDMI, LVDS and LCD output in UBoot.     2) Support UBoot logo keep from uboot to kernel to Android.     3) For HDMI, both 720P and 1080P mode were supported.     4) For LVDS, 1024x768 and 1080P dual channel panels were supported.     5) The logo file is a 32 bpp bmp file. 2. File List -- kernel_imx\0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch -- kernel_imx\0002-Bug-fix-for-uboot-logo-keep-patch.patch    Kernel patch to support the logo keep feature. -- uboot-imx\0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch    Uboot patch to support the logo display. -- logo.bmp    Example 32bpp logo file. -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - Android JB4.2.2_1.1.0-GA UBoot and kernel. 4. How to use -- Copy the two patch files to Android kernel_imx and uboot-imx folder and apply them.     $ cd ~/myandroid/kernel_imx/     $ git apply ./0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch     $ cd ~/myandroid/bootable/bootloader/uboot-imx/     $ git apply ./0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch     $ git apply ./0002-Bug-fix-for-uboot-logo-keep-patch.patch   -- Build the new uboot image:     $ cd ~/myandroid/bootable/bootloader/uboot-imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make mx6q_sabresd_android_config     $ make   -- Before build new UBoot image, the display type can be selected from file uboot-imx\include\configs\mx6q_sabresd.h // Select one of the output mode #define IPU_OUTPUT_MODE_HDMI //#define IPU_OUTPUT_MODE_LVDS //#define IPU_OUTPUT_MODE_LCD   -- Build the new kernel image:     $ cd ~/myandroid/kernel_imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make imx6_android_defconfig     $ make uImage   -- Before "make uImage", make menuconfig can be used to select the display type.                 System Type  --->                    Freescale MXC Implementations  --->                       MX6 clk setting for smooth UI transtion from bootloader to kernel  --->                           Select Display Interface                              ( )  Smooth UI transtion on LCD, IPU1, DI0                              ( )  Smooth UI transtion on LVDS, IPU1, DI1                              (X)  Smooth UI transtion on HDMI, IPU2, DI0   -- Uboot parameters for video mode    1080P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=148500000"      720P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=74250000"      1024x768 LVDS:       "video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666,bpp=32 fb0base=0x27b00000 fbmem=28M"      800x480 LCD:       "video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB565,bpp=32 fb0base=0x27b00000 fbmem=28M" -- dd the logo.bmp to SD card address 0x100000 and skip the 54 bytes bmp file header.    sudo dd if=logo.bmp of=/dev/sdc bs=1 seek=1048576 skip=54 5. Note     1) The logo.bmp file should be 32bpp or 16bpp, and it should be synced with video mode parameters "bpp=xx",          and uboot config file mx6q_sabresd.h (#define DISPLAY_BPP  xx).       2) The IPU number and DI number are hard coded in kernel file "board-mx6q_sabresd.c". static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {   .ipu_id = 1,   .disp_id = 0, }; static struct fsl_mxc_lcd_platform_data lcdif_data = {   .ipu_id = 0,   .disp_id = 0,   .default_ifmt = IPU_PIX_FMT_RGB565, }; static struct fsl_mxc_ldb_platform_data ldb_data = {   .ipu_id = 0,   .disp_id = 1,   .ext_ref = 1,   .mode = LDB_SEP1,   .sec_ipu_id = 0,   .sec_disp_id = 0, };       3) The IPU number and DI number are defined by Macro in Uboot file "include\configs\mx6q_sabresd.h" #define IPU_NUM   2  // 1 for IPU1, 2 for IPU2. #define DI_NUM   0  // 0 for DI0, 1 for DI1.       4) The display type used in uboot and kernel must be same, same type, same IPU number, same DI port and        same resolution.     [2015-06-29 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-06-29.zip Fix some LVDS issues for iMX6DL. Also given an example for LVDS0 with DI0. New Uboot patches:      0002-Updated-lvds-clock-source-to-pll2_pfd0.-Same-as-kern.patch      0003-Add-support-for-iMX6DL.patch   New kernel patches      0003-Skip-lvds-re-initialization-for-logo-keep.patch      0004-Add-examlpe-for-LVDS0-logo-keep.patch     [2015-08-07 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-08-07.zip Added the new Uboot patch 0004-Correct-the-sequence-to-set-LDB-clock.patch It can correct the LVDS clock set sequence whch is a known issue that caused no LVDS display sometimes.   [2015-09-18 Update]: JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip Added the patch for Android JB4.3_GA1.1.1 release. Updated clock usecount, after blank the display, the related clock can be gated off correctly. Support LVDS clock from PLL5.   [2015-12-21 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2015-12-21.zip. Verified on iMX6DL/Q SabreSD board. It supports LCD and LVDS panels, HDMI patch will be released later.   [2016-01-04 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2016-01-04.zip. Added HDMI display support. Now it supports LCD, LVDS and HDMI displays. Fixed the video playback issue for boot up.   [2016-05-18 Update]: 0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch An issue was founded, when dual channel 4 lanes LVDS panel was used, in uboot there will be no LVDS TX3 signa on one LVDS port, the attach "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip, for other BSP, please port it manually.   [2016-08-29 Update]: 0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch On some iMX6 chip, after reset the IPU in SRC Control Register, enable IPU at once will cause system hang up, to avoid such issue, software needs wait for IPU reset done by polling the SRC register. The attach "0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip + "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch", for other BSP, please port it manually.   [2017-01-06 Update] Added patch for L4.1.15_GA1.2.0 BSP and Android M6.0.1_GA2.1.0 BSP. Files: L4.1.15_GA1.2.0_uboot_logo_keep_patch_2017-01-06.zip; M6.0.1_2.1.0_uboot_logo_keep_patch_2017-01-06.zip

Qt framework Qt is a cross-platform complete development framework with tools designed to streamline the creation of stunning native applications and amazing user interfaces for desktop, embedded and mobile platforms. Qt's cross-platform full framework and tools enables developers to target various desktop, embedded, mobile and real-time operating systems with one code base. Qt brings freedom to the developer saving development time, adding efficiency and ultimately shortening time to market. Building Qt Compile Qt for i.MX28 Building QT5 for i.MX53 Building QT for i.MX6 Qt on iMX6 Installing tools Installing and Configuring QT Creator (Ubuntu) Qt5 with Qt3D over Wayland rootfs Demos Qt5 Cinematic Experience Demo on i.MX6 Video - IMx 53 Qt5 qt3d demo Qt5 with Qt3D over Wayland rootfs Information Qt5 on i.MX6  DO's and DONT's Best Practices for QML

There is GPU SDK for i.MX6D/Q/DL/S: IMX_GPU_SDK.  This is to share the experience when compiling the example code from the SDK with Linux BSP release: L3.0.35_1.1.0_121218 and  L3.0.35_4.0.0_130424 . Minimal profile is using and have been verified on both i.MX6Q SDP and i.MX6DL SDP. To start: Please make sure “gpu-viv-bin-mx6q” has been selected in the Package list and compiled to your rootfs. After finished the compilation of the rootfs, you should find some newly added libraries for GLES1.0, GLES2.0, OpenVG and EGL in <ltib>/rootfs/usr/lib However, you should find libOpenVG.so is actually copied from libOepnVG_3D.so: vmuser@ubuntu:~/ltib_src/ltib/rootfs/usr/lib$ ls -al libOpen* -rwxr-xr-x 1 root root 115999 2013-06-06 18:31 libOpenCL.so -rwxr-xr-x 1 root root 515174 2013-06-06 18:31 libOpenVG_355.so -rwxr-xr-x 1 root root 272156 2013-06-06 18:31 libOpenVG_3D.so -rwxr-xr-x 1 root root 272156 2013-06-06 18:31 libOpenVG.so So, in this way, i.MX6D/Q will no use libOpenVG_355.so in the build. Also, if you run NFS, the libOpenVG.so will change to symbolic link:           For example, run on i.MX6Q SDP, it will link to /usr/lib/libOpenVG_355.so                          For example, run on i.MX6DL SDP, it will link to /usr/lib/libOpenVG_3D.so                Then, when you compile the OpenVG example code, it is becoming very confusing.  Thus, it needs to pay attention when doing the compilation.  For example, delete the symbolic link and make copy of the corresponding library: For i.MX6D/Q, please do this: $ sudo /bin/rm libOpenVG.so $ sudo cp libOpenVG_355.so libOpenVG.so For i.MX6S/DL, please do this: $ sudo /bin/rm libOpenVG.so $ sudo cp libOpenVG_3D.so libOpenVG.so To compile the sample code in the GPU SDK, you could refer to iMXGraphicsSDK_OpenGLES2.0.pdf or iMXGraphicsSDK_OpenGLES1.1.pdf in ~/gpu_sdk_v1.00.tar/Documentation/Tutorials to set up the cross compilation environment; which is assuming the LTIB and the rootfs is ready. $ export ROOTFS=/home/vmuser/ltib_src/ltib/rootfs $ export CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi- For OpenVG: $ cd ~/gpu_sdk_v1.00/Samples/OpenVG $ make -f Makefile.fbdev clean $ make -f Makefile.fbdev $ make -f Makefile.fbdev install The executable will then be copied to this directory: ~/gpu_sdk_v1.00/Samples/OpenVG/bin/OpenVG_fbdev For GLES2.0 $ cd ~/gpu_sdk_v1.00/Samples/ GLES2.0 $ make -f Makefile.fbdev clean $ make -f Makefile.fbdev $ make -f Makefile.fbdev install The executable will then be copied to this directory: ~/gpu_sdk_v1.00/Samples/ GLES2.0/bin/GLES20_fbdev For GLES1.1, please modify the Makefile.fbdev to remove the compilation of example codes "18_VertexBufferObjects" and "19_Beizer" that are not exist. Then, $ cd ~/gpu_sdk_v1.00/Samples/ GLES1.1 $ make -f Makefile.fbdev clean $ make -f Makefile.fbdev $ make -f Makefile.fbdev install The executable will then be copied to this directory: ~/gpu_sdk_v1.00/Samples/ GLES1.1/bin/GLES11_fbdev Finally, you could copy the executable to the rootfs and test on i.MX6Q SDP/SDB or i.MX6DL SDP board. NOTE: the newly added makefiles.tgz contains Makefile.x11 hacked from GLES2.0 example code to make OpenVG to compile and run on Ubuntu 11.10 rootfs.

The attached patch enables HDMI overscan for Android JB, and tested by MX6Q SabreSD with Android_4.2.2_1.0.0-ga. The bootargs includes "video=mxcfb0:dev=ldb,bpp=32 video=mxcfb1:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 video=mxcfb2:off".

This work is the result of my daughter's idea, she finished it with my guidance. Cradle-1 Palmsize mini-HPC World's first full function heterogeneous mini-HPC, this is what it looks like: 1 Architecture         Overall:  CPU+GPU heterogeneous, 4 nodes, connected by a 100M Ethernet switcher;         Nodes： FreeScale I.MX6 Quad core mini-pc, with 4 ARM Cortex-A9 cores and 1 Vivante GC2000 GPU 2  Software         OS:   Ubuntu 11.10 linaro         OpenCL driver: Vivante GC2000 OpenCL driver         Compiler:  C/C++: gcc 4.6.1, Fortan90/95:  gfortran 4.6.1,         MPI Parallel Computing: MPICH2 1.4-1         NFS network file system: nfs-kernel-server 1.2.4         SSH security:   openssh   1:5.8 3 Hardware         The hardware of all nodes are the same, only the software configurations are slightly different. One of them was assigned as the master node, the others are slave nodes. They were TV sticks originally, with android 4.0 installed. The node's hardware specification is:         CPU: 4 1.2G Cortex-A9 cores         GPU: 1 Vivante GC2000 GPU         RAM: 1G DDR         ROM: 8G SD         NIC:   usb2.0 100M Ethernet Adapter (this NIC is not the TV stick's component, we added it)         WIFI: 150M         Display Interface:  HDMI         Network Switcher: 5 port 100M Ethernet Switcher 4  Network         Each node has one USB2.0 NIC and one WIFI interface, the WIFI is used as the backup connection for NIC connection. Network configurations are:         IP Address assignment:  (baby1 - baby4 are the four computing nodes)         baby1: 100M NIC 192.168.10.1 WIFI 192.168.0.111         baby2: 100M NIC 192.168.10.2 WIFI 192.168.0.112         baby3: 100M NIC 192.168.10.3 WIFI 192.168.0.113         baby4: 100M NIC 192.168.10.4 WIFI 192.168.0.114 5  Performance         Cradle-1 has 16 1.2G ARM Cortex-A9 cores and 4 Vivante GC2000 GPU cores, the total computing power of these 20 computing devices is more than 100GFLOPS,   more powerful than an ordinary desktop. The whole machine is only a little bigger than a palm, and the total power consumption is less than 15 watts.          The overall architecture of Cradle-1 is almost the same as Chinese Tianhe-1A or the Titan in the oak ridge lab. they used the same set of software, LINUX+OPENCL+OPENMPI. Cradle-1 supports C/C++, Fortran90/95. And almost all kinds of parallel computing algorithms can run on it, the only difference is the scale.         We coded a MPI parallel computing program for large matrix multiplication with 4 processes, each process had 5 threads, four threads for the four CPU cores, and one thread for GPU computing. 6 Appearance Front Back Top Left Right One node, it has three interfaces, the right is HDMI interface, upper-left is the wireless adapter for keyboard and mouse, down-left is the power connection. One node is running Ubuntu 11.10. Coded a simple OpenCL program to display OpenCL driver information On a notebook, using remote desktop access function to obtan the node baby1's desktop. This is the sign in desktop of baby1 node. Baby 1 has X11VNC server installed. sign in baby1, open a terminal Ran a MPI testing program, ensuring that all babies (baby1 - baby4) were working     Any comments? please mail to audrey.tao@hotmail.com