Recently many customers faced the issue about connecting the git.freesacle .com failed when they built old bsp version like 4.1.15 or 3.14.52,  when the customer repo init according to the yocto user guide, they get the error message like ： repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-4.1-krogoth manifests:  escale.com[0: 192.88.156.202]: errno=Connection refused  fatal: cannot obtain manifest git://git.freescale.com/imx/fsl-arm-yocto-bsp.git ///// git clone git://git.freescale.com:9418/imx/fsl-arm-yocto-bsp.git -b imx-4.1.15-1.0.0_ga Cloning into 'fsl-arm-yocto-bsp'... fatal: unable to connect to git.freescale.com: git.freescale.com[0: 192.88.156.202]: errno=Connection refused the reason is that the old bsp source code was moved to "https://source.codeaurora.org/external/imx", customer needs to change "git://git.freescale.com/imx"  to "https://source.codeaurora.org/external/imx", for new repo init commands, try to use the commands like “repo init -u https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp -b <branch> [-m <manifest>]” for example: 4.1.15_1.0.0: repo init -u https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp -b imx-4.1.15-1.0.0_ga 4.1.15_2.0.0: repo init -u https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp -b imx-4.1-krogoth -m imx-4.1.15-2.0.0.xml 4.1.15_2.1.1: repo init -u https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp -b imx-4.1-krogoth -m imx-4.1.15-2.1.1.xml then you can "repo sync" and "bitbake", but some customers still has the connection error on building firmware-imx package, the error message like : ERROR: firmware-imx-1_5.4-r0 do_fetch: Fetcher failure: Fetch command failed with exit code 128, output: Cloning into bare repository '/opt/yocto/fsl-release-bsp/downloads//git2/git.freescale.com.imx.imx-firmware.git'... fatal: unable to connect to git.freescale.com: git.freescale.com[0: 192.88.156.202]: errno=Connection refused ERROR: firmware-imx-1_5.4-r0 do_fetch: Function failed: Fetcher failure for URL: 'git://git.freescale.com/imx/imx-firmware.git;branch=master;destsuffix=/opt/yocto/fsl-release-bsp/fsl_build_x11/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/firmware-imx/1_5.4-r0/firmware-imx-5.4/git'. Unable to fetch URL from any source. this reason is that 4.1.15 needs to download git2 package from git.freescale.com, then I uploaded the firmwar-imx git2 package, try to unzip first, then put packages under downloads/git2, then "bitbake firmware-imx" again

