LinuxBIOS: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Add LinuxBIOSHowto link)
(Add {{deprecated}} tag)
 
(34 intermediate revisions by 14 users not shown)
Line 1: Line 1:
<noinclude>{{Translations}}</noinclude>
{{deprecated|OLPC now uses [[Open Firmware]] for the bootloader}}

==Overview==
==Overview==


We're using LinuxBIOS in place of a proprietary BIOS on the Laptop board. We're doing this for a number of reasons:
We are using [http://linuxbios.org/index.php/Main_Page 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:


# 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.
1. Cost. 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.
# 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.
# 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.
# Cost. 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. 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. Regardless, LinuxBIOS remains an attractive solution for the other reasons given.
# Freedom. Free Software allows us to do what we need, independent of any proprietary software vendor.


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.
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.


==Video of a LinuxBIOS boot on OLPC==
3. 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.
Here's a video of LinuxBIOS booting Linux on a rev a board. [http://www.youtube.com/watch?v=Ig8vW5ACP-k The movie]


==Hardware Limitations==
==Hardware Limitations==


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

# the LinuxBIOS code that sets up the basic hardware.
# the VSA (Virtual System Architecture code) that emulates many of the legacy devices on the Geode.
# 64kb of code for the embedded controller, used for keyboard and power management functions.
# 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.
# An initrd (in memory file system) with busybox and scripts for installation.
# 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:
# this 64kb region, which we hope will never be updated in the field
# 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==
==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.
We have some pretty specific design goals with LinuxBIOS 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===
===Boot from NAND Flash===
Line 21: Line 44:
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.
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 Devices===
===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.
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 Wireless===
===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
This is the most interesting scenario, and one that is unique to this laptop. This feature could allow a kid in a remote area to get a boot image via a wireless network. This requires no external hardware (flash drives are expensive!) and you can use another machine as the image from which you would like to install. This requires including a wireless driver, the wireless firmware, networking and a small program that accepts the kernel image, loads it into ram and executes it.
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.
==Included Modules==


== Care and feeding of a LinuxBIOS Image ==
* Kernel
* (MSRs?)
* Networking stack
* Basic HID USB drivers
* Marvell Driver
* Marvell Firmware
* Installer stub
* DirectFB driver
* NAND Flash driver


* [[Building LinuxBIOS]]
==HOWTO and Directions==
* [[Flashing LinuxBIOS]]

* [[ROM Emulators for OLPC]]
Go to [[LinuxBIOSHowto]] for instructions on building LinuxBIOS and the ROM image.
* [[Building an SPI image for olpcflash]]


==People==
==People==
Line 56: Line 73:
* Jordan Crouse
* Jordan Crouse
* Michael Lin
* Michael Lin
* Richard Smith

==External Links==
[http://www.fsf.org/campaigns/free-bios.html FSF Campaign for a Free BIOS]

[[Category:Hardware]]

Latest revision as of 21:23, 18 April 2007

  english | 한국어 HowTo [ID# 34323]  +/-  
Stop hand.png WARNING:
The content of this section is considered
DEPRECATED and OBSOLETE
It is preserved for historical or documenting reasons.
OLPC now uses Open Firmware for the bootloader

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. Cost. 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. 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. Regardless, LinuxBIOS remains an attractive solution for the other reasons given.
  5. Freedom. Free Software allows us to do what we need, independent of any proprietary software vendor.

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 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.

Care and feeding of a LinuxBIOS 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
  • Richard Smith

External Links

FSF Campaign for a Free BIOS