• The resulting statically linked binary should be smaller than the dynamically linked one with all the shared objects it needs. The linker will be able to only include the symbols which are actually used by my app.
• At runtime the dynamic linker will not have to resolve a huge amount of symbols although this probably hasn't a big impact because everything is already in RAM so there should be no expensive I/O

One thing I need to try out is to link everything statically expect libc which is required by other stuff (kexec, dropbear, busybox). I *think* this should work with a few linker flags but I am not yet sure how it behaves in practice.

-Wl,-Bstatic -leina -lts ... -Wl,-Bdynamic -lc

Fortunately the modular design of the EFL which dlopen(3) modules at runtime also has an option to build said modules statically which means the code will be embedded into the main shared object. This can be enabled at compile time with

./configure --enable-$FOO=static

Unfortunately the same is not possible with stock tslib plugins which is why I wrote a patch to support it.

On a somewhat unrelated note the only thing I hate more than mailing list which are configured for member only posts are mailing lists with slow moderation for non member posts. Grumble.

Marc ]]> Tue, 05 Jan 2010 10:24:11 GMT http://www.brain-dump.org/blog/entry/141/Boot_Time_Optimizations_-_Tslib_static_modules http://www.brain-dump.org/blog/entry/140/Qi_Bootmenu_Progress build scripts that launches a bootmenu application which scans the available partitions and presents a list of bootable systems which can be loaded via kexec.

In the process I added uImage support to kexec which means it should work with the current distros out there like SHR which provide uImages for their kernels.

The kernel I am using is based on Lars om-gta02-2.6.31 branch with a few patches to show an openmoko boot logo and my printk verbosity patchset.

The next thing I'm going to do is patching Qi to load an alternative kernel upon AUX press instead of just skipping one.

Then I need to optimize the whole thing for speed. It currently takes between 12-14 seconds (depending on whether I also scan the flash partition, mounting a jffs2 filesystem is slow because of the initial inode scanning I should probably test with ubifs). This is with the debug board attached, I don't know if that makes a difference. The whole uncompressed initramfs content is about 3.4 Mb (this is with network support + dropbear). I should try to remove more unneeded stuff and maybe link a few things statically. And the kernel can probably also be optimized for speed. Using devtmpfs from 2.6.32 for example would make busybox's mdev obsolete (I don't want to use a static /dev).

Anyway the basic functionality is there and I should probably provide a pre built kernel which contains the initramfs for users to test. And gta01 support is also a TODO item of course. My progress can be followed on the distro-devel list.

Marc ]]> Sat, 28 Nov 2009 18:02:26 GMT http://www.brain-dump.org/blog/entry/140/Qi_Bootmenu_Progress http://www.brain-dump.org/blog/entry/139/Status_update_-_debug_board_-_%231024-fix

• ecore-con
• uclibc's locale data
• freetype: i disabled everything which didn't seem that important

The resulting image (without the kernel) compiled with -Os is about 4.5MB large. This could be reduced by some 500K if evas could be compiled with -Os but this caused my elementary test application to segfault. In fact any optimization resulted in a segfault only -O0 worked. I will have to update to latest enlightenment svn and see if the problem is still reproducible.

Because it turned out to be rather difficult to debug a network setup problem without a working network I decided to buy a debug board. A serial console is a handy thing. Fortunately Telepixel GmbH which is located in Bern had the debug board on stock which meant I could pick it up from there.

On the hardware front, someone organized a professional #1024-fix for Switzerland which I am interested in because it doubles battery life.

So my next steps will be to make the usb network work in my image for that I will need to integrate the kernel build (until now I have mainly just tested in a chroot environment). I also started with the bootmenu application but as I lack EFL knowledge I will have to spend some time changing that. And I should push my scripts + code to some public git repository.

On a completely unrelated note I got a few mails about dvtm recently. Someone suggested a keyboard multiplexing mode which could be used to control multiple applications at once for example ssh servers something like ssh-cluster but interactive. By now I have implemented it and should probably prepare a point release containing this new functionality.

