Blog

Cross Compiling Revival

28.09.2009 at 19:33

While the idea of avoiding cross compilation is certainly desirable it's currently not really feasible performance wise for my poor little macbook. I therefore adjusted my scripts to support cross compilation. That means additional pain but once it works it should be relatively fast.

libtool madness

Of course I ran into some common cross compiling pitfalls where some part of the build tries to pull in various bits from the host system. In my particular case it was libtool that had some wrong paths in it's *.la files which then tried to link against libraries from the host system which obviously is doomed to fail. Of course I spent considerable time reading through configure and finally libtool shell scripts before finding out what was going on. The lesson here is probably: always ask Google if the problem isn't solved within 5-10 minutes. However what gave me the rest was the number one motivation / design goal of libtool which is:

The system must be as elegant as possible.

Epic fail!

pkg-config sysroot support

A similar problem exists with pkg-config which also has some paths in it's *.pc files. In the latest release (0.23) there is support for a PKG_CONFIG_SYSROOT_DIR environment variable which will prefix any -L -I compiler options with the specified value. Unfortunately for some reason Debian unstable which I have installed on my macbook is still stuck with version 0.22 albeit 0.23 was released back in January 2008. I'm wondering what's the reason for this delay. Anyway I have added a workaround for the problem in my build scripts.

boot distro status

I so far have cross compiled all the necessary dependencies of elementary but for some reason an elementary hello world app doesn't yet work.

Back to debugging.

Marc

read more comments

OpenExpo 2009 Winterthur

24.09.2009 at 10:18

Although the feedback from the openmoko-community was non-existent I nevertheless decided to make a trip to Winterthur and attend the OpenExpo Social Event. To raise awareness and do some advertisement I was wearing my OpenMoko T-shirt. Unfortunately the reactions I got were rather negative the most common question I had to answer was probably "Is it dead yet?" or "when will it die?". My answer was of course that it's alive and doing well. That SHR is getting usable as a daily phone. That #gta02-core makes good progress and breaks now ground in the territory of Open Hardware Design.

To my surprise I actually also met 2 active community members. Sebastian Spaeth (spaetz) from the SHR Team and Ben Hagen who was responsible for the OpenMoko booth at previous OpenExpo's.

Besides these OpenMoko related contacts I also had some good conversations with Adriaan de Groot a FSFE employee and KDE hacker. He ported KDE to OpenSolaris so we talked about OpenSolaris, software patents and the relationship between the FSF and the FSFE.

On the downside it didn't seem like there were a lot of people who support the suckless philosophy. The OpenBSD folks are probably the closest ones to share the same kind of spirit. Unfortunately I didn't manage to talk to them at their booth (I should have asked how the pcc development is going on) and couldn't find them later at the social event.

I was rather sceptical of the event but the few interesting discussion made it a worthwhile stay.

Marc

read more comments

On the Way Towards a Minimal Elementary Based Boot System

23.09.2009 at 00:48

Now that I have a working toolchain I also built a full system image for qemu which contains a native toolchain. This avoids the broken by design approach of cross compiling (configure and friends analyze the host system and then based on these wrong assumption draw conclusions about the target system) by using emulation. Of course this also has a price: slower build times.

FWL has a neat trick though which at least in theory should speed up compilation: it uses distcc to call out to the host system (over the virtual network of qemu) where the distccd instance compiles the passed source code with the cross compiler. This means that the CPU intensive compiling process bypasses emulation but the environment dependent steps (./configure etc) are still run within a target environment and therefore can't leak in bits from the host system.

You might wonder why I said "in theory" above. Well in practice this works best for large compilation units where the overhead of the emulated network and hard disk (I/O) has a smaller influence. And there are also cases where distcc fails to compile something and then falls back to the native compiler (which runs under emulation) if that happens the time spent for distcc is of course wasted. The solution here seems to be throw more/faster hardware at the problem. Unfortunately that's hardware I currently don't have. Oh well.

Building a framebuffer based elementary with minimal dependencies

One idea for the boot menu application is to use elementary with the framebuffer backend as a GUI toolkit. This would provide a nice looking touchscreen aware user interface. However I am not really familiar with the whole EFL software stack and therefore don't know how small/big all required dependencies would be. Some research lead to the following "dependency graph" for elementary:

So it seems like this is getting quite complex/large. Maybe link everything static and let the compiler do some magic to eliminate all the unnecessary code paths? Anyway we will see. Spent a few hours configuring every package and disabling lot's and lot's of compile time options. During this process I also found some problems in ecore's touchscreen detection code and submitted the changes back to the enlightenment folks.

Hope this will eventually work in one way or another.

Marc

read more comments

Creating an uClibc armv4tl-softfloat-eabi Toolchain

18.09.2009 at 11:07

Spent the last couple of days trying to build an uclibc toolchain for the Freerunner. This turned out to be quite a pain in the ass!

The easiest way would probably have been to just use the OpenWRT build system but I think for my specialized needs this is a bit overkill. After all my current goal is to build a small user space based boot menu and not a full blown distribution. Therefore I wanted to get Firmware Linux a set of relatively small, simple and therefore understandable shell scripts which among other things generate a relocatable cross compiler.

Unfortunately FWL doesn't provide an armv4tl-softfloat-eabi configuration out of the box and my first attempts all resulted in an "Illegal instruction" error. The compiler for some reason generated code which doesn't actually run on the hardware it should.

After a lot of head scratching and quite some frustration I finally found a solution. The problem seems to be that ARM EABI is only supported by armv4t+ (read: armv4 with thumb instruction support or anything newer like armv{5,6,..} etc). But gcc actually defaults to an armv5 instruction set when using EABI, this obviously doesn't work on armv4t although the hardware is EABI capable.

A patch to gcc which is also used by the OpenWRT folks that changes the default cpu type solved the problem. I now have a working cross compiler. Yeah!

Marc

read more comments

Kernel Diet -- Filtering Printk Messages Based on Verbosity Level

09.09.2009 at 12:36

As part of my upcoming boot menu/distro for Openmoko's Freerunner I searched for relatively simple and generic applicable ways to reduce the Linux Kernel binary size. An obvious candidate for size reduction are the possibly unnecessary kernel printk messages.

I therefore wrote a little patch series which introduces a new configuration option (CONFIG_PRINTK_VERBOSITY) to selectively compile out printk message strings based on a verbosity level. The implementation works by wrapping printk with a macro which evaluates to a constant if condition which the compiler will be able to optimize out.

Thanks to the feedback from the linux-embedded folks the second version of the patch series works as a drop in replacement for the regular printk and no longer changes existing kernel code.

However unfortunately there is a problem with continued kernel messages. They don't contain the loglevel which means it's impossible to filter them correctly based on a verbosity setting without the information from the first printk which started the message. For a solution we would need a way to pass the loglevel from the first printk which started the message to all following ones until a message is terminated by a new line. This could be achieved by a local variable, however such a variable would have to be available in every kernel function which calls printk and there is no way (I know of) which which would guarantee that.

Anyway it was great fun to play around with the CPP. I will think about a solution for the continued message problem although I am rather sceptical whether a CPP based solution is possible at all. I may or may not submit the patch series to LKML after the 2.6.31 release is out.

Marc

read more comments

<< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 >>