I got a Linksys WRT160NL and because I didn’t find any pictures of the board nor any data about the serial – here’s what I got:
Author: admin
qi-hardware is a startup (announced 20th of July on linux.com) which set itself the target of manufacturing and deploying hardware under the idea of “Open Source Hardware” (for details you might want to read the mentioned article on linux.com or on qi-hardware.com itself).
This idea might call some analogies to Openmoko and – indeed – not just the ideas, also the people are almost the same 🙂
Same idea? Same targets? Same people? Let’s face it: same mistakes? At least qi is saying: “no!” as described in their post “Lessons learned”
Based on the saying “back to the roots” aka “the more basics the fewer problems” they announced their first device:
the “Ben NanoNote”, which (at least for now) comes with no RF-hardware at all.
Nevertheless the project looks very interesting and promising – even more when I was told that OpenWrt is going to be used as default operating system.
Shortly after I was asked whether I’m interested in helping getting OpenWrt running on it – I agreed, got one and am now hacking on it 🙂
Let’s see how things will do…
Long time no news regarding OpenWrt <-> the Openmoko Neo devices; but it
happened much!
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 2.6.30.1 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
OpenWrt-package now
– 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,
etc.)
– 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
23.
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
svn-revision 16709.
Suggestions / critism is welcome… 🙂
The original announcement on the mailinglists can be found here (http://kerneltrap.org/mailarchive/openmoko-devel/2009/7/6/6147903)
While getting the phone suite “paroli” (http://paroli-project.org) working on OpenWrt, I got some thrown exceptions in the OpenWrt-environment which I didn’t get in the official OM-builds.
I tried to figure out what exactly is causing the exception on the OpenWrt-target and created a minimal program which raises it:
You don’t have to know what’s <tichy> and its <Item> class, nor what <issubclass> is doing exactly – just mind the return values.
root@OpenWrt:/# DISPLAY=:0 python
Python 2.6.1 (r261:67515, Jun 8 2009, 09:18:20)
[GCC 4.1.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> from tichy.item import Item
>>> issubclass(bool, Item)
False
>>> assert issubclass(bool, Item)
Traceback (most recent call last):
File “<stdin>”, line 1, in <module>
AssertionError
Ah, ok. On the OpenWrt-target the assert throws an exception, because <issubclass> returns <False>
So, logically, within the Openmoko-environment, the <issubclass>-statement must return <True> to not get assert raising an exception – but that’s not the case:
root@om-gta02:~# DISPLAY=:0 python
Python 2.6.2 (r262:71600, May 31 2009, 00:18:54)
[GCC 4.1.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> from tichy.item import Item
>>> issubclass(bool, Item)
False
>>> assert issubclass(bool, Item)
>>>
Huh – ok, let’s take a closer look here:
<issubclass (bool, Item)> is returning False, but <assert issubclass(bool, Item)> is not throwing an exception – that’s weird and caused me to do test the assert-statement in a very simple way:
root@om-gta02:~# DISPLAY=:0 python
Python 2.6.2 (r262:71600, May 31 2009, 00:18:54)
[GCC 4.1.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> assert False
>>>
That’s definitely not the expected result of assert.
So, why is that happening? Why python’s assert is just doing nothing?
Some research about that got me into this statement:
“[..]The current code generator emits no code for an assert statement when optimization is requested at compile time. Note that it is unnecessary to include the source code for the expression that failed in the error message; it will be displayed as part of the stack trace.[..]” – http://docs.python.org/reference/simple_stmts.html#grammar-token-assert_stmt
Let’s check that with a regular python-installation:
$ python
Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47)
[GCC 4.3.3] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> assert False
Traceback (most recent call last):
File “<stdin>”, line 1, in <module>
AssertionError
>>>
$ python -O # enable optimizations
Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47)
[GCC 4.3.3] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> assert False
>>>
Conclusion:
– some distributions are shipping their python-package configured for executing python-scripts with optimizations enabled
– asserts may not act as expected, means, they may don’t do anything when above is true
– i’m not using asserts anymore when my app is relying on asserts and I don’t know for sure which target/distribution my scripts are running on
Besides the ongoing work related to the Openmoko Freerunner <-> OpenWrt integration, I decided to focus on multimedia application ports for OpenWrt.
The Xbox Multimedia Center (xbmc -> http://www.xbmc.org), which I’m using (and lovin’) for several years on my Xbox now, was starting getting ported to Linux quite some time ago.
The port looks really promising, so I decided to start get it working within OpenWrt.
I already started porting some basic needed dependencies, including <(lib)boost> (http://www.boost.org), a apparently widely used c++ library set.
Because this project – ehrm – really resists all normal tries getting cross-compiled and staged (it does use an alternative to make called <bjam> which is better because of… – I really have no clue), I took a look how the OpenEmbedded-project got it done – and it helped! – technically as well as morally.
Besides giving me some hints how to workaround some of their (really weird) stuff, I “discovered” a comment in the middle of the file (http://cgit.openembedded.net/cgit.cgi?url=openembedded/tree/recipes/boost/boost.inc) which I like to quote:
[..]
80 # Oh yippee, a new build system, it’s sooo cooool I could eat my own
81 # foot. inlining=on lets the compiler choose, I think. At least this
82 # stuff is documented…
83 # NOTE: if you leave on then in a debug build the build sys
84 # objcopy will be invoked, and that won’t work. Building debug apparently
85 # requires hacking gcc-tools.jam
86 #
87 # Sometimes I wake up screaming. Famous figures are gathered in the nightmare,
88 # Steve Bourne, Larry Wall, the whole of the ANSI C committee. They’re just
89 # standing there, waiting, but the truely terrifying thing is what they carry
90 # in their hands. At first sight each seems to bear the same thing, but it is
91 # not so for the forms in their grasp are ever so slightly different one from
92 # the other. Each is twisted in some grotesque way from the other to make each
93 # an unspeakable perversion impossible to perceive without the onset of madness.
94 # True insanity awaits anyone who perceives all of these horrors together.
95 #
96 # Quotation marks, there might be an easier way to do this, but I can’t find
97 # it. The problem is that the user.hpp configuration file must receive a
98 # pre-processor macro defined as the appropriate string – complete with “‘s
99 # around it. (<> is a possibility here but the danger to that is that the
100 # failure case interprets the < and > as shell redirections, creating
101 # random files in the source tree.)
[..]
Reading this really made my day 🙂
Anyway – boost is ported and working on OpenWrt now, but that’s only the head of the list of dependencies for getting xbmc compiled and running –
any help here – packaging requirements for xbmc for OpenWrt – is highly appreciated!
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!
Hurray! 🙂
first days in Taipei
Drei Tage sind bereits nach meiner Landung vergangen, bin noch immer gejetlagged, habe nichtsdestotrotz bisher soviel versucht mitzunehmen wie geht.
Der Flug war problemlos, was nicht heißt angenehm (16h in einer überklimatisierten und dadurch extrem trockenen Kabine auf einem dieser engen Plätze hocken zu müssen und dabei angestrengt versuchen zu schlafen ist nach wie vor nicht wirklich (m)ein Vergnügen).
Nach Ortszeit früh morgens angekommen – den fehlenden Schlaf kompensiert – wurde ich Abends ein wenig durch die Stadt geführt.
Taipei hat ein gutes Netz an öffentlichen Verkehrsmitteln; vorallem die U-Bahn (MRT) wird weltweit als eine der besten und sichersten gelobt. Und zu meinem Glück: So ziemlich alles ist auch ins Englische übersetzt!
Tickets gibt es nur in RFID-Form (in Form von Coins (analog zu Eintelfahrscheinen) oder der sog. “EasyCard” (analg. Dauerkarten)). Mal abgesehen davon, dass sie wohl das gehackte MiFare Classic verwenden, ist das System so wie man es sich wünscht:
Der Betrag, welcher der Karte zugeordnet ist, lässt sich an jeder Station einsehen, auffüllen oder auszahlen. Ein- und Ausgänge sind mit RFID-Lesern versehen; beim Betreten wird man identifiziert, beim Verlassen ebenfalls und der Betrag der automatisch ermittelten gefahrenen Strecke von der Karte abgezogen. — keine Pappkarten, kein altmodisches Abstempelm, keine zig-Ticketmöglichkeiten mehr.
Es ist immer wieder ein Schauspiel zu beobachten was passiert, wenn eine der alle zwei Minuten ankommenden und so ziemlich immer überfuellten Bahnen hält: Die sonst mit Nichts aus der Ruhe zu bringenden Taiwanesen stürmen auf den Zug zu, pressen und drängeln sich rein und DANACH versuchen die Menschen, die die Intention haben auszustiegen sich durch die im Zug weiterhin einsteigende Menschenmasse nach draußen zu kämpfen. Einen Optimierungswillen seitens der Taiwanesen habe ich hier noch nicht bemerkt. Wozu auch – das System funktioniert ja anscheinend… irgendwie… meistens…
Später am Abend noch einen der generell für Fernost berühmten jede Nacht stattfindenden Nachtmärkte besucht. Hier wird deutlich wieviele Menschen die flächenmaessig eigentlich nicht allzugrosse Hauptstadt bewohnen. So viele Menschen auf einem Haufen habe ich in der Öffentlichkeit bisher selten gesehen. An den gutbesuchten und damit meist qualitativ hochwertigeren Essensständen gibt es “Einweiser”, welche versuchen die Menschenmassen möglichst effektiv in eine Schlange einzuordneun (mir wurde gesagt fuer gutes Essen auf Nachtmärkten bekommt man sogar Wartenummern zugeordnet).
Am Tag darauf die ehemals für die Herstellung von Töpferwaren bekannte Stadt <Yingge> besucht. Als Europäer ist man hier ein echtes Highlight – man kann sich vor neugierigen Kinderblicken und auf einen zeigenden Fingern kaum retten 🙂
Hier ein paar Bilder der Töpferstadt Yingge:
http://nanl.de/nanl/bildchen/taipei (yingge_*.jpg)