Marc]]> Thu, 29 Oct 2009 12:36:40 GMT http://www.brain-dump.org/blog/entry/139/Status_update_-_debug_board_-_%231024-fix http://www.brain-dump.org/blog/entry/138/Cross_Arch_Remote_Debugging_with_gdb_and_gdbserver initramfs system I recently added gdbserver to the build scripts. And since I have never done that before I might as well document how this works.

gdbserver which runs on the target basically just provides the 'debugging backend' and makes it available to a normal host gdb. This has the advantage that gdbserver is relatively easy to build for your embedded system of choice, it doesn't provide a user interface and therefore doesn't require readline/curses libraries.

So we cross compile gdbserver whose source can be found in the gdb tarball under gdb/gdbserver like this (replace $ARCH with your target architecture in my case it was armv4tl-unknown-linux-gnueabi):

cd gdb/gdbserver

./configure --build=`./config.guess` 
        --target=$ARCH 
        --host=$ARCH 
        --prefix=/usr 
        --program-prefix="" &&
make &&
make DESTDIR=$SOMEDIR install

Then you will need a host gdb which understands the instructions of your target architecture. Your distribution probably only enabled support for your native architecture which means you will have to build your host gdb from source. Note that this time we only set --target and build from the toplevel directory.

./configure --host=`./config.guess` 
        --build=`./config.guess` 
        --target=$ARCH &&
make &&
make DESTDIR=$SOMEDIR install

Now we can start our debugging session. On the target execute gdbserver and specify a port and your executable.

gdbserver :$SOME_PORT /path/to/file/you/want/to/debug

Back on the host connect to the listening gdbserver instance with your host gdb:

$ARCH-gdb
file /path/to/file/you/want/to/debug
target remote $IP_OF_TARGET:$SOME_PORT
set solib-absolute-prefix $ROOT_DIR
continue

The solib-absolute-prefix should point to the root directory of the target on your host. Confused? Well you probably have cross compiled all your stuff for the target and installed it into a directory on your host and this is what I mean with "the root directory of the target on your host". gdb will use the solib-absolute-prefix whenever it needs to load a shared library. What this means is that if the app you are debugging depends on a library gdb will load the library symbols from $ROOT_DIR/lib/libfoo.so instead of /lib/libfoo.so from the host system where it either has the wrong architecture or doesn't exists at all.

Hope this is useful for someone out there. At the very least I now know where to look should I have to do it again in the future when I have already forgotten how it actually works.

Marc]]> Sun, 11 Oct 2009 23:31:11 GMT http://www.brain-dump.org/blog/entry/138/Cross_Arch_Remote_Debugging_with_gdb_and_gdbserver http://www.brain-dump.org/blog/entry/137/Font_configuration_for_elementary_%2B_framebuffer_backend XFree86 Font De-uglification HOWTO's TrueType Fonts section is useful. You basically have to copy your fonts into a directory and then run:

ttmkfdir
mkfontdir

This generates a fonts.scale file (which you can ignore because evas doesn't care about it) and a fonts.dir file which is read by evas.

The default elementary theme uses Sans as default font so we have to set up an alias for this. This can be done by creating a fonts.alias file containing for example:

However it is important that there is now trailing white space at the end of the line. Otherwise evas will reject the alias because it doesn't match with a font from the fonts.dir file which doesn't have any trailing spaces. Of course I only found this out after reading through evas source code and in the meantime I was told to just use X -- Sigh.

Anyway while reading through the source I actually noticed that evas also uses the filename without extension as a font name. So a simple symlink like:

ln -s DejaVuSans.ttf Sans.ttf

also works as alias and in this case we don't need the fonts.alias and fonts.dir files.

On a completely unrelated thing whoever came up with the idea to use XML for the fontconfig configuration files should be taken away from computers better sooner than later.

While the font problem is now solved the next thing to investigate is probably touchscreen handling which doesn't quite work the way it should.

irc

I have never been a heavy user of irc (if you are not paying attention you can just waste too much time with senseless flamewars) but sometimes it's actually a useful medium to get some answers in real time. Anyway because I haven't used my original irc nick for quite some time someone else has overtaken it's ownership. Yeah I really should add a few lines to my login scripts which authenticate my irc nick on freenode and oftc. Anyway registered some new nicks, I am now known as }mat or ]mat.

Marc]]> Thu, 08 Oct 2009 22:04:42 GMT http://www.brain-dump.org/blog/entry/137/Font_configuration_for_elementary_%2B_framebuffer_backend http://www.brain-dump.org/blog/entry/136/Still_just_a_white_screen libtool related. It seems like people who actually have kind of taste don't want to use libtool. I am not yet sure whether building a shared variant is useful at all in my particular case because currently the only user is edje (for now I don't install the lua interpreter).