Instead to use gst-launch to play your audio/video media you can create an application do to that. This application was tested in iMX27ADS but should to work on iMX27PDK First execute LTIB (./ltib -c) and select these packages: all gstreamer plugin, alsa-utils and libmad. Create your file code (i.e.: playvideo.c): #include <gst/gst.h> #include <glib.h> #include <string.h> static GstElement *source, *demuxer, *vdqueue, *adqueue, *vdsink, *adsink, *decvd, *decad; void on_pad_added (GstElement *element, GstPad *pad) {         g_debug ("Signal: pad-added");         GstCaps *caps;         GstStructure *str;         caps = gst_pad_get_caps (pad);         g_assert (caps != NULL);         str = gst_caps_get_structure (caps, 0);         g_assert (str != NULL);         if (g_strrstr (gst_structure_get_name (str), "video")) {                 g_debug ("Linking video pad to dec_vd");                 // Link it actually                 GstPad *targetsink = gst_element_get_pad (decvd, "sink");                 g_assert (targetsink != NULL);                 gst_pad_link (pad, targetsink);                 gst_object_unref (targetsink);         }         if (g_strrstr (gst_structure_get_name (str), "audio")) {                 g_debug ("Linking audio pad to dec_ad");                 // Link it actually                 GstPad *targetsink = gst_element_get_pad (decad, "sink");                 g_assert (targetsink != NULL);                 gst_pad_link (pad, targetsink);                 gst_object_unref (targetsink);         }         gst_caps_unref (caps); } static gboolean bus_call (GstBus    *bus,           GstMessage *msg,           gpointer    data) {   GMainLoop *loop = (GMainLoop *) data;   switch (GST_MESSAGE_TYPE (msg)) {     case GST_MESSAGE_EOS:       g_print ("End of stream\n");       g_main_loop_quit (loop);       break;     case GST_MESSAGE_ERROR: {       gchar  *debug;       GError *error;       gst_message_parse_error (msg, &error, &debug);       g_free (debug);       g_printerr ("Error: %s\n", error->message);       g_error_free (error);       g_main_loop_quit (loop);       break;     }     default:       break;   }   return TRUE; } int main (int  argc,       char *argv[]) {   GMainLoop *loop;   GstElement *pipeline;   GstBus *bus;   /* Initialisation */   gst_init (&argc, &argv);   loop = g_main_loop_new (NULL, FALSE);   /* Check input arguments */   if (argc != 2) {     g_printerr ("Usage: %s <Video H264 filename>\n", argv[0]);     return -1;   }   /* Create gstreamer elements */   pipeline      = gst_pipeline_new ("media-player");   source        = gst_element_factory_make ("filesrc","file-source");   demuxer      = gst_element_factory_make ("mfw_mp4demuxer","avi-demuxer");   decvd        = gst_element_factory_make ("mfw_vpudecoder", "video-decoder");   decad        = gst_element_factory_make ("mad", "mp3-decoder");   vdsink        = gst_element_factory_make ("mfw_v4lsink",    "video-sink");   vdqueue      = gst_element_factory_make ("queue",            "video-queue");   adqueue      = gst_element_factory_make ("queue",            "audio-queue");   adsink        = gst_element_factory_make ("fakesink",        "audio-sink");   g_object_set (decvd, "codec-type", "std_avc", NULL);   if (!pipeline || !source || !demuxer || !decvd || !decad || !vdsink || !vdqueue || !adqueue || !adsink) {     g_printerr ("One element could not be created. Exiting.\n");     return -1;   }   /* Set up the pipeline */   /* we set the input filename to the source element */   g_object_set (G_OBJECT (source), "location", argv[1], NULL);   /* we add a message handler */   bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));   gst_bus_add_watch (bus, bus_call, loop);   gst_object_unref (bus);   /* we add all elements into the pipeline */   /* file-source | ogg-demuxer | vorbis-decoder | converter | alsa-output */   gst_bin_add_many (GST_BIN (pipeline),                     source, demuxer, decvd, decad, adqueue, vdqueue, vdsink, adsink,  NULL);   /* we link the elements together */   /* file-source -> ogg-demuxer ~> vorbis-decoder -> converter -> alsa-output */   gst_element_link (source, demuxer);   gst_element_link (decvd, vdqueue);   gst_element_link (vdqueue, vdsink);   //gst_element_link (decad, adqueue);   gst_element_link (adqueue, adsink);   g_signal_connect (demuxer, "pad-added", G_CALLBACK (on_pad_added), NULL);   /* note that the demuxer will be linked to the decoder dynamically.     The reason is that Ogg may contain various streams (for example     audio and video). The source pad(s) will be created at run time,     by the demuxer when it detects the amount and nature of streams.     Therefore we connect a callback function which will be executed     when the "pad-added" is emitted.*/   /* Set the pipeline to "playing" state*/   g_print ("Now playing: %s\n", argv[1]);   gst_element_set_state (pipeline, GST_STATE_PLAYING);   /* Iterate */   g_print ("Running...\n");   g_main_loop_run (loop);   /* Out of the main loop, clean up nicely */   g_print ("Returned, stopping playback\n");   gst_element_set_state (pipeline, GST_STATE_NULL);   g_print ("Deleting pipeline\n");   gst_object_unref (GST_OBJECT (pipeline));   return 0; } Create a directory inside your ltib directory to compile your source code: $ mkdir ~/your-ltib-dir/rpm/BUILD/gst Enter on LTIB shell mode: $ ./ltib -m shell Entering ltib shell mode, type 'exit' to quit LTIB> Enter in your application dir: LTIB> cd rpm/BUILD/gst/ Compile your application: LTIB> gcc -Wall $(pkg-config --cflags --libs gstreamer-0.10) playvideo.c -o playvideo If everything worked file you will get a "playvideo" arm binary: LTIB> file playvideo playvideo: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped Now just copy it to ~/your-ltib-dir/rootfs/home. Start your board using this rootfs and execute: root@freescale ~$ cd /home/ root@freescale /home$ ./playvideo your-file-h264-mp3.avi Now playing: your-file-h264-mp3.avi Running...

