The K-Zone: Some notes on OpenZaurus

Memory and storage

• To install OpenZaurus, you need to write the kernel and root filesystem images to a compact flash (SF) card. An SD card won't work. I found that my CF card had to be formatted on a Linux system before the flash process recognized it.

# mkfs.ext -F 16 /dev/sda1

(where /dev/sda1 is the card reader). Although the card was notionally supplied as FAT16 format, the flash process stubbornly refused to start until I had done this.
• The OpenZaurus kernel is happy enough to use memory cards (SD or CF) formatted as FAT16 or FAT32, which is generally how they arrive from the factory. However, in practice a lot of operations go more smoothly if cards are formatted as ext2. This is mostly because this filesystem supports symbolic links, and most Linux software relies heavily on links working. For example, it is common practice for binaries of shared objects (dynamically linkable libraries) to be access through symbolic links which are shortened versions of their own names. Thus libxmms.so.1.0.0 is symbolically linked to libxmms.so.1.0, which is linked to libxmms.so.1, which is linked to libxmms.so. It is usually one of these last two names that an application will use. If your memory card is not ext2-formatted, after installing software you will probably have to create all these links manually, back to the root filesystem (which does support links).


To format as ext2:

# umount /mnt/card
# mkfs.ext2 /dev/mmcda1

Naturally, you don't want to do this unless you've backed up everything on the SD, and it's a lot easier to do before you install anything at all.
• Don't be tempted to format as ext3, unless you have a driver for this filesystem type compiled for the Zaurus. There is no ext3 support in the standard OZ kernel.
• One of the great advantages of OpenZaurus over the standard Zaurus kernel is that it can use the whole of the internal 64Mb of low-power RAM as working RAM, and not storage. The factory configuration uses half of this memory area for RAM, and half for storage. Now, 32Mb RAM isn't much by modern standards, and some applications -- xmms and Opera in particular -- behaved quite badly with this amount of RAM available to them. 64Mb RAM is a different matter.


However, you should think very carefully about whether you want to allocate the whole of the 64Mb area as RAM; you have a choice, determined by the specific kernel image you install. The OZ people recommend 48Mb RAM / 16Mb storage, and there are advantages and disadvantages to either strategy.

The first advantage of using all 64 Mb of RAM is obvious -- more RAM, more applications running. Generally multitasking works better with more RAM. The second advantage is a more subtle one. Remember that the whole of this memory area is wiped when you do a full reset (that is, press the little button under the battery cover). Allocation the whole area if RAM means that nothing is lost if you are forced to do this. One of the main problems with the factory configuration was that PIM data and configuration was stored in this area, and was lost in the event of a full reset.

However, there are also disadvantages to allocating the whole area as RAM. First, if you take this approach, you only get 16Mb of internal (non-card) storage. The kernel, together with the most fundamental parts of the desktop environment, take up nearly all that space. You can install a few small applications on the internal memory, but that's about it. Now, you can store anything you like on an SD card, including applications, but SD write access is much, much slower than writing the internal RAM. Read access is slower too, albeit not to the same extent. So, although you can store applications on an SD card, there are certain advantages to having them in internal memory, which may even offset the disadvantage of having to restore from a backup if you do a full reset. The disadvantage that follows from the need to install applications on SD is that you won't be able to eject the SD card while there are files open on it. A particular problem is Opie applets. There are a number of useful applets that can be installed to extend the functionality of the Opie launcher, and these can be installed to the SD card if you like. The problem here is that if you do this, you'll never be able to eject the card, because the binaries will be opened at boot time, and will thereafter be considered `in use'. The only way you'll be able to eject the card cleanly is to shut down Opie, which is a drag.

But, you say, what if you never plan to eject the SD card? Well, there's still a problem. I've discovered that the SD driver does not always appear to suspend cleanly if there are files in use. The effect is that when the Zaurus wakes up after a suspend, the SD filesystem appears garbled. Goodness knows what would happen if you tried to write a file when it was in that state -- the only fix is to reboot, as the driver won't unload. I generally try to avoid leaving the Zaurus idle with applications running that are on, or use, the SD card. The more applications, rather than data, you store on the SD, the more burdensome this becomes.

In short, it is good to have all 64Mb allocated to RAM, but be aware that there are subtle disadvantages in doing this, that you might want to have regard to.

• Although OpenZaurus implements a standard Unix filesystem -- there are directories /etc,/usr, /bin, etc., most of the real action happens in the /opt/Qtopia directories. There will typically be one of these for each attached storage device, and the desktop software knows to look for them on each storage device. Under each /opt/Qtopia directory, there will be a subset of a standard Unix filesystem, so we have /opt/Qtopia/etc, /opt/Qtopia/bin, etc. Most of the Opie/Qt executables and configuration files are in these directories, not in the traditional Unix locations.

