April 9 2014 - FTF Wandboard/Wandcam in the techlab


20140410-wandcam-ftf
We are at FTF (Freescale Technology Forum) in Dallas and our Wandboard friend John Weber is showing off his wandcam in the technology lab at the Avnet booth.

Talk back and discuss in the Wandboard community forums

April 8 2014 - FTF Wandboard running Java


20140408-ftf-wandboard-java
We are at FTF (Freescale Technology Forum) in Dallas and our Wandboard can be found at the Oracle booth as one of the development boards for Java and IoT applications.

Talk back and discuss in the Wandboard community forums

March 19 2014 - Build your own Wandboard Cluster


We all heard about CERN over the past years. (Large Hardon Collider). Searching for the magic particle. The holy grail.

For that reason it's not a surprise they have built a magic Wandboard cluster.

Find more information together with instructions at the CERN homepage : https://twiki.cern.ch/twiki/bin/view/Main/WandboardCluster

Talk back and discuss in the Wandboard community forums

March 3 2014 - Freescale Univerity Program uses the Wandboard


20140303-freescale-universi
Last week at Embedded World the Wandboard was used in the Freescale University Program controlling remote controlled cars by running Ubuntu, OpenCL and a lot of imagination.

Talk back and discuss in the Wandboard community forums

February 25 2014 - Wandboard goes Embedded World (again)


20140225-embeddedworld
We are in Nuremberg (Germany) at Embedded World (again). This year once again the Wandboard is featured at the Freescale booth.

Talk back and discuss in the Wandboard community forums

February 12 2014 - Virtual machine for compiling Android 4.3


20140212-wandboard-vm-android43

Sometimes, setting up an envirnonment for building Android can sometimes be a little trouble. The required packages might not be correctly documented, can vary between Android versions, and the defaults installed by your distribution is different versions than the expected ones.

In order to reduce the initial barrier for building an Android runtime image for the Wandboard, we have prepared a virtual machine where all the required packages are installed.

The VM image, is playable using the free VMPlayer 6 (from VMWare), and contains a Ubuntu 12.04 LTS 64-bit.

Instructions how to compile and create a bootable SD card can be found in the Wiki.

So, those interested, go get the VM image from the downloads section!


Talk back and discuss in the Wandboard community forums

January 23 2014 - Video playback using the Wandboard VPU, part 3

This article conlcudes the article series on gstreamer by sketching on how gstreamer acceleration is implemented on Freescale iMX6.

Gstreamer hardware acceleration on iMX6

The typical gstreamer usage on iMX6 is to use the VPU for video decoding. This is usually done using the vpudec element, and then using a Video For Linux sink (mfw_v4lsink) to display the video in a X11 window. The v4lsink has a problem though: it only supports one movie at a time. The recommended solution from Freescale is to use mfw_isink when playing back several videos -- but that does not integrate well with X11 (in fact, it changes the framebuffer to YUV mode).

Further the X11 integration is not made easier from xvimagesink being a fake in the Freescale Xorg driver (it announces XV support, but when asked to use it there are no adapters!)

Gstreamer and OpenGL

For X11 integration, glimagesink seems to be the most general.

It uses the OpenGL framework to display and resize the video. It cooperates with X11. It rescales without problems or use of additional elements (like videoscale).

While the default glimagesink does not allow placement of the movie window, or playback to a preexisting XWindow. However gstreamer allows a facility called GstXOverlay for this. It is a abstract base class (or as close you get in C) for X11 output. Using this, the handy hacker should be able to get a OpenGL and VPU accelerated X video player up and running by implementing their own imagesink (based on the code in glimagesink, and adding arguments for position and window id)


Demo image

For those who are curious about multiple simultaneous videos, there is a simple demo image here that plays for videos continously.


Talk back and discuss in the Wandboard community forums


January 20 2014 - Video playback using the Wandboard VPU, part 2


This post is the second article of three about hardware accelerated video playback on the Wandboard. Todays topic is gstreamer basics and how gstreamer framework can be used from the linux command line.

Gstreamer overview

The gstreamer framework is typically integrated in a movie player, and quite unnoticable for the user. Here, we will instead dive into the command line interface to gstreamer.

The main command is called gst-launch.

However that is not enough as such. One needs to give it arguments with:
- where to play from
- how to decode video / audio
- how to 'display' the result

The word display is in quotes, since gstreamer can read and send playback from several different sources. Here we will assume a video file is to be displayed on the screen.

An example command is:

% gst-launch filesrc location=movie.mp4 typefind=true \
 ! aiurdemux \
 ! vpudec \
 ! mfw_v4lsink

The first argument to gst-launch is typically the video source. Typically the source is a media file, but it can be a network socket or just about anything. It is from where the videostream (encoded) is to be read. In the example command, the video is to be read from the file "movie.mp4".

The sink is where to dump the decoded video, typically the screen, but can also be just about anything. Here the sink is mfw_v4lsink, which is to display it using the iMX6 Video4Linux output.