It is suggested to create a layer when creating or modifying any metadata file (recipe, configuration file or class). The main reason is simple: modularity. Follow these steps 1. To have access to Yocto scripts, setup the enviroment from the BASE folder fsl-community-bsp $ . setup-environment build 2. Move to the place you want to create your layer and choose a name (e.g. `fsl-custom`) sources $ yocto-layer create fsl-custom # Answer the questions. Make sure the priority is set correctly (higher numbers, # higher priorities). Set the priority equal to the lowest already present, except # when you have introduce a new recipe with the same name as other and want to shadow # the original one. 3. Add any metadata content. Suggestion: Version the layer with Git and upload your local git repo to a server 4. Edit and add the layer to the `build/conf/bblayers.conf` file 5. To verify that your layer is *seen* by BitBake, run the following command under the build folder build $ bitbake-layers show-layers This document was generated from the following discussion: i.MX Yocto Proyect: How can I create a new Layer?

[中文翻译版] 见附件   原文链接： Guide to flash an eMMC from SD Card on i.MX6Q SABRE-SD 

Q: Does VIN have to be valid before we can talk to the PMIC over i2c? Can a valid voltage on LICELL and VDDIO work instead? The PF0100 datasheet says: ---------------------------------------------- To communicate with I2C, VIN must be valid and VDDIO, to which SDA and SCL are pulled up, must be powered by a 1.7 to 3.6V supply. VIN, or the coin cell voltage must be valid to maintain the contents of the registers. -------------------------------- A: VIN and VDDIO must be valid for communicating to the I2C block. Having LICELL and VDDIO will not work since a portion of the digital circuitry needed for accessing the registers is powered through VIN. This document was generated from the following discussion: Programming PMIC over i2c

