| My professional interests |
|
Computing Law Education Science and research |
| My leisure interests |
|
Martial arts Heritage railways Garden railways Motorcycles DIY |
| Downloads |
|
Linux downloads Windows downloads Java downloads Perl downloads Home automation downloads |
| About me |
|
Home & family My CV |
| Site info |
|
Contact the author Download policy Keyword index |
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 modulevpx32266f, 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 driverav500-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 iswlags49-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 asext2.
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 ofgcc
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.
| Search |
| Shameless plug |
 By the author of this site. Buy on-line from Amazon USA | UK |
| Editorial |
So you want to be a university lecturer? Read this first! Speak like your boss: new developments in managerese |
| Computing features |
|
File handling in the Linux kernel: an in-depth look at how Linux handles files, filesystems, and file I/O
All sorts of Linux stuff Confused about CLASSPATH? answers are here First steps in EJB using jBoss (recently revised for jBoss 3.2) |