kodi official support for i.MX6

Hi all,

With a little delay, I share with you this great news : The PR5202 I issued to add official i.MX6 support in Kodi was merged a month ago.
It is a major milestone that happens more than one year after I began to work on this support and I would like to thank warmly people who helped for the development (Jan, Chris, Rudi, Thomas…), distro which provided early support (Geexbox, archlinux arm, openelec…), companies who sent to me free samples (compulab, solid-run, udoo, tbsdtv) and all users who have praised or blamed this work !
It is not the end : I am very happy to announce that kodi team has welcomed me as a core team member so that i will continue to support that code upstream.
Regarding the xbmc-imx6 repository, it remains active for now because I will maintain its master branch which is based on Gotham at least as long as helix is not a stable release.
Of course, all helix stuff will directly be subject to PR in official xbmc repo which is now the place where main development happens.


EzeeCube : An exciting mediacenter and photo organizer

One year ago, I was looking for a capable System On Chip that is properly documented and that provides support for pure Linux and not only for android. Out of this research, I selected the Freescale i.MX6, I bought my first target (a GK802 which would have been a wonderful value for money if it had not exhibited a very annoying overheating issue) and began to work on XBMC porting for this specific soc.
Since that time I have heard about many devices based on this i.MX6 chip. But a few weeks ago, a specific project caught my attention : the EzeeCube.
This EzeeCube project is not yet another raw board but it is a full product which aims at addressing a specific need : Storing, organizing and syncing photos in a very simple way.
The project initiators have already developed a specific plugin for XBMC and dedicated applications for iPhone and android smartphones. They have also worked to design an aesthetic product with an innovative concept to stack additional hard disks or even DVD reader.

At hardware level, aside the energy efficient iMX6 (Dural Core), we can find 1GiB RAM, 1TB HDD, internal eMMC and rich connectivity (Ethernet, Wifi, BT, USB, SDcard, IR receiver…)

At first sight, one could think that the need is already fulfilled by other means.
First, some cloud storage services could enable to organize photos. Yet it is obvious that storing media on his own device can be less prone to safety concern, faster to sync as we don’t have to go through a slow uplink to the internet and especially cheaper as there is no recurrent fee which is quite high when you have a few hundreds of GiB to store.
Then, some NAS have interesting features regarding photos but the ones which have similar capabilities tend to be expensive and being able to turn them into a XBMC capable device is not so frequent while the XBMC nature of the EzeeCube makes it a natural mediacenter…

So at the end, this product has an innovative design, it enables to store a big amount of photos privately and to sync them with smartphones by focusing on simplicity while using XBMC as its main software.
After some exchanges with the project leader, Ashok, I even agreed to provide support to them because I am enthusiast regarding initiatives which aim at building a product with a real concept.
I invite you to discover further this product on its website and its crowdfunding campaign to make your mind about it and share your thoughts with the team…

XBMC development for i.MX6 : A new organization


As you know, I have been working on XBMC iMX6 support for a few months.
Last week, a major contribution was submitted by Chris (Koying) to enable rendering using Vivante direct texture extensions.
It was the opportunity to discuss how we could organize to upstream the imx6 support and a new way of working has just been defined.

New way of working

First of all, following Chris advice, I have created a github organization xbmc-imx6.
Please note that this account is now the place where i.MX6 development effort for XBMC will take place.
It aims at easing developers collaboration and at preparing a pull request on XBMC main repository to add official support.

Here are a few guidelines (which have been discussed here)

  • The branch master-pr will be the one which is ready for the “final” PR in XBMC main repository. This branch will be rebased vs xbmc master and it will be kept in sync with local master once a week.
  • The branch master will hold the current state of the art of this imx6 version : It will not be rebased against xbmc master but required changes (spotted while rebasing master-pr) will be merged.
    These 2 branches may seem weird at first sight : it is a way to keep a branch (master) that can be used for packaging (as git hashes will be stable on this one) and another one (master-pr) which is always ready for a PR in xbmc main repo.
  • In this imx6 repository developers can have their own branch but there is absolutely no guaranty about the content and stability of these branches. So, it is highly discouraged to build them or to directly cherry pick commits.
  • Locally, all commits into master are subject to a PR :
    • PR requires at least a review/comment from another developer before being merged. Exceptions are trivial fixes such as : comments fixes, cosmetics changes, very simple fixes that are urgently required to stabilize master branch (ie guard against NULL pointer).
    • I will have to confirm any major PR : Anything that changes the current logic or adds a new functionality.
    • A 24hours delay after the last comment will always be observed before closing a PR to deal with different TZ and availability of the members
  • At last, in xbmc-imx6 account, the issues will be the favorite place
    • to discuss new feature to be implemented (and assign job to prevent work duplication)
    • to exchange regarding this iMX6 development
    • to report bugs (if any lol)

