DIET-PC ARM Port

Last Update: 6 January 2008

Why?

ARM is a very popular architecture for handhelds, and is now also starting to gain popularity at the "heavy" end of the embedded spectrum, where DIET-PC is most useful.

The success of the PowerPC port, which has already solved a lot of the non-x86 issues, and a hardware donation from an open-source friendly company with a vested interest (thanks John!), encouraged me to give this a go.

Hardware

DIET-PC 2 for ARM was compiled and tested on a Hot-e HL200 that was generously donated by ThinLinx. The Hot-e HL200 is based on a Cogent CSB337 single board computer, with the addition of an SM501 video SOC, and features an ARM920T (armv4t) CPU.

The DIET-PC ARM port is optimised for generic version 4 ARM chipsets (-mtune=strongarm), but should also work on older version 3 chipsets and the newer version 5 (Xscale) chipsets. Please note that I only intend to support 32-bit architectures (arm32), not 26-bit (arm26, aka Thumb).

There is a great deal of variation in ARM hardware, and no clear de-facto standard with regard to boot monitors (BIOS equivalents), so at present I can offer little assistance with boot loader issues. Hot-e uses Micromonitor (uMon), so I know a little about this.

Standard vs EABI

ARM Linux comes in two flavours. The standard ABI (Application Binary Interface) doesn't support hardware floating point (for complex historical reasons) and almost certainly never will. The Enhanced ABI (EABI) looks set to replace the standard ABI, although it is still very new. It has a different calling convention that is flexible enough to cater to various ARM FP acceleration schemes. The EABI allows some programs to run a lot faster, because software floating point emulation is very slow.

Although a Linux kernel can be compiled to support both ABIs, userspace programs (including glibc itself) cannot - they must be one or the other. Hence the two ABIs are in effect totally different platforms. Debian calls the standard ABI "arm" and the EABI "armel". See http://wiki.debian.org/ArmEabiPort for lots of detail about EABI, why it came about, and where it's going.

The question for DIET-PC is: which ABI to support? My intention is to support the standard ABI only for DIET-PC 2, and either both ABIs or EABI only (still undecided) for DIET-PC 3. There are two main reasons for this:

EABI runs on armv4t or later CPUs only. I happen to have brand new devices with armv4t CPUs, but I expect that there is still a lot of equipment out there that doesn't. I want DIET-PC to remain as inclusive as possible, until old hardware still in circulation has suffered major attrition losses.
EABI requires glibc 2.4 or later (in practice 2.5) and gcc 4.1 or later. There are rumours that EABI will be retrofitted to a forthcoming glibc 2.3.7 release, but no such release exists as yet. DIET-PC 2 is based on glibc 2.3.x, and I do not want the ARM port to be inconsistent with other ports in this respect. gcc 4.1 poses fewer problems, since almost all software used in DIET-PC 2 is now gcc 4.x compliant.

I have begun a DIET-PC 3 EABI port, but this is still in the very early stages. The remainder of this webpage refers to the standard ABI DIET-PC 2 port only.

Downloads

Snapshots of the diet-pc ARM tree are available from the ARM section of the DIET-PC downloads page. At present there is no documentation whatsoever.

A demonstration initrd.img is also available. It includes the following packages: assembler_installer 2.1+, ica 2.2, qvwm pre-2.0, rdp 2.4, remotefs 2.6, rfb 2.1, shell 2.5+, sshserver 2.3, xcore 2.1, xserver_xvnc 2.0. You can try this out even if you don't have any ARM hardware using the Windows version of the QEMU ARM emulator along with a non-broken demo kernel (this one was taken from arm-test-0.2.tar.gz on the QEMU website), and this DOS batch file. Once running, you can connect to the machine via SSH to localhost:2222 or to via VNC to localhost:[59]10. The DIET-PC image lacks a true X11 console (i.e. xserver_xorg package using Xfbdev) because QEMU's framebuffer is (or was last time I checked, in 0.8.2) too buggy for a viable demonstration. As always, all passwords are set to "foobar".

