The Touch Book comes without a battery backed RTC, which means that the device will lose the correct time every power down. While this won't be much of a problem once power management works and the Touch Book stays mostly on it's quite annoying right now.

There are several easy to use RTC chips with different interfaces available. Since the Touch Book uses I2C, and the I2C buses are easily accessible chosing a RTC chip with I2C interface appears to be the best option. This article demonstrates how to hook up a DS1307 to one of the Touch Books I2C buses.

You need: One DS1307, one 3V Lithium Cell with at least 48mAh, one 32.768kHz quartz crystal, some wires. You should be able to get these components for about 3 Euros.

First you bend the pins of the crystal so you can put it on top of the DS1307 and solder it to X1/X2 (pins 1 and 2), and solder GND (pin4) to the batteries negative terminal:

Now mark pin 1 on your cable, and make a note which wire you'd like to use for which signal. In my setup the lines from right (1) to left (4) are:

Connect the cable to the DS1307: GND to the batteries negative terminal, SDA to pin 5, SCL to pin 6 and VCC to pin 8

Use a small piece of cable to connect the batteries positive terminal with VBAT (pin 3), and mark the soldering points we want to use on the mainboard. The interesting pins from right (1) to left (8) are: USB 5V (1), used as power supply for the chip during normal operations, GND (4), SCL (5) and SDA (6).

Update: Since USB 5V is only available when the USB subsystem is loaded using it is not the best option. When using USB as power source you need a 1 second wait in the kernel modules initalization routine. A better option is soldering VCC to L21:

Disconnect your Touch Book from the power supply, unplug the internal battery, and carefully (preferably without accidentally swapping some lines) solder the wires to the mainboard (Update: The following pictures are for the version using USB for VCC. Better use 3 wires to the interpart connector, and a seperate wire from VCC to L21). After that you can turn on your Touch Book to test if everything works.

You need to get the i2c commandline utility from Gumstix to initialize and test the chip. You can use this version compiled for AI OS if you don't want to compile it yourself. Save the i2c program somewhere in the search path. My binary tries to open /dev/i2c-3, while the gumstick sources use i2c-0 by default. You'll need to adjust this if you use the sources.

To initialize the RTC and set the time to February 19th 2010, 00:51 do the following:

i2c --count=8 0x68 wb 0x0 0x0051000719021000

0x68 is the address of the chip, for the date format description please read the DS1307 datasheet (Table 2, Timekeeper Registers). If everything worked well you can now use watch to see the RTC counting seconds:

watch -n 1 i2c --count=8 0x68 readbyte 0

Once you're satisfied with the results you can stick the battery to the displays backside using some double sided adhesive tape. The attached chip fits nicely into one of the notches around the border:

To use the chip as a RTC you can either apply my patch to the AI-OS tree and build your own kernel image, or download a patched uImage. Just copy the uImage over the one on the first partition of the SD card, and reboot.

The new DS1307 should show up as first RTC, the old TWL4030 as second:

$ dmesg|grep rtc
[   19.007293] rtc-ds1307 3-0068: rtc core: registered ds1307 as rtc0
[   19.007324] rtc-ds1307 3-0068: 56 bytes nvram
[   19.007659] twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc1
[   19.007781] twl4030_rtc twl4030_rtc: Power up reset detected.
[   19.008148] twl4030_rtc twl4030_rtc: Enabling TWL4030-RTC.
[   19.273559] rtc-ds1307 3-0068: setting system clock to 2010-02-21 13:52:16 UTC (1266760336)

You can control both RTCs using hwclock, though the TWL4030 is mostly useless after the mod:

$ hwclock -f /dev/rtc
Sun Feb 21 14:09:47 2010  0.000000 seconds
$ hwclock -f /dev/rtc1
Sat Jan  1 00:17:32 2000  0.000000 seconds

For more information you can poke around in sysfs, interesting locations include /sys/bus/i2c/devices/ (3-0068 is the DS1307), /sys/bus/i2c/drivers/ and /sys/class/rtc/.

My build system for nightly builds is finally back online. For now it's just used for The Mana Client, but other builds will be added soon.

The current version can produce Windows builds using MingW and NSIS as well as static Linux builds using dietlibc. I'm currently adding support for Win32 Qt builds.

