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!

Raspberry Pi: Another platform for Neutrino-MP

Last night I got video decoding via libilcore working on Raspberry Pi, so now the port of Neutrino-MP is starting to look like it will get usable some time in the future.

Most stuff is encapsulated inside libstb-hal, which means that only a small change in Neutrino-MP (just adding the proper LDFLAGS) was necessary. Later, with proper implementation / packaging of libstb-hal, this might also be unnecessary.

For those who dare to try it, I'd suggest to start with current raspbian, then use the Makefile for native building (after tweaking it to your needs) to build it directly on the Raspi -- this is how I did it :-) ). The stuff is not yet ready for cross compilation (too many hard-coded /opt/vc/lib etc).
You'll first need to build libdvbsi++ -- there's a target in the Makefile for that -- and install all missing devel packages -- hopefully, configure will compain. Otherwise the missing includes will be obvious, I guess.

The next step will be implementation of the audio decoder, which should be not too hard, then the thing will be truly useful :-) .

Coolstream neo broken power supply

Now who would have guessed the guys that are good at trademark trolling (they withdrew their trademark application after other users of the name "Neutrino" complained, too, now they are trying to get new variations of the neutrino brand) are apparently not very good when it comes to hardware engineering?
The power supply of my coolstream neo box died of blown out capacitors after only 18 months -- which tells you about the hardware quality IMHO. I own a lot of electronics but have never seen this happening after such a short time.

My advice to the coolstream guys: spend a little less effort on trademark trolling and violating the GPL, instead spend a little more effort on quality assurance. I cannot say that I'd recommend this hardware to anyone.

I could probably just replace the capacitors, but that box has been just annoying lately and I have enough other well-working boxes so I'll probably just leave it dead so I don't need to get upset whenever I try to use it for something serious.

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

Setting the repeat rate on an input device (Kernel 2.4 and 2.6)

If you ever come into the situation of having to set the repeat delay/period on an input device (/dev/input/eventX), with the additional challenge of needing it to work on both 2.4 and 2.6 kernels, maybe this code snippet might help you (fd is the filedescriptor of the device, opened writable):

        #include <linux/input.h>
        struct input_event ie;
        ie.type = EV_REP;
        ie.code = REP_DELAY;
        ie.value = 1000; /* 1 second initial delay */
        if (write(fd, &ie, sizeof(ie)) == -1)
                perror("REP_DELAY");
        ie.code = REP_PERIOD;
        ie.value = 250; /* 4 events per second */
        if (write(fd, &ie, sizeof(ie)) == -1)
                perror("REP_PERIOD");

Looks pretty trivial, doesn't it? But it took me quite some time to realize that I needed to write a "magic" event into the device to set the properties ;)

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

linux@dbox2: implemented AVIA ENX reset

Since this is the first weekend after returning from vacation, i thought i'd turn to the tuxbox project again. This time i experimented with my Sagem dbox2 instead of my dreambox 500.
I was finally fed up with the joy of reverse-engineered hardware: sometimes, if you do strange things to the AVIA ENX chip, it will somehow lock up. Unfortunately, there is no way to reset it, short of rebooting the box. Looking at the code i found out that there actually is a reset function for the chip, but it's only used at module load and unload. Unfortunately you cannot unload the module since lots of other stuff depends on it, so rebooting the box is actually faster than trying to reload the module.

I went for the quick and very dirty way and exported a file in /proc which, if something is echoed into it, performs a chip reset of the AVIA ENX chip.

The diff is quick, dirty, and trivial. But it works for me. The important parts of it are here:

--- a/driver/ext/aviaEXT.c      21 May 2006 23:01:10 -0000
+++ b/driver/ext/aviaEXT.c      25 Aug 2007 12:53:13 -0000
@@ -27,6 +27,7 @@
 #include <linux/module.h>
 #include <linux/devfs_fs_kernel.h>
 #include <asm/uaccess.h>
+#include <linux/proc_fs.h>

 #include "avia_av.h"
 #include <dbox/aviaEXT.h>
@@ -86,6 +87,14 @@ static struct file_operations aviaEXT_fo
                .ioctl = aviaEXT_ioctl
 };

+extern void avia_gt_dmx_risc_reset(int);
+static int avia_av_proc_write_avia_reset(struct file *f, const char *b, unsigned long c, void *d)
+{
+       printk("calling avia_gt_dmx_risc_reset(1)\n");
+       avia_gt_dmx_risc_reset(1);
+       return c;
+}
+
 static int __init aviaEXT_init(void)
 {        if (!(devfs_h = devfs_register(NULL,"dbox/aviaEXT", DEVFS_FL_DEFAULT, 0, 0,
@@ -93,6 +102,18 @@
                printk(KERN_ERR "aviaEXT: could not register with devfs.\n");
                return -EIO;
        }
+
+       struct proc_dir_entry *proc_bus_avia_reset;
+
+       proc_bus_avia_reset = create_proc_entry("avia_reset", 0200, proc_bus);
+       if (!proc_bus_avia_reset) {
+               printk("avia_av_proc: could not create /proc/bus/avia_reset");
+               return -ENOENT;
+       }
+
+       proc_bus_avia_reset->write_proc = avia_av_proc_write_avia_reset;
+       proc_bus_avia_reset->owner = THIS_MODULE;
+
        return 0;
 }

Of course you need to EXPORT_SYMBOL(avia_gt_dmx_risc_reset); at the appropriate place.

Combine this interface with something like the following:

#!/bin/sh
valold=""
while sleep 1; do
        # the "avia" interrupts stop if the chip has crashed
        valnew=$(grep avia$ /proc/interrupts)
        if [ "$valnew" = "$valold" ]; then
                echo "$(date) avia_reset"
                echo > /proc/bus/avia_reset
        fi
        valold="$valnew"
done

It resets the chip automatically, should it crash again while experimenting.

Hackweek is over

Hackweek was an event where my employer, the SUSE Linux Products GmbH in Nürnberg, or to be precise: our mother company, Novell, allowed all of its Linux engineers to work one week on stuff that we like.
Not on the stuff that our boss (or marketing, or the sales people or whoever) likes.
This was a pretty neat idea. They topped it off by taking care of everything: we had a nice brunch every morning, during the days we were served various refreshments and the evenings were rounded off with a nice meal, too. Sometimes it was hard to get to hacking, besides all that food ;-)

I mostly finished off one of my pet projects from the last months, porting the neutrino GUI to the dreambox, which is now committed to the project's cvs and, save some minor cleanups, should be pretty much ready to use.

Some links:

My idea.opensuse.org project page (not much to see there)

The tuxbox project

The tuxbox project webforum (mostly german)