Status Update - Debug Board - 1024-Fix

29.10.2009 at 12:36

Ok short status update for the qi-bootmenu thingy which I am playing around with (although I haven't had much time recently). I reduced the image size by disabling/removing the following components:

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 SSH sessions it would be an interactive alternative to something like ssh-cluster. By now I have implemented it and should probably prepare a point release containing this new functionality.


read more comments

Cross Arch Remote Debugging with GDB and gdbserver

11.10.2009 at 23:31

To further debug a problem in my little 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` 
        --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 top level directory.

./configure --host=`./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:

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

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/ instead of /lib/ 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.


read more comments

Font Configuration for Elementary with Famebuffer Backend

08.10.2009 at 22:04

I found out what the problem with the elementary hello world application was. The fonts were missing. So how does font configuration work? To answer this the XFree86 Font De-uglification HOWTO's TrueType Fonts section is useful. You basically have to copy your fonts into a directory and then run:


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:

Sans -misc-dejavu sans-medium-r-normal--0-0-0-0-c-0-ascii-0

However it is important that there is no 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.


read more comments

Still Just a White Screen

05.10.2009 at 23:49

As I mentioned in the last blog post recent svn versions of edje require Lua. The Lua build by default just creates a static liblua.a I wondered what the reason for this is. And it is once again 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 luck. I need to ping the enlightenment folks and finally post an RFC about the whole thing to the openmoko-devel list.


read more comments

More Automake and Libtool Mystery

01.10.2009 at 11:02

Initially I based my boot menu system around the 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 doesn'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 a 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.

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.


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