dsd’s weblog

Some followup notes from our alternate Linux desktop on XO work:

• The README included with the script provides some more specific instructions.
• Your SD card needs to be a minimum of 4GB capacity, because these distributions install more than 2GB by default. We could probably find some smaller distributions, although we require some relatively recent components for some part of the system (e.g. X), so finding a distribution that is both modern and small might be a challenge.
• There are ongoing efforts to create a significantly smaller distro to run on the internal flash, but that is an early project at the moment.
• We heavily recommend using a SD card that is advertised as fast, extreme, ultimate, or whatever! I was previously sceptical of cards advertised in this way - are they actually significantly faster? The answer is YES - we have a ‘non-extreme’ Kingston card and it is so much slower than the others. Installation took 4 times as long. I’m not sure a good way of benchmarking these, the standard “hdparm -t” test showed similar figures on both slow and fast cards.
• I’ve spent most of my time with Fedora. On the whole, it works very well for a machine that is understandably lower spec than most. I do recommend slimming down the services though - turn off all the NFS daemons, cups, bluetooth daemon, pcscd, kerneloops, … In fedora this is done with the ’service’ command for a one-time stop, and ‘chkconfig’ to prevent things starting at boot.
• When you run a lot of big applications, the machine does really slow down. Sometimes the mouse cursor freezes for a while. Perhaps we should experiment with swap space, currently I have none.
• Sound does not work. In Fedora, it doesn’t work at all, probably a PulseAudio bug. I’m hoping that applying the system updates will fix this, but the Fedora infrastructure is down at the moment. In Ubuntu, sound works at the login screen (you hear the welcome sound) but not after you login.
• On the postive side: wireless works, suspend works (most of the time), mouse and keyboard are good, gnome-power-manager dims the screen when idle, etc. It really acts as a normal fully usable distro with a few quirks identified above.

Me and Bobby Powers have spent a few hours smoothing out the process of getting fully-featured Linux desktops to boot on the XO laptop. On the whole, OLPC developers have been pretty good at getting code upstream, so only a few fixups are needed to get things operational on the XO.

The only caveat is that you need a 4GB (or larger) SD card. The XO itself only has 1GB of storage, which is not big enough for the standard installs of the distributions that we’ve been playing with.

We’ve got Fedora 9 and Ubuntu Intrepid Alpha 3 working. Here is the process, using Fedora 9 as an example:

First, download the regular CD/DVD installation media for your distribution. For Fedora 9, you go to http://fedoraproject.org/en/get-fedora. Burn that to CD/DVD.

Next, find a regular PC that is capable of reading SD cards. We’re using a standard desktop plus a USB card reader. Boot that PC from the CD/DVD installation media that you burned earlier. Proceed through the installation as usual, but when asked where you would like to install the operating system, select the SD card.

Choose to setup the disk partitions manually. Do not do any fancy partitioning, just choose one partition that fills up the card. You don’t need to add any swap space.

Select the ext3 filesystem and choose to not install a bootloader.

Wait for installation to complete, and shut down the system.

Next, you need a PC running Linux. This can be the same PC as the one you used to install onto SD, assuming that one has Linux installed on it’s hard disk too. It doesn’t really matter which distribution, as long as you have git and regular development tools installed, and the SD card mounted at a known location.

On this PC, run the following:

# git clone git://dev.laptop.org/users/dsd/XO-alt-distro

Next, become root and run the script.

# sudo su -
# cd ~dsd/XO-alt-distro
# ./sd_fixup fedora-9 /media/disk

It will now download and compile the OLPC kernel, and perform a few other necessary tweaks to your SD card.

When the script has completed, unmount the SD card and plug it into an XO. Boot the XO, and say hello to your fully-functional Linux desktop.

In future, we plan to publish filesystem images of SD-installed distributions, so that you can avoid much of the above. To simplify further, we could also write a tool which runs on the XO which downloads said filesystem image and flashes onto SD.

Update 19/08/2008: Posted some additional notes

Since starting at One Laptop per Child I have been doing some distro work on the OS platform for the XO laptop. The platform is based on Fedora 7 and I have been working on rebasing us onto Fedora 9 for the next release.

