One Laptop Update

I wrote up a long update on where we are in the software and hardware for the One Laptop per Child project. We’ve gotten a lot done, but I don’t think that’s been communicated to the outside world very well. So, for the first time, here’s an update of where we are. Hopefully I’ll be able to do this on a regular basis.

Kernel

In the One Laptop project we actually have two kernels. The first kernel, found in the BIOS, is based on LinuxBIOS. The second is a kernel that’s built from Red Hat’s sources, and aside from a few patches and a different configuration, is a pretty standard OS kernel.

Over the last few weeks, we’ve been pretty successful in getting LinuxBIOS working on the test-A boards that we have in hand. This has been largely due to work from AMD and from the LB project itself. We’ve managed to get the LB image down to under 1 megabyte to fit into the onboard SPI flash that’s found on the boards. The BIOS itself is supposed to handle operating system re-installs as well as finding and booting from the internal NAND flash that contains the main OS. We haven’t got all of these pieces together yet, but we’re making a lot progress. The BIOS is able to boot from two sources right now:

1. Internal NAND flash. This requires that the BIOS is able to find the NAND flash, read the filesystem and find the boot kernel, load the boot kernel and jump to it.

2. External USB media. This requires being able to find a USB key and boot from it.

We plan on adding two more targets, space allowing. These would allow you to boot and re-install over a USB ethernet device and the other, more interesting one, is to boot off the on-board USB wireless. Re-installs without wires are a big requirement for the places that we’re going to be deploying these laptops.

The main kernel itself is working pretty well. It has a different configuration than our mainline kernels, and includes a driver for the on-board wireless chip. It’s built separately from our mainline kernels, both because we have a different config, but also because we have to have some level of stability while Fedora development has been happening.

Over the upcoming couple of months we’ll be adding support to our kernels for the various hardware components in the machine. These include the new controller to access the onboard flash, the display controller, the camera in the machine and the SD reader that’s also included.

Power Management

One of the main areas that we need to focus on is power usage on the laptop. The ability to use power efficiently and use human power to run the laptops is an important part of the story that we need to be able to tell. A large part of our design work has been in this area. From the innovative display to the display controller, to the choice in using our own BIOS, all of these things have set us up to be able to really control how much power we’re using.

In the BIOS and OS side we haven’t done a lot of work because the hardware has only just now started to come alive, and the BIOS has only now started to run well on the machine. But just as a baseline we have a few measurements. Dave Jones recently measured the baseline power usage of the machine in an idle state (which is what most computers spend most of their time doing) and the board itself was only pulling about 3 watts. This is without the recent tickless patches that were posted to linux kernel and without a lot of the userspace work that also needs to happen to prevent userspace from waking up the kernel on a regular basis.

Additionally, Jim has done some measurements on his iPaq and discovered that the kernel itself – once the hardware and BIOS have gone through their wakeup process – only requires about 10ms of time to start scheduling processes. Once that happens, there are some processes that might need work. In particular, his experience was that cardmgr was doing something that added a huge amount of time after the initial wakeup probably probing ports and whatnot. That will need some examination and work. Our goal is to try and go from suspend to full operation in 100-150ms of time, enough so that a user won’t notice the wakeup. A bold goal, but one that doesn’t seem so out of reach given our current measurements.

In terms of what needs to be done, there are a few areas of work that are currently underway:

In the kernel there are two main areas that will probably have the largest impact. The recent tickless patches and the DCON changes that need to be made to enable the DCON to take over the display and let the kernel sleep. The kernel changes for the DCON are well underway thanks to both David Woodhouse and Jordan Crouse. The tickless patches have been submitted upstream and are under consideration. There’s a lot of interest in those patches from various members of the community so we’re hopeful they will be accepted and have full community support.

In userspace there’s a lot of work that still needs to be done. On the Red Hat side there’s a bug that’s tracking a lot of the user space issues that was created by Arjan at Intel. Some of the patches that he’s submitted to keep userland programs from waking up the kernel have already made their way into the distribution. One change that will probably be of most interest to us is to change the way that python and the glib mainloop interact. Apparently there is a wakeup that happens every 100ms or so. Even with that, Dave Jones also reports that while a normal workstation usually wakes up the kernel about 200 times a second, our current OLPC runtime only wakes it up about 10-15 times a second. Lots of work left to be done, of course, but we’re well on our way already.

The BIOS still needs a lot of work in order to support proper susupend/resume. In normal machines, the BIOS handles the suspend/resume via ACPI interfaces. Our BIOS doesn’t use ACPI and we want something faster than the traditional methods of handling suspend/resume, which are designed around the idea of long-term, non-interactive suspends. The work to identify the various power domains for the kernel is underway now, but the work to actually implement suspend/resume inside the BIOS and the kernel hasn’t been done yet.

X Window System

For the X Window System we have a couple of important software components.

These include a new input driver for the touchpad we’re including in the hardware. This dual mode sensor both is a standard touchpad and also will allow you to use a stylus as a separate input. The input driver for this hardware is underway by a contractor who is working for OLPC. It should land in the x.org tree some time in the 7.2 time frame and we’ll have to carry both 7.2 and those drivers as separate packages.

The display in the hardware is based off of the Geode GX2. One of the folks at AMD has written an EXA driver for the hardware. It hasn’t been wildly optimized, but it’s working pretty well today. Coming up, we have to add support for the “DCON” chip that’s included in the machine. This is the chip that will allow the display to continue to refresh even as the machine is suspended. This work is just getting started today as we are just now getting hardware samples of the DCON chips as well as the LCD displays for the laptop.

Python and related libraries

