CedarX/XBMC

Kodi (formerly XBMC) is a popular free and open source media player software application designed as a 10-foot frontend graphical home theater (a.k.a. media center) interface for large-screen televisions. Made to be controlled with a remote control it enables ARM-based media players and set-top boxes like those with Allwinner SoCs with CedarX VPU (Video Processor Unit) to hardware decode and play high-definition videos, music, and other digital media files from local and network storage media, as well as stream podcasts, videocasts, and such of the internet, and displayed in a appealing way on your living-room TV.

This article contain instructions on compiling and developing Kodi/XBMC on and for Allwinner SoCs that features the CedarX VPU, like A10, A10s, A13, A20, and A23. Note that these instructions are specifically only meant for developers and advanced or expert Linux users that can actively assist with the porting process.

=Overview= Kodi/XBMC has already have an initial but ultimatly obsolete port for the A10 / A20 SoC with CedarX hardware accelerated video decoding, this experimental third-party port and the code patches have however not made it upstream into mainline Kodi/XBMC.

Pre-built application binaries of this initial port are not available so therefore you will need to compile Kodi/XBMC yourself, at least until if and when code for these CedarX based Allwinner SoCs makes it into the mainline XBMC upstream at http://kodi.tv

Team-Kodi (who before used to be known as Team-XBMC), the official development team of Kodi/XBMC, does currently not recommend that any end-user buy Allwinner A1x or A2x based hardware for the specific purpose of only running Kodi/XBMC since they do not have the resources to support this platform as of yet.

More information about Kodi/XBMC can be found on wikipedia http://en.wikipedia.org/wiki/XBMC and the Kodi wiki http://wiki.kodi.tv or http://forum.kodi.tv

= Building Kodi/XBMC for A10 and A20 SoC series= This is a little how-to of steps to compile XBMC for devices using Allwinner A10 and A20 SoC series (e.g. for hardware like Mele A1000, Cubieboard, and Banana Pi) based on Empat0's GitHub sources http://github.com/empatzero/xbmca10. The development work on the coding side was all done by Empat0 (a.k.a. empat zero). The used repository in the example below is however from http://github.com/rellla/xbmca10 which is currently the newest and contains a few adaptions. It is a fork of empat0's work. If you want an only A20 version you can use this repository: https://github.com/fflayol/xbmc.

The result should be a Debian armhf system with XBMC using CedarX for hardware accelerated video decoding.

This version of XBMC runs directly on the framebuffer, and thus XServer is therefor not needed!

Prerequisites
There are more ways to prepare a working rootfs for XBMC. You can either prepare the sdcard directly as described or you can chroot into the rootfs on your host system and sync it with your sdcard later when you have finished. So the following steps can also be done in a chroot on your host if you are cross-compiling.

Prepare your SD-Card
Create a bootable SD-Card follwing our manual build howto and Debian. Be sure to use a kernel with mali-drivers-version r3p0 (sunxi-3.0 should be good).

Boot into your target system
Boot the new debian from the sd-card directly on the target and bring the system up to date: root@mele:~/# apt-get update root@mele:~/# apt-get upgrade

Install the dependencies for XBMC (needs update!)
root@mele:~/# apt-get build-dep xbmc


 * this should install the following packages:

need to install 3 more dependencies: root@mele:~/# apt-get install swig default-jre libgtk2.0-bin libssh-4 libssh-dev

ensure you use hardware acceleration root@mele:~/# echo -e "\nA10HWR=1" >> /etc/environment (to set it permanently)

Now go on with Native Compile or  Cross Compile.

Prerequisites for native compile
Create a swap-file, because otherwise the compiler runs out of memory during compiling and aborts root@mele:~/# dd if=/dev/zero of=/swap bs=1M count=384 root@mele:~/# mkswap -c /swap root@mele:~/# swapon /swap

Create your workspace directory: root@mele:~/# mkdir melehacking root@mele:~/# cd melehacking

Checkout the source code
root@mele:~/melehacking# apt-get install git root@mele:~/melehacking# git clone git://github.com/rellla/xbmca10.git root@mele:~/melehacking# cd xbmca10 root@mele:~/melehacking/xbmca10# git checkout stage/Frodo

Build
The following external libs/ repos are used/ downloaded:
 * taglib: https://github.com/downloads/taglib/taglib/taglib-1.8.tar.gz
 * cedarx: https://github.com/linux-sunxi/cedarx-libs/tree/master/libcedarv/linux-armhf
 * libmad: ftp://ftp.mars.org/pub/mpeg/libmad-0.15.1b.tar.gz
 * mali: https://github.com/linux-sunxi/sunxi-mali-proprietary/tree/master/r3p0/armhf
 * mali-dev: https://github.com/linux-sunxi/sunxi-mali/tree/master/include

