Notes on using the OLPC developer boards: Difference between revisions
DanWilliams (talk | contribs) No edit summary |
DanWilliams (talk | contribs) (explain PCB picture annotations) |
||
Line 14: | Line 14: | ||
== Hardware Notes == |
== Hardware Notes == |
||
See [[media:Img 2834.jpg|A-test |
See [[media:Img 2834.jpg|A-test Developer Board]] for a close-up picture of the A-test PCB. In this photo, (A) refers to the wifi antenna connectors, (B) to the reset button, and (C) to the serial board connector. |
||
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. |
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. |
Revision as of 21:17, 31 May 2006
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
The Developers Program has information on how to get developer's boards.
Hardware Notes
See A-test Developer Board for a close-up picture of the A-test PCB. In this photo, (A) refers to the wifi antenna connectors, (B) to the reset button, and (C) to the serial board connector.
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, and please file them there as well.
Note that if your board is a Pre-A test board (or one of the unlabeled early A-Test boards) the wireless will not be "canned". This causes the noise floor to be extremely high, as the reciever is out in the open where anything can interfere; as a result, those boards are unsuitable for more than basic driver testing, as their range will be measured in inches or a few feet. The labeled "A-Test" boards should come through canned. You will have to find antennae for the connectors on the board (note there are two antennae connectors. There are several suppliers of antennae available though the gain is wrong. Until/unless we can make better arrangements, you can buy antennae with the right U.FL connectors through Netgate or Connex Wireless.
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.
Types of Boards
- 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.
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. Please file bug reports to help others who may have similar problems.
To configure the flash memory interface in the Insyde BIOS, follow the following sequence.
Enter CMOS setup: (Press F1 during POST)
- C. Motherboard Device Configuration
- -> A. Drive Configuration
- -->Flash Configuration
- --->Flash Interface: Enabled
- --->Chip select 0 - size: 8K/16B
- --->Base: PCI default
- --->Type: NAND I/O
Note that LinuxBIOS, when we move to it, will always set the controller to bare flash.
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).
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, and you can expect unreliable results. This is not uncommon in laptops; engineering for worst case power consumption adds expense.
pre-A Reset
In the pre-A boards, resetting the board is a bit of a challenge.
- Unplug the power supply from the board
- You will find a little button on the *bottom* of the board (non-component side), which you must press.
The regular "A-Test" boards have a hard reset button on the top.
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:
- the usual initrd does not currently include drivers for booting off of USB on either system.
- 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. Rawhide is close to "just installing" onto a USB disk or flash on the machine, and this milestone is expected soon.
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.
Bug reporting
A bug tracking system is being established. If you suspect hardware trouble, please file a bug under product "OLPC Hardware", component "Pre A-Test" or "A-Test" as appropriate. A link to the bug reporting system will appear here very soon. Note that we may require you to return the boards for failure analysis: this is very important to us, and your help here may be essential to detect serious issues that should be fixed. We are holding back spares to enable us to ship out replacement boards for failed boards, to keep developers able to work. Mark hard failures as severe bugs. Please include serial numbers in bug reports.
Similarly, we'll establish a component for the BIOS. Do not expect any problems with the Insyde BIOS to be fixed, though as a courtesy to Insyde, who have been very generous, and to other developers who may run into problems using it, please file bugs against the Insyde BIOS as well.