git made implementing a nightly build system a lot easier. As it provides wrappers around the most common VCS dealing with several VCS requires next to no additional code. Clean builds can easily be ensured with almost no overhead by keeping a clean repository to pull in upstream changes, and creating fresh clones from it for the builds.

The recently released Linux kernel 2.6.32 finally includes support for some device filesystem again. It's called devtmpfs, and simply creates device nodes for all devices known to the kernel in a tmpfs. I've been using a similar approach on some boxes for the last years, and I'm quite glad that I don't have to keep an out-of-upstream filesystem up to date any longer.

The main reason for including it into the kernel apparently was `bootup speed', udev needs too much time parsing sysfs for devices on complex systems. With devtmpfs, udev finds a populated /dev directory and just needs to adjust some permissions. While this hopefully will solve some of the current udev problems like using NIS/LDAP groups, I think in the long run it's more important that it's possible again to have a udev-less system with a dynamically generated /dev.

There are several cases where this can be important. Sometimes it's nice to run a system where no hardware gets plugged in after bootup without a static /dev. udev is more prone to errors and way to complex for that scenario, it's enough to have the kernel generate the device nodes, and adjust a few device permissions on startup. I've been running my router that way for several years with a custom linux, and was quite glad not wasting inodes on the 4MB memory card I used.

More importantly, it allows for small initramfs images on systems with limited hardware resources again. I've proved about three years ago that it's possible to include a minimalistic package system in an initramfs while keeping its size under 60K. This allowed me to bootstrap a custom distribution with a 2.6 kernel from CD on a system with only 4MB of RAM - the initramfs contains code to check device nodes for a cd drive, mount the cd, search for packages, and extract it to hard disk. Shipping a static dev for such a setup either is prone to errors due to missing device nodes, or takes up too much space. Same goes for the udev userland tools.

You don't need much additional code around your package system to get an installer (given you don't need a shiny UI): You need to do some basic hardware setup, like formatting a drive, mounting the future rootfs. After that it's just ordinary package system functionality. You could even do parts of the hardware setup in the first package to be installed as pre-install scripts, and let this package pull in all other required packages as post-install dependencies.

For embedded systems this approach will give you completely new install or recovery scenarios: You just need to flash a kernel with a 20K overhead (compressed), and you'll be able to do the initial installation or a recovery installation during an ordinary bootup (given the kernel can get the network running). Going for a two-kernel-approach, one non-erasable rescue kernel, and one for the final system your device is virtually unbrickable, even for users unfamiliar with serial interfaces or JTAG. (Some systems, like the WRT routers, listen for incoming TFTP transfers on startup to reflash bricked devices. While this gives you an equally unbrickable device it's harder to implement than the above in-kernel approach, and depends on the actual hardware/bootloader combination)

I've stopped development on my package system implementing the above ideas after finishing a working prototype a few years ago, partly because devfs was vanishing, making the device handling to complex, partly due to the lack of time. The first reason has been eliminated with devtmpfs, now I hope I'll be able to find the time to complete the package system.

A few interesting gadgets which have been announced for a long time are now finally becoming available. All feature an ARM CPU and are running a custom Linux version. Two of the devices rely on an active community for further development, though it's possible to replace the operating system easily on all of them.

Touch Book

The Touch Book is by far the most interesting piece of hardware shown here. It's a netbook with a detachable top, giving you a tablet when needed. AlwaysInnovating has been shipping a limited amount of beta hardware devices since about August, but reached a stable design by now and announced to ship everything in the order backlog pretty soon.

The device is designed to give you easy access to the mainboard, which features 4 internal USB slots. Two of them are already used for WLan and bluetooth dongles, the other two are for your own enhancements. All the hardware sits in the tablet part of the device, the keyboard only contains an additional battery pack. You put the display on the keyboard backwards, giving you a slightly thicker tablet with the additional battery runtime. Or just take of the tablet, and use it seperately. Like, stick it to your fridge using the included magnets.

The software is still in beta, but is expected to become release quality by end of December. The preinstalled Touch Book OS is based on Angstrom, other distributions working on the device include Android, Ubuntu and Gentoo. Anybody getting this device now should be aware of his status of a paying beta tester, though it looks like it'll give you a lot of fun.

SmartQ 7

The SmartQ7 is an Internet tablet with a 7" touchscreen. It's the most mature of the devices presented here, and most likely the one you want to get if you'd like to spend more time using it than making it work. The hardware has been finalized several months ago, though the operating system still seems to have some problems.

It's manufactured the `classic way', by an old fashioned company who sells devices with beta grade software as final product, trying to keep the customers happy by supplying regular updates. While that's fine as an ordinary user it leads to a cluttered community of people hacking the device, resulting in lots of searching if you want to change something by yourself without duplicating efforts.

