Polluting the twitter cloud with statements / impressions I don’t think they’re worth a whole blog post… most tweets are not related to technical / computer stuff by the way – used language is mostly English…
OpenWrt is now able to run applications based on toolkit GTK+ on top of DirectFB!
Using DirectFB avoids having a full blown X11-server (most times Xorg) running, but having the possibiliy of getting nice GTK2 widgets onto your display without altering applications which are using the toolkit.
I was quite happy I got that working, because unfortunately DirectFB-support on part of gtk2 is quite broken in most versions.
Due its incredible slowness of GTK2 on the Openmoko Freerunner (400 MHz ARM, 128 MB RAM) I didn’t expect much of gtk2 on top of DirectFB.
I was curious and started some benchmarking with the gtk2 performance testing tool “gtkperf”. However I had to patch gtkperf that it’ll be usable with the qvga-resolution on the Ben NanoNote (otherwise parts of the app were hidden and the benchmark will get falsified because not the whole gets redrawed).
On the Openmoko GTA02 (Freerunner) GTK on DirectFB seems to be almost twice as fast as GTK on top of Xorg!
Even though the Hardware of the Ben NanoNote is quite limited compared to the GTA02, the benchmark looks quite promising and GTK2-applications seem to be – unline I expected – really usable on that kind of limited hardware.
What’s really confusing to me: running gtkperf on top of the accelerated Xorg-glamo driver for the glamo graphics chip is slower than using the not accelerated Xorg-fbdev driver. However this myth should not be part of this article; I’ll get in touch with Lars – the author of Xorg-glamo – regarding this issue.
UPDATE: Lars told me this is related to the glamo-overhead. Data transferred to the framebuffer via fbdev only consists of pure pixmap-data. Data transferred via the glamo-driver consists of data AND special glamo-related commands (telling the chip what to accelerate) which results in more data to be transferred. Normally this shouldn’t cause such a discrepancy, however the glamo memory-onnection is a bottleneck and only capable of tansferring around 4 MB / second which slows down unacceleraed content. The glamo chip provides the interface for the SD-card, so the whole bus is shared by graphics- and SD-carc-traffic. That’s the reason why e.g. playing videos (unaccelerated) stored on SD-card is that damn slow!
Further tests, benchmarks, evaluation coming soon…
Long time no news regarding OpenWrt <-> the Openmoko Neo devices; but it
It now reached a state where I think it’s justified to announce a ready-to-work(/debug?) OpenWrt-Image for the Openmoko Freerunner.
This should be a short overview of what happened
– kernel 126.96.36.199 is running
all neo-specific patches were extracted from the OM-kernel-tree and
created an atomic and maintainable patchset for the Neo (thanks to Lars !!)
– clean, stable and accelerated graphics system
thanks to the gorgeous work of the xf86-video-glamo developers (especially Lars (again)), finally
there’s no need for <Xglamo> anymore – acceleration is done from within
an usual <Xorg> with the glamo-driver used. The infamous WSOD (white screen of death) should be
ultimately purged out.
– GPS works
the amazing application <tangoGPS> is also available as an
– performance tuned
due to it’s architecture itself, fixed bugs and found ways for
optimizations through all layers, OpenWrt now boots in less than 1
minute into illume (very first boot excluded)
– software added/upgraded
besides lot’s of just OpenWrt-related improvements, also typical
OM-community-used packages were added and upgraded to recent versions
(e.g. tangogps, enlightenment/the whole efl-suite, paroli, fso, connman,
– a beautiful bootsplash
real beauty can’t be described by words 😛
– phone calls are still possible
thanks to paroli, the basic phone stuff is (still) working (phone calls,
messages, contacts, etc.)
== Images / environment
Images can be found here: http://nanl.de/files/openwrt/openmoko/
Mind – that, as usual for OpenWrt – the default IP of your device will
be “192.168.1.1” and the only running service will be <telnet> on port
After logging in and setting a password, <telnetd> is getting replaced
through <sshd> (port 22).
The mentioned files/images have the prefix “20090706_r16709_1”, based on
Suggestions / critism is welcome… 🙂
The original announcement on the mailinglists can be found here (http://kerneltrap.org/mailarchive/openmoko-devel/2009/7/6/6147903)
It’s done – the Openmoko GTA02 “Freerunner” is running OpenWrt!
There’s lot’s of stuff to do but let’s see what I spent most of my time the last few months for:
– kernel (2.6.28) is building and booting (merging the Openmoko and OpenWrt patchsets, whereof one (and that’s not ours ;)) consists of either over 620 little non-atomic patches or one 10MB patchblob [kudos to git!], is no picnic (thanks to the work of Michael “mb” Buesch at this point!)
– D-Bus and the freesmartphone.org reference implementation (they import the libc.so.6 via ctypes – I was really puzzled when python told me it can’t find my libc, because I was using the uclibc)
– Xglamo with acceleration (in the beginning Xglamo just crashed, even JTAG wasn’t available anymore; it took us weeks to figure out that a compiler bug was the cause (thanks to Felix Fietkau, Holger Freyther and Lars Clausen) – Lars btw. is currently making good progress to get glamo acceleration working within Xorg)
– the EFL (enlightenment foundation libraries) and enlightenment including illume (needs some more love to make it really fit into the OpenWrt-environment – currently <edje_cc> and <eet> are required as pre-installed host tools)
– paroli phone application suite (in case it’s working ;))
A few days ago we established the first OpenWrt<->OpenWrt phone call which worked out of the box after flashing our devices!
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.