Contributors program archive

OLPC Developer's Program

Background

We've had approximately 500 developer boards built, to jump start serious development in the free and open source software community and the initial deployment countries. Quantities of this generation of boards is limited as we do not have production test fixtures. Note that these are bare printed circuit boards. Packaged machines will not be available until this fall.

Note that machines from this build are also being allocated to launch countries and do not come under this program, which is aimed at individual FOSS developers or research organizations.

Board Types

There are a number of board types in the wild:

• 30 Pre A-Test PCB, which have been built and distributed.
• 20 A-Test PCB's, which have been built and distributed.
• 485 A-Test PCB's, which have been built and will be distributed through Brightstar. These can be distinguished from the first 50 boards in that they have real serial number bar codes on them.

Note that these boards lack DCON chips, and instead come with a standard VGA connector. We expect that production boards may ship with pads for VGA connectors, but no connector. Additionally, the Pre A-Test PCB have populated mini-pci connectors. The A-Test boards, these mini-pci connectors have been left off, but the pads are included and will probably be included on production boards. We want the same electronics to be as flexible as possible, so long as it does not increase cost of the units.

The A-Test PCB's include a socketed ROM chip for BIOS development, though this socket will not be on production boards. You will note these are empty; the BIOS is now stored in the serial flash chip that is interfaced via the embedded controller. Note that the process for updating the serial flash under Linux is not yet available and at the moment involves booting DOS and updating the flash chip using a utility from Quanta. Unless you are directly involved in BIOS development, you should stear clear of BIOS updates until/unless instructed by responsible people working on behalf of OLPC.

At this time, the hardware is all believed to work (having been tested), but not all drivers are working properly under Linux. The audio driver is having trouble, for example.

See: Notes on using the OLPC developer_boards.

Setting Expectations

Expect to get a box with:

1. one bare OLPC A-Test board, in a static protective bag, with static warning, with serial number both on the box and on the board.
2. one power supply brick (U.S. plugs), 15 watt capacity. Note that Sony power bricks should also work fine, and that if you can find the connector (the Sony appears compatibile) you can use many different DC voltages.
3. RS-232 cable adapter to DB9 connector for serial console use and debugging

Do not expect:

1. Monitor or flat panel
2. disk, DVD, CD or USB drives
3. keyboard or mice
4. powered USB hubs that may be needed for use with some peripherals
5. USB ethernet adaptors
6. other input devices

We expect you have or can acquire these locally.

Hardware Schedule

In this first generation of boards, which we call A-Test boards, the hardware is fully functional except that video is VGA out, rather than using a flat panel with the DCON chip we're building, which won't be available for some months.

There will be B-Test boards sometime in August, we expect, at which time we will have production tooling and test fixtures, so quantities could easily be much larger. Note that there won't be serious limits on how many beta test boards we can make, and therefore, if funding of manufacturing can be arranged, larger scale experiments may make more sense then. These will be beta test boards (except for the DCON chip, which we won't have until September); there will be a very few Xilinx stand-in's for the DCON chip on a few boards for graphics developers.

Packaged machines in production quality molded plastic are expected in October. This is the point at which experiments with children start to make serious sense.

Goals

Our goals will vary as the hardware matures. For the A-Test boards right now, we need the most help on:

• device drivers, and power management in the drivers: for us, every joule matters, and a simplistic "oh, we mostly have most of a chip turned off, maybe" isn't good enough. We want to know that every possible power savings has been realized, and that suspend/resume is rock solid.
• fast suspend/resume: We may very well have to go beyond the current state of the art as discussed at the power management summit.
• display driver: we must convert from an XAA to EXA driver for the X Window System.
• variable speed display driving: (aka: mode change on the fly).
• fbdev driver for the machine: fbdev exists for the GX1 and LX, but we need an LX2 version. AMD has started work here. We'll need to finish this up, and also support the DCON chip.
• input driver: we have a novel, dual mode pointing device, which needs support in the window system and applications. And besides the built in pointing device, we'd like to ensure that common USB HID input devices work well. This may be the point when conversion to evdev may make the most sense, if we can support common HID input device classes. After all, we lack any sort of a serial port, short of a USB to serial converter.
• file system: for first shipment. Dave Woodhouse is improving on its existing performance and memory usage. Additionally, there is work underway at some large computer vendor for a third generation flash file system, though it is unlikely to be ready in time for initial shipment, we would like to be able to convert to it in a timely fashion, only possible if we have good first hand experience with it and it gets good testing.
• wireless: we will be deploying mesh networking. Serious experimentation in this area is in order, to shake down the drivers and to gain experience in its behavior in differing conditions (e.g. rural areas with low noise characteristics; busy metropolitan areas). We understand that to do serious tests, more than a single board will be needed. Please be realistic in your expectations: two boards is not interesting; two hundred boards can't be provided.
• compiler optimization: if you are a compiler wizard, we understand that the Geode lacks a specific back end code scheduler, which limits performance, particularly FP performance. We'd love to see work go on in this area which would help everyone.
• codec optimization: we're sure there is room to be gained on performance here that may be Geode specific. Remember that CPU cycles and memory references (particularly memory references to main memory) translate to power consumed.

You can contribute in many areas which do not require hardware. For example:

• memory usage: many applications and toolkits waste and/or leak memory. Fixing these will help everyone and most easily done on conventional systems.
• performance optimization: fixing memory usage will usually result in faster code.
• toolkit adaptation: the display's effective resolution will change from grayscale to color made and back. Toolkits and applications need to be able to adapt, and themes that work well in both modes verified.
• UI: most of the user interface work can be done today on conventional Linux desktops. But our system will also have an e-book mode, with dual 4 direction keys and enter. Key applications will need updating to work well in this environment (e.g. evince, web browser). Testing application's behavior under grayscale conditions and making whatever changes are needed would be helpful.
• Applications: goes without saying. The "sugar" environment under development can be run on conventional desktops.

We will give preference for A-Test hardware to proposals that require access to the OLPC hardware to make progress. At this time, we do not know exactly where the line will be drawn, so we are interested in seeing what everyone is interested in doing.

Qualifications

We're looking for people able and interested in helping in development. The qualifications needed depend strongly upon where you are interested in working: for example, people working on BIOS/boot paths should be seriously "friends of the electrons", and not scared of JTAG and similar kinds of debugging.

Most driver work takes normal driver debugging skills, though getting power management right can be more challenging than most driver development.

Window system development requires X experience, and so on.

Idle machines

If you no longer have time to contribute to the OLPC effort, please be so kind as to return your board for redistribution.

How to apply

Please send Jim Gettys email with the following information:

1. Name
2. Email address
3. Employer
4. Country (for customs purposes)
5. Description of your plans for the machine(s)
6. Quantity of machines desired
7. Description of your experience, both with hardware and software

Presuming your request is approved, a mail message will be sent to you with a URL and a code. Visit that URL and enter your shipping information and the code(s) authorizing the machine(s).