Last but not least, everyone is welcome and any contributions will be very appreciated…


I am very happy with this change and I thank warmly Chris and Jan who are already very active to bring this i.MX6 version to a state that will allow upstreaming…

Yet another yocto image


I am pleased to announce that a new yocto based image (v0.0.4) with my newest XBMC for iMX6 is now available.
I would like to thanks all people who helped me to improve the current state of XBMC.
This image is an update of the previous one and is built in a similar way (Thanks to yocto dora)
Note that this image is rather for advanced users who want to give a try at the current state of XBMC for iMX6. Many users will prefer other well packaged distros like geeXboX or openelec.

The image is currently available for the following devices :

  • Wandboard Dual and Quad
  • Utilite : I have a pro model but it may work on other variants (untested for now)
  • udoo Dual and Quad

What’s new

This image packages XBMC Gotham Alpha 11 (12/31/2013) with my specific changes for iMX6.
The biggest changes compared to the previous one are :

  • Full liveTV support (with support for hardware deinterlacing)
  • Solve issues with some videos which were jerky
  • The “noise” on SPDIF is worked around
  • Kernel configuration also enablse many new options and drivers (especially most DVB USB drivers)


Here are the files :


I have updated the website to provide direct access to frequently used instructions.
For installation, you can refer to this page (It is also available in the menu header->howto->installation)

Also for liveTV, note that all XBMC clients are packaged.

If you want to plug a tuner on your target itself, most kernel USB DVD drivers are available.
Firmwares are not available by default in the Root FileSystem but the command :


will enable to download firmware for common devices..

tvheadend is running but you have to configure it a first time. To do so :

killall tvheadend
tvheadend -C

Then connect to you web interface : http://yourip:9981

Known issues

  • Some interlaced H264 1080p streams @50fps or @60fps are not played smoothly
  • HDMI passthrough for HD audio does not work
  • lirc is not properly configured to function properly “out of the box”
    Yet everything is available if you have a working driver (the driver for cheap IR receiver is available in wandboard image)
    You can launch lircd that way :
lircd -d /dev/lirc0 /etc/lircd.conf –output=/dev/lircd

And then xbmc that way,

/imx6/xbmc/lib/xbmc/xbmc.bin -l /dev/lircd

At last, the Smart packages updater has a few issues in this release :
If the update command

smart update

does not work in spite of working internet connection, then, issue the following commands :

rm -rf /var/lib/smart/
smart channel --add wolf_repo type=rpm-md baseurl=http://www.stephan-rafin.net/rpmhf2

For obscure reasons, smart is fooled in thinking that some basics packages are not installed (while they are ) and fails when it tries to reinstall them…
As a workaround, when you install a package, use the stepped option :

smart install --stepped your_package

and refuse installation of already installed packages…

Bugs Report

I have created a forum to discuss issues.
Please use it instead of comments as it should be more appropriate…


Lots of work has been addressed since the previous version.
I hope you will be able to witness the improvements and to enjoy liveTV.
Please understand that I cannot dedicate too much time for the packaging itself as I still have to focus on XBMC development and improvement…

Donate Button

First look at Matrix TBS2910


A few weeks ago, I received from TBS technologies their new Matrix tbs2910 device

The hardware device