Posted my initial attempt at adding support for source control management systems to FWL. I don't care about the actual implementation but the functionality should be available in one way or another.

Unfortunately my elementary test application still just shows a completely white screen. Ran the whole thing under strace to check whether it tries to open some thing which isn't there, but saw nothing suspicious so far. Played a bit with fbset and /etc/fb.modes but no look. Need to ping the enlightenment folks and finally post an RFC about the whole thing to the openmoko-devel list.

Marc]]> Mon, 05 Oct 2009 23:49:50 GMT http://www.brain-dump.org/blog/entry/136/Still_just_a_white_screen http://www.brain-dump.org/blog/entry/135/More_automake_and_libtool_mystery EFL Snapshots from Juli 29th. The idea was to start with some known to work state instead of a randomly picked svn revision. Once I had everything compiled I wanted to run the elementary hello world application. Unfortunately all I got was a completely white screen. But hey it didn't segfault which is progress.

I then decided to update to a more recent svn revision to see whether it was an upstream error which got fixed in the meantime or if it was an error on my side. I choose the same revision as the OpenWRT folks. Again with the idea that it had worked for others before. Because I was now checking out upstream sources I needed to run aclocal, auto{header,conf,make} and libtoolize to generate the actual Makefiles etc. Unfortunately this didn't quite work out for me because apperently automake-1.11 does't like trailing slashes. This just shows how fragile the whole autohell system actually is.

I then decided to update to current svn HEAD because the latest and greatest should have all the bugs fixed, right? By the way this added lua as dependency. Unfortunately this resulted in build errors whenever a library package had it's library compiled and wanted to link against it later during the build. For some yet unknown reason libtool wasn't linking the binaries against the required libraries. After some head scratching I compared the libtool script as shipped with the EFL snapshots from Juli and the one generated by me locally. The crucial difference was the following line:

# Whether libtool must link a program against all its dependency libraries.
link_all_deplibs=no

Don't know yet why it was set to no in the first place but I decided to go with the quick and dirty solution for now and added a sed one liner to set the variable value to unknown after the ./configure stage. The build succeeded, Yay!

With this whole thing I wasted another few hours and unfortunately the end result was the same (the elementary hello world application just showed a white screen).

On the upside I am now on the bleeding edge enlightenment stuff which was the only sane thing to do in the long run anyway.

Marc]]> Thu, 01 Oct 2009 11:02:58 GMT http://www.brain-dump.org/blog/entry/135/More_automake_and_libtool_mystery http://www.brain-dump.org/blog/entry/134/Cross_compiling_revival

libtool madness

Of course I ran into some common cross compiling pitfalls were 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:

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]]> Mon, 28 Sep 2009 19:33:35 GMT http://www.brain-dump.org/blog/entry/134/Cross_compiling_revival http://www.brain-dump.org/blog/entry/133/OpenExpo_2009_Winterthur feedback from the openmoko-community was well 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 ]]> Thu, 24 Sep 2009 10:18:27 GMT http://www.brain-dump.org/blog/entry/133/OpenExpo_2009_Winterthur http://www.brain-dump.org/blog/entry/132/On_the_way_towards_a_minimal_elementary_based_boot_system qemu which contains a native toolchain. This avoids the broken by design approach of cross compiling (configure and friends analyse 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 an 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:

• eina
• eet
  • zlib
  • libjpeg
• evas
  • freetype
• ecore
  • ecore-file
  • ecore-evas
  • ecore-input
  • ecore-job
  • ecore-txt
  • libiconv
  • tslib
• edje
  • embryo
• libpng

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]]> Wed, 23 Sep 2009 00:48:28 GMT http://www.brain-dump.org/blog/entry/132/On_the_way_towards_a_minimal_elementary_based_boot_system