I was just looking through the contents of the olpcrd.img file on my XO build update.1 708, and it seems that the initrd is a minature installation of Debian.
It contains some giveaway files, such as /var/lib/dpkg/status, which contains:
Package: libnss-dns-udeb Status: install ok unpacked Version: 2.7-5 Description: GNU C Library: NSS helper for DNS - udeb Package: wireless-tools-udeb Status: install ok unpacked Version: 29-1 Depends: libc6 (>= 2.6.1-1), libiw29-udeb (>= 28+29pre7) Description: Tools for manipulating Linux Wireless Extensions Package: python2.5-minimal Status: install ok unpacked Version: 2.5.1-1 Depends: zlib1g-udeb, libc6 Description: A minimal subset of the Python language (version 2.5) Package: module-init-tools-udeb Status: install ok unpacked Version: 3.3-pre11-4 Depends: libc6 (>= 2.5-5) Description: tools for managing Linux kernel modules Package: olpcrd-rootskel Status: install ok unpacked Version: 1.54 Depends: python2.5-minimal, wireless-tools-udeb Description: Skeleton root filesystem used by OLPC initramfs Package: busybox-udeb Status: install ok unpacked Version: 1:1.1.3-5 Depends: libc6 (>= 2.5-5) Description: Tiny utilities for the debian-installer Package: libiw29-udeb Status: install ok unpacked Version: 29-1 Depends: libc6 (>= 2.6.1-1) Description: Tools for manipulating Linux Wireless Extensions Package: zlib1g-udeb Status: install ok unpacked Version: 1:1.2.3.3.dfsg-8 Description: compression library - runtime for Debian installer Package: debian-installer Status: install ok installed Version: olpc-20071227-05:33 Description: debian installation image
The packages installed seem to be udebs, which are basically a lite version of normal Debian packages, designed for specialised uses, such as bootstrapping the Debian installer.
But even worse, it seems that the init script for the XO is written in Python. Seriously. The head of the file /init that runs on the OLPC is:
#!/usr/bin/python2.5 ## Add an '-i' to the #! line to enable the interactive shell. ## Remove the -i for deployment, to ensure that an ## error in the script doesn't land us in an interactive shell. from __future__ import division, with_statement from initutil import * from activate import activate import antitheft import os, os.path, sys, time debug = False # set to false for deployment # let's notify console that we've reached this point and python has launched print "Hello, (children of the) world!"
No wonder it takes so long to boot up! You have to load a whole Python interpreter before we get anywhere!
I haven’t been able to find much documentation on the reasons or inner workings for this bootstrap process. Probably because it’s too embarrasing to reveal. 
Can anybody confirm my findings?
Beyond my knowledge, but one of the early developers was a big debian fan. I found this incomprehensible (to me) page:
http://wiki.laptop.org/go/Early_Boot
Perhaps it will make more sense to you?
Interesting link. In particular:
“I haven’t been able to find much documentation on the reasons or inner workings for this bootstrap process. Probably because it’s too embarrasing to reveal.”
And what’s so embarrassing in that? I really fail to see your point.
Mike (who elected to omit his e-mail address, BTW), don’t you think it’s the least bit ironic that they’d use Debian to bootstrap the Fedora-based OLPC? It’s embarrasing for Red Hat because Debian is on the other side.
Then again, it’s equally embarrasing for Red Hat because they’re using Fedora, and not RHEL. (Like what happened with Kennards Hire.)
(BTW, if you want to discredit me, point out the fact that OLPC is run by the OLPC Foundation, not Red Hat.
)