totalueberwachung

As you may know Openmoko recently released gllin v1.1 that addresses some longstanding issues, notably: * Move the gllin binary and dependent libraries to /usr/share/gllin (was in /home/root/gllin before). There's a wrapper at /usr/bin/gllin * An init script is now available in /etc/init.d/gllin

By default this init script only enables UDP packets of the NMEA data to port 6000. Logging to file and named pipe are disabled, but you can change this behaviour in /etc/default/gllin.

For GTA01 ogpsd listens to UDP port 6000 already and now it will also start and stop gllin for you (which in turn will power the chip on/off) so GPS on GTA01 should work as seamless as it does on GTA02 (you have to install the gllin package separately, though).

Just posting this from Sao Paulo Airport over their commercial WiFi infrastructure with dnstunnel and openvpn.

Because I can. :-)

elara /home/alphaone # ip r
134.169.172.64 via 172.30.3.1 dev tundns  src 172.30.3.3 
134.169.172.70 via 201.1.232.1 dev ath0 
10.0.0.0/24 dev ethlan  proto kernel  scope link  src 10.0.0.1 
172.30.3.0/24 dev tundns  proto kernel  scope link  src 172.30.3.3 
192.168.0.0/24 dev taphome  proto kernel  scope link  src 192.168.0.8 
201.1.232.0/24 dev ath0  proto kernel  scope link  src 201.1.232.76 
134.169.172.0/24 via 172.30.3.1 dev tundns 
169.254.0.0/16 dev ethlan  scope link  metric 1 
127.0.0.0/8 dev lo  scope link 
default via 192.168.0.1 dev taphome 

elara /home/alphaone # ping heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=245 time=1610 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=2 ttl=245 time=1941 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3 ttl=245 time=4298 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=4 ttl=245 time=6518 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=5 ttl=245 time=5518 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=6 ttl=245 time=4518 ms
^C64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=7 ttl=245 time=3518 ms

--- heise.de ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 16931ms
rtt min/avg/max/mdev = 1610.768/3989.087/6518.088/1655.231 ms, pipe 5
elara /home/alphaone # 

GPRS is blazingly fast compared to this, but hey! At least I have internet.

Get the images and instructions from here:
http://totalueberwachung.de/~alphaone/chumby-image/

From the README:

What works

• console access, though the colours are a bit off (seems like red and green are swapped
• Input via USB Keyboard
• WiFi (association to Open and WPAPSK Networks tested) You need to follow iwpriv-usage.txt which is included in the rt73 sourcecode to setup encrypted networks
• Sound via alsa
• Touch screen

Issues

• Mode switching seems broken. When X is started or when ts_calibrate exits the screen becomes really unstable. I have now added a patch, that just returns when the kernel function is called. The function that needs to be fixed is imxfb_activate_var. There is already a workaround in this function, but it doesn't seem to help.
• Something isn't right regarding the colours. Maybe the kernel thinks it's using palette mode while it's not or vice versa.
• Using the rt73 drivers provided by chumby resulted in a kernel panic after some traffic.

Please send any issues/advice/questions to daniel@totalueberwachung.de

Actually this post was supposed to be about how cool and flashy the Chumby - my new toy - is. I even had an hour to play around with this ARM9 based alarm clock and try out some of the flash widgets (their whole UI is flash based) and so far it was fun.

However, then we didn't have enough US -> Euro power plug converters (I group ordered the Chumby together with Wansti, Shoragan and Stefan) so I dug around and found a power supply that was rated at 12V, 1A. The website of the Chumby said it would function over quite a range of voltage so I didn't bother to check more closely.
This changed when I noticed the magic smoke coming out of my Chumby. That can't be good! Turns out the power supply I used had the polarity reversed and the Chumby doesn't have any protection for that case.

Now nothing would happen any more, even with the original power supply plugged in, so I needed to open up my Chumby. I was planning on doing that anyway to hack the hardware, but under these circumstances I wasn't too happy having to do this now. Fortunately both the software (at least most of it) and schematics for the hardware are openly available, so I was able to download the schematics and try to figure out what went wrong.

It turns out that both 3.3V power regulators were fried. The one powering the P33V_BKUP rail just passed the input voltage (12V) right through. At this point I was quite sure that my Chumby was beyond recovery since the cryptochip is powered from that rail, but I went ahead and replaced the regulator with a different one I had at home. Now something happened when I tried to turn on the Chumby. The other power rails came up when I pressed the power button, and since the power logic is handled by the crypto processor it must still be alive! Apart from that, nothing much happened, though, except that the Chumby drew ~100mA more power than one of its little brothers (Thanks Shoragan for entrusting me with your Chumby after I already killed mine) and mine didn't even turn its display on. So I measured again and found the second bad 3.3V regulator that delivered 3.8V to the P33V power rail (and got pretty hot in the process). After replacing that part the power consumption seemed about right. Time to connect the display again and try it out...yay, it powers up, boots, and....doesn't find the wifi card. Well, I didn't have it plugged in so that's okay. :-)