In between the source and the sink, a number of elements can be specified, acting as filters, converters etc. In the example command above, one important element is the vpudec one -- that is the VPU video decoder element. More about that in part 3.

Colourspaces

One issue one might encounter is incompatible colourspaces. The vpudec element outputs YUV format, while the framebuffer is in RGBA format. While imagesinks like ximagesink is able to convert YUV to RGBA, the conversion is very slow. The iMX6 has hardware support for colourspace conversion, and one element for colourspace conversion is the mfw_ipucsc element: gst-launch filesrc location=movie.mp4 typefind=true ! aiurdemux ! vpudec frame-plus=1 ! mfw_ipucsc ! videoscale ! ximagesink

To find out the input and output formats of elements, one can use the 'gst-inspect' command, i.e: gst-inspect vpudec


Talk back and discuss in the Wandboard community forums



January 17 2014 - Video playback using the Wandboard VPU, part 1


This is the first part of three in a series of articles about hardware accelerated video playback.
The very first part is about a common VPU driver issue on iMX6. The second and third part are about gstreamer, in general and on iMX6.

Physical memory allocation failure

Some of you will shiver seeing those words. It is a kernel error message haunting Linux video playback on the iMX6.

This blogpost discusses the reasons for this error, and proposes a workaround.

Why it happens

Primarily, the physical memory allocation failure is caused by a failure to allocate DMA memory inside the VPU driver. Contrary what some might believe, it is not because insufficient memory available or memory leals. It is due something far more sinister: DMA memory pool fragmentation.

Using the VPU for video decoding, the VPU driver will request and free blocks of varying sizes (range ~80k - ~5M), and eventually the fragmentation of the free memory will be so bad that a large continous block can no longer be allocated. Bam!

Fragmentation is a common problem when dealing with memory allocators. Many methods have been tried and tested, but thre is no silver bullet.

The current strategy employed by the kernel is a straightforward "first fit" allocator (deep inside dma_alloc_coherent()). That is, when a say 300kB block is requested, the first free block of sufficient size is used. Be it a 300kB block or a 5MB block. This way, eventually all continous, say 5MB, blocks are partially in use by far smaller blocks.

Workaround idea

While a smarter algorithm for allocating dma memory probably could improve on the situation, it would be a non-trivial task to test and implement other allocators.

It happens that the likelyhood of badly fragmented memory is only one consideration when implementing a memory allocator. Other considerations, like speed, has also to be taken into account. Let's just contend that memory allocators are a rich area of research, and focus on the problem at hand.

Instead of an ultimate memory allocator, the following workaround is proposed: how about not really freeing and allocating memory, and just caching the continous blocks when they were supposed to be freed? This is the age-old technique of using a memory pool allocator.

Results

We tested this inside the VPU driver, with promising results. Our test playback demo played four simultaneous video clips, and the DMA allocation error usually happened after 10-20 minutes.

After implementing the pool allocator, we were able to play the clips for days without any errors.

Patch

The patch can be found in the Wandboard git.

The drawback of the patch is that the VPU driver keeps a pool of memory blocks that are never freed. It binds DMA memory that can never be used by other drivers.

Future work

Also DMA memory is also requested by the PXP driver. In case of persistent issues, implementing a memory pool allocator might be beneficial in the PXP driver as well. Maybe even with combined memory pools with the VPU driver?


Talk back and discuss in the Wandboard community forums


January 13 2014 - Wandboard meets the WandCam


20140113-wandcam 

Avnet has created a camera board for Wandboard and they call it WandCam. WandCam uses an OV5460 MIPI image sensor module with autofocus from Leopard Imaging, so engineers can easily leverage this design for security/surveillance and robotics applications.

It is very affordable and available from the Avnet Express website at http://www.em.avnet.com/wandcam

Wandboard

wandboard-freescale-imx6

Wandboard Specifications

  Wandboard Solo Wandboard Dual Wandboard Quad
 Processor Freescale i.MX6 Solo Freescale i.MX6 Duallite Freescale i.MX6 Quad
 Cores Cortex-A9 Single core Cortex-A9 Dual core Cortex-A9 Quad core
 Graphic
 engine
Vivante GC 880
+ Vivante GC 320
Vivante GC 880
+ Vivante GC 320
Vivante GC 2000
+ Vivante GC 355
+ Vivante GC 320
 Memory 512 MB DDR3 1GB DDR3 2GB DDR3
       
 Audio tag tag tag
 Optical
 S/P DIF
tag tag tag
 HDMI tag tag tag
 Camera
 interface
tag tag tag
 Micro-SD slot 2 2 2
       
 Serial port tag tag tag
 Expansion
 Header
tag tag tag
 USB tag tag tag
 USB OTG tag tag tag
 SATA NO NO tag
       
 Gigabit LAN tag tag tag
 WiFi (802.11n)   tag tag
 Bluetooth   tag tag
 

79 USD

99 USD

129 USD

Wandboard on Twitter