LinuxBIOS: Difference between revisions
No edit summary |
JordanCrouse (talk | contribs) (Add {{deprecated}} tag) |
||
Line 1: | Line 1: | ||
<noinclude>{{Translations}}</noinclude> |
<noinclude>{{Translations}}</noinclude> |
||
{{deprecated|OLPC now uses [[Open Firmware]] for the bootloader}} |
|||
==Overview== |
==Overview== |
Latest revision as of 21:23, 18 April 2007
OverviewWe 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:
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 OLPCHere's a video of LinuxBIOS booting Linux on a rev a board. The movie Hardware LimitationsWe are limited to the 1MB of serial flash that's available in the OLPC board. Into this space (mostly compressed) must fit:
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:
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 GoalsWe 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 FlashThis 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 DevicesAnother 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 EthernetBy 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 ImagePeopleThe following people are heavily involved with the LinuxBIOS project. Please contact them on the devel@laptop.org mailing list.
External Links |