It is iMX6Q device derived from the SabreSD board with nice specifications.
Of course, we find common features for an iMX6Q device such as :

  • 2GiB RAM
  • HDMI output
  • 1Gbps wired Ethernet (in fact limited to 400mbps as any other iMX6 device)
  • wifi 802.11n/b/g
  • sdcard slot
  • Analog audio output
  • 3 USB 2.0 slots
  • 1 USB OTG
  • RS232 (optional with additional adaptation board)

But it also exhibits a few, less common, interfaces :

  • mini PCIe slot
  • TF card slot
  • optical SPDIF (with TOSLINK connector)
  • SATA interface (including power connector)

Last but not least : A 16GiB eMMC is embedded.
This approach differs from most alternatives and their sdcard slots only solutions…

It is also worth mentioning that the HDMI CEC signal is properly wired and functional.

The device is packaged in a acrylic case which looks a little… Hmm well I guess you should have look at the pictures and make your own mind (Click on the picture tab)
There are also a few buttons (power, vol up and down) that are not so useful to be honest : But after all they could be bounded to other activities with a few changes…

At last the most worrying item is a fan !
Why the hell should we add a fan on a iMX6 device ? Of course heat dissipation can become a concern especially with the Quad variant and its GPU but I really think most ARM users just don’t want active cooling and that’s it…


The embedded eMMC can be programmed through the USB OTG port with freescale MfgTool2 tool, a user friendly but windows only utility.
TBS distributes several images on sourceforge :

  • An Android image
  • An ubuntu image
  • A MatrixTV image

I will mainly speak about the matrixTV as it is the one I have tried and I know about.
This image is built using the openbricks build system and the relevant source is again available on sourceforge.
This image packages my XBMC port along with useful programs for liveTV (especially VDR and tvheadend).
It even supports out of the box the TBS tuners (TBS5922, TBS5980, TBS5925, TBS5680, TBS DVB-C sticks, TBS5220, TBS5880,TBS5881) with a configuration program to setup everything at first boot.
That way, I have been able to have a smooth experience with my DVB-T TBS5880 tuner at first try (well at second try to be perfectly honest because there was a little mismatch between the dvb-c and dvb-t kernels at some time. But it is now something of the past…)

The developers seem to be pretty active and to listen to users feedback.
After my grunts about the fan which is quite loud, they quickly implemented an automatic regulation that really mitigates the issue as the fan will almost never run while using XBMC (only a few seconds if you heavily use the GUI but not during playback for sure)
They have also integrated in their kernel Rene driver to give access to a cheap IR receiver (It is easy to connect a TSOP on the header available at the corner of the board)

To get an idea about how it behaves, you can have a look at these videos posted by an user (piotras) on the XBMC forums :


At the end, it can definitively be an attractive iMX6 device with specific features and a team which wants to provide a good experience out of the box.
As I guess many users wonder which iMX6 devices they should buy, I will try to post an article which compares the ones I own (I currently have 7 different boards/devices) to help with this choice.
I will also post a similar article for the cubox-i4 as soon as I can as I have recently received a sample from solidrun and it is a very good device…

github account down

Hi all,

Only a little post to inform that github has deactivated my account (wolfgar) for unknown reasons.
I have the following error message :

One of our mostly harmless robots seems to think you are not a human.
Because of that, it’s hidden your profile from the public. If you really are human, please contact support to have your profile reinstated.
We promise we won’t require DNA proof of your humanity.

So all my work (XBMC, yocto meta layers, kernels…) is unavailable for now.
I am sorry for the inconvenience and I hope it will be solved soon (Don’t worry I have all my stuff locally and I will be able to host it elsewhere if github does not solve this stupid issue)

Edit : It is solved !
You can access my account again. Many thanks to github team for dealing with this on sunday…


Cheap IR receiver


Turning an iMX6 board into a perfect mediacenter certainly requires to be able to interact thanks to an IR remote command.
Some of you may think it is a thing of the past and a nice remote application on a smartphone is the way to go but I may be quite old school as I still think that a plain old remote is very useful.
If your TV and your board support CEC, then your TV remote can be the right candidate. Unfortunately, as I pointed in a previous article, only a few products (utilite being the only one I have successfully tested so far) wire correctly the CEC signal.
If you are unlucky with CEC, a IR receiver may be very welcome. Here again there are no many imx6 boards/products which have such a feature. As far as I know solidrun cuboxi products/boards are the only one.

