I said I'd never blog

As I just announced on the DeforaOS website, the libc now works on my Openmoko phone, running Linux/ARM. There were a couple subtleties in the process, which are probably worth mentioning here.

There are different ABIs

ABI stands for "Application Binary Interface". It is the convention used between applications and the Operating System's kernel to perform low-level actions. Reading a file, sending data through a network, asking for the hour are common examples of such actions. There isn't really an established convention for this on the i386, where system developers know it often varies from a system to another.

On the ARM platform however, and just like on the other RISC platforms I know, I was expecting one ABI to be specified and to be implemented. So I copied my working code from the OpenBSD/ARM port of my libc, and it didn't work. Thankfully there is an excellent article on the matter on the Debian wiki.

Quick tips and tricks

As always, this is to the best of my knowledge, and from the top of my head:

• an ARM CPU has two interesting numbers: the family and architecture version, as seen here (eg ARM7 is ARMv3, ARM9 can be ARMv4 or ARMv5...)
• it can boot in either little or big endian
• it may support at least two instruction sets (16 and 32 bits)

If you find reading about data alignment constraints interesting, and if it is amusing to you that it can matter down to the numbers of the registers to use, read the Debian article cited above immediately.

The syscall numbers are not shared with i386

Unlike my experience with the BSD systems so far, the syscall numbers do not match regardless of the architecture on Linux. Thankfully, strace helped me to notice it really quick. The code executed simply made no sense :)

This is currently only tested on Debian Linux etch on i386. A number of packages are expected to be already installed, like grub and mkisofs. The location of some files is still hardcoded, such as grub's stage1 and stage2 loaders. This is the most important obstacle for cross-OS portability of the script (with the kernel itself, obviously).
A NetBSD/i386 version will follow, assuming grub from pkgsrc first.

The "iso" target

The image is simply done using the "iso" target of the new building system:

$ ./build.sh
Usage: build.sh [option=value...] target...
Targets:
  [...]
  iso		create bootable CD-ROM image
  [...]

A few options are required though, starting with this one:

$ ./build.sh iso
build.sh: DESTDIR needs to be set

• DESTDIR: temporary directory serving as root for the files installed
• PREFIX: parent directory where the files should go (defaults to /usr/local)
• KERNEL: path to the kernel binary
• KERNEL_MODULES: path to an archive of the kernel modules if applicable, uncompressed at the root of the filesystem
• KERNEL_ARGS: optional arguments to give to the kernel
• CDROM_IMAGE: filename of the image to create (defaults to DeforaOS.iso)

The "ramdisk" target

However, we're not there yet. The iso image requires a ramdisk to boot from, which can then lookup and mount the CD-ROM itself. This is done using the revived linuxrc program. It is automatically compiled within the "ramdisk" target, which in turn takes the following arguments:

• DESTDIR: as above (not sure if it's actually used here)
• MOUNTPOINT: a temporary directory to mount the ramdisk image
• RAMDISK_IMAGE: filename of the image to create

Generating the image

Here is what I am currently using myself:

$ ./build.sh MOUNTPOINT=/tmp/ramdisk DESTDIR=/tmp/destdir PREFIX=/usr \
		KERNEL=/usr/src/linux-2.4.36.6/arch/i386/boot/bzImage \
		KERNEL_ARGS="vga=0x301 rw" KERNEL_MODULES=modules.tgz \
		RAMDISK_IMAGE=initrd.img distclean install ramdisk iso

This cleans up the tree everytime, re-builds and installs the UNIX base of the OS in $DESTDIR, generates the ramdisk, and creates the iso image from what's been installed.

Noteworthy details

The $KERNEL_ARGS variable above sets the video mode to VESA framebuffer with a resolution of 640x480 with 256 colors. My kernel explicitly supports it, you'll have to adapt it to your own needs. I also use devfs and have it mounted by default, so I did not populate the /dev tree; you may want to check that out.

Now for a more embarassing part, DeforaOS does not contain the insmod or modprobe commands yet (or any equivalent). Therefore, although I support the installation of kernel modules, they cannot be loaded yet. You'll have to compile all the necessary options inside the kernel itself for now (ISO9660, NLS ISO-8859-1 + Joliet...).

Testing the image

You'll probably find qemu well-suited for this task. You can run it this way:

$ qemu -cdrom DeforaOS.iso

It will automatically boot from the CD-ROM image specified. This link may break, but I uploaded an image for you to test. I built it about two weeks ago.

I did not really polish the usability of the image. The shell supports no completion or globbing yet. The binaries are found in /mnt/cdrom/usr/bin, so you will certainly want to enter this first:

# PATH=/mnt/cdrom/usr/bin
# COLUMNS=80

I think most is said now. Have fun!

Introduction

Yeah, it's getting late, but it seems it's the only way I manage to get things done. You may have noticed I haven't "blogged" in July. I wish I could say I was on vacation, but it's quite the opposite. Not that I didn't work at all on DeforaOS for example, although as always I felt it wasn't enough. However, I recently got an opportunity to spend time on it, more or less directly.

Working for Bearstech

Bearstech is a French company working exclusively with free software. I am currently helping with their hackable devices activity. Some of the projects in this regard will be announced within two weeks. As a hint, I'll just remind you that Bearstech is an official Openmoko Freerunner reseller. By the way, I will try my best to attend this event.

DeforaOS, Whitix, and the GPL

Following this message, I got in touch with Matthew Whitworth of the Whitix project. We discussed ways to cooperate together, and after getting to know about the organization of his project (by re-factoring a few Makefiles) I proposed him to use the DeforaOS libc in his project. Obviously, this means that I will replace the DeforaOS Project License for the GPL in a number of projects. It's certainly not a bad thing.

Document, rinse, repeat

With this happening, I will try to better document my work, via more comments in the code, more news and more articles here. It's not easy, it takes a lot of time, I don't have any users but me (?), but I still hope it will be useful.

The software news

Notably, there are two important things that I have achieved for DeforaOS:

• an improved build framework;
• the generation of useful filesystem images, like a LiveCD.

I will write down the technical details here in another couple of posts.