The K-Zone: Inside the Archos PMA430

The PMA400 is the latest portable media offering from Archos -- a combined audio/video player/recorder and computer/PDA gadget. Externally it is very similar to the earlier AV420, but internally the differences are substantial -- the PMA400 is a full Linux platform, and supports multitasking, networking, and the installation of third-party applications.
      If you are interested in the capabilities of the PMA400 as a media player/PDA, then you won't be interested in what follows. This article contains information that I've gleaned about the internals of the unit, which may be of interest to Linux developers. It also indicates what I haven't been able to find out, which is alot. In any case, I'm assuming in what follows that the reader knows something about Linux and Qtopia, because I don't have the time or enthusiasm to explain these things in detail. I'm also assuming you know something about the PMA400 as it appears to an end user (but, if not, see this article).

Hardware

The PMA400 has a set of hardware features that would do justice to a desktop computer.

CPU

The PMA400 is based on Texas Instruments' OMAP5910 CPU, which is essentially an ARM 925 with integrated DSP controller. The clock speed is undocumented, but the manufacturer's data sheet recommends 150MHz. The `bogomips' rating reported by the device is `76', but the unit seems a lot faster than this (in comparison, my laptop reoprts 2785 bogomips -- 36 times higher, and Shapr Zaurus models range from 140-370), except when loading programs into memory. Most of the peripheral controllers are integrated into the CPU, including the USB controller and the LCD panel controller. The integrated DSP unit contains accelerators for audio and video decompression, among other things.
      Attached to the CPU is 64 Mb of volatile RAM. There is little, if any, non-volatile memory, but there is that 30Gb hard disk...
      TI provides a lot of information about running Linux on the OMAP CPU, and it should be possible to replace the Archos/Qtopia Linux implementation on the PMA400 with something else if required (Opie? OpenEmbedded?).

Screen

The screen is a 320x240 LCD panel, with touchscreen interface.
      The screen is represented as a framebuffer device (/dev/fb0), implemented in the kernel module dm270fb.
      The touchscreen is connected to an i2c bus. The low-level interface to the touchscreen is provided in a kernel module av500_ts, which makes its output available through the device /dev/ts. I don't know what format the touchscreen data is provided in, but it shouldn't be hard to figure out.

Video capture

The video capture device appears to be a Micronas VPX3226. There is a kernel module vpx32266f, but its interface is undocumented.

USB

The PMA400 has both host and device USB ports. The USB host port is made available through the normal (/dev/usb*) Linux interface.

Audio

