Building Yocto/Poky on openSUSE Factory

Since a few weeks, openSUSE Factory no longer is labeled as "openSUSE Project 13.2", but as:

seife@susi:~> lsb_release -ir
Distributor ID: openSUSE project
Release: 20140918

When trying to build the current Yocto poky release, you get the following Warning:

WARNING: Host distribution "openSUSE-project-20140918" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.

Now I know these warnings and have ignored those before. The list of tested distributions is hard coded in the build system configuration and in general it would be a bad idea to add not yet released versions (as 13.2) or rolling releases. And since the Factory release number changes every few days, it is clearly impossible to keep this up to date: once you have tested everything, the version has increased already. But apart from this, purely cosmetic warning, there is a really annoying consequence of the version change: the configuration cache of bitbake (the build tool used by Yocto poky/OpenEmbedded) is rebuilt on every change of the host distribution release. Updating the cache takes about 2 minutes on my machine, so doing a simple configuration check on your already built Yocto distribution once a week can get quite annoying. I looked for a solution and went for the "quick hack" route:

• bitbake parses "lsb_release -ir"
• I  replace "lsb_release" with a script that emits filtered output and is before the original lsb_release in $PATH

This is what I have put into ~/bin/lsb_release (the variable check is a bit of paranoia to let this only have an effect in a bitbake environment):

#!/bin/bash

if [ -z "$BB_ENV_EXTRAWHITE" -o "x$1" != "x-ir" ]; then

        exec lsb-release $@

fi

printf "Distributor ID:\topenSUSE project\nRelease:\t2014\n"

Then "chmod 755 ~/bin/lsb_release" and now the warning is

WARNING: Host distribution "openSUSE-project-2014" has not been validated...

And more important: it stays the same after updating Factory to the next release. Mission accomplished.

UPDATE: Koen Kooi noted that "Yocto" is only the umbrella project and what I'm fixing here is actually the "poky" build system that's part of the project, so I edited this post for clarity. Thanks for the hint!

What to do about a trademark trolls?

Imagine there is a GPL'd open source project, going strong for more than 10 years, with more than 50 contributors. Now a company comes along and registers the name of the project as a trademark with the clear intention of suing people using this name to sell equipment with the software preloaded.

They are not contributing to the project.

Is there anything the project can do about that?
The opposition deadline (german: "Widerspruchsfrist") is not over yet.

Oh - and of course they are blatant GPL violators, linking the project's GPL'd software against closed source libraries which in turn use closed source kernel drivers, ship a U-Boot version of which nobody has ever seen the sources and so on, but that's a different story.

My first remotely useful Arduino sketch

I want to use the arduino to interface a small graphic LCD to my satellite set-top-boxes.
The problem with most of the boxes you can buy today is, that they only have a one-line, 12-16 character text-only VFD display and no longer the nice credit-card sized graphic LCDs the old dbox2 or dreamboxes had.
Most new boxes have an USB port,though, so interfacing the LCD via USB is pretty easy.
The code (both arduino and a small test program for the box) is here on gitorious. The protocol is primitive but pretty efficient on RAM and it does recover from errors surprisingly well. The update rate of maybe 10 FPS is enough for this kind of usage.
Now I need to implement some "display driving daemon" which can be interfaced easily with the set-top-box software.

(e)glibc cross compiling issue...

While building a brand new powerpc cross-compiler with crosstool-ng (which is great), I came about a simple issue which was unexpectedly hard to fix:

../misc/syslog.c: In function '__vsyslog_chk':
../misc/syslog.c:123: sorry, unimplemented: inlining 
failed in call to 'syslog': function body not available
../misc/syslog.c:155: sorry, unimplemented: called from here

Using different combinations of build helper tools, eglibc, gcc, whatever did not really help. Even the search engine results were full of the same questions but with very little answers, and most of the answers were clearly in the league of cargo cult programming, nothing you'd want to rely on for a toolchain to be used by others.
But finally I came across this mail from Mike Frysinger which finally showed that it can be as easy as

CT_LIBC_GLIBC_EXTRA_CFLAGS="-U_FORTIFY_SOURCE"

:-)
Of course the question remains why compiling glibc has to be always a major PITA, but that's something I'd rather not discuss in public...

U-Boot hacking -or- The dbox2 can boot from disk!