Build dependencies root@mele:~/melehacking/xbmca10# cd tools/a10/depends root@mele:~/melehacking/xbmca10/tools/a10/depends# make Build xbmc itself root@mele:~/melehacking/xbmca10/tools/a10/depends# make -C xbmc root@mele:~/melehacking/xbmca10/tools/a10/depends# cd ../../../ root@mele:~/melehacking/xbmca10# make install

Move on to and start XBMC.

Cross Compile of XBMC
This was tested with github.com/rellla/xbmca10 and built in Debian Sid as host. You will need several packages on the build system and a copy of the root file system of the target to build against. This howto assumes you are running off an SD card with the root file system in /dev/sdb2.

Setup Cross Compiler

 * At first set up your toolchain.

Prerequisites for Cross Compiling
root@debian:~/# mount /dev/sdb2 /mnt/rootfs-a10 root@debian:~/# ln -s /mnt/rootfs-a10/lib/arm-linux-gnueabihf /lib/arm-linux-gnueabihf root@debian:~/# ln -s /mnt/rootfs-a10/usr/lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf root@debian:~/# ln -s /mnt/rootfs-a10/usr/include/arm-linux-gnueabihf /usr/include/arm-linux-gnueabihf root@debian:~/# apt-get build-dep xbmc root@debian:~/# apt-get install shtool swig default-jre Note: If compiling on a 64 bit system there is a known bug with the libcurl headers not working with 32 bit programs. To work around the problem build on a 32 bit system, or copy the file /usr/include/curl/curlbuild.h from a 32 bit system to your 64 bit build host. root@debian:~/# mkdir melehacking root@debian:~/# cd melehacking
 * Sync and move SD card to build system
 * Mount the rootfs of the prepared SD Card
 * Create symlinks to the mounted libraries
 * Install the dependencies for building XBMC on the host system
 * Create your workspace directory:

Checkout the source code
root@debian:~/melehacking# git clone git://github.com/rellla/xbmca10.git root@debian:~/melehacking# cd xbmca10 root@debian:~/melehacking/xbmca10# git checkout stage/Frodo

Update XBMC build config
Update this section at line 48 of tools/a10/depends/depends.mk with your values, e.g. #where is your arm rootfs SDKSTAGE=/mnt/rootfs-a10 #where is your xbmc install root XBMCPREFIX=/allwinner/xbmc-pvr-bin$(HF) #where is your toolchain TOOLCHAIN=/usr/arm-linux-gnueabi$(HF)

Build
At this point the settings are basically the same for the native build: Build dependencies root@debian:~/melehacking/xbmca10# cd tools/a10/depends root@debian:~/melehacking/xbmca10/tools/a10/depends# make Build xbmc itself root@debian:~/melehacking/xbmca10/tools/a10/depends# make -C xbmc root@debian:~/melehacking/xbmca10/tools/a10/depends# cd ../../../ root@debian:~/melehacking/xbmca10# make install

Move XBMC to target system
You should copy from your install location on your build system to an identical location on the target system (may not vital that they have the same path) like so ... root@debian:~/melehacking/xbmca10/cp -r /allwinner/xbmc-pvr-binhf /mnt/rootfs-a10/allwinner/xbmc-pvr-binhf

To redistribute it, you can also create a tarball: root@debian:~/melehacking/xbmca10/tools/a10/depends# make -C package tarball This results in a xbmca10.tar.gz which includes all needed (and stripped) files in /allwinner/xbmc-pvr-binhf. This can easily be copied and extracted on the target rootfs.

Umount your SD Card root@debian:~/melehacking/xbmca10# umount /dev/sdb2 and boot it on your A10 Device.

Start XBMC
After a reboot you modprobe the needed modules (depending on the used kernel version): root@mele:~/# modprobe disp root@mele:~/# modprobe lcd root@mele:~/# modprobe hdmi root@mele:~/# modprobe mali root@mele:~/# export A10HWR=1 (ensure to have this set if not rebooting!) root@mele:~/# cd /allwinner/xbmc-pvr-bin/lib/xbmc root@mele:/allwinner/xbmc-pvr-bin/lib/xbmc# ./xbmc.bin

Using the Android libraries via libhybris
Due to some bugs in the native linux binaries of cedarx, ssvb succeeded to use libhybris and the Android binaries instead. This is the recommended way. See CedarX/libve.