The audio hardware is supported by a custom driver av500-audio, which appears to be OSS-compatible. The usual /dev/dsp and /dev/mixer are present. I've found that if you just dump samples into /dev/dsp, even after setting the correct data type, sample rate, etc., the results are horrible. I don't if there is some magic write-block size that makes it Just Work. In any case, I've found that I get best results from audio apps by using ioctl() calls to set the fragment size to 4096 bytes, and then writing to /dev/dsp in 4096-byte blocks. Please contact me if you want to know more about this -- audio apps for the Zaurus basically don't work at all unless they set the fragment size (most don't, and need to be modified).

PCMCIA

The PMA400 has a PCMCIA interface and full driver support, but there does not appear to be any external connection. This interface seems to be present only to support the built-in wireless network interface.

Wireless networking

The built-in wireless network interface is an Agere WLAGS49 Hermes II, connected to an internal PCMCIA bus. There is a driver for this device in standard linux distributions, and that seems to be the one used here. The kernel module is wlags49-h2-cs.

Operating environment

The PMA's built-in operating environment is Qtopia 1.7 on a Linux 2.4.19 kernel. This is essentially the same OE as used in the Sharp Zaurus range. I'm not sure why Archos is using such an old version of Qtopia (I believe the latest is 2.1), but perhaps the fact that it is open-source is a consideration. To its credit, Archos has re-engineered all the built-in media apps from the AV400 series as proper Linux/Qtopia applications, rather than bypassing Linux and driving the hardware directly (which would have been a lot easier, because they could have used all the AV420 code without significant changes). Making the built-in apps real Linux programs means that there is proper multitasking. You can, for example, read an e-mail message while listening to music.

Filesystem layout

The hard disk is formatted as a vfat (Windows 95) filesystem, which is OK for storing large volumes of files, but rubbish for an operating system. In particular, this filesystem type does not support symbolic links. Consequently, the Linux filesystem is implemented using two loopback files. These files are located in the vfat partition, and are internally formated as ext2. Both of these lookback files are 64 Mb in size, and I believe these sizes cannot be increased. The file aimage.img contains the Linux root filesystem, while progfs.img contains the `program storage', that is, the 64 Mb set aside for 3rd-party applications. The program storage area is formatted as you would format a memory card to use with Qtopia. That is, it has directories such as /opt/Qtopia pre-defined, and the built-in package manager knows how to distribute a Qtopia package file to these directories.
      Within Linux, the whole hard disk is mounted at /media, and all the built-in applications take this directory as the top-level directory. When the PMA400 is connected to a host computer so that it emulates an external disk drive, the /media directory appears as the root directory of the drive. This means that the host computer cannot directly access the Linux filesystem itself. This, no doubt, is done to protect the Linux internals from careless PC users. However, this situation is not as bad as it might be. First, it is easy enough to use the built-in shell prompt, or a third-party file manager, to transfer files between the /media directory and other Linux directories. Second, most of the data that you'd want to get access to from a PC is under the /media directory anyway. For example, all the PIM data in in /media/pda, so you can read and write the PIM files over the USB link if you like, which simplifies the backup process.
      Despite what Archos suggests in the PMA's manual, you can store executable code in the /media area, which means that the whole 30 Gb is available for Linux apps and their data, if you wish. Of course, the built-in software package manager can only install into the `program storage' area (which is a loopback filesystem mounted at /progfs so, if you wanted to install more substantial applications, you'd have to take care of their installation and configuration yourself. You'd probably want to create a loopback file under /media and format it as ext3, rather than write directly to the vfat-formatted /media filesystem.
      The natural hack-ability of Linux poses a severe problem for designers of embedded Linux system. On the one hand, it is nice to be able to provide users with the ability to configure their machines; on the other, it's all too easy to provide sufficient rope for the user to hang himself. Consequently, any embedded linux system needs an ability to restore to factory settings if there is a catastrophic misconfiguration. Different vendors tackle this problem in different ways. Archos has taken a particularly brutal approach with the PMA400 -- in effect, the entire unit is restored to factory settings whenever it reboots.
      This is accomplished by keeping the main configuration directories -- /etc and /opt/Qtopia -- in a volatile (RAM-based) filesystem, and copying their contents from the read-only root filesystem on boot. So, if you try to modify the contents of /etc (to add a new user, for example), you'll find that any changes you make are overwritten on the next boot. The same applies to the configuration of the launcher under /opt/Qtopia/apps. You may think you can change the layout of the launcher by moving the .desktop files around under this directory, but you can't. Or, at least, you can't in the long term, because they'll get set back on the next boot. What you can do, however, is to create entirely new launcher tabs and icons by adding files files under /progfs/opt/Qtpalmtop/apps. This is how the package installer works, and these files are copied or linked to /opt/Qtopia/apps at boot. So there is a measure of persistence.
      This measure effectively makes it impossible to configure the Qtopia environment in any except the most trivial ways. However, it does guarantee that almost nothing you are likely to do while hacking the unit around will do damage that requires more than a reboot to put right. To be fair, nothing is provided with Qtopia for configuring the launcher, and Trolltech discourage developers from providing the facilities to do so (because it confuses the poor users!)
      If you really want to recover the ability to configure the Qtopia launcher as you want it, what you can do is to replicate the whole of the /dev/shm/opt/Qtopia directory (which is where the Qtopia config lives in volatile storage) on a filesystem in a loopback file, delete the whole of /dev/shm/opt/Qtopia, the link your loopback filesystem into /dev/shm/opt/Qtopia instead of its original contents. Of course, this change will be lost when you reboot, so you'd need to write a shell script to redo it shortly after booting. It will also be necessary to restart Qtopia to make the changes take effect. This tactic is really only useful if you very rarely have to reboot the unit.

C/C++ development

I do not know if the PMA400's Linux implementation is based on Embedix (from Lineo/Metrowerks) as the Zaurus implementation is; but I do know that the Embedix versions of gcc and g++ do produce code which runs on the PMA400 perfectly well. This is the same cross-compiler that I used to write code for the Zaurus, so porting simple Zaurus applications should be easy enough. To compile console-based PMA400 apps, all you need is the Embedix compiler tools (which include gcc, an ARM build of glibc, ARM-specific header files, and the ARM assembler/linker. All these tools are widely available free of charge (do a google search for ``Embedix ARM cross-compiler''). I was able to port a Linux telnet daemon to the PMA400 in twenty minutes or so. You can run console applications from the built-in shell prompt; so far as I can tell there is no straightforward way to launch them from the PMA400 file browser, and it's not clear whether it will be possible to create icons for them in the launcher (and, even if you can, you have the problem of making them persistence, as described above).
      For the development of graphical applications, it is easiest, for now at least, to stick with the Qtopia environment. In due course somebody may port a complete XFree86 distribution to the PMA400 (it already exists for OpenZaurus, so this shouldn't be technically difficult, but the repackaging is likely to be time-consuming). For now, and for applications that are targeted at consumers, Qtopia is the only game in town. Devloping for Qtopia isn't difficult, in itself. The problem is that learning how to do it amounts more-or-less to learning a non-transferrable skill. To be fair, Qtopia programming isn't that different from developing for the Qt environment on bigger computers, but it is different enough to be a headache.
      In principle, all you need to develop for Qtopia, in addition to the cross-compiler environment you'll also need for simple console-based apps, is the Qtopia headers and libraries, and something called a `meta-object compiler'. In fact, you can copy the libraries off the device itself, and it's probably safest to do this anyway, so you can be sure you're linking against exactly the right versions. You can get all this for free from Trolltech if you are producing open-source applications. Otherwise, you have to pay.
      The meta-object compiler is a tool for generating the event-management plumbing that joins C++ classes together in a Qtopia application. Inter-object communication is implemented using a `slots and signals' paradigm, which is specific to Qt. A signal is not the same as a Unix signal, it is an event (usually a user-interface event, but not necessarily) emited by a particular object. A slot is a function defined to handle that signal when it is emited. Developers are expected to defined slots and signals in their code, using the slot and signal macros, and the meta-object compiler translates the macros into real C++ code.
      Trolltech provide tools for doing Qtopia/Qt development, and these might be helpful for such tasks as defining a user interface layout (which is a tedious thing to code by hand). However, you don't need any of these tools -- the open-source stuff works perfectly well.

Other programming languages

At this stage we have no way of knowing for certain whether programming the PMA400 in a language other C/C++ will ever be possible. There are implementations of Perl and other scripting languages for ARM Linux, and in principle it should not be too difficult to make them work. Things are likely to be a bit more complicated applications with graphical interfaces. The problem here is that the graphical environments have to integrate properly with the Qtopia user interface. At present, the only way applications can get input from the touchscreen is to receive mouse events from qtopia. The are, for example, a number of different Java JVM implementations for ARM Linux (Blackdown have released an ARM JVM for versions up to JDK1.3.1) The problem with these is they expect input from a mouse and output to the framebuffer; to work on the PMA400 they will have to modified to work with the Qtopia system.
©1994-2006 Kevin Boone, all rights reserved