So when a user, Rene vand den Braken, sent to me a way to add this feature thanks to a very cheap component 2 months ago, I though it is worth sharing this with all of you. (I am ashamed for being so long to write this article).
The wandboard will be used here but the same kind of hack can be done on any imx6 board with VCC/GND and a GPIO available on headers with minor modifications.

At last, it is worth mentioning that the initial driver/idea comes from Aron Robert Szabo and his work on RaspberryPi and that even if this hack works fine at least for Rene and I, you decide to realize it under your own responsibility and we will not be responsible if you damage your board…


At hardware level, we use a Vishay TSOP4838. It is a very affordable component : I have been able to order 5 pieces for 2.6$ (shipment included) on ebay.
You can read the whole datasheet but here is what you need to know :
The TSOP has 3 pins :
1 = OUT, 2 = GND, 3 = Vs

For our example, we will connect the TSOP on the JP4 header
And we will connect :

  • TSOP 2 to JP4 pin 19
  • TSOP 3 to JP4 pin 1
  • TSOP 1 to JP4 pin 18

Here is how it looks like on my own wandboard


Changes are required in the kernel (they will be included in my next image of course).
First the GPIO has to be freed from the generic GPIO framework to be usable for our needs. For now, the used pin is hardcoded and you will have to change this by yourself if you decide to use another GPIO.
Then, a dedicated lirc driver (lirc_wand.c) is required : This driver has been provided by René (as a derivative work from Aron lirc_rpi.c driver).
All the required changes are available in this commit

This new kernel driver will behave as a lirc_serial driver and the standard userspace lirc tools will be usable after loading it by :

modprobe lirc_wand

Maybe I can summarize how to start quickly with lirc user tools :

irrecord -n -d /dev/lirc0 myremote.conf

will enable to create a new configuration file for your remote.
You can launch lircd that way :

lircd -d /dev/lirc0 /path/to/myremote.conf

And, at last, you can test the correct behavior by launching


and pressing buttons on your remote
Many LIRC tutorials will give you further details…


That’s it ! Now, you can have fun with your IR remotes.
All this work can easily be adapted for another imx6 board…

XBMC on utilite SSD


I have stated several times that the XBMC image can perfectly be run from the the SSD on the utilite pro.
Yet, as I wanted users to be able to easily revert to another installation, I have not publicly published the way to run the XBMC image from the SDD so far.
Very recently, Compulab published the way to fully reinstall their official image on SSD on utilite wiki.
So it is time that I describe how to install the XBMC image on this SSD !

Installation how-to

First, you have to follow compulab wiki to create a SDcard.
Here is a quick summary (You need a Linux host) :

sudo SD=/dev/sdX ROOTFS_IMAGE=./utilite_ubuntu-12.04.3_2013-12-11.tar.bz2 ./dep-procedure.sh

with /dev/sdX being the SDCard device.

  • Insert the SDcard in utilite and boot your device with this fresh image
  • Configure Network and download my XBMC image on the utilite.
  • Download again the installation script
  • And launch it that way :
sudo SSD=/dev/sda ROOTFS_IMAGE=./xbmc-image-utilite_ssd.tar.bz2 ./dep-procedure.sh
  • When the script is finished, turn off the utilite, remove the sdcard and you are done !

You can now power on the device and enjoy your SSD…

build environment


In my previous post, I have published a little how-to to rebuild the whole image using yocto.
Some readers managed to follow the guide and to build the whole thing but a few others reported issues which seem mostly related to their build host.
Of course, yocto should behave the same (and it strives to do so by rebuilding almost all native requirements) whatever the development environment is. However it is not always the case especially for my XBMC recipe (So blame me for it : I am mostly the culprit here)
As I have not been able to understand all the reported issues, I have just decided to publish this new article to describe how to create a build environment which is known to work.

RFS generation

Of course, I could distribute a whole virtual machine image but I will describe a more lightweight way to generate a root filesystem ready to run yocto.
The plan is simply to use debootstrap to fetch a basic Ubuntu 12.04 (precise pangolin) file system and to chroot in this new environment to install the few additional requirements to be able to build my image.

