totalueberwachung

I've been playing around with the #1024 recamping problem for some time now, testing stuff Joerg and Dieter come up with and it seems that the latest workaround seems to address the problem (ironically enough all of Openmoko's problems seem to be solveable by increasing a capacitor). There are some other issues that surfaced during these tests, but I'm pretty sure that this is just the framework behaving badly when the calypso actually goes into deep sleep.

One thing I have asked myself over and over was if all the hassle of hunting bug #1024 was worth the gain we would have from deep-sleep. So once I've found a version of frameworkd that played somewhat nicely with the deep-sleep mode of the calypso I started measureing the battery life.

What I did was just run

 root@om-gta02 ~ $ while true; do
 > date
 > mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/PowerSupply/battery org.freesmartphone.Device.PowerSupply.GetInfo
 > sleep 5
 > done >> battery-data

in a terminal while waking the phone occasionally. The phone crashed one evening and spent one night turned off, but I tried to compensate for that by keeping it turned on for an hour or so. I didn't use the phone except wake it up every now and then to collect data and make a phone call (at 0% capacity) to ensure that GSM was still up and running.

So here's the result:

143 hours - almost 6 days worth of standby - not bad for a phone that barely lasted 6 hours in the beginning. So it seems that all the hard work in getting bug #1024 fixed really is worth it.

Unfortunately the remaining problems with deep-sleep make the phone unusable as a regular phone (as does bug #416). If you've got time please help by testing gsm0710muxd or fso-abyss and the framework with deep-sleep.

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

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.

GUADEC has been over a while now, but I still wanted to say how much I enjoyed being there. The atmosphere was really friendly and I enjoyed the lectures and the talks afterwards at dinner. If I have time I definitely want to come again next year. So thanks to all who crossed my way in the UK and made this. You know who you are.

In a couple hours my plane is going to leave from Hanover to Birmingham and I will be attending GUADEC during July 15th through 19th.

I hope to talk with many interesting people (known and unknown), finally meet some of the o-hand guys face to face and have a great time. :-)

My flight back is at July 22nd so I'll have a little time to visit the UK with my girlfriend and finally watch a [musical][1] I've been wanting to watch for some time now. [1]: http://www.avenueqthemusical.co.uk/

Some time ago I got a 19" computer rack for free from a bank branch that closed. Actually Stefan spotted the offer on our local LUG mailing list and planned on installing it in his server room, but unfortunately the rack was too big.

Lucky me :-)

I disassembled it completely, but even then the inner frame was too large for the elevator. Jan, Stefan and I had to carry it 12 storeys high. Thanks again guys, I owe you (and I hope you'll be there when I move out ;-).

I recently installed a UPS and two shelves in my rack and threw out the big 17" monitor. I think the result looks a lot nicer.

Here's a before/after picture:

The rack now consists of (from top to bottom):

• CMC Rittal rack monitoring and security system. The door is locked with a keypad, but you can open it anyway, if you know where to place a strong magnet (so much for security)
• Two shelves with computer related books and CDs
• Rittal KVM switch (unused)
• Fonera access point
• Nortel BayStack 450-24T 24 port 10/100 switch
• My server, an Athlon TBird 800MHz (so if you ever wondered why this site is so slow here's the answer), which is housed in an old SCSI storage controller. That controller had some cool features like a LCD text display, 18 dual color LEDs and 5 big fans not to mention the 18 5.25" slots. I already have a PCB designed to control all of this with an ATMega8 chip but it will be some time until I find the time to finish that project.
• APCSmart 700 uninterruptible power supply

I finally configured my local jabber server for multiple domains. And the whole procedure was really painless, too. I just followed the instructions on: http://www.jms1.net/jabberd2/

My previous domain, thebe.orbit.homelinux.net, will still remain active in parallel to totalueberwachung.de as there are quite some people registered (mostly friends and their friends) and I don't want to force anyone to switch, especially since migrating the contact list is not trivial.

Anyone can join that server, so if you are in need of a jabber account feel free.