Desktop integration

• You can do standard TCP/IP operations through a wireless network adapter (plugged into the CF slot), through the USB cable (via a desktop system with the appropriate USB-Network protocol support), or through IP-over-Bluetooth. All these methods are well documented and, in my experience, work reasonably well. More about networking later.
  
• You can install a VNC server on the Zaurus; then you can run a VNC client on any computer for which such a client is avilable (i.e., everything) and drive the Zaurus remotely. This is a very handy way to enter large amounts of data, because you can run applications on the Zaurus without being constrained to the built-in keypad. However, don't be tempted to install vncserver on a removable memory card, as it stops the Zaurus suspending properly. The driver gets loaded at boot time, and it appears to the kernel that the driver file is in use. The kernel can therefore not unmount the removable device, and you won't get a clean suspend.
• Consider installing rsync on the Zaurus; with this in place you can copy files between the Zaurus and a Linux desktop system very easily, without the hassle of mounting the desktop system as a remote NFS share on the Zaurus.
• Syncronizing PIM data between a handheld device and a desktop computer is a hard problem. Most developers don't understand this, and the Opie PIM application developers have, sadly, understood in no better than anyone else. This is not a criticism -- these people are writing this code and making it available free of charge, for the general satisfication of doing so. They shouldn't be expected to be experts in database synchronization as well. But, for all that, PIM developers don't seem to understand that to get proper synchronization, each atomic unit of data in the database must have its own timestamp. You can't use the timestamps on the files to determine which data in the database is most up-to-date, because different elements of data may have been edited separately on different machines. Consequently, even if you can get the software to do it, synchronization of Opie PIM data is going to be no more robust than that of the data of any other kind of PIM software.
  

User interface

• Although the OpenZaurus user interface model is based on the Opie project, it is largely compatible with user interface extensions written for plain Qtopia. This means that things like taskbar applets written for the stock Zaurus mostly work on OpenZaurus as well.
  
