Notes on using the OLPC developer boards

Hardware Notes

This is very early hardware: it has not undergone extensive testing. It is not unusual with such boards that some component or another has a problem of some sort; sometimes this is only seen in a small fraction of samples.

So far, the hardware seems to have been pretty solid.

Handling of bare boards

Commercial hardware gets extensive testing for immunity to static damage, and the packaging provides more protection. With the developer boards, we have neither of these luxuries (yet). Testing sometimes uncovers design or component problems that end up requiring engineering changes, and the boards are bare, not protected by packaging. This ESD testing will occur later this summer, but the early developer boards have not seen such testing.

So please treat the boards carefully; boards are not yet common. Developer boards will start coming through with standoffs. They arrive in a static (conductive) bag. Using boards on ESD protection stations is ideal. One can easily buy ESD plastic sheets for use on desktops. Certain carpets can #generate static easily; please be careful. Similarly, there are anti-static sprays you can use on carpets to reduce their propensity to generate static.

Power Starvation

The OLPC power supply is supposed to have (not yet verified by testing) enough power to power according to specifications, a single USB 2 port; it has three ports. So if you plug power hungry devices into the system, please make sure they are externally powered or interfaced via a powered hub. Conventional disk drives often draw too much power, particularly when being heavily used.

pre-A Reset

In the pre-A boards (not the large distribution we plan in June), resetting the board is a bit of a challenge.

1. Unplug the power supply from the board
2. You will find a little button on the *bottom* of the board (non-component side), which you must press.

The regular developer boards will come with a hard reset button.

Insyde BIOS Notes

The Insyde BIOS currently being used as we debug LinuxBIOS and bring up Linux, however, underwent minimal testing; our great thanks to Insyde for cooperating with the OLPC project and extremely generously donating several days of engineering to help bring up our boards, despite the lack of long term opportunity.

There may be some problems with certain hardware in the Insyde BIOS that will not be present when running Linux; you may find it expedient to try other hardware that interacts better with the Insyde BIOS. This should in no way be thought of as a reflection of the Insyde BIOS quality, just that the usual amounts of testing and timing adjustment it would have undergone are *not* present in the BIOS image we are currently using.

To configure the flash memory interface in the Insyde BIOS, follow the following sequence.

Enter CMOS setup: (Press F1 during POST)

1. C. Motherboard Device Configuration
2. -> A. Drive Configuration
3. -->Flash Configuration
   1. --->Flash Interface: Enabled
   2. --->Chip select 0 - size: 8K/16B
   3. --->Base: PCI default
   4. --->Type: NAND I/O

Linux BIOS Status

Linux BIOS is making progress on the boards, but not yet fully functional.

Software notes

Knoppix is known to "just work" when booting from CD; it does not correctly install onto disk (but then again, this is often true for the Knoppix CD).

Fedora Core 5 and Ubuntu Breezy have both been installed onto external USB disks and made to run. This is a challenge for two reasons:

1. the usual initrd does not currently include drivers for booting off of USB on either system.
2. there is a delay at boot time before you can access an external USB disk. So if the system tries to boot before the hardware is ready, the expected chaos ensues. Right now, Linux doesn't seem to have a great way to wait until a USB device is fully ready.

Fedora notes

Fixes for the above problems are being pushed upstream into Fedora.

Other Software observations

The JFFS2 file system is up on the flash, but not yet ready for use, as it does not yet support hardware ECC and other issues. Stay tuned. Dave Woodhouse has a Git tree where he does his work, for the truly adventurous. Please contact him before working on the driver as he is in the midst of heavy development himself.