LinuxBIOS

Overview

We are using LinuxBIOS and Linux as a bootloader in place of a proprietary BIOS on the Laptop board. We're doing this for a number of reasons:

1. Functionality. Some parts of the design scenarios listed below are unique to this laptop. We would only be able to do this with the community and LinuxBIOS. In particular, we need to be able to resume the hardware very quickly; many BIOS's impose long delays on power on, and this reason, by itself, makes a commercial BIOS questionable.
2. Transparency. We want kids to be able to get all the way down to the bare metal on these machines. The transparency that LinuxBIOS gives us is matched by no others.
3. Robustness and speed. By leveraging Linux drivers rather than hand-crafted drivers in BIOS's we get well tested drivers for a wider variety of devices than any other system. And these drivers have been tuned for speed, as they are identical to that used in production Linux systems.
4. Potential cost. This justification is not real on the OLPC system. Per-machine royalties add to the cost of the laptop. Every cent we have to spend for each machine means some number of kids that don't get laptops. However, in our case, the cost to use LinuxBIOS and Linux as Bootloader is approximately equal to what the cost would have been using a commercial BIOS: the savings of royalties were used by wanting a larger ROM for storing Linux as Bootloader in our serial flash.

On other systems, for example ones on which one can write protect main flash pages, one might put the Linux image being used as a bootloader into such write protected pages. The NAND flash on our system lacks page level write protect bits, and therefore for robustness sake, we decided we want Linux as bootloader to also fit into the the ROM with LinuxBIOS (and the embedded controller code). The actual cost turned out to be almost identical to using a commercial BIOS.

Video of a LinuxBIOS boot on OLPC

Here's a video of LinuxBIOS booting Linux on a rev a board. The movie

Hardware Limitations

We are limited to the 1MB of serial flash that's available in the OLPC board. Into this space (mostly compressed) must fit:

1. the LinuxBIOS code that sets up the basic hardware.
2. the VSA (Virtual System Architecture code) that emulates many of the legacy devices on the Geode.
3. 64kb of code for the embedded controller, used for keyboard and power management functions.
4. A Linux kernel (configured to be small), that includes a USB stack. It now appears likely we'll also be able to fit a full networking stack into the serial flash as well, when work is completed on converting to LZMA compression. If the networking stack cannot fit into the serial flash, we'll put the stack as a module in a partition on the NAND flash, but this is less robust and more prone to corruption than the serial flash. In order to complete functionality sooner rather than later, we will take this route until the compression work can be merged.
5. An initrd (in memory file system) with busybox and scripts for installation.
6. Any icons we use for installation, which may avoid localization headaches.

Since recovery of a board that has been mis-flashed can be extremely difficult if the 64kb of code the EC uses is damaged, and we need some place to store a serial number, keyboard type, and similar information, we are going to write the serial flash in two independent pieces:

1. this 64kb region, which we hope will never be updated in the field
2. the rest of the serial flash, which might have to be updated in the field.

Since the EC code has control of the line for write-enable of the serial flash, we will enforce that a key be held down before write-enable can be asserted, so that any virus or worm cannot easily destroy the serial flash, which would render the machine unusuable.

Design Goals

We have some pretty specific design goals with LinuxBIOS on on the Laptop hardware. We need to support a few re-install scenarios via the BIOS to enable kids in remote areas to be able to reflash their machines. The scenarios are outlined below.

Boot from NAND Flash

This is the normal case for the laptop. Simply loading a kernel off the NAND flash and then using kexec() to load that new kernel into memory and jump to it. This requires having a driver for the NAND flash and being able to locate the kernel on the internal NAND flash.

Boot from USB Storage Devices

Another common system for booting the machine to recover it is to use a USB Flash Drive or use a USB Hard Drive to start an install process. This requires having decent USB drivers for flash drives and hard drives. One of the headaches is that many USB storage devices claim they are ready, but actually are not ready and require a delay before accessing the device.

Boot from Ethernet

By far the easiest way to load the flash in the factory will be via ethernet. While installing from USB storage devices is possible, factory production flow will be easiest and most flexible if USB storage devices do not have to be used on the line, but we can simply plug in a USB wireless dongle connected to a network. Wireless is not feasible at these production rates (potentially .5 gigabytes by 20,000 or more machines/day).

Additionally, the factory floor will want to load individual images onto particular machines, at least the 64kb of the serial flash including a serial number, date of manufacture, manufacturer, etc. Generating these images on the fly is simple on a server system, which can also record the MAC address for each machine built.

Building LinuxBIOS

Go to LinuxBIOSHowto for instructions on building LinuxBIOS and the ROM image.

People

The following people are heavily involved with the LinuxBIOS project. Please contact them on the devel@laptop.org mailing list.

• Ronald Minnich
• Marcelo Tosatti
• Ray Tseng
• Roger Huang
• Morse Chen
• Jordan Crouse
• Michael Lin