Upgrading to LinuxBIOS: Difference between revisions

From OLPC
Jump to navigation Jump to search
(use Template:Obsolete and Template:Deprecated, explain why, remove most categories)
 
(98 intermediate revisions by 12 users not shown)
Line 1: Line 1:
{{obsolete|link=[[Open Firmware]]}}
'''Important: This procedure is currently being vetted. Unless you are one of the designated testers, please ignore this page until this message is removed (hopefully within the next day or so).'''
Around 2007, OLPC prototype boards switched to the awesome [[Open Firmware]], and the latter is what ships on all XO-1 machines.
{{deprecated}}
{{Translations}} <!-- to add translations edit [[Upgrading to LinuxBIOS/translations]] -->
== Introduction ==


''This page is mostly for ATest developers. BTest-1 developers should not update the firmware or they will lose valuable manufacturing data in the flash. New tools will be released soon.''


This procedure installs LinuxBIOS in the SPI flash of an OLPC development board, replacing the factory-installed Insyde BIOS if it's there. Insyde BIOS expired on Aug. 23, 2006.
===Purpose===


This process works by booting one of the OLPC [[Build images|build images]], which include the
This procedure installs LinuxBIOS in the SPI FLASH of an OLPC
utilities required for loading LinuxBIOS into the board's SPI flash. The build image can boot either under Insyde BIOS or under LinuxBIOS. Once the flash has been updated, you may optionally continue to install the build image to internal NAND flash, or install a full [[Fedora]] installation on a USB hard disk.
development board, replacing the factory-installed Insyde BIOS. Insyde BIOS
expires on Aug. 26, 2006, so the OLPC team hopes to cut over
to LinuxBIOS soon.

===Warnings===


==Warnings==
----
* '''BTest-1''' users please stop here. Do not update your firmware from the Q2A42 version that is factory installed. The current tools will '''not''' preserve your manufacturing data. We will release new tools shortly.
----
* This is a one-way procedure. Once you have installed LinuxBIOS and rebooted, going back to Insyde BIOS requires other tools and procedures.
* This is a one-way procedure. Once you have installed LinuxBIOS and rebooted, going back to Insyde BIOS requires other tools and procedures.
* If you install a CL 2.0 BIOS version onto a board with Infineon RAMS, you may have trouble (re)booting. Please be careful to choose the correct version of the BIOS.
* We expect that most people may find it easiest to reinstall their systems from scratch. However, you can also use the Fedora image provided solely to update your BIOS from Insyde to LinuxBIOS.
* We '''strongly recommend''' that you install a new OS (build) image at the same time that you upgrade to LinuxBIOS. However, you can also use a new OS image solely to update your BIOS from Insyde to LinuxBIOS.
* LinuxBIOS is not compatible with Insyde BIOS. After LinuxBIOS is installed, old software installations that used to work under Insyde BIOS will no longer boot. If you wish to continue using your existing installation, you will need to update both your kernel and your X driver, as described below.
* LinuxBIOS is not compatible with Insyde BIOS. After LinuxBIOS is installed, old software installations that used to work under Insyde BIOS may no longer boot. If you wish to continue using your existing installation, you will need to update both your kernel and your X driver, as described below.
* The Geode does not have VESA console graphics hardware built in: instead, the Insyde BIOS has code that emulates VESA hardware. This emulator is not owned by AMD, and we prefer to use the BIOS space for other capability. We could also not maintain this binary blob should it require maintenance. This means that DOS or Windows will *not* boot under LinuxBIOS directly, as they expect to find VESA graphics present.
* The Geode processor on the OLPC boards does not have VESA console graphics hardware built in: instead, the Insyde BIOS has code that emulates VESA hardware. This emulator is not owned by AMD, and we prefer to use the BIOS space for other capability. We could also not maintain this binary blob should it require maintenance. This means that DOS or Windows will '''not''' boot under LinuxBIOS directly, as they expect to find VESA graphics present.
* If for some reason you are not using the Fedora builds, you should first update your kernel to our latest kernel, and use the gxfb driver as your console. You will also need the amd X driver. To boot a Linux kernel on OLPC on the graphics console, you must use the gxfb driver. Note that the VESA X driver will also no longer function: you should be using the new "amd" X Window System driver as well, which has much higher performance.
* If for some reason you are not using the [[Fedora]] builds, you should first update your kernel to our latest kernel, and use the gxfb driver as your console. You will also need the amd X driver. To boot a Linux kernel on OLPC on the graphics console, you must use the gxfb driver. Note that the VESA X driver will also no longer function: you should be using the new "amd" X Window System driver as well, which has much higher performance.

==The OLPC LinuxBIOS Installation Procedure==

===Before You Begin===


If you have a UPS (uninterruptible power supply) handy, you should plug in your OLPC system to use it; you do not want to lose power part way through this operation. During the process of erasing and rewriting the SPI flash (which takes about a minute) you are vulnerable to power failures that could cause your hardware to become "bricked" (jargon for unusable).
===The procedure===