Having very little distribution experience outside of developing Gentoo for the last few years, I’ve found some aspects of Fedora’s binary package (RPM) workflow particularly interesting:

1. Automatically detected dependencies: In Gentoo ebuilds, we have to state that package A depends on library B. In Fedora, when building the binary package, the build tools determine many runtime dependencies automatically so there is no need for developers to manually list all dependencies in spec files.
2. Chroot build environments: All packages are built in an otherwise-empty chroot. The build system creates a chroot, quickly installs all of the base binary packages and the build dependencies, then builds/installs a package, produces a package, and throws the chroot away. This allows for predictable build environments and is good for QA.
3. Community access to the build box: All packages are built by Koji. Koji has a nice “scratch-build” system where you can throw a source RPM at it, and it will build it and serve it back to you on a webpage a few minutes later. Great for build testing and handy if you don’t have a complete build environment locally. The scratch-build service is open to non-developers assuming they have been through the click-through contributor agreement.
4. Subpackages: It’s pretty neat how one spec file (equivalent to an ebuild in some ways - textual build scripts) can actually produce several packages. Your spec file takes one upstream tarball, unpacks/compiles/installs it, and then specifies which of the installed files belong to which subpackage.

Naturally, there are some drawbacks too:

1. Build dependencies: Even though many runtime dependencies are automatically detected, you still need to specify the components required for compilation. Remember, each package is built in a clean chroot. You end up having to specify most of the dependencies anyway (although it is still convenient in that you do not have to specify which subpackage has which dependencies - that is determined automatically).
2. No build customisation: OLPC have to fork a few packages which have wacky dependency chains, just to disable support for a certain feature or whatever. Forking away from upstream is undesirable but sometimes necessary. For example, we had to disable libgnome support in GNOME’s Python bindings to avoid libgnome being pulled into the build. libgnome was pulling in the following packages: audiofile bluecurve-icon-theme control-center-filesystem esound-libs fedora-gnome-theme fedora-icon-theme fedora-logos gail gnome-icon-theme gnome-keyring gnome-themes gtk-nodoka-engine libart_lgpl libbonoboui libgnomecanvas libgnomeui libutempter metacity nodoka-metacity-theme pyorbit. Ouch.
3. Convolution/confusion of build tools: To build a package, you can use rpmbuild to do it on your live system, or you can use mock to do the clean chroot thing I described above. Or you can use koji’s command-line client to upload it to koji. Not everything can be done through koji/mock, e.g. you still need to use rpmbuild to build OLPC’s kernel. Also, rpmbuild is the only tool that can build a source RPM, I think.

I’ve also been impressed by the Fedora development community. The community recently made the realisation that OLPC is Fedora’s biggest deployment (over 400,000 XO laptops worldwide, 55,000 more built and distributed each month, 100% of them running Fedora). Greg Dekoenigsberg recently announced the Fedora OLPC special interest group which sounds promising.

The learning lab is one of the aspects of One Laptop per Child which you don’t hear much about. It took me a couple of weeks at the office before I stumbled across their lab space in the corner of our office.

The learning lab is staffed by some key people, including David Cavallo from the MIT Media Lab and Cynthia Solomon, one of the original founders of Logo. These people have years of experience working alongside top scientists such as Marvin Minsky and Seymour Papert.

Last week, David Cavallo gave an enjoyable presentation about the education model behind the efforts of learning group. He shared some experiences from around the world and started a discussion on how to better integrate such ideals into the XO laptop and its software. The session has been published on dailymotion - if you’ve got an hour to kill, I’d definitely recommend watching it.

As part of my fprint fingerprint scanning on Linux efforts, I have completed a new driver for a popular bit of hardware that has been unsupported on Linux until now: the UPEK TouchStrip sensor-only variant with USB ID 147e:2016.

We have already supported another variant including a biometric co-processor for some time now, but in the absence of the co-processor, the sensor-only variant required a completely different driver. Support for the sensor-only devices is a significant step forward as this hardware can be found in a lot of laptops. I’ve already received some success reports - thanks!

The driver is only available in libfprint development repositories (not any released versions). System76 have created an installation guide which may be useful for keen users.

I’ve just released a new development version of libusb-1.0. It incorporates all the feedback I’ve received from the v0.9.0 release, and includes some API changes, so be sure to update and recompile your apps if you were previously using v0.9.0.