Thanks to a kind donator, I now own a Nokia dbox2 with IDE interface. (For those that don't know - the dbox2 is a settop box designed for german paytv 10 years ago in a way that its bootloader would only run signed software. A limitation that was put aside by some cool hackers early in this century. Nowadays it usually runs Linux on its 66MHz powerpc CPU, 32MB RAM and 8MB FLASH ROM. Later some cool guys designed an IDE interface that plugs into the memory expansion slot)

The main use of such an IDE interface for most people is to use the box as a video recorder. However, I am already doing this via the ethernet port, wich is more practical for me than a built in disk.

I would have deemed it much more useful if I was able to boot from the IDE drive, since that would make it much easier to try out new experimental code without needing to upgrade the FLASH image all the time (having the known working version in FLASH as a fallback is mandatory for good WAF).

So I pondered the problem and found out, that people had already implemented basic support for the IDE interface in U-Boot (which is used as a "second stage" bootloader), and it could already access and read the disk.

Unfortunately, U-Boot needs to be in FLASH, and this U-Boot would then only boot from disk.

So I have been hacking on making U-Boot actually read multiple boot command lines (and and option which one to boot as default) from a config file in the /var/ partition of the FLASH which makes it pretty easy to switch the device we boot from. It is now actually similar to the boot process of the Tripledragon.

The only thing that's missing now is a driver for the front panel keys, so that you can change the selection on the fly without using a serial console. That's coming next, after the summer vacation ;)

Cross compilers for openSUSE

Based on Torsten Duwe's great work (currently in the Buildservice in home:duwe:crosstools), which is building but not working 100% correctly, I fixed the powerpc version up (I have no other architecture to test on) and put them into the openSUSE Buildservice in home:seife:cross for now.
Get them from here: http://download.opensuse.org/repositories/home://seife://cross/SLE_11
(don't get put off by that SLE_11, the cross compilers should be pretty system agnostic. For testing I ran them on a SLES10 which is probably older than anything you want to use, and they worked just fine)

Edit: I just found out that this only works because I have a patched rpm on my SLES10 which understands lzma compression. I have added SLES10SP2 to the repository so that pre-LZMA-rpm distributions still can use it.

So if you need a powerpc crosscompiler, just add that repository, install packages "cross-powerpc-embed-linux-gnueabi-binutils", "cross-powerpc-embed-linux-gnueabi-gcc", "cross-powerpc-embed-linux-gnueabi-glibc" and "cross-powerpc-embed-linux-gnueabi-kernel-headers" and you are ready to go.
Make sure that /opt/cross/bin is in your $PATH and configure your project for target "powerpc-embed-linux-gnueabi".

Still TODO: get them into a proper semi-official project.

Oh - and of course I already changed my favourite embedded projects so that they are now able to build with an "external" toolchain ;)

Triple Dragon continued

This week is entirely dedicated to getting the Triple Dragon started with some usable software - and it is going along quite well.
I feared that I would have to dig down into DirectFB to solve my original framebuffer problems (on the first try I was unable to set the transparency - the setting, which is done with a private ioctl(), was always ignored), since the original software uses DirectFB, but in the end this is fortunately not the case.
The solution was simple: I need to issue the transparency-ioctl() after setting the framebuffer parameters, not before.
Right now, enigma is pretty usable, the "normal" TV viewing stuff is already working. I'm now refining the build system, so that I can tell people what they need to do to build the software, then I'll look at the init scripts etc, so that they can even boot it.
Next thing will be fixing the not yet working stuff - some hardware-dependent like the SCART switching stuff, some software like the media-player and record / timeshift features, but then I'll hopefully have some more people working on the project ;-)

Triple Dragon, anyone?

After a kind guy donated me a Triple Dragon satellite STB (running Linux, of course), i started hacking on it. Unfortunately, the source code to the original Application is not available, but i'm not too happy with that one anyway. With the help of another Tuxbox-pioneer, Carsten "Carjay" Juttner, i now have the enigma GUI basically running on the machine. I do have some problems with the graphics device and the framebuffer (especially the interaction between both), so if you have information or can share your programming experience on IBM STB04xxx boxes or even on the Triple Dragon hardware / API, i would be most grateful for any hints.
I want to solve those problems before moving on and porting neutrino to that beast ;-)