Install debootstrap

If you don’t already have this utility in your distro, just install it. Most Linux distro (even RPM based distro) package it.
Of course the ubuntu/debian (and derivative) users will issue a command like :

apt-get install debootstrap

OpenSuse users will try

zypper install debootstrap

And I will be flamed by Fedora fans if I do not allude to :

yum install debootstrap

Install and configure precise

OK, let’s start :

USER=$(id -n -u)

# if your native install is 64bits
sudo debootstrap --variant=buildd --arch amd64 precise $CHROOT_PATH
# if your native install is 32bits, you will use instead 
# sudo debootstrap --variant=buildd --arch i386 precise $CHROOT_PATH

# copy a few file from native host to be able to use the same user in chroot
sudo cp /etc/passwd $CHROOT_PATH/etc/
sudo cp /etc/shadow $CHROOT_PATH/etc/
sudo cp /etc/resolv.conf $CHROOT_PATH/etc/
sudo cp /etc/group $CHROOT_PATH/etc/
sudo mkdir $CHROOT_PATH/home/$USER
sudo chown $USER  $CHROOT_PATH/home/$USER

# give access to sys, proc and dev in chroot 
# Not permanent (has to be redone after reboot)
 sudo mount --bind /proc $CHROOT_PATH/proc
 sudo mount --bind /sys  $CHROOT_PATH/sys
 sudo mount --bind /dev  $CHROOT_PATH/dev
 sudo mount --bind /dev/pts  $CHROOT_PATH/dev/pts

Then we have to finalize the installation in the chroot itself by entering into the fresh system :

sudo chroot ./precise/ /bin/bash -i

In the new system, let’s finish the install :

mkdir /run/shm
mount -t tmpfs none /run/shm/

apt-get update
apt-get install wget curl python-m2crypto git diffstat  gawk chrpath texi2html texinfo openjdk-6-jre zip


You should have exited the chroot, now reenter as normal user :

ID_NUM=$(id -u)
GID_NUM=$(id -g)
sudo chroot --userspec=${ID_NUM}:${GID_NUM} ./precise/ /bin/bash -i

In the chroot, you can issue the commands from the other post to launch the build.
I copy them for convenience :

#Install repo
mkdir ~/bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
#Create BSP folder
mkdir xbmc-bsp
cd xbmc-bsp
#Download layers
repo init -u https://github.com/wolfgar/fsl-community-bsp-platform -b dora
repo sync
#Initialize build environement
#Valid MACHINE values are wandboard-quad wandboard-dual and utilite
TEMPLATECONF=`pwd`/sources/meta-stef/conf MACHINE=wandboard-quad source setup-environment build
#Let's build the whole thing
bitbake xbmc-image

And you are done… 😉



Udoo is a dev board which was funded by a kickstarter project.
During these last years, I am convinced that many people have though : Why the hell there is not a single modern dev board (pandaboard, beaglebone, Rpi, cubieboard…) which strives to provide some sort of real compatibility with the arduino ecosystem ?
It would be the best of two worlds : A modern a powerful system on chip and the availability of so many sketches for all and any crazy projects…
Udoo exactly solves this absurdity by coupling a freescale iMX6 and a Atmel SAM3X8E (arduino due) !
Thus, this board is obviously very attractive for DIY enthusiasts and I am very pleased to make my iMX6 XBMC work available for it.


I have just packaged the recent u-boot 2013-10 for udoo and upgraded the 2.6.35_4.0.0 udoo kernel to 2.6.35_4.1.0 so that my last image can be available for this exciting platform.
I also added all relevant recipes in my yocto layer : The new machines are udoo-quad and udoo-dual
That being said, my previous post is fully relevant for any other topics (installation, bug reports, distro generation and so on…)

  • The udoo-quad image is available for download – md5sum 676736f4c0a139ba9ecd48ec5c7be29b
  • The udoo-dual image is available for download – md5sum 53773dd84d97bbbd25aa008ab250ddac

This is a first release which may be quite rough but it will improve over time of course…
Discussion about this image can happen in udoo forums