You can order the SmartQ from DealExtreme if you want to give it a try.

txtr Reader

The txtr Reader is an ebook reader with an epaper display. The operating system is based on Fedora - not a decision I would have made, but at least it's a well known base which can be customized, if needed. It's booting from an SD card, which makes it easy to try out custom operating system images, without bricking the device.

The final hardware specifications have been announced only a few days ago. Unfortunately they decided to kick out WLAN support last-minute to keep the retail price of the device under EUR 300. Which means that - unless you want to fiddle with bluetooth NAP - you need to pay a monthly EUR 12 subscription fee for 3G to get wireless access to the Internet.

I've been looking forward to the txtr reader launch for a long time now, but decided I won't get one. WLAN was the connection I most likely would have used most of the time, and I'm not willing to spend 300 bucks on a gadget with one of the main features I'm interested in gone. I guess it should be possible to hook up a USB WLAN card, and patch the operating system to recognize it, but I won't spend money to try it. At least that saves me the time I would have needed to put in to write a BBeB reader to be able to read my Librie ebooks...

Conclusion

I'd get the touch book. Preferably with keyboard, as the software is still in beta stadium and may get you into situations where you need to have a keyboard plugged in. Since you can just plug in any USB keyboard it would be my first choice for a tablet without keyboard, too. With its well documented hardware design and several operating systems to run on it clearly offers the most hack value.

The SmartQ 7 is nice if you can't afford the touch book, or don't want to play that much with the operating system or hardware.

The txtr reader is basically a disappointment, I'd wait for the next release, hoping for it to contain WLAN again. They clearly decided to aim the first revision hardware to end users instead of hackers improving it, despite trying to emphasize the openness of their platform for the last months. To be honest, the developer documentation they've released so far is mostly worthless. I've hoped for them to release an early batch of readers to developers (like AlwaysInnovating did with the touch book), but as an end user it's just too expensive.

Notes GUI programming, introduction

The C/C++-API toolkit for Notes provides the developer a lot of interesting new options. You can write addin programs or dlls for both the Domino server or the Notes client. You can perform operations neither Java, nor Lotus Script, nor the formula language will allow you to, and you'll get better control over error handling in some cases. Last, but not least, you can write stand alone applications to perform tasks without blocking the client or requiring the client to be running, unlike any solution using Java/Lotus Script/Formula language.

For the latter case it's sometimes desirable to provide a GUI to the user. The classic win32-MFC-approach is a pain in the ass, takes long, and is prone to errors. Fortunately, it's possible to combine a Notes API program with the Qt toolkit, which will enable you to rapidly develop a GUI for your program, assist you in providing translations, while keeping translations, GUI and code separated.

Even if you're writing a server plugin you might benefit from Qt hiding some of the usual cross platform annoyances, provide translation functions, and a few nice-to-have little helpers.

This article is the first in a series of posts about writing GUI applications using Qt and the Lotus C++ toolkit. I'll cover setting up a build environment under Windows first, to continue with topics like a simple sample application, a multithreading example, a custom model to tie to Qt's model/view-enabled widgets, using Notes API datatypes in signals/slots, and porting your applications to UNIX.

Required software

To start you'll need to install three software packages:

Visual C++