You need a USB key (or USB disk), an OLPC devel board with a powered USB 2.0 hub and a USB keyboard ''(important)'', and a Linux-based host system.
You need a USB key (or USB disk), an OLPC devel board with a powered USB 2.0 hub and a USB keyboard ''(important)'', and a Linux-based host system.
([[#Hardware Requirements - Details|More hardware details...]])
([[#Using Windows as a Host System|Using Windows as a Host System...]])


* [[#Hardware Requirements - Details|More hardware details]]
Since the distribution includes the Marvell wireless driver, please ensure your antennae have been installed; there is a chance of damage to the wireless if it is turned on without the antennae installed.
* [[#Using Windows as a Host System|Using Windows as a Host System]]


===Hardware Requirements - Details===
If you have a UPS (uninterruptable power supply) handy, you should plug in
your OLPC system to use it; you do not want to lose power part way through this
operation. While the SPI flash is erased and not fully rewritten (a period of a minute or two) you are
vulnerable to power failures that could cause your hardware to become unusable
(or "bricked", as we sometimes call it).


* An OLPC development board - this is the machine whose SPI flash you will update.
Download spi_flash_linuxbios-20060824.dd from this location, with the following checksums:
* Antennae for your board, if you plan to ever enabling the on-board wireless.
* A powered USB 2.0 hub attached to the OLPC board.
* A USB keyboard attached to that powered hub. Don't use a PS/2 keyboard; it won't work right with this procedure because of a hardware interaction between the PS/2 and SPI programming circuits.
* A USB flash key or USB disk drive, minimum size of 512Mb. Note that we often refer to a flash key when any USB storage device, flash or disk, will do. I tested with a SanDisk Cruzer Mini 1.0GB device. Any existing data on that device will be overwritten.
* A working Linux-based "host system" to copy the software image to a USB key (or see [[#Using Windows as a Host system]]).
* Remember to plug into a UPS if you have one.


===Checking your DRAM type===
http://dev.laptop.org/~krstic/spi_flash_linuxbios-20060824.dd
MD5: 9fba47b90c6269571a0a558103fc30ae
SHA1: 4cc2c4c6fd962d0e4132468ec0bd078a6c65c302


OLPC ATest boards were shiped with DRAM from 3 different manufacturers. Hynix, PSC, and Infineon. The infineon RAMs are the wrong part. They are CL3 parts and the OLPC runs at CL2. Running the Infineon parts at CL2 can cause your board to fail to boot. The Geode does not have a setting for CL3 so there is no "safe" speed for the Infineon. However, after a reasonable ammount of analysis and testing we have found that the Infineon parts will operate at CL2.5 without problems.
onto the host system. ([[#Source Code|Source code ...]])


Therefore we provide 2 different LinuxBIOS images for upgrade. One that operates at CL2 and another at CL2.5.
'''Check that the checksums match!''' You don't want to flash garbage into your
flash.


Your RAM can be identified by looking at the following picture:
Plug your USB key or disk into the host system, verify that /dev/sda is its
correct name ([[#Linux USB drive device names|Alternative names for /dev/sda...]])
and type:


[[Image:Reva infineon highlight small.jpg]]
$ dd bs=5M if=/dev/sda of=oldkey.img
$ dd bs=5M if=spi_flash_linuxbios-20060824.dd of=/dev/sda


The 4 highlighted chips are the DRAM.
Move the USB key to the OLPC board (connect it via the powered
USB 2.0 hub).


The labeling on the Infineon chips looks like this:
Boot the OLPC board ([[#Boot sequence details|Boot sequence details...]])


[[Image:Infineon closeup.png]]
When it finishes booting, there will be a "$" shell prompt hidden in the midst of some USB probing messages.


If your RAM matches the above then you need to use the '''CL2.5''' version of the LinuxBIOS upgrade.
On the OLPC USB keyboard, type:


===Installing LinuxBIOS===
$ flashlb


==== Newer builds : 175+ ====
([[#flashlb details|Details of what flashlb does...]])
http://olpc.download.redhat.com/olpc/streams/development/latest/


Find a source with which to confirm the checksum before flashing. For example:
If something goes wrong (shouldn't happen :-), see [[#Disaster Recovery]].


$ md5sum olpc-redhat-stream-development-ext3.img.bz2
If all goes well (i.e. the verification step succeeds), you can
c37b4fc8b9af3ec119b7f522fd66933c olpc-redhat-stream-development-ext3.img.bz2
upgrade some more OLPB boards by repeating the boot/flashlb steps.


'''Check that the checksums match the corresponding .md5 file!''' You don't want to flash garbage into your flash. You can use the md5sum utility on your Linux host system to do the check.
After you have upgraded all your OLPC boards, you can restore the
previous contents of your USB key if you wish. Plug the USB key
back into the host system and type:


Plug your USB key or disk into the host system, and verify that /dev/sda is its correct name ([[#Linux USB drive device names|Alternative names for /dev/sda...]]). Make '''sure''' you do the verification, since SATA hard drives are becoming more common, so using the wrong device name here might overwrite your own hard drive! Now type the following, replacing /dev/sda with the appropriate device if needed:
$ dd bs=5M if=oldkey.img of=/dev/sda


$ bunzip2 olpc-redhat-stream-development-ext3.img.bz2
This is the end of the procedure. The sections below contain
$ dd bs=1M if=olpc-redhat-stream-development-ext3.img of=/dev/sda
additional information that may be useful if you have problems
$ sync
or are just curious.


When the dd command finishes (it gives no progress indication, so wait until you return to the prompt!), run 'sync' as above, then move the USB key to the OLPC board (connect it via the powered USB 2.0 hub).
===Hardware Requirements - Details===


If you have ddrescue installed you can use:
* An OLPC development board - this is the machine whose SPI FLASH you will update.

* A powered USB 2.0 hub attached to the OLPC board.
ddrescue olpc-redhat-stream-development-ext3.img /dev/sda
* A USB keyboard attached to that powered hub. (Don't use a PS/2 keyboard; it won't work right with this procedure because of a hardware interaction between the PS/2 and SPI programming circuits.)

* A USB FLASH key drive. Any size will do, since the software image is only 5 MB. I tested with a SanDisk Cruzer Mini 1.0GB device. The procedure preserves and restores the USB key's existing contents so you can use a USB key that already has stuff on it.
ddrescue has progress indication.
* A working Linux-based "host system" to copy the software image to a USB key (or see [[#Using Windows as a Host system]]).

* If you have an Uninterruptible Power Supply, it's a good idea to power the OLPC board from it. A power failure during FLASH programming is difficult to recover from.
If you are still using Insyde BIOS, you will likely have it complain that it
has expired. Set the date back to sometime in the summer, for example, August 1, 2006.

Boot the OLPC board ([[#Boot sequence details|Boot sequence details...]]), and be sure to choose the '''second option''' in the green grub boot menu (don't accidentally boot the OLPC qemu target!).

When it finishes booting, you should see the sugar login prompt. Press ctrl+alt+F1 to get to a console, and login as 'root' with no password.

Now depending on what DRAM type you have you should flash in one of 2 different images. See [[#Checking your DRAM type|Checking your DRAM type]] for help on figureing out what DRAM mfg you have.

For Hynix and PSC DRAM use:

$ olpcflash -r insyde.rom
$ olpcflash --brick -w /var/lib/olpc/Olpc-Q2A53.rom (at the time of writing)

For Infineon DRAM use:

$ olpcflash -r insyde.rom
$ olpcflash --brick -w /var/lib/olpc/Olpc-Q2A53_CL2.5.rom

These take of order a minute each to execute. ([[#olpcflash details|Details of what olpcflash does...]])

'''If the flashing is successful, the last line of the output from the last command you executed above will be "- VERIFIED".''' If something went wrong, or verification failed, see [[#Disaster Recovery]], and '''do not power cycle or reset the board.'''

It is important to shutdown the system cleanly as LinuxBIOS is currently picky about finding a clean file system for boot.

$ shutdown -h now

'''At this point you MUST power cycle the board to make sure it is fully reset. If you do not then your PS/2 keyboard and mice will not work.'''

Please unplug the board from the wall power wait 10 seconds and then reapply power.

If all goes well and the machine eventually loads the Sugar login prompt after you've power cycled it, you can upgrade some more OLPC boards by repeating this procedure.

'''This is the end of the procedure. The sections below contain additional information that may be useful if you have problems or are just curious.'''

== Troubleshooting and additional information for the curious ==

===Continuing by upgrading to Open Firmware and the latest build image===

If you are trying to use the [[Autoreinstallation image]], at this point you are ready to boot from the updater image. You should create an EXT2 filesystem on your USB disk and unzip the updater image onto it (again, assuming your disk is sda):

$ mkfs.ext2 /dev/sda1
$ mount /dev/sda1 /mnt
$ cd /mnt
$ unzip ~/olpc193_A62.zip
$ cd /
$ umount /mnt

You can now insert the USB disk into your A-Test board, and it will boot Open Firmware, update the BIOS, update the NAND flash (anything you have stored on there will be destroyed), and reboot. If you now power off the machine and power it back on, it will boot from NAND.
(This is slow, so you may want to write the latest stable image to a USB disk and boot from that instead.)

The Linux-as-Bootloader BIOS found in linuxbios.rom can not boot from USB disks formatted with a Windows partition, which is why we used mkfs.ext2 in the last step. To have Open Firmware boot the ext2 partition, the filesystem label on the partition must also be ext2, which it won't be if the above was run on a Windows-formatted partition. We can fix this with fdisk:

$ fdisk /dev/sda
Command (m for help): <b>p</b>
...
/dev/sda1 1 993 492497 83 Linux
Command (m for help): <b>t</b>
Partition number (1-4): <b>1</b>
Hex code (Type L to list codes: <b>b</b>
Changed system type of partition 1 to b (W95 FAT32)
Command (m for help): <b>w</b>
The partition table has been altered!

(You can now boot the modified disk on the A-Test machine.)

===Continuing with an Installation===

If you installed the image onto a flash key or disk, and are happy to run
off of that, guess what? You are running the OLPC Fedora distribution with
Sugar, and have nothing more to do.

If you want to install some other system, a full [[Fedora]] installation,
or install the image onto the internal
flash (which is quite slow, by the way; this is why we are building the CAFE chip), then you can follow the directions below.

===Continuing with a Full [[Fedora Core]] Installation===

The [[Installing Fedora Core]] page describes how to continue with a full [[Fedora]] installation, once you have installed LinuxBIOS, if the minimal OLPC installation is insufficient.

===Continuing with a NAND flash installation===
The [[Installing to NAND]] page describes how to install a build image to the internal NAND flash on the board and boot from it.

===Release Notes===

* The LinuxBIOS buildrom package is '''very''' sensitive to the compiler toolchain used to build it; we found that FC6 rawhide would build a broken ROM (now being investigated). Ubuntu Edgy unstable has other problems building buildrom head. We '''strongly''' recommend against trying to rebuild the LinuxBIOS rom yourself. Please '''only''' use binaries that OLPC has tested and do not attempt to build your own BIOS image unless you are a serious LinuxBIOS developer.
* The X server have been configured to use 1024x768x16@60hz, by default, to maximize the chance of it "just working" on as many panels and monitors as possible. Feel free to tune for your own use. Note the OLPC panel is 1200x900 resolution, so if your flat panel or monitor will support that resolution, you may want to choose that size during your development, though we highly recommend using scalable graphics libraries based on Cairo to keep independent of display resolution.
* The Marvell firmware is not yet included in the distribution, but must be separately installed. The [http://www.marvell.com/drivers/driverDisplay.do?dId=160&pId=38 firmware] should be downloaded and installed as the file /lib/firmware/usb8388.bin.
* LinuxBIOS won't boot to an unclean filesystem. Be '''sure''' to shut down the OLPC board cleanly after using it (running 'init 0' in the shell will do the trick).


===Linux USB drive device names===
===Linux USB drive device names===


On many Linux systems, USB mass storage devices (e.g. USB key drives)
On many Linux systems, USB mass storage devices (e.g. USB key drives) have device names like /dev/sda, /dev/sdb, etc. Those are the same names that are used for SCSI disks, because USB mass storage devices use SCSI-like commands at one level of their software protocol.
have device names like /dev/sda, /dev/sdb, etc. Those are the same
names that are used for SCSI disks, because USB mass storage devices
use SCSI-like commands at one level of their software protocol.


In the common case where there is only one USB key drive and no "real"
In the common case where there is only one USB key drive and no "real" SCSI hard disks, the device name will be /dev/sda. If there are multiple USB mass storage devices or some SCSI hard disks, the USB key might be /dev/sda, /dev/sdb, /dev/sdc, etc. Make sure that you find the right one, because you don't want to overwrite the wrong drive.
SCSI hard disks, the device name will be /dev/sda. If there are multiple
USB mass storage devices or some SCSI hard disks, the USB key might
be /dev/sda, /dev/sdb, /dev/sdc, etc. Make sure that you find the right
one, because you don't want to overwrite the wrong drive.


On some Linux systems, USB mass storage devices have names like
On some Linux systems, USB mass storage devices have names like /dev/uba, /dev/ubb, etc. ("ub" instead of "sd").
/dev/uba, /dev/ubb, etc. ("ub" instead of "sd").


===Boot sequence details===
===Boot sequence details===


This section describes what you should see while the reflashing
This section describes what you should see while the OS image is booting under Insyde BIOS.
software is booting under Insyde BIOS.


A few seconds after power on, the white Insyde BIOS banner screen
A few seconds after power on, the white Insyde BIOS banner screen will appear. A little later, the top of that screen will show the results of USB probing. Those results should include your USB key.
will appear. A little later, the top of that screen will show the
results of USB probing. Those results should include your USB key.


Then the screen will switch to white text on a black background. Eventually it will boot GRUB (the intermediate bootloader). After a brief timeout, GRUB will then start Linux. When Linux takes control of the screen, the font size will decrease and you'll see a lot of Linux startup messages.
Then the screen will switch to white text on a black
background. Eventually it will boot GRUB (the intermediate bootloader).
After a brief timeout, GRUB will then start Linux. When Linux takes
control of the screen, the font size will decrease and you'll see a
lot of Linux startup messages.


X should start, showing a login prompt in a window titled 'Sugar'. At this point, you can press ctrl+alt+F1 to see a login shell.
New startup message will stop appearing after a few seconds.
The last few lines on the screen will be messages about "/dev/sda"
from the USB subsystem. The "$" prompt from the shell will already
be on the screen, but it's hard to find because there are several
USB messages after it.


===olpcflash details===
If you want to get a fresh prompt, just type the Enter key.


The steps that occurs during the execution of the instructions above are as follows.
===flashlb details===


# (-r) Make a backup copy of the SPI FLASH in insyde.rom
The steps that occurs during the execution of "flashlb" are
# (-E) Erase the SPI FLASH
as follows. It should be clear from the screen messages which
# (-w) Write the contents of /var/lib/olpc/linuxbios.rom to the SPI FLASH
steps are happening.
# (-v) Verify that the newly-written data matches the file

# Make a backup copy of the SPI FLASH in /insyde.rom (unless /insyde.rom already exists)
# Erase the SPI FLASH
# Write the contents of /linuxbios.rom to the SPI FLASH
# Verify that the newly-written data matches the file


===Disaster Recovery===
===Disaster Recovery===


If the reflashing process fails, ''Don't power off or reset the OLPC board''. Here are some things you can try that might be
If the reflashing process fails, ''Don't power off or reset the OLPC board''. Here are some things you can try that might be helpful. These are just suggestions, because I've never seen any failures - recovery procedures for hypothetical failures are inherently speculative.
helpful. These are just suggestions, because I've never seen
any failures - recovery procedures for hypothetical failures
are inherently speculative.


====Retrying the write command====
====Retrying the write command====
Line 147: Line 214:
You can retry the command that writes the SPI FLASH, i.e.
You can retry the command that writes the SPI FLASH, i.e.


$ olpcflash -w /var/lib/olpc/linuxbios.rom
$ flashlb

Retrying might conceivably be of some use if the failure
was transient.


Retrying might conceivably be of some use if the failure was transient.
Re-executing flashlb won't overwrite the /insyde.rom
backup file that was created on the first try, since the
program only creates a backup if no such file exists.


====Restoring Insyde BIOS====
====Restoring Insyde BIOS====
Line 160: Line 222:
You might be able to restore the Insyde BIOS with
You might be able to restore the Insyde BIOS with


$ olpcflash -w insyde.rom
$ restore


This only works if you haven't powered off or otherwise
This only works if you haven't powered off or otherwise reset the OLPC board since you loaded LinuxBIOS into FLASH. The reason is because LinuxBIOS cannot boot the software
that we use in this procedure, which is set up to be booted by Insyde BIOS.
reset the OLPC board since you loaded LinuxBIOS into FLASH.
The reason is because LinuxBIOS cannot boot the software
that we use in this procedure, which is set up to be booted
by Insyde BIOS.


If something went wrong with the flashlb process, it's possible
If something went wrong with the olpcflash process, it's possible - perhaps even likely that the same problem might also affect writing the insyde.rom back. So don't expect miracles; this is suggested "just in case it helps". It might help, for example,
- perhaps even likely that the same problem might also affect
"restore". So don't expect miracles from "restore"; it is
provided "just in case it helps". It might help, for example,
if the flash has a single bit error that Insyde BIOS's code has happened to hide.
if the flash has a single bit error that Insyde BIOS's code has happened to hide.


("restore" was helpful in the testing of this procedure,
("olpcflash -w insyde.rom" was helpful in the testing of this procedure, allowing me to test the procedure several times before committing to the "one way" nature of the upgrade.)
allowing me to test the procedure several times before
committing to the "one way" nature of the upgrade.)


====If you are still having trouble====
====If you are still having trouble====


''Don't power off or reset the OLPC board'' and please get in contact with us,
''Don't power off or reset the OLPC board'' and please get in contact with us, on IRC or via email, so that we have a chance to see what has gone wrong. If you power off or reset the board, we will have no way to diagnose the problem short of returning the board to OLPC and time consuming hardware diagnosis, and even then, may not be able to figure out what went wrong.
on IRC or via email, so that we have a chance to see what has gone wrong.
If you power off or reset the board, we will have no way to diagnose the problem short of returning the board to OLPC and time consuming hardware diagnosis, and even then, may not be able to figure out what went wrong.


===Using Windows as a Host System===
====Using Windows as a Host System====


http://www.chrysocome.net/dd has a version of the "dd" command
http://www.chrysocome.net/dd has a version of the "dd" command that runs under Windows. The command line arguments are compatible with the Linux version, but you have to use the Windows form of the USB device name (not /dev/sda). The Windows "dd" has a "--list"
that runs under Windows. The command line arguments are compatible
with the Linux version, but you have to use the Windows form of
the USB device name (not /dev/sda). The Windows "dd" has a "--list"
command to help you discover the right device name.
command to help you discover the right device name.


===Source Code===
==Credits==
* LinuxBIOS: Ron Minnich, Richard Smith, Mitch Bradley, Li-Ta Lo and the LinuxBIOS project
* Linux: Cast of thousands
* gxfb driver: Jordan Crouse
* amd EXA X driver: Jordan Crouse
* Libertas Marvell 8388 wireless driver: Ronak Chokshi, Aswath Mohan, Michailis Bletsas, Marcelo Tosatti
* Distro hacking, and initramfs goodness: David Zeuthen
* Kernel hacking: David Woodhouse, Marcelo Tosatti
* JFFS2: David Woodhouse
* Sugar: Dan Williams, Marco Gritti, Chris Blizzard, Walter Bender
* Amazing Sleuthing: Mitch Bradley
* Testing: Chris Ball, Ivan Krstić, Ray Tseng
* Lots of information: Ray Tseng
* Installation directions: Mitch Bradley, Ivan Krstić, Jim Gettys, Chris Ball, Carl-Daniel Hailfinger
* Official OLPC virgin (tester): Léandra King


[[Category:Hardware]]
The source tarball(s) for the packages in the ROM image and the image BOM is available from http://dev.laptop.org/www/gpl . Look for names beginning with "linuxbios".

Latest revision as of 22:15, 4 October 2008

542-stopicon.png This page has a more up-to-date location: Open Firmware

Around 2007, OLPC prototype boards switched to the awesome Open Firmware, and the latter is what ships on all XO-1 machines.

Stop hand.png WARNING:
The content of this section is considered
DEPRECATED and OBSOLETE
It is preserved for historical or documenting reasons.

  english | português HowTo [ID# 171176]  +/-  

Introduction

This page is mostly for ATest developers. BTest-1 developers should not update the firmware or they will lose valuable manufacturing data in the flash. New tools will be released soon.

This procedure installs LinuxBIOS in the SPI flash of an OLPC development board, replacing the factory-installed Insyde BIOS if it's there. Insyde BIOS expired on Aug. 23, 2006.

This process works by booting one of the OLPC build images, which include the utilities required for loading LinuxBIOS into the board's SPI flash. The build image can boot either under Insyde BIOS or under LinuxBIOS. Once the flash has been updated, you may optionally continue to install the build image to internal NAND flash, or install a full Fedora installation on a USB hard disk.

Warnings


  • BTest-1 users please stop here. Do not update your firmware from the Q2A42 version that is factory installed. The current tools will not preserve your manufacturing data. We will release new tools shortly.

  • This is a one-way procedure. Once you have installed LinuxBIOS and rebooted, going back to Insyde BIOS requires other tools and procedures.
  • If you install a CL 2.0 BIOS version onto a board with Infineon RAMS, you may have trouble (re)booting. Please be careful to choose the correct version of the BIOS.
  • We strongly recommend that you install a new OS (build) image at the same time that you upgrade to LinuxBIOS. However, you can also use a new OS image solely to update your BIOS from Insyde to LinuxBIOS.
  • LinuxBIOS is not compatible with Insyde BIOS. After LinuxBIOS is installed, old software installations that used to work under Insyde BIOS may no longer boot. If you wish to continue using your existing installation, you will need to update both your kernel and your X driver, as described below.
  • The Geode processor on the OLPC boards does not have VESA console graphics hardware built in: instead, the Insyde BIOS has code that emulates VESA hardware. This emulator is not owned by AMD, and we prefer to use the BIOS space for other capability. We could also not maintain this binary blob should it require maintenance. This means that DOS or Windows will not boot under LinuxBIOS directly, as they expect to find VESA graphics present.
  • If for some reason you are not using the Fedora builds, you should first update your kernel to our latest kernel, and use the gxfb driver as your console. You will also need the amd X driver. To boot a Linux kernel on OLPC on the graphics console, you must use the gxfb driver. Note that the VESA X driver will also no longer function: you should be using the new "amd" X Window System driver as well, which has much higher performance.

The OLPC LinuxBIOS Installation Procedure

Before You Begin

If you have a UPS (uninterruptible power supply) handy, you should plug in your OLPC system to use it; you do not want to lose power part way through this operation. During the process of erasing and rewriting the SPI flash (which takes about a minute) you are vulnerable to power failures that could cause your hardware to become "bricked" (jargon for unusable).

You need a USB key (or USB disk), an OLPC devel board with a powered USB 2.0 hub and a USB keyboard (important), and a Linux-based host system.

Hardware Requirements - Details

  • An OLPC development board - this is the machine whose SPI flash you will update.
  • Antennae for your board, if you plan to ever enabling the on-board wireless.
  • A powered USB 2.0 hub attached to the OLPC board.
  • A USB keyboard attached to that powered hub. Don't use a PS/2 keyboard; it won't work right with this procedure because of a hardware interaction between the PS/2 and SPI programming circuits.
  • A USB flash key or USB disk drive, minimum size of 512Mb. Note that we often refer to a flash key when any USB storage device, flash or disk, will do. I tested with a SanDisk Cruzer Mini 1.0GB device. Any existing data on that device will be overwritten.
  • A working Linux-based "host system" to copy the software image to a USB key (or see #Using Windows as a Host system).
  • Remember to plug into a UPS if you have one.

Checking your DRAM type

OLPC ATest boards were shiped with DRAM from 3 different manufacturers. Hynix, PSC, and Infineon. The infineon RAMs are the wrong part. They are CL3 parts and the OLPC runs at CL2. Running the Infineon parts at CL2 can cause your board to fail to boot. The Geode does not have a setting for CL3 so there is no "safe" speed for the Infineon. However, after a reasonable ammount of analysis and testing we have found that the Infineon parts will operate at CL2.5 without problems.

Therefore we provide 2 different LinuxBIOS images for upgrade. One that operates at CL2 and another at CL2.5.

Your RAM can be identified by looking at the following picture:

Reva infineon highlight small.jpg

The 4 highlighted chips are the DRAM.

The labeling on the Infineon chips looks like this:

Infineon closeup.png

If your RAM matches the above then you need to use the CL2.5 version of the LinuxBIOS upgrade.

Installing LinuxBIOS

Newer builds : 175+

http://olpc.download.redhat.com/olpc/streams/development/latest/

Find a source with which to confirm the checksum before flashing. For example:

$ md5sum olpc-redhat-stream-development-ext3.img.bz2
c37b4fc8b9af3ec119b7f522fd66933c  olpc-redhat-stream-development-ext3.img.bz2

Check that the checksums match the corresponding .md5 file! You don't want to flash garbage into your flash. You can use the md5sum utility on your Linux host system to do the check.

Plug your USB key or disk into the host system, and verify that /dev/sda is its correct name (Alternative names for /dev/sda...). Make sure you do the verification, since SATA hard drives are becoming more common, so using the wrong device name here might overwrite your own hard drive! Now type the following, replacing /dev/sda with the appropriate device if needed:

$ bunzip2 olpc-redhat-stream-development-ext3.img.bz2       
$ dd bs=1M if=olpc-redhat-stream-development-ext3.img of=/dev/sda
$ sync

When the dd command finishes (it gives no progress indication, so wait until you return to the prompt!), run 'sync' as above, then move the USB key to the OLPC board (connect it via the powered USB 2.0 hub).

If you have ddrescue installed you can use:

ddrescue olpc-redhat-stream-development-ext3.img /dev/sda

ddrescue has progress indication.

If you are still using Insyde BIOS, you will likely have it complain that it has expired. Set the date back to sometime in the summer, for example, August 1, 2006.

Boot the OLPC board (Boot sequence details...), and be sure to choose the second option in the green grub boot menu (don't accidentally boot the OLPC qemu target!).

When it finishes booting, you should see the sugar login prompt. Press ctrl+alt+F1 to get to a console, and login as 'root' with no password.

Now depending on what DRAM type you have you should flash in one of 2 different images. See Checking your DRAM type for help on figureing out what DRAM mfg you have.

For Hynix and PSC DRAM use:

$ olpcflash -r insyde.rom
$ olpcflash --brick -w /var/lib/olpc/Olpc-Q2A53.rom (at the time of writing)

For Infineon DRAM use:

$ olpcflash -r insyde.rom
$ olpcflash --brick -w /var/lib/olpc/Olpc-Q2A53_CL2.5.rom

These take of order a minute each to execute. (Details of what olpcflash does...)

If the flashing is successful, the last line of the output from the last command you executed above will be "- VERIFIED". If something went wrong, or verification failed, see #Disaster Recovery, and do not power cycle or reset the board.

It is important to shutdown the system cleanly as LinuxBIOS is currently picky about finding a clean file system for boot.

$ shutdown -h now

At this point you MUST power cycle the board to make sure it is fully reset. If you do not then your PS/2 keyboard and mice will not work.

Please unplug the board from the wall power wait 10 seconds and then reapply power.

If all goes well and the machine eventually loads the Sugar login prompt after you've power cycled it, you can upgrade some more OLPC boards by repeating this procedure.

This is the end of the procedure. The sections below contain additional information that may be useful if you have problems or are just curious.

Troubleshooting and additional information for the curious

Continuing by upgrading to Open Firmware and the latest build image

If you are trying to use the Autoreinstallation image, at this point you are ready to boot from the updater image. You should create an EXT2 filesystem on your USB disk and unzip the updater image onto it (again, assuming your disk is sda):

$ mkfs.ext2 /dev/sda1
$ mount /dev/sda1 /mnt
$ cd /mnt
$ unzip ~/olpc193_A62.zip
$ cd /
$ umount /mnt

You can now insert the USB disk into your A-Test board, and it will boot Open Firmware, update the BIOS, update the NAND flash (anything you have stored on there will be destroyed), and reboot. If you now power off the machine and power it back on, it will boot from NAND. (This is slow, so you may want to write the latest stable image to a USB disk and boot from that instead.)

The Linux-as-Bootloader BIOS found in linuxbios.rom can not boot from USB disks formatted with a Windows partition, which is why we used mkfs.ext2 in the last step. To have Open Firmware boot the ext2 partition, the filesystem label on the partition must also be ext2, which it won't be if the above was run on a Windows-formatted partition. We can fix this with fdisk:

$ fdisk /dev/sda
Command (m for help): p
...
/dev/sda1       1       993     492497    83  Linux

Command (m for help): t 
Partition number (1-4): 1
Hex code (Type L to list codes: b
Changed system type of partition 1 to b (W95 FAT32)
Command (m for help): w
The partition table has been altered!

(You can now boot the modified disk on the A-Test machine.)

Continuing with an Installation

If you installed the image onto a flash key or disk, and are happy to run off of that, guess what? You are running the OLPC Fedora distribution with Sugar, and have nothing more to do.

If you want to install some other system, a full Fedora installation, or install the image onto the internal flash (which is quite slow, by the way; this is why we are building the CAFE chip), then you can follow the directions below.

Continuing with a Full Fedora Core Installation

The Installing Fedora Core page describes how to continue with a full Fedora installation, once you have installed LinuxBIOS, if the minimal OLPC installation is insufficient.

Continuing with a NAND flash installation

The Installing to NAND page describes how to install a build image to the internal NAND flash on the board and boot from it.

Release Notes

  • The LinuxBIOS buildrom package is very sensitive to the compiler toolchain used to build it; we found that FC6 rawhide would build a broken ROM (now being investigated). Ubuntu Edgy unstable has other problems building buildrom head. We strongly recommend against trying to rebuild the LinuxBIOS rom yourself. Please only use binaries that OLPC has tested and do not attempt to build your own BIOS image unless you are a serious LinuxBIOS developer.
  • The X server have been configured to use 1024x768x16@60hz, by default, to maximize the chance of it "just working" on as many panels and monitors as possible. Feel free to tune for your own use. Note the OLPC panel is 1200x900 resolution, so if your flat panel or monitor will support that resolution, you may want to choose that size during your development, though we highly recommend using scalable graphics libraries based on Cairo to keep independent of display resolution.
  • The Marvell firmware is not yet included in the distribution, but must be separately installed. The firmware should be downloaded and installed as the file /lib/firmware/usb8388.bin.
  • LinuxBIOS won't boot to an unclean filesystem. Be sure to shut down the OLPC board cleanly after using it (running 'init 0' in the shell will do the trick).

Linux USB drive device names

On many Linux systems, USB mass storage devices (e.g. USB key drives) have device names like /dev/sda, /dev/sdb, etc. Those are the same names that are used for SCSI disks, because USB mass storage devices use SCSI-like commands at one level of their software protocol.

In the common case where there is only one USB key drive and no "real" SCSI hard disks, the device name will be /dev/sda. If there are multiple USB mass storage devices or some SCSI hard disks, the USB key might be /dev/sda, /dev/sdb, /dev/sdc, etc. Make sure that you find the right one, because you don't want to overwrite the wrong drive.

On some Linux systems, USB mass storage devices have names like /dev/uba, /dev/ubb, etc. ("ub" instead of "sd").

Boot sequence details

This section describes what you should see while the OS image is booting under Insyde BIOS.

A few seconds after power on, the white Insyde BIOS banner screen will appear. A little later, the top of that screen will show the results of USB probing. Those results should include your USB key.

Then the screen will switch to white text on a black background. Eventually it will boot GRUB (the intermediate bootloader). After a brief timeout, GRUB will then start Linux. When Linux takes control of the screen, the font size will decrease and you'll see a lot of Linux startup messages.

X should start, showing a login prompt in a window titled 'Sugar'. At this point, you can press ctrl+alt+F1 to see a login shell.

olpcflash details

The steps that occurs during the execution of the instructions above are as follows.

  1. (-r) Make a backup copy of the SPI FLASH in insyde.rom
  2. (-E) Erase the SPI FLASH
  3. (-w) Write the contents of /var/lib/olpc/linuxbios.rom to the SPI FLASH
  4. (-v) Verify that the newly-written data matches the file

Disaster Recovery

If the reflashing process fails, Don't power off or reset the OLPC board. Here are some things you can try that might be helpful. These are just suggestions, because I've never seen any failures - recovery procedures for hypothetical failures are inherently speculative.

Retrying the write command

You can retry the command that writes the SPI FLASH, i.e.

$ olpcflash -w /var/lib/olpc/linuxbios.rom

Retrying might conceivably be of some use if the failure was transient.

Restoring Insyde BIOS

You might be able to restore the Insyde BIOS with

$ olpcflash -w insyde.rom

This only works if you haven't powered off or otherwise reset the OLPC board since you loaded LinuxBIOS into FLASH. The reason is because LinuxBIOS cannot boot the software that we use in this procedure, which is set up to be booted by Insyde BIOS.

If something went wrong with the olpcflash process, it's possible - perhaps even likely that the same problem might also affect writing the insyde.rom back. So don't expect miracles; this is suggested "just in case it helps". It might help, for example, if the flash has a single bit error that Insyde BIOS's code has happened to hide.

("olpcflash -w insyde.rom" was helpful in the testing of this procedure, allowing me to test the procedure several times before committing to the "one way" nature of the upgrade.)

If you are still having trouble

Don't power off or reset the OLPC board and please get in contact with us, on IRC or via email, so that we have a chance to see what has gone wrong. If you power off or reset the board, we will have no way to diagnose the problem short of returning the board to OLPC and time consuming hardware diagnosis, and even then, may not be able to figure out what went wrong.

Using Windows as a Host System

http://www.chrysocome.net/dd has a version of the "dd" command that runs under Windows. The command line arguments are compatible with the Linux version, but you have to use the Windows form of the USB device name (not /dev/sda). The Windows "dd" has a "--list" command to help you discover the right device name.

Credits

  • LinuxBIOS: Ron Minnich, Richard Smith, Mitch Bradley, Li-Ta Lo and the LinuxBIOS project
  • Linux: Cast of thousands
  • gxfb driver: Jordan Crouse
  • amd EXA X driver: Jordan Crouse
  • Libertas Marvell 8388 wireless driver: Ronak Chokshi, Aswath Mohan, Michailis Bletsas, Marcelo Tosatti
  • Distro hacking, and initramfs goodness: David Zeuthen
  • Kernel hacking: David Woodhouse, Marcelo Tosatti
  • JFFS2: David Woodhouse
  • Sugar: Dan Williams, Marco Gritti, Chris Blizzard, Walter Bender
  • Amazing Sleuthing: Mitch Bradley
  • Testing: Chris Ball, Ivan Krstić, Ray Tseng
  • Lots of information: Ray Tseng
  • Installation directions: Mitch Bradley, Ivan Krstić, Jim Gettys, Chris Ball, Carl-Daniel Hailfinger
  • Official OLPC virgin (tester): Léandra King