• Despite what it says in the documentation, the background images for the launcher screen can be in JPG format, rather than PNG.
• The Opie Launcher screen does not provide a way to move or delete application icons from the Launcher tabs. To do that you need the package opie-tabmanager-applet, which is not supplied as part of the OZ filesystem image. When installed, this applet puts an icon into the Settings tab, which you can run to manage the tab contents.
• The Launcher has a tab called `Documents', which is of dubious utility. What the tab is supposed to do is to show files of recognized type, for which software handlers are available. The idea, I guess, is to conceal the underlying filesystem from the user. The problem with this is that the Documents tab has no sub-structure; every recognizable file creates an icon in this tab. If you have a lot of data on the Zaurus, it is less easy to find things here than using, say, the file manager. Moreover, scanning a large removeable memory card for recognizable files can be quite time-consuming. The latest versions of Opie allow this feature to be switched off, which I have found to be a good idea. I understand that the Opie people are working on a much more sophisticated document management system for future versions.

Applications

• The OpenZaurus people kindly maintain an archive of applications that have been compiled for the OpenZaurus environment. However, these aren't necessarily the most recent versions of these applications, and you may find that versions provided by the individual maintainers work better.
• opiealarm is not, as the name might suggest, an alarm clock application. It is a utility that resynchronizes the Linux system clock and the internal real-time clock when the Zaurus suspends. If you don't install opiealarm, you'll find that the Zaurus doesn't keep time properly.
• In my opinion, the most stable and usable media player application for OpenZaurus (and the Zaurus in general) is the Zaurus port of xmms. The basic package can be enhanced to support a wider variety of video fomats by installing mplayer, and the mplayer plug-in for xmms. Both are available in Zaurus format. However, it's worth bearing in mind that when you play video using mplayer, either through xmms or at the prompt, you're still outputting directly to the video framebuffer. The video output will trash anything else you have on the screen, and the underlying desktop won't be redrawn when playback finishes. This isn't a show-stopper, but it is an irritation.
• The Opie PIM applications use an XML-based data format. It isn't well documented, as far as I can tell, but it's fairly simple to figure out by looking at it. It's relatively easy to query the PIM data using shell scripts and standard utilities like grep.
• Some applications supplied with the standard Zaurus do not work at all under OpenZaurus; some others work less well than they should. In some cases the problems can be traced back to a missing library, that cannot be distributed with OpenZaurus for legal reasons. In other cases there are missing icons and images. These problems can usually be fixed with a bit of perseverance. Launching an application from a terminal prompt, rather than the Launcher, often gives a clue where the problem lies. The Opera Web browser does not work all that well for me on OpenZaurus, probably because its display relies on image files that aren't available. The OpenZaurus guys point to Konqueror as an alternative but, in my opinion, Konqueror is not even in the same class as Opera. 

Networking

• In my experience, the difference between a wireless CF network adapter that costs £30 and one that costs £100 is in the current consumption. A top-quality device may only draw 8mA in standby mode, which will have little impact on battery life. A cheap device may draw 50mA all the time, which will have a significant impact. 
• If you want to copy a large file (> 1 Mb) from a desktop system to the Zaurus using a wireless CF card, it's much faster to copy it to the internal flash (e.g., the /tmp directory) then copy it to SD, rather than send it directly to SD over the air. The internal flash is generally faster to write. This means that the wireless card gets back into standby mode quicker, which saves the battery.
• I was very impressed with how easy it was to configure the wireless networking in OpenZaurus. On an unecrypted network, all I had to do was to plug in the CF card, and everything autoconfigured through DHCP. On a WEP-encrypted network it wasn't quite so straightforward, because I couldn't figure out where to put the key. It took a while for me to figure out that all the WEP configuration applet does is to write settings into /etc/pcmcia/wireless.opts , so the answers to questions about configuration are to be found in the general Linux wireless networking repositories, not in Zaurus-specific locations.

Development

C/C++ Development

The problem with Qtopia and Opie is that both require proprietary tools for development. To be fair, you can get these tools free-of-charge for non-commercial use, but if you want to develop commerical applications, you'll need to pay for your tools. There's nothing inherently unreasonable about this -- I had to pay for the other tools of my trade, after all. It's just that this isn't what we've come to expect when working in the Linux world. In addition, the basic tools come bundled with a whole heap of other clever things, like IDEs and build management tools. You may, or may not, like to use this sort of thing. Personally, I don't. My favoured build tools are make,gcc, and vi. You can (just about) built Qtopia apps using these simple tools, but it's not well documented.

Ranting aside, here's what you will need to develop for Qtopia on OpenZaurus.

• A C++ cross-compiler for the ARM CPU, and a standard C library to go with it. There are links to the Embedix versions of these tools on the OpenZaurus web site. They aren't the latest versions, but unless you fancy recompiling your build tools before you compile your applications, they'll probably do the trick.
• The Qtopia development environment, from Trolltech. If you aren't developing for profit, you can get the free version. This is a whopping download, nearly 30Mb. Of that, what you really need is the header (.h) files, and the Meta-Object Compiler (moc). Of course, you can use all the other stuff as well, but I don't bother. moc, however, is essential unless you are a masochist. What moc does is to read a .h file containing the declaration of your user interface objects, and generate another .cpp file containing all the plumbing and infrastructure to hook these objects into the system.
• The Qtopia and Qt/Embedded libraries, in ARM format. These are easy to get: just copy them from the Zaurus. I just copied all the contents of /lib, /usr/lib, and /opt/Qtopia/lib from my Zaurus into a directory, and add that directory to the gcc linker line using the -L switch.

If you don't know how to code Qtopia applications, you've got an uphill struggle ahead of you, but there's plenty of examples and documentation on the Trolltech web site.

Java Development

The other JVM is an implementation of the `J2ME Personal Profile' from Sun Microsystems, which you can get from java.sun.com. This one does work out-of-the-box with OpenZaurus, but there are a few problems. First, you'll need to install a library called libfloat.so which is not supplied with the JVM. The download location is in the release notes, and you'll need it even if you don't plan to run any application that does floating-point arithmetic -- the JVM won't start without it. The second problem is that, with OZ 3.3.5, the JVM's main window does not align properly with the top of the screen. This means that you can't see the title bar. Again, you can work around this, but it's a nuisance.

Whichever JVM you use, there are general problems with Java on the Zaurus. The JVM is not as well-integrated into the Zaurus desktop environment as Qt applications are. For example, if you pop up the virtual keyboard to enter text with the stylus, it takes up the bottom third of the screen. Most Qt applications dynamically resize to accomodate this loss of screen area. There does not seem to be any way to do this in Java -- the virtual keyboard just obscures the application. Also, Java applications take a lot longer to start up the C applications, and use a lot more RAM while they are running.

If you can live with these limitations, and you can find a JVM version that works properly, Java development on the Zaurus is more-or-less trivial, so long as you know Java. The user interface is provided by standard AWT objects, and these behave much as they do in any other JVM. If you use Jeode, you're stuck with a fairly ancient API (it is officially compliant with JDK1.1.8, as per the PersonalJava Specificiation), which means that modern applications may need some tweaking. With the Sun JVM, a significant part of the JDK1.4 API is available, which makes porting modern applications more straightforward.

Other languages