The Notes C++ toolkit documentation lists Visual C++ 6.0 as supported compiler, but works with any Visual C++ compiler newer than that. Qt/Windows is mainly developed using Visual Studio 2005 and 2008, so you should at least use VS 2005. You only need the command line tools, which means you can get away by only installing freely available components. I suggest using VS 2008 (Note: Even though I'm talking about VisualStudio just Visual C++ should be enough to follow my articles. Installing VS is just the easiest way, given you have access to it)

Notes C++ Toolkit

Unless you need features only available in Notes 7 or Notes 8 I suggest downloading the latest version of the 3.0 toolkit (3.0i at the time of writing). It's a free download you can get from the Lotus download page, though you'll have to register an IBM account. Unpack the toolkit wherever you like -- I'll assume it's located in c:\notescpp for the rest of the series.

Qt

Unless you have a commercial Qt license you'll need to build Qt for VS by yourself (Update: Since the 4.6 release Nokia provides VS2008 binary packages). Get the Windows source package from Nokias Qt download page, extract the package and follow the included instructions. If you don't want to go through all the configure options you can save build-qt.bat to your Qt source directory (we'll assume it's c:\qt\4.5.2), add c:\qt\4.5.2\bin to your PATH variable, and execute the batch file from a Visual Studio command prompt. This will take some time, and requires about 5GB of disk space.

Final steps

With Qt compiled, VS installed, and the Notes toolkit unpacked there's not much left for this article.

Header pitfalls

The Notes API redefines a few identifiers found in the Windows API headers, so you need to make sure your compiler parses the Notes headers first. Since the VS init scripts prepend their include directories to the %INCLUDE% variable you can't just add the Notes include directories to the system wide variable, like you'd usually do. You can either modify the VS init scripts (which are rather messy), or put a batch file with the following contents somewhere in your path:

set INCLUDE=c:\notescpp\include;%INCLUDE%

If you forget to execute this batch file before trying to build a notes application the build will fail.

Compiling a sample notes application

As a last step you should now try building some of the sample notes applications you can find in c:\notescpp\samples, like the mailscan example. Open a VS command prompt, navigate to the sample directory, execute the notes-dev batch script, and build the example:

Setting environment for using Microsoft Visual Studio 2008 x86 tools.
c:\Program Files\Microsoft Visual Studio 9.0\VC>cd \notescpp\samples\mailscan
C:\notescpp\samples\mailscan>notesdev
C:\notescpp\samples\mailscan>set INCLUDE=c:\notescpp\include;c:\Program Files\Microsoft Visual Studio[...]
C:\notescpp\samples\mailscan>nmake /f mswin32.mak

Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

        cl -Zi -Od -DDEBUG -c -W3 -nologo -GX -MT -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -DW32 -DNODLL  
-D_X86_=1 -Zp1  -D_MT -MTd MAILSCAN.cpp
MAILSCAN.cpp(20) : fatal error C1083: Cannot open include file: 'iostream.h': No such file or directory
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.EXE"' : return code '0x2'
Stop.

Oops. You just made your first contact with the prehistoric C++ used in the Notes C++ API. The errors here are easy to fix, however. You need to replace

#include <iostream.h>
#include <fstream.h>

by

#include <iostream>
#include <fstream>
using namespace std;

and remove libcimt.lib from the makefile.

Coming soon...

In the next article I'll show a simple example application combining Qt and the Notes C++ API, and tell you about error handling. Starting with the 3rd article I'll present an actually useful application, which gets more and more features as we cover more advanced topics.

The swedish domain registry used yesterdays evening to test one of the classic BIND shoot yourself in the foot scenarios -- with great success. You need to substitute DNS for BIND on most occurences to make the article factually accurate. Apparently they didn't train their people to be extra careful about BINDs many pitfalls -- and didn't have a testing step involved in their zone updates. I hope they learn from their grossly negligent workflow and make sure this never happens again -- and remind the many working the same way that it might be wise to have safer procedures in place. There's absolutely no excuse for not having safeguards against software behaviour known for over 10 years to be potentially harmful.

I've got a Bilora Box some time ago. Since I'm shooting medium format with my Pentax 645n anyway both films and tools to develop them are at hand.

Box cameras are pretty much pin hole cameras on steroids -- one cheap fix-focus lens, if you're lucky more than one aperture, shutter speeds of about 1/30s and bulb. On the back of the case is a small red window for the picture counter -- numbers printed on the backing paper of the film.

My box takes 6x9cm pictures, big enough for contact prints. Given the blurriness of the pictures you don't want to enlarge them much anyway. As an alternative to making prints and scanning them I tried scanning the negatives directly today -- with impressing results, when ignoring that the scanner became quite dusty and I'm unable to locate it. Fortunately the dust and reams add to the antique look.

To scan the negatives I placed two sheets of paper on top of the negative and added light from two 500W halogen spotlights to replace the lack of a transparency unit.

(Click to enlarge)

Perls hashes are a handy way of storing lots of easily accessible data. Most of the time you just use it to hold lots of scalars, but sometimes it would be nice to add an array. This article describes how to do it.

Storing an array or an array reference in a hash is pretty straightforward, you just need to know when to explicitly cast the element to an array using @{} -- which is almost everytime, with two exceptions: You don't need the cast when assigning an array reference to a hash element or handing over an array reference as a function parameter:

@{%hash->{array}}=@array;
%hash->{arrayref}=\@array;

Of course it's possible to push() or pop() from a hash element, given you cast it:

push(@{%hash->{array}}, "push_array_1");

Looping -- you might have guessed it already -- works as always, once you added the cast:

print "$_\" foreach(@{%hash->{$_}});

The same syntax rules apply to using hash refs. The following example demonstrates everything described above, showing the difference between storing an array or an array reference by adding values to both an array and an array reference:

#!/usr/bin/perl

use strict;
my %hash;
my $href={};
my @array=('foo', 'bar', 'baz');

@{%hash->{array}}=@array;
%hash->{arrayref}=\@array;

@{$href->{array}}=@array;
$href->{arrayref}=\@array;

push(@array, 'push_ref_1');
push(@{%hash->{array}}, "push_array_1");
push(@{%hash->{arrayref}}, "push_ref_2");

foreach ('array', 'arrayref'){
  print "$_:\n";
  print "(hash)\t$_\n" foreach(@{%hash->{$_}});
  print "(hashref)\t$_\n" foreach(@{$href->{$_}});
  print "\n";
}

$ ./perl-array-hash.pl 
array:
(hash)	foo
(hash)	bar
(hash)	baz
(hash)	push_array_1
(hashref)	foo
(hashref)	bar
(hashref)	baz

arrayref:
(hash)	foo
(hash)	bar
(hash)	baz
(hash)	push_ref_1
(hash)	push_ref_2
(hashref)	foo
(hashref)	bar
(hashref)	baz
(hashref)	push_ref_1
(hashref)	push_ref_2

Flashing the Fonera using custom firmware is widely documented. At least for the units I own TFTP-flashing is highly unreliable. Fortunately it's possible to flash the fonera using XMODEM or YMODEM. Unfortunately, my favorite terminal emulator (kermit) does not provide built-in XYMODEM-support.

Fortunately kermit supports external protocols, and there's a free implementation available in the lrzsz package. Once lrzsz is installed configuration for YMODEM is quite easy:

set protocol ymodem {} {} {sb %s} {} {rb} {}
set file type binary

You might want to put those two lines into .mykermrc, in case you intend to flash your unit more than once. Flashing works almost like using TFTP, you just need to tell `load' where to load from (-m ymodem) and start sending the file:

RedBoot> load -r -b %{FREEMEMLO} openwrt-atheros-vmlinux.lzma -m ymodem
C
(Back at zak.serf.lart.info)
----------------------------------------------------
(/home/bwachter/fonera/) C-Kermit>send /binary openwrt-atheros-vmlinux.lzma
Sending: openwrt-atheros-vmlinux.lzma
Bytes Sent: 786432   BPS:9014                            
Sending: 
Ymodem sectors/kbytes sent:   0/ 0k
Transfer complete
(/home/bwachter/fonera/) C-Kermit>c
[..]
Raw file loaded 0x80040800-0x801007ff, assumed entry at 0x80040800
xyzModem - CRC mode, 6146(SOH)/0(STX)/0(CAN) packets, 3 retries
RedBoot> fis init
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot> fis create -e 0x80041000 -r 0x80041000 vmlinux.bin.l7
... Erase from 0xa8030000-0xa80f0000: ............
... Program from 0x80040800-0x80100800 at 0xa8030000: ............
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
[...]

Unless you'd like to spend a nice evening watching data transferred at 9600Bps you might want to set the baudrate to 115200 before flashing:

RedBoot> baudrate -b 115200
Baud rate will be changed to 115200 - update your settings

The change is non-permanent. In case you're using a distribution which supports higher baudrates on the console you can change it permanently using fconfig.

It has been a while since my last post, for various reasons. One was the lack of interest to change my old scripts to allow posting while keeping out the incredible amount of spam. A new set of scripts is finally usable, replacing all my old cgi-scripts, making maintenance a lot easier. While everything is still far from ready I'm at a point where I can use it for basic blogging, amongst other things. New features will be added when I'm in the mood to do so, if some of them might be interesting for the readers I'll write about them. There's no comment function right now, if you'd like to comment on something please write an email. For navigation, use the newly introduced tags.