Abstract: On the time otp driver initializes, it will check the mac bits of eFuse,  when the value is invalid, generate a random mac, and program  it to eFuse. Environment: i.mx6dl android-4.2.2 kernel-3.0.35 Changes: 1. kernel_imx/arch/arm/mach-mx6/mx6_fec.c ---------------------------------------------------------------- void __init imx6_init_fec(struct fec_platform_data fec_data) {   fec_get_mac_addr(fec_data.mac);   if (!is_valid_ether_addr(fec_data.mac))       fec_data.mac[0] = 0x10; // changed by xxx   if (cpu_is_mx6sl())   imx6sl_add_fec(&fec_data);   else   imx6q_add_fec(&fec_data); } 2. kernel_imx/drivers/char/fsl_otp.c ---------------------------------------------------------------- //add by xxx static void check_otp_mac(void) {   unsigned int index_mac0 = 34;   unsigned int index_mac1 = 35;   u32 value_mac0 = 0;   u32 value_mac1 = 0;   u32 value_random_mac0 = 0;   u32 value_random_mac1 = 0;   char otp_mac[6], random_mac[6];   memset(otp_mac, 0, sizeof(otp_mac));   memset(random_mac, 0, sizeof(random_mac));   mutex_lock(&otp_mutex);   //get   if (otp_read_prepare(otp_data)) {   mutex_unlock(&otp_mutex);   return 0;   }   value_mac0 = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUSTn(index_mac0));   value_mac1 = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUSTn(index_mac1));   otp_read_post(otp_data);   mutex_unlock(&otp_mutex);   if(value_mac0 != 0 && value_mac1 != 0)   {   otp_mac[5] = value_mac0 & 0xff;   otp_mac[4] = (value_mac0 >> 😎 & 0xff;   otp_mac[3] = (value_mac0 >> 16) & 0xff;   otp_mac[2] = (value_mac0 >> 24) & 0xff;   otp_mac[1] = value_mac1 & 0xff;   otp_mac[0] = (value_mac1 >> 😎 & 0xff;   }   printk("otp_mac=%pM\n", otp_mac);   //check   if (!is_valid_ether_addr(otp_mac))   {   random_ether_addr(random_mac);   printk("get random mac:%pM\n", random_mac);   //set   value_random_mac0 = 0;   value_random_mac0 = value_random_mac0 | random_mac[2];   value_random_mac0 = (value_random_mac0 << 😎 | random_mac[3];   value_random_mac0 = (value_random_mac0 << 😎 | random_mac[4];   value_random_mac0 = (value_random_mac0 << 😎 | random_mac[5];   value_random_mac1 = 0;   value_random_mac1 = value_random_mac1 | random_mac[0];   value_random_mac1 = (value_random_mac1 << 😎 | random_mac[1];   mutex_lock(&otp_mutex);   if (otp_write_prepare(otp_data)) {   mutex_unlock(&otp_mutex);   return 0;   }   otp_write_bits(index_mac0, value_random_mac0, 0x3e77);   otp_write_bits(index_mac1, value_random_mac1, 0x3e77);   otp_write_post(otp_data);   mutex_unlock(&otp_mutex);   } } //end 3.  kernel_imx/drivers/char/fsl_otp.c ---------------------------------------------------------------- static int __devinit fsl_otp_probe(struct platform_device *pdev) {   ...   retval = sysfs_create_group(otp_kobj, &attr_group);   if (retval)   goto error;   mutex_init(&otp_mutex);   //add by xxx   check_otp_mac();   //end

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

Question: Is SN65LVDS315 (MIPI CSI-1) compatible with our i.MX6 MIPI CSI-2 interface? CSI-2 extends CSI-1 with multiple lanes, but both standards use the same D-PHY layer. Answer: No, the i.MX6 MIPI CSI-2 interface is not compatible with CSI-1 devices. Standards that require backward compatibility to legacy standards always state that the standards are backward compatible. The CSI-2 standard does not say that. (I have a copy of the standard and I have read it specfically for that reason)  The CSI-2 standard does say that a specifically designed PHY, built to D-PHY MIPI01 specification is used for CSI-2. The PHY's used for CSI-1 and CSI-2 are different and they are not compatible. There are some processors that do have compatiblity for CSI-1 and CSI-2, but if you read closer, you will find that they have two different modes (and probably two different sets of pins): One for CSI-2 and One for CSI-2/CSI-1 legacy. It is interesting that a company would choose to inlcude a dying technology in a newer processor, but my guess is that they have a number of other CSI-1 devices they are trying to sell before they can't be used anywhere and nobody wants them. if the customer is looking for a parallel camera interface to CSI-2 converter IC, may I recommend the Toshiba TC358746 device. I have not used it specifically, but I have worked with a Toshiba rep on an HDMI to MIPI CSI-2 project that input into the i.MX6 processor. Once all the correct parameters were determined, it worked very well. Much higher data rate flow.

I.MX6 CoreBoard Computer On Module • Processor Freescale i.MX 6Quad, 1GHz • RAM 1GB DDR3 SDRAM 64-bit • ROM 4GB NAND Flash    UP to 16GB • ROM 2M SPI Nor Flash • Power supply Single 5V • Size 40mm SO-DIMM • Temp.-Range     0 to + 95C (Consumer)               -20 to + 105C (Extended Consumer)               -40 to +105C (Industrial)               -40 to + 125C (Automotive) Key Features • 10/100Mbps Ethernet • One High Speed USB 2.0 ports • Full HD LCD controller, 24bpp • OpenGL ES 2.0 and OpenVG 1.1        hardware accelerators • Multi-format HD 1080p60 video decoder and 1080p30 encoder hardware engine • Two Camera Interfaces • NEON MPE coprocessor — SIMD Media Processing Architecture — dual, single-precision floating point execute pipeline • Unified 1MB L2 cache • Several interfaces: 5x UART, 2x SDIO, 1x SSI/AC97/I2S, 3x I2C, 2xCSPI • 3.3V I/O • 2x Controller Area Network (FlexCAN) • PCIe 2.0 (1-lane) LVDS Option only: • Dual LVDS display port • SATA OS Support • Linux • Android

Attached is a chunk of the Filesystem needed to construct the Linux Image https://community.freescale.com/docs/DOC-93887

The MMPF0100 and MMPF0200 are the newest in the family of Freescale Analog PMICs supporting the i.MX6 processor.  These devices are economical, quick turn programmable system power management solutions with fully programmable voltages, sequencing, and timings.  Why risk anything else?  These are optimized and validated to work seamlessly with our i.MX6 processors. 

L5.4.3_1.0.0 release is now available on IMX_SW landing page: BSP Updates and Releases -> Linux ->Linux L5.4.3_1.0.0. Documentation -> Linux -> Linux 5.4.3_1.0.0 Documentation Files available: # Name Description 1 imx-yocto-LF_L5.4.3_1.0.0.zip i.MX L5.4.3_1.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 LF_v5.4.y-1.0.0_images_MX6QPDLSOLOX.zip i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualLite, i.MX 6Solox Linux Binary Demo Files 3 LF_v5.4.y-1.0.0_images_MX6SLLEVK.zip i.MX 6SLL EVK Linux Binary Demo Files 4 LF_v5.4.y-1.0.0_images_MX6UL7D.zip i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 LF_v5.4.y-1.0.0_images_MX7ULPEVK.zip i.MX 7ULP EVK Linux Binary Demo Files  6 LF_v5.4.y-1.0.0_images_MX8MMEVK.zip i.MX 8M Mini EVK Linux Binary Demo Files  7 LF_v5.4.y-1.0.0_images_MX8MNEVK.zip i.MX 8M Nano EVK Linux Binary Demo Files  8 LF_v5.4.y-1.0.0_images_MX8MQEVK.zip i.MX 8M Quad EVK Linux Binary Demo files 9 LF_v5.4.y-1.0.0_images_MX8QMMEK.zip i.MX 8QMax MEK Linux Binary Demo files 10 LF_v5.4.y-1.0.0_images_MX8QXPMEK.zip i.MX 8QXPlus MEK Linux Binary Demo files 11 imx-scfw-porting-kit-1.2.10.1.tar.gz System Controller Firmware (SCFW) porting kit v1.2.10.1 for L5.4.3_1.0.0   Target board: MX 8 Series MX 8QuadXPlus MEK Board MX 8QuadMax MEK Board MX 8M Quad EVK Board MX 8M Mini EVK Board MX 8M Nano EVK Board MX 7 Series MX 7Dual SABRE-SD Board MX 7ULP EVK Board MX 6 Series MX 6QuadPlus SABRE-SD and SABRE-AI Boards MX 6Quad SABRE-SD and SABRE-AI Boards MX 6DualLite SDP SABRE-SD and SABRE-AI Boards MX 6SoloX SABRE-SD MX 6UltraLite EVK Board MX 6ULL EVK Board MX 6ULZ EVK Board MX 6SLL EVK Board   What’s New/Features: Please consult the Release Notes.   Known Issues: For known issues and more details please consult the Release Notes.   More information on changes of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-zeus ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-zeus      

This describes how to perform frequency measurements of an external signal by using the Camera Sensor Interface (CSI) of an i.MX21/25/35 processor. Principle: A way to measure the frequency of a digital signal is to count the number of received rising or falling edges during a known amount of time. The CSI embeds a 16-bit frame counter. When programmed in non-gated clock mode, this counter increases at any rising edge on the VSYNC signal. Other signals of this interface could be ignored such: MCLK, PIXEL_CLK, HSYNC, DATA. Software example for the i.MX25: void CSI_init(void){       unsigned int tmp_value = 0;       /* It assumes that the VSYNC I/O is set to CSI mode */       /* Disable IPG_PER_CSI to save power consumption */       *((unsigned int *) CCM_CGR0) &= ~(0x1<<0);       /* HCLK_CSI and IPG_CLK_CSI should be enabled. */       *((unsigned int *) CCM_CGR0) |= (0x1<<18);       *((unsigned int *) CCM_CGR1) |= (0x1<<4);       /* Configuration of CSI_CSICR1 in non-gated clock mode */       tmp_value = 0;       tmp_value |= (1<<8);    // sync FIFO clear       tmp_value |= (1<<30);   // ext vsync enable       *((unsigned int *) CSI_CSICR1) = tmp_value;       // Reset frame counter       *((unsigned int *) CSI_CSICR3) |= (1<<15); } Then, every T seconds, the software has to read the register CSI_CSICR3. The 16-bit size field from bit 16 shows the current value of the frame counter (FRMCNT). This regular or irregular read could be done based on a GPT to have a known time reference. It is easy to calculate the frequency of the signal: Frequency = FRMCNT / T (Hz). At any time, the frame counter can be reset thanks to the bit 15 of the register CSI_CSICR3. NOTES: MCLK does not need to be enabled. The input frequency should not be higher than what can electrically support the VSYNC input. Please, refer to each i.MX datasheet for more information.

Network File System (NFS) Setting the host 1 - Install NFS Service on host typing: your slackware linux probably already have a version of nfs-utils installed, but if it doesn't you can get it downloading the nfs-utils from:  [1] then as root:  #installpkg nfs-utils-1.0.7-i386-1.tgz 2 - Setup exports typing: $sudo kedit /etc/exports and add the following line: /tftpboot/ltib/ *(rw,no_root_squash,async) 3 - Reestart the NFS server: $sudo /etc/rc.d/rc.rpc restart $sudo /etc/rc.d/rc.nfsd restart Now the host is ready to use NFS. Setting Target Linux Image to use NFS 1 - Run LTIB configuration typing: $./ltib -c 2 - On first page menu, go to "Target Image Generation -> Options" as in the picture below. 3 - Select the option NFS only and exit LTIB configuration to compile with the new configuration. 4 - LTIB should start new compiling and create a new Linux image on /<ltib instalation folder>/rootfs/boot/zImage 5 - Copy the created image on /<ltib instalation folder>/rootfs/boot/zImage to /tftpboot/zImage 6 - The system is ready to run with NFS. The root file system on target will be located on host on /<ltib instalation folder>/rootfs/

Please join us for a webinar tomorrow - July 30 at 10 AM CDT. Register here: https://info.cranksoftware.com/resources/modernize-embedded-graphics-ultra-low-power-ui-nxpcranksoftware NXP’s i.MX 7ULP applications processor, alongside Crank's Storyboard GUI design and development software, gives embedded teams the best of both worlds – rich 2D/3D performance with MCU-level low power. Join Brian Edmond and Nik Jedrzejewski to get a technical deep dive into the i.MX 7ULP and Storyboard and learn: the latest trends in graphics for battery-powered devices hardware features of the i.MX 7ULP, including the Heterogeneous Domain Computing architecture how to leverage Storyboard's hybrid rendering solution when switching between 2D and 3D graphics to minimize power consumption   PANELLISTS Brian Edmond, President, Crank Software Nik Jedrzejewski, i.MX Product Manager, NXP

You can create GTK applications manually—this is just like creating Graphics Java Applications. It uses a similar layout idea! Copy this example and save as helloworld.c: /* example-start helloworld helloworld.c */ #include <gtk/gtk.h> /* This is a callback function. The data arguments are ignored * in this example. More on callbacks below. */ void hello( GtkWidget *widget, gpointer   data ) {    g_print ("Hello World\n"); } gint delete_event( GtkWidget *widget, GdkEvent  *event,  gpointer   data ) {    /* If you return FALSE in the "delete_event" signal handler,     * GTK will emit the "destroy" signal. Returning TRUE means     * you don't want the window to be destroyed.     * This is useful for popping up 'are you sure you want to quit?'     * type dialogs. */    g_print ("delete event occurred\n");    /* Change TRUE to FALSE and the main window will be destroyed with     * a "delete_event". */    return(TRUE); } /* Another callback */ void destroy( GtkWidget *widget, gpointer   data ) {    gtk_main_quit(); } int main( int   argc, char *argv[] ) {    /* GtkWidget is the storage type for widgets */    GtkWidget *window;    GtkWidget *button;       /* This is called in all GTK applications. Arguments are parsed     * from the command line and are returned to the application. */    gtk_init(&argc, &argv);       /* create a new window */    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);       /* When the window is given the "delete_event" signal (this is given     * by the window manager, usually by the "close" option, or on the     * titlebar), we ask it to call the delete_event () function     * as defined above. The data passed to the callback     * function is NULL and is ignored in the callback function. */    gtk_signal_connect (GTK_OBJECT (window), "delete_event",                        GTK_SIGNAL_FUNC (delete_event), NULL);       /* Here we connect the "destroy" event to a signal handler.      * This event occurs when we call gtk_widget_destroy() on the window,     * or if we return FALSE in the "delete_event" callback. */    gtk_signal_connect (GTK_OBJECT (window), "destroy",                        GTK_SIGNAL_FUNC (destroy), NULL);       /* Sets the border width of the window. */    gtk_container_set_border_width (GTK_CONTAINER (window), 10);       /* Creates a new button with the label "Hello World". */    button = gtk_button_new_with_label ("Hello World");       /* When the button receives the "clicked" signal, it will call the     * function hello() passing it NULL as its argument.  The hello()     * function is defined above. */    gtk_signal_connect (GTK_OBJECT (button), "clicked",                        GTK_SIGNAL_FUNC (hello), NULL);       /* This will cause the window to be destroyed by calling     * gtk_widget_destroy(window) when "clicked".  Again, the destroy     * signal could come from here, or the window manager. */    gtk_signal_connect_object (GTK_OBJECT (button), "clicked",                               GTK_SIGNAL_FUNC (gtk_widget_destroy),                               GTK_OBJECT (window));       /* This packs the button into the window (a gtk container). */    gtk_container_add (GTK_CONTAINER (window), button);       /* The final step is to display this newly created widget. */    gtk_widget_show (button);       /* and the window */    gtk_widget_show (window);       /* All GTK applications must have a gtk_main(). Control ends here     * and waits for an event to occur (like a key press or     * mouse event). */    gtk_main ();       return(0); } /* example-end */

Setting the host          1 - Install NFS Service on host typing: your slackware linux probably already have a version of nfs"utils installed, but if it doesn't you can get it downloading the nfs-utils from:  [1] then as root:  #installpkg nfs-utils-1.0.7-i386-1.tgz 2 - Setup exports typing: $sudo kedit /etc/exports          and add the following line: /tftpboot/ltib/ *(rw,no_root_squash,async)          3 - Restart the NFS server: $sudo /etc/rc.d/rc.rpc restart $sudo /etc/rc.d/rc.nfsd restart          Now the host is ready to use NFS.      Setting Target Linux Image to use NFS          1 - Run LTIB configuration typing: $./ltib -c 2 - On first page menu, go to "Target Image Generation -> Options".               3 - Select the option NFS only and exit LTIB configuration to compile with the new configuration.          4 - LTIB should start new compiling and create a new Linux image on /<ltib instalation folder>/rootfs/boot/zImage         5 - Copy the created image on /<ltib instalation folder>/rootfs/boot/zImage to /tftpboot/zImage 6 - The system is ready to run with NFS. The root file system on target will be located on host on /<ltib instalation folder>/rootfs/                           

Computer On Module • Processor Freescale i.MX535,1GHz/i.MX536, 800MHz • RAM 512MB/1GB DDR3 SDRAM • ROM 4GB EMMC,up to 32GB • Power supply Single 3.1V to 5.5V • Size 54mm SO-DIMM • Temp.-Range -20°C..70°C   -40°C..120°C Key Features • 10/100Mbps Ethernet • Two High Speed USB 2.0 ports • LCD controller up to 1600 x 1200, 24bpp • OpenGL ES 2.0 and OpenVG 1.1 hardware accelerators • Multi-format HD 1080p video decoder and 720p video encoder hardware engine • Two Camera Interfaces • NEON SIMD media accelerator • Unified 256KB L2 cache • Vector Floating Point Unit • Several interfaces: 3x UART, 2x SDIO, 2x SSI/AC97/I2S, I2C, CSPI, Keypad, Ext. Memory I/F • 3.3V I/O OS Support     • Linux     • Android Application:Smart mobile devices,Smart Display,Automotive Infotainment,Digital Signage, Telemedicine,Retail POS Terminal,Security,Barcode Scanner,Visual IP Phone,Patient Monitors,Surveillance Cameras,building control, factory / home automation, HMI For more information, please see Attachment We can provide a complete solution