Troubleshooting
ln -s usr/include/dbus1.0/dbus usr/include/dbus libegl1-mesa libegl1-mesa-dev libegl1-mesa-drivers libgles2-mesa libgles2-mesa-dev
 * (native) If you get a compiler error when processing h264.o or building xbmc.bin, then check, if swap is enabled. The compiler ran out of memory!
 * (native) If deb-building fails, check, if your tmp-directory has enough free space and is no tmpfs, because of the lack of memory an mele.
 * To use the bash-script bin/xbmc to start xbmc, you have to comment out the exec of FEH.py, because of a failing test of glxinfo -> no display found.
 * Depending on your setup you may have to change some things to build
 * If mysql_config is not found, even though it is clearly there you can set disable-mysql in Makefile under xbmca10/tools/a10/depends/xbmc
 * Header files might not be where they are expected, this can be fixed with symlinks and copying headers, for example...
 * Once you get in trouble with some mesa conflicts, ensure to not have installed the following packages on your target system:
 * Check the discussion section for more notes.
 * Ensure that you have installed ALL of the dependencies, header files etc. in your target rootfs and ensure that they are available during build. The build script does not search for them on your host-rootfs!

= Configuring XBMC dependencies for Linux on A10 based devices =

Getting IR (infrared) remotes working on A10 based media players
For getting IR (infrared) remote controls working on the A10 based media players, please see the LIRC article in this wiki. Place a suitable Lircmap.xml in userdata-directory.

= Enabling dirty regions (a.k.a. dirty textures) for XBMC = This dirty region (a.k.a. dirty texture) feature in XBMC is designed to improve XBMC's GUI renderer performance on the GPU by only drawing when something like a texture changes on the screen, that region is then marked as dirty by XBMC's GUI library and only that region is redraw region on the screen.

This feature is however still a little buggy and therefor not enabled by default in XBMC, but all users of XBMC on A10 based devices can try enabling the hidden "dirty regions" (a.k.a. "dirty textures") rendering feature advanced setting themselves manually.


 * http://wiki.xbmc.org/index.php?title=HOW-TO:Enable_dirty_regions
 * http://xbmc.org/theuni/2011/06/19/working-with-dirty-regions/
 * http://wiki.xbmc.org/index.php?title=Advancedsettings.xml#.3Calgorithmdirtyregions.3E

Dirty regions are any parts of the screen that have changed since the last frame. By not re-rendering what hasn't changed, big speed gains can be seen. Because all GPUs work differently, only Mode 3, combined with nofliptimeout=0, is guaranteed to be safe for everyone, but current timing issues with nofliptimeout keep this from being the default. Note that with "dirty regions" your system CPU usage might go up a little (because it is doing the dirty regions calculations) but your GPU usage will be much lower, and since it is the GPU and not CPU that is the bottleneck in XBMC for embedded systems your GUI performance will be better even though the CPU usage is higher.

To enable dirty regions manually you need to create a "advancedsettings.xml" text file youself and put the XML enabling tags in there and copying to your "/userdata/" folder (/home/username/.xbmc/userdata/).

Example:

You could also try to enable the feature but that is even more experimental so know that it can cause even more GUI rendering issues in XBMC

Example:

To have both of these enabled your "advancedsettings.xml" then the finished file should look something like this:

=Sources implementing CedarX support in XBMC=
 * https://github.com/empatzero/xbmca10
 * https://github.com/rellla/xbmca10 Recommended fork of empatzero (Diff to upstream)
 * https://github.com/vidonme/xbmc/ Sources of VidOn.Me Player? Seems to be a fork from empatzero. (Diff to upstream and Github Compare) This repo is reported from VidOn.me to be the "official" source code for their Allwinner XBMC version, yet the only code commit from VidOn.me themselves is this one.
 * https://github.com/huceke/xbmc/tree/allwinner Gimli's implementation (Diff to upstream)

= See also =
 * CedarX - Library for Allwinner CedarX VPU (Video Processor Unit) used for audio and video decoding and encoding hardware off-loading on A1x and A2x SoC series.
 * CedarXVideoRenderingChart - Overview chart of working/ non working video files
 * LIRC (Linux Infrared Remote Control) for IR receivers and and remotes
 * Tvheadend TV Tuner Server and PVR backend

=xternal Links=
 * http://kodi.tv - Kodi.tv the official Kodi/XBMC website with wiki and forums.
 * http://github.com/xbmc/xbmc/ - The upstream Kodi mainstream source code repository on GitHub.
 * XBMC Official Community Forum discussion about porting to Allwinner A10
 * Jas Hacks Hackberry A10 - XBMC on Ubuntu 12.10 image
 * Buildroot XBMC on the Mele A1000 (Allwinner A10)
 * XBMC for Linux on AllWinner A10 Devices? It Works! (Sort of)

=References=