Most of the UI components we’re building are written in Python, gtk and cairo. Python and the bindings are pretty stable, but we’re interested in some of the features that are included in 2.5. These include some memory management patches (which might not actually make a difference because of the way that memory management works in Linux) and performance increases. Some people have reported some minor problems with Python 2.5, but for the most part the people who have been running the pre-releases have had really good things to say about it. So we’re strongly considering carrying the weight of moving to 2.5 earlier rather than later. To do so, we would also have to drag along a lot of the support libraries that link to python. This includes at the very least glib, gtk and cairo.

Sugar and the UI

One of the largest areas of work that we have underway right now is to put together the user interface and the framework for the laptop. The design work is being headed up by a combination of Walter Bender, a design firm in New York named Pentagram, myself, Bryan Clark and Marco Gritti. We’ve got most of the basic concepts nailed down and much of the basic feel, and now we’re moving on to a lot of the details.

Marco has already started the work to get much of the “home view” in place. This is a screen that both handles activity launching as well as system status. Activities themselves will be all full screen, and switching between them will be done from the home view. Interactions include a framework for sharing and working together that’s available to every program that is running on the machine, including pre-built UI. We also include a context sensitive “frame” that give status and notification information as well as information about who you are working with in a particular activity.

The keyboard on the laptop also reflects the UI that we’re designing. There are special keys on the laptop keyboard that allow you to access functions in the UI. Some of these include a button for the camera, a button to show and hide the frame and a pair of keys to handle scrolling in the UI. (i.e. instead of using scrollbars you can hold down one of these keys and roll across the touchpad and the frame you’re on will scroll.)

Of the work that needs to be done on the laptop, the UI is probably the area that’s still in the most flux, isn’t far along and is the highest risk. The look is different that what people are used to even though we think that it will be pretty intuitive. This is a political and acceptance problem, more than anything else.

Over the next couple of weeks we’ll be putting together a set of design documents and a style guide for building activities for the laptop. This will enable programmers and integrators to know what they have to do to make applications work in the environment and feel of the laptop.

There’s also a strong disconnect between the wiki work that’s going on and the rest of the UI. Discussions over whether or not the wiki should be web based or not are still up for discussion and a lot of the backend database work is being done without an eye towards the visual design – something that risks wasting effort on the backend with features that we don’t intend to use or something that’s implemented in such a way that we can’t do something on the front end we care about.

Crypto and Security

One of the areas that’s under heavy discussion right now is around the use of crypto on the laptop. This includes the use of signing for messages between the laptops and signing of software itself. We have neither made choices about what libraries we want or what the exact role will be for all these bits, but we are exploring the goals for which crypto plays a role.

Also up for review is the use of SELinux or some other related technology. There are technical problems that make it a little bit harder to set up an selinux-enabled system onto jffs2 inside of a chroot envionment (as opposed to using the installer) but we have work arounds for some of those problems.

There’s a security consultant working with One Laptop to identify a set of threats and issues that we need to think about. We’ll have a report from him soon as he’s been talking to everyone and trying to gather their thoughts.

Base Operating System

In the base operating system there’s still a lot of low hanging fruit that needs to be worked out. For example, in order to hit our targets for operating system footprint (100MB of flash used) we need to remove a lot of unused bits from the set of packages we’re including. These include things like the X font server, bitmap-fonts, perl, and lots of other random low-hanging fruit. 100MB might sound like a pretty low number but we’re pretty sure we can make that. We don’t need that much infrastructure in order to support the programs that are on the machine.

Overall performance is good in some areas, poor in others. We haven’t done enough measurement to know about the performance of the UI, nor is there enough code in place to be able to know what the overall performance of the UI will look like. The web browser (gecko) is pokey, but quite usable.

Startup performance is poor because we still serialize startup and there are a lot of services still on the machine that we need to not include. In the end we will probably just fire up the few programs that we need by hand and not use the initscripts infrastructure. It just makes things wildly more complex than they need to be.

The way that Red Hat has udev set up is another problem during startup. We know from the new initrd setup that udev itself will start up very fast – certainly in less than a second – but we have a huge number of udev rules set up in our startup scripts which make this a many-second affair on this hardware.

Networking

Networking is one area where we have both good and bad news. The wireless driver has been under development by Marcelo and Marvell. The driver hasn’t been submitted for upstream because it’s not ready yet, but it does appear to work reasonably well. Also, we have working firmware from Marvell that seems to work well but we don’t have the source code to that firmware yet.

We haven’t spent much time working on network scaling nor the various ways that we will be configuring networking on the laptop. The driver hasn’t been fixed to work with NetworkManager (although Dan says that the work would take “just a day”), nor has NM itself even been ported over to what we have on the laptop. In addition, we will need a new front end to NM or change nm-applet to support the environment on the laptop.

Our strategy for scaling through the use of services (backed by jabber) hasn’t been fleshed out yet, either. Although we can wait to do this work later in the schedule, design and resource work for this needs to happen at some point.

One of the key points for our plans also include working with IPv6. Although we know that the support in the OS that we’re using is pretty good, we haven’t spent a lot of time trying to get the code that we have working on top of IPv6 yet. Nor have we actually converted our internal development networks to support it.

Internationalization and Translations

Our strategy for creating builds for various countries is pretty simple: we want to make sure that translations and code are as centralized as possible, but we want to be able to make per-country builds to enable localized builds possible. We have much of the latter part of the infrastructure in place – it should be possible to make localized builds – but we have yet to have a country to try it with.

The first part – centralized code and translations – is just a goal, and it will stay that way. We know that a lot of people will maintain their own translations and we will encourage them to submit them for inclusion, but our infrastructure is such that it will be able to translate activities on the laptop and install translations after the fact.