Notes on using the OLPC developer boards

Community Notes

The Getting involved in OLPC page has information about OLPC, mailing lists, project lists, and so on. Most of the hardware and driver discussions should take place on the devel list. If this becomes a problem, we'll split lists to finer topics as needed. There are a number of other OLPC lists on various topics (e.g. security, networking). OLPC Fedora distribution specific questions should go to that list.

The Fedora source repository has the Fedora distribution being developed for OLPC.

In general, work in the upstream projects whenever possible. Laptop.org is also able and willing to host projects, but we will get quite grumpy you ask to host projects that are effectively forks of other upstream projects without extremely good justifications.

Additionally, git repositories of drivers under development before they go upstream to Andrew Morton / Linus Torvalds are being hosted by Dave Woodhouse at git://git.infradead.org/.

Getting Developer Boards

A process will appear here in the next few days.

Hardware Notes

This is very early hardware: it has not yet 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 has been pretty solid. Please report suspected problems to the devel list. We'll establish a bugzilla component for tracking these problem reports.

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 anti-static (slightly conductive) bag, which you can leave the board on. 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 even more careful on carpeting, particularly in dry climates. Similarly, there are anti-static sprays you can use on carpets to reduce their propensity to generate static.

The board plugged in is much more protected than when it is not. Touch nearby objects first to discharge any static. Touch one of the ground plane points on the board before touching other parts of the machine (e.g. the reset button). If you follow these guidelines, you are unlikely to have static related problems.

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, 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 "A" or alpha developer boards have a hard reset button on the top.

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 or ready to install; this is expected to change soon. Watch this space for more information (or the devel list).

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

Full Fedora Core 5 and Ubuntu Breezy releases have both been installed onto external USB disks and run; there are problems installing Linux you may want to be aware of. There are (at least) 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, and will be ready for use soon. 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.