Status

DIET-PC Package	Equivalent x86 Version	Status
assembler_installer	2.2	Fully ported.
generic_kernel_586+	2.6.18.3	No kernel provided as yet. I've provided an alpha Hot-e kernel, but this probably won't be of much use to you. QEMU ARM kernels are available.
ica	2.3	Fully ported. The only version of Citrix ICA Client available for ARM Linux is 3.0.86, which is very old, but luckily the DIET-PC ica wrapper script was originally written for 3.0 and works OK with only trivial modification.
mmedia_xine	-	Futile. Xine compiles and runs, but there is no ARM platform powerful enough to get anywhere near acceptable performance, even using the EABI. Audio playback is possible, but requires simpler software such as madplay. mpg321 also works, but only on an EABI platform.
persistfs	2.3	Fully ported.
qvwm	2.0pre	Working prototype window manager package not yet released for x86 and PPC.
rdp	2.5	Fully ported.
remotefs	2.8	Fully ported.
rfb	2.2	Fully ported.
rfbserver	2.1	Not working. Possibly this is due to framebuffer peculiarites on my hardware - additional testers needed.
sensors	2.5	Fully ported, untested.
shell	2.7	Fully ported.
skeleton	2.3	Rudimentary capability only. Sufficient to build initrd.img, but no bootloader support.
smbserver	2.1	Fully ported.
ssh	2.5	Fully ported, untested.
sshserver	2.3	Fully ported.
storageserver	2.3	Fully ported, requires further testing.
wireless	2.0pre	Fully ported.
xcore	2.2	Working, although on my hardware there is an unresolved problem with X11 keymaps.
xserver_tinyx	2.3	Non-working equivalent (Xfbdev instead of Xvesa). Possibly this is due to framebuffer peculiarites on my hardware - additional testers needed.
xserver_xf3	-	Not viable due to lack of ARM support in XFree86 3.x code.
xserver_xorg	2.3	Working equivalent (fbdev instead of vesa).
xserver_xorg_*	2.1	There are some bits and pieces of hardware acceleration overlays, some fully prepared from Xorg 6.9 sources, but none of them will do you any good. No ARM hardware that I know of has a PCI bus, so using a kernel framebuffer driver is your only option.
xserver_xorg_vnc	2.3	Fully ported.
xserver_xvnc	2.1pre	Fully ported.

Major Platform Differences/Challenges

As with the PowerPC port, the ARM port relies on a kernel framebuffer due to lack of VGA/VESA.
No PXE or El Torito support either, but your boot monitor may provide similar functionality. The Linux kernel provides romfs eXecute-In-Place (XIP) support for certain platforms, but I have not had a chance to test this yet. CD booting in the usual sense (with a CD-resident kernel and initrd) is not possible on my hardware, because Hot-e's uMon is not ISO9660-aware, and there is no standardised CD- or HDD-resident boot loader for ARM.
Lack of reliable ARM support in glibc. Vanilla glibc 2.3.6 won't compile on ARM without a lot of patches. There doesn't seem to be a clear de-facto patch set for this, so I have used the Debian patch cluster.
Lack of ARM hardware support in the Linux kernel. The Linux kernel is PCI/AGP-centric, but ARM hardware typically lacks a PCI bus. Support for alternate bus technologies (SM501 in my case) is often missing or very immature and unstable.
The QEMU ARM emulator is fairly stable, but it's very slow. QEMU versions less than 0.9.0 have no support for virtual hard disks. QEMU 0.9.0 supports pseudo-IDE disks in the usual way, for Versatile AB/PB targets only, although from the O/S perspective these are SCSI rather than IDE disks. Hence it is now possible to make a boot-from-virtual-disk ARM emulator; I have done so, but it is not quite release-ready yet.
Even my native ARM hardware is very slow, and the build automation for certain large software distributions is very inefficient (eg. compiling glibc takes ~12 hours).