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.

Stéphan

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…

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…

Stephan

Intro

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…

Hardware

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

Software

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

irw

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

Conclusion

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

Intro

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) :

• Download the latest Utilite Linux Image, it is utilite_ubuntu-12.04.3_2013-12-11.tar.bz2 at the time this article is written.
• Download the installation script
• Insert the SDcard and launch the script that way :

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…

Intro

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)
CHROOT_PATH=$(pwd)/precise

# 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
exit

Build

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 :

cd  
#Install repo
mkdir ~/bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
 
#Create BSP folder
PATH=${PATH}:~/bin
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… 😉

Intro

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.

XBMC

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