Check out the pictures here: http://totalueberwachung.de/~alphaone/gallery/2008-01-16-chumby-resurrection/

What a relief! Now I resoldered the power regulators so they would fit in the assembly (The ones I have weren't even SMD parts) and reassembled everything.

And it works! Words can't describe how relieved I was when the Chumby greeted me with its little startup animation.

I have now joined Shoragan's efforts to add Chumby support to OpenEmbedded and we already have a working kernel and rootfs. Unfortunately the bootloader keeps passing cramfs as the fstype to the kernel and OpenEmbedded doesn't really seem to like a readonly filesystem, so the kernel needs to be patched to ignore the cmdline arguments and use it's default - for now. I'd like to use u-boot on the Chumby in the long run so that it can be updated via dfu-util. That would save quite some space which is now used as backup kernel/rootfs and a cache partition that holds OTA firmware updates before they are flashed.

Right now though we have a 22MB rootfs partition which is too small for most images (like the openmoko-image). Booting from USB stick works, though, which is what we'll try to optimize for now.

If you want to try out the images (use at your own risk!) they're at http://totalueberwachung.de/~alphaone/openembedded-build/glibc/images/chumby/

Let me know if you have any problems, either by mail or in ##chumby on freenode.

After two days of playing around with the Chumby I have to say that I really like that form factor. It's really nice as a small display for various information, as an alarm, a small portable wifi terminal (Just plug in a USB keyboard and you're set) or all sorts of other things.

I just had the chance to test a 4GB SDHC card in my PowerShot S3 IS and it works. After formating the card it showed 3.7GB free space. I recorded well over 2GB (the limit for non-SDHC cards) to see if the whole card really is accessible and everything seems to work.

I was a little sceptically since the PowerShot S5 IS is advertised as supporting SDHC and the S3 is not, but I guess Canon just wants to score some selling points on their new model or the old SD controller had SDHC support without them even knowing (or caring at that time).
So now I can get myself an 8GB µSDHC card and use it in any one of my X40, camera or Neo1973 which is pretty cool.

I'm lazy. I used to sort my mails with procmail and I was hesitant of subscribing to yet another mailing list because that meant finding the appropriate X-Ben-There: (Or List-Id:) header, logging into my server, adding a procmail rule for this list and logging out again, then moving all the mails that arrived before the rule into the folder. This seems precisely like the kind of dull task a computer is good at. :-)

When I started to become involved in the OpenMoko project the number of mailing lists I subscribed to just exploded.

So I read up on the MATCH operator in procmail and came up with the following snippet:

:0
* ^X-BeenThere: \/[^@]*
.ML.$MATCH/

