Custom Ubuntu’s root file-system for the panda-board

Since I started to work with the beagle-board, one of my main concerns has been generate a custom image with the minimal setup required for the task: In my opinion it is important to have installed only the necessary and do not bloat the SD with a full featured distribution. In this way, we will control the dependencies, and we will remove possible points of failure which only will drowse our cycle of development/testing.

In the case of a OMAP3 base board or any other board with inferior capabilities, the solutions were in builder systems with cross-compilation support, such as OpenEmbedded, Buildroot, etc.. Those builders use the cross-compilation technique to generate custom images for the target hardware.

But in OMAP4 we are in the border line between an embedded system and a PC, and because of this, I needed a kind of a mixed approach: a native compiling environment within a custom image, in order to set it up as a builbot slave.

As I attained certain experience with OpenEmbedded I started to craft a custom native-sdk image, with rather thwarted results: after several days of patches and bug fixes, I was not able to compile, in the panda-board, the software I was willing to test.

Dodging the OE’s approach, I decided to uproot it and I started to explore new paths. Soon I stumbled with rootstock: a shell script which generates custom images of the Ubuntu distribution for the ARM architecture.

Nonetheless I tried it under Debian, since I don’t have any machine with Ubuntu. The script is difficult to trace and its logs are not useful on many occasions, mainly when the processing occurs in the qemu virtual machine. Anyway, I found that the qemu distributed by Squeeze was not functional in this particular case, so I grabbed the latest code from its repository, I compiled it and it worked like a charm.

NOTE: use the latest code of the RootStock hosted in the Launchpad bazaar repository.

At the end I came with a script where I set the parameters for my particular use case:


export TMPDIR=$(pwd)/tmp
export PATH=$PATH:/usr/sbin/:/sbin:/opt/qemu/bin

[ -d $TMPDIR ] || mkdir -p $TMPDIR


./rootstock --fqdn 
            --login user 
            --password 000  
            --imagesize 512M 
            --dist maverick 
            --serial ttyO2 
            --seed $BASE,$V8_DEPS,$JSC_DEPS

In this way I can generate a minimal image, in a tarball, for my panda build-slave.

AAC decoder for gst-dsp

One of my purposes for this year was collaborate with the gst-dsp project. But the JPEG decoder was not enough, as there are other released socketnodes by TI which are not yet wrapped in gst-dsp, such as, in this case, the AAC decoder.

gst-dsp is a project with only video decoding use case in mind, and audio streams might not be optimally handled by it. The biggest concern was about the memory mapping of small buffers, which could consume more CPU rather than the direct decoding. Nevertheless I decided give it a try.

These last two weeks I devoted them to pull out the dspadec element and it seems to perform quite good without any significant modification in the gst-dsp core. You can find the submitted patches in the gst-dsp mailing list.

These patches are still in review process and perhaps they will not land on the repository, nevertheless, I also updated the marmita’s recipes in order to provide an installable image for the beagleboard, so anybody could test this new element.

Among other candies, this marmita snapshot brings libsoup and the souphttpsrc GStreamer element, besides all the alsa stuff for the audio rendering. Also gdb hit into the tarball.

Enjoy it!

These bytes were brought to you thanks to Igalia, who sponsored this development.

my DSP related activities

When I started to play with the Beagleboard, my objective was to poke with the DSP accelerated codecs through OpenMAX and GStreamer. But soon I realized that it would be a hard task to achieve since the framework, developed by Texas Instrument, is in part proprietary (though free), and the another is open source, but it is not developed with an open source community in mind.

When I started to pulled it out, the first decision I had to face was to choose a cross compiling environment. As you know, there are plenty: scratchbox, OpenEmbedded, buildroot, PTXdist, etc. But just because people I know from TI began to write recipes for Poky, I devoted some time learning about it. Although, after a while, I jumped into OpenEmbedded. The reason were the slow updating rate against upstream which Poky had (and as I don’t follow the project anymore, I’m not aware about its current state).

