Blog
Creating an uclibc armv4tl-softfloat-eabi toolchain
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 userspace 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
Kernel diet -- filtering printk messages based on a verbosity level
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 garantee 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
New dvtm and dwm-win32 releases - future openmoko related activities
Long time no blog post, sorry about that but I was again rather busy. Quite a lot actually happened in the meantime. I passed my BMS exams and will now try to successfully take the Passerelle which would allow me to study at an university. Because of this I left my current employer and will focus on school. Most of the preparation for this supplementary exam is actually done in a self-studying manner which means it requires quite a bit of discipline. Well we will see how this works in practice. A possible advantage of this type of learning is that I will be much more flexible in my time planing. I therefore hope that will find a bit more time to spend on my opensource related activities.
dvtm
dvtm is actually in quite good shape and mostly in maintainance mode. The latest release dates from last week.
dwm-win32
dwm-win32 a port of the X window manager dwm to MS Windows which I wrote about in my last blog post. It's basically in a proof of concept stage and I currently don't plan to further develop it. Checkout the project page for further information.
openmoko
I hope that I can finally start to contribute in one way or another to the openmoko project.
As a first step I would like to implement a minimal bootmenu which is based on a small linux system. It's basically a stripped down kernel with an initramfs which contains a minimal C library like uClibc. The goal is to make this boot as fast as possible and then start a regular user space application which reads all available partitions of the SD card, searches for kernels and finally presents a nice looking boot list. The selected kernel will then be started via kexec.
That's the plan anyway, we will see if and how usable this actually works in practice.
That's all for now. Hope the next blog post won't take another 4 months to get written.
Marc
Update and future plans
The last few months have been rather busy because of various school and work related reasons. Therefore my free time coding sessions were rather short during this timeframe. I hope this will improve in the summer holidays when I leave my current employer.
I would like to play around with Rasters new GUI Library for embedded devices called Elementary and finally get around to programm something useful for my Freerunner. I am also thinking about porting dwm to win32 but as I have absolutely no win32-api knowledge it's not yet sure whether it will ever happen. Oh and there were new dvtm releases which should be pretty stable and feature complete.
Stay tuned.
Marc
Getting the Freedom Universal Keyboard2 to work under Linux
I recently bought a Freedom Universal Keyboard2 for use with my
Freerunner. When it finally arrived I found out that it doesn't work by default under Linux although the openmoko wiki stated otherwise.
Anyway I started googling around and found a mailing list post on bluez-user which suggested to disable the whole MTU handling. With this information I started looking around in the bluez-utils source and finally came up with a patch for hidd. With this patch applied and the steps below I got the keyboard to work both on my desktop (Debian Sid) and Freerunner (Om2008.8). First we check whether our bluetooth controller is operating in HID mode and if so we will switch it to HCI mode. Then we search for new bluetooth devices and the keyboard should be found and connected.
lsusb | grep HID && hid2hci
./hidd --search
So far so good, then I learned that hidd is depreciated and a new dbus based input-service should be used instead. I hope they will at least provide a shell script wrapper with some easy to use command line switches. Haven't yet found the time to actually test this new method, but the keyboard works with hidd which means it should be possible to make it work one way or another.
Marc