This takes the part matching the regular expression right of the '\/' and assigns that to the variable MATCH.
The problem here is that this only grabs the part before the domain, so announce@foo and announce@bar are both sorted into ML/announce (Folders can't contain @ in their name). Unfortunately there is only one MATCH variable in procmail so there's no way around that as long as you're using procmail. So I had a look at and maildrop.

I find the syntax maildrop uses much more concise (if you know C style syntax anyway). However it seems that you can't define and use functions yourself, which is a little annoying. Especially since you will have to create a new folder yourself if it doesn't already exist.

But anyway here's the snippet, that sorts your mailinglists into folders of the format ML/listname-at-listdomain (replacing the dots in the domain with a hyphen):

if ( /^X-BeenThere:\s*(.*)/ )
{
  ADDR=getaddr($MATCH)
  if ($ADDR =~ /^(.*)@(.*)/)
  {
    LISTNAME=${MATCH1}
    LISTDOMAIN=""
    foreach ($MATCH2) =~ /[^.]+/
    { 
      LISTDOMAIN="${LISTDOMAIN}-${MATCH}"
    }

    MDFOLDER="${MLBASE}.${LISTNAME}-at${LISTDOMAIN}"
    include "${MAILDROPFOLDER}/deliver2folder"
  }
}

Since I can't define any functions I am including files with the required functionality and pass arguments through variables (ugly, but it works). Here's the content of deliver2folder and createfolder (used by deliver2folder):

deliver2folder:

include "${MAILDROPFOLDER}/createfolder"
to "${MDBASE}/.${MDFOLDER}/"

createfolder:

# Check if a maildir folder exists and create it if necessary
# The folder must be in MDFOLDER, the maildir base folder in MDBASE

`test -d ${MDBASE}/.${MDFOLDER}`

if ( $RETURNCODE == 1 )
{
  `/usr/bin/maildirmake -f ${MDFOLDER} ${MDBASE}`
}

Now if only I could convince claws-mail to automatically scan for new folders every time...

From November 20th - 21st Roh, Gismo, Stefan, Mickey and I got together in Berlin for a small meeting. Harald generously provided a room for the meeting in his apartment and lots of food for breakfast. Thanks again very much for the hospitality.

We talked about quite a few things, mostly getting everyone up to date on what is happening inside OpenMoko. Among other things we also talked about the status of the OpenMoko distro to release a new snapshot. The apps have matured quite a bit during the past months and all that is needed is a little more integration work and we should have a new snapshot real soon. (TM)
Another issue is that many people are forced to use OpenEmbedded, a build system, even if they just want to develop applications. These people don't care about all the flexibility (and overhead) that oe provides, they just want to compile their applications. So we talked a bit about how this SDK/cross-toolchain should look like, what features it should have. Basically it should pick up autofoo projects automatically and package them into an ipkg to test on the Neo.

Overall it was a real nice meeting and it was great to see Harald so relaxed. Have fun with your regained freedom! :-)

From left to right: Harald, Stefan, Roh, Daniel, Mickey and Gismo

I've been in Taipei, Taiwan from Oct 11th through Oct 28th to visit the OpenMoko office there and get to know the team working in Taipei. This being my first visit to Asia I also wanted to experience the culture.

I can say I managed doing both and want to thank everyone at the office who made me feel very much welcome and at home. I really enjoyed working with the people there and I hope I can repeat that visit sometime in the future.

I wont go into detail about the restructuring partly because Mickey has already mentioned most of the changes and partly because I want to wait how things turn out when the dust settles before I start bitching around. ;-)

I'll try to have some more time for OpenEZX in the future. Until recently I didn't own any EZX device, but fortunately this has changed now. I bought a Motorola A1200 in Taipei and I also have a Motorazr2 V8 now. :-)

Granted, the last one is based on the MotoMAGX platform and will take some more effort until we're able to flash our own stuff onto it, but porting the drivers to a recent kernel should be much easier because it's version 2.6 to begin with.

I've already started hacking on the A1200, basically just getting my build system up and running and verifying that I am able to build and boot my own kernel via boot_usb. Next I'll try to integrate the patches that are floating around to fix the framebuffer.

It is quite slow (at least with the osm data) and I haven't tried integrating gllin yet, but I think it's cool nonetheless.

After driving to Beriln on August 1st to pick up my brother we finally got to Finowfurt today. The camp location is really nice. We already have power, network will hopefully follow in a few days. In the mean time I'm online through GPRS which is pretty usable for irc and web browsing if you have patience (I don't), but sucks for almost anything else (especially remote shells).