But bitbake and OpenEmbedded are not the magic wand to build up a complete image to boot up in a device. There are a lot of things to define previously. Just to mention one, the distribution to build. By default OpenEmbedded offers Angstrom. But I did not want a full featured distribution, I wondered for something thin and lean, only a serial shell to start with, something I could set as a workbench for my multimedia experiments.

And for that reason marmita born.

As you may see, I mimicked the “Poky’s way”, making an overlay of OpenEmbedded, but as soon as I was getting involved in the OE’s community, I realized that maybe that it was not the correct decision, maybe I should push my changes into Angstrom instead.

Anyway, right now I have a steady set of recipes which allows me to build images for the Beagleboard, with the latest dspbridge kernel branch, and many of the TI bytes (either proprietary and open source) required for running the DSP accelerated codecs.

On the other hand, I have revamped the DSP how-to at wiki, with the instructions to build up a kernel with DSP/BIOS Bridge support, and the means to test the communication with the DSP through it.

Along this process I became aware of the TI problems to release his DSP user space stack to the open source community. Even though the kernel side is moving quite well towards the kernel mainline, the user space bits are not doing that well, even more, they will be completely deprecated soon, because the kernel interface is still evolving.

At the lowest layer, on the ARM side of the DSP users pace stack, there is a library known as libbridge, which is basically an abstraction of the ioctl to the dspbridge kernel module, and it offers an interface with a nice semantics, but it is too much aligned to the old win16/32 API style (a bad idea in my opinion).

But the problem does not start with the API style, it begins at locating the library inside of a chaotic bunch of files, insanely bundled in a git repository, along with binaries (either for Windows and Linux), tarballs, and all sort of unrelated documentation.

Furthermore, the image building machinery within TI is a custom set of invasive makefiles, which all the projects must include and being conform with them. As result of this highly coupled build engine, extracting and isolating a project for it release is a painful and error prone process.

Given those problems, I got lost as soon as I began. So I decided to emulate the Felipe Contreras‘ approach: get rid of libbridge and use his minimalistic dspbridge ioctl wrapper: dsp_bridge, what he uses for gst-dsp. In order to train myself in these topics I wrote a clone of the TI’s ping application, using the dsp_bridge instead. And later on I wrote the DSP socket node counterpart. Both included in the dsp-samples repository.

Currently, the ping application is also included in the Meego’s dsp-tools repository.

Nevertheless, most of the DSP multimedia codecs are exposed, out of the box, through the TI’s OpenMAX IL implementation. And it depends on libbridge. For that reason I ripped out the libbridge from the userspace-dspbridge repository and pushed it into a different repository, cleaned it up its building machinery and removed other unneeded bytes too.

Finally, I had to do the same for the OpenMAX IL, which is not only messed up with the inside building machinery, but it is not released through a git repository yet, using instead old fashioned tarballs.

The future work will be integrate gst-openmax into marmita and try to participate with gst-dsp development. Also, FelipeC came up with the idea of rewrite libbridge in terms of dsp_bridge, task that I have been exploring lately.

Jhbuild beneath OpenEmbedded

Since a while I’ve been working on a OpenEmbedded overlay called marmita. But this post is not about it. Where I want to aim now is about a nice trick: how to use Jhbuild using an OpenEmbedded setup.

First of all, install jhbuild. And, of course, install Marmita.

In Marmita, just as in Poky, in order to get into the OE environment, the user source the script marmita-init-build-env.

Then, I setup another script, which is though to be the rcfile of a new bash session: marmita-simple-cross-compiling-env.

So, at this moment we have set all those environment variables needed to run a jhbuild session. There is also an alias for the jhbuild build, which specifies the jhbuildrc file, crafted for a cross-compiled environment: marmita.jhbuildrc.

For the moment I’ve only built GStreamer. And as a matter of fact, in the process, I came up with a simple patch for gst-plugins-bad.

By the way, the destination directory is in the /opt directory, under the stage directory; so, if you want to play with the generated output in a device, just copy that directory tree into the device’s file system.

Yes, I cannot say that I achieved a full integration between jhbuild and OE, but what I can state is that cooperation is quite possible.