Download links:

• libusb-0.9.1
• libusb-compat-0.1.0-beta2

Last week, I took my final exam for my BSc Computer Science degree at The University of Manchester, results pending. I was originally planning to graduate with a masters degree a year from now, but because of some political brain-damage at university, I ended up switching to the shorter degree so that I can take up a great opportunity this summer:

Today was my first day of a 14 week internship at One Laptop per Child, an exciting company producing cool laptops to distribute to children in developing nations with the aim of improving education. I’m going to be working on aspects of the XO software, starting by helping the efforts to upgrade to Fedora 9 for the v8.2.0 August release.

OLPC is based in Cambridge, MA, USA, and this is my 2nd time in this area. I’m living in Brookline until September, and then will need to find somewhere else to live for a month.

My plans for after the summer are uncertain. I’m thinking about hunting for some work in Europe somewhere, I might write more about that nearer the time.

I’m looking to find someone to take over some part-time contract work that I’ve been doing. I’m only stopping as I am about to start some full-time summer work.

The project is Linux driver development for a PCI frame grabber. Kernel experience is essential, and the important areas of knowledge are PCI and DMA. Location does not matter, this is a remote development project.

If you’re interested, or know anyone that might be, please drop me an email.

Lorin Olivier has created a kernel driver for his GL860 webcam. Lorin’s device is the 05e3:f191 variant, whereas mine is the more common 05e3:0503. There are differences between the devices that we don’t have much of a grasp on. The code we’ve written for each device is incompatible with the other, even though there are some protocol similarities.

Lorin reports that his driver works reasonably well with his device - it works with camorama, xawtv, ekiga, amsn, mplayer and xsane. He has also determined how to adjust various camera settings (luminosity, saturation, hue, sharpness, retrolighting, mirror effects, light source, AC power frequency).

Although Lorin doesn’t actually own an 0503 device, he’s attempted to implement support for it based on my earlier efforts. Given that I didn’t get very far, it probably doesn’t work that well. I haven’t had a chance to try it, but there’s no point me sitting on this any longer.

It’s in my git repository in the nvgl subdirectory:
git://projects.reactivated.net/~dsd/gl860.git (gitweb).

All credit goes to Lorin here - thanks! He’s done a great job, but do remember that its experimental code based on a reverse-engineered protocol, so don’t expect it to be flawless.

I’ve been making good progress on libusb-1.0, which has now entered beta. Features over libusb-0.1 include:

1. Asynchronous transfer capabilities (in addition to the synchronous style presented by v0.1)
2. Support for transfers to isochronous endpoints
3. Significantly faster bulk transfer performance for large transfers (several kilobytes or more)
4. Detailed API documentation
5. Power saving: on systems running recent Linux kernels, libusb-1.0 does not wake up all the USB devices plugged into the system during device enumeration
6. Greatly reduced CPU usage while waiting for results of bulk/interrupt transfers (libusb-0.1 was waking up every 1ms)
7. Thread safety

Backwards compatibility

As noted on the homepage, libusb-1.0 is entirely incompatible with libusb-0.1. However, it is designed to install in parallel, in the same way that you can have GTK+ 1.2 and GTK+ 2.x installed on the same system and in use at the same time.

I have also produced a compatibility layer which replaces libusb-0.1. libusb-compat-0.1 looks and smells exactly the same as libusb-0.1 (same library name, API, header file, etc) but internally it just converts libusb-0.1 calls to libusb-1.0.

This means that existing libusb-0.1 applications can take advantage of some of the new libusb-1.0 hotness mentioned above: improved bulk I/O performance, decreased CPU usage, power saving. These improvements appear without any modification to the original application, provided that the user has uninstalled libusb-0.1, and installed libusb-1.0 plus libusb-compat-0.1.

Status

I’m hoping this release will result in:

• More testing and adoption
• API review and feedback
• Ports to other operating systems. Only Linux is supported at the moment, but the library is structured internally for other ports to be written, and the internal API is documented in the source.

Further API changes may happen as a result of the above. This is not a finished product.

Source download

• libusb-0.9.0
• libusb-compat-0.1.0-beta1