BTest-1 Release Notes
Introductions and Expectations Setting
There is a major difference between the OLPC system and a conventional laptop of approximately five years ago; that is, our base system software is much more capable than it was then. The Linux environment now supports internationalization capability for scripts that were out of our reach then, and much higher quality rendering and, best of all, a much wider range of applications.
This has come somewhat at a cost, however: Moore's "Law" has allowed us to become sloppy, both in memory usage and CPU usage; this tends to force us to make some tough choices to keep the "footprint" of the software acceptable. The OLPC laptop have only 512 MB of storage (Flash), and probably the most serious limitation, 128 MB of RAM, and a single-core processor. Over the last year or so, the community has become much more sensitive to these issues, and work is well underway toward reigning in this "bloat" and performance work in general. Small is beautiful (and usually faster!).
Our base technology choices have been predicated on the ability of the software to achieve the best overall worldwide "user experience". This drove our choice of GTK+ and Pango (with Cairo as the graphical underpinnings), since Pango's abilities in complex scripts are currently most advanced of free software technologies. Other toolkits can be used: but they come at a cost in memory and flash footprint, and today, in the ability of software based on them to be localized to many of the scripts we face immediately, which include both Thai and Arabic. Including other toolkits as a standard part of our base system is therefore problematic, and experience on embedded systems show that including multiple toolkits would almost certainly cause the overall experience to suffer.
The Meaning of BTest-1
This is the beta test of fully functional hardware. The camera, SD slot and NAND flash are currently interfaced by an FPGA version of CaFE; the ASIC version will be available by BTest-2.
However, the software is alpha test.
Most of our effort to date has been consumed by basic device support as well as putting together the basic user interface framework for children, which has known performance problems. Major components are as yet not complete: power management and the wiki editing system to name two large components. Enough is now present to begin to sketch the outline of where we believe the children's software should go: enabling the construction of software in which children and teachers can easily collaborate is central to our vision. Children should not be passive receivers of "content" but creators as well.
We do not expect that the software is yet ready for trials with children: BTest-1 is aimed primarily at developers to become familiar with the hardware and to enable testing of both the hardware and software.
OLPC's Expectations of BTest-1 Users
Bug Reporting
Note that our process is a fully open one: in a "conventional" beta test program for a product, you would have been asked to sign a non-disclosure agreement, and not disclose any of the problems you might have, or even be aware of problems other beta testers might be having.
Beta test hardware means a much higher probability of hardware problems than production hardware. The design is just now being fully tested, which includes stress testing at elevated temperature, cold, vibration, shock, and humidity as well as many other tests. Components that are fine on paper, may not work well in practice, either by defects in the design of the components or in their use. The components themselves may be new, and have their own manufacturing problems to be resolved (e.g. the writing pad problem we note below). Errors can be made in assembly. Errors can be made in design or component selection. A particular lot of components may be defective. The purpose of beta test, particularly for a high volume product, is to discover these problems, long before volume production, analyze the failures completely, and, by understanding the root cause of each failure, be able to eliminate or prevent these problems in the production units. If you have a hardware problem, OLPC may ask you to return the machine for failure analysis.
We expect that you will enter new hardware and software problems you encounter into our bug tracking system, so that the problems can be tracked and resolved. While duplicate bug entries are inevitable, searching to see if the problem has already been reported will be very helpful to us. Problems cannot be fixed if we don't know what you encounter, or how often they are encountered; if you find clearly the same problem as some one else, it is still helpful to know how often it is occurring, or any additional details you know. Add such information to the bug reports. Err by too much reporting, rather than too little. Bugs are good. Each bug is much easier to fix now than later.
System Updating
When you receive the systems, and occasionally afterwards during beta test, the software and/or firmware (BIOS), may need to be upgraded. We expect that during deployment partial addition of local software and content or total replacement of the factory installed software will be normal. We are working to make this process as painless and error free as we can.
The BIOS (LinuxBIOS + OpenFirmware as bootloader), Linux itself, and the OLPC software stack were installed at the factory; however, this was more intended as testing and practice for later. In the time since we gave the system to Quanta for manufacturing until now, a number of key bugs have been fixed, support for non-US keyboards has been added, and quite a few other problems resolved.
Hardware
User's guide to the hardware
You are using a system during test, well before when you would have the opportunity to use a "normal" commercial product. This is to allow both hardware and software testing to start, since our system is significantly different than conventional laptops (e.g. the screen, power management, ruggedness), and will be used in very different environments. You will see "behind the curtain" (and be part of) the process that computer system manufacturers hide from you: the good, the bad, and the ugly process of hardware and software debug.
The picture on the right locates most of the features of the machine. To open the machine you must first unlatch the antennae and then lift it open.
To rotate the screen to transform to ebook mode, the screen must be in the 90% upright position. It can only rotate one of two directions to the point where the screen can again be closed down over the keyboard.
The battery pack is located under the screen underneath the keyboard, and is released by two slide latches as seen in the lower thumbnail. You can also see the SD slot clearly. Note: the plastic will be textured in later builds so the surface of the machine will not be shiny.
Hardware Specification
The BTest-1 systems were built with an extra 128meg of RAM, to partially make up for well known memory problems in key applications, in particular the web browser, based on Firefox's Gecko technology. Work is well underway to reduce the browser's footprint; some of this work is visible in Firefox 2.0. BTest-2 will be built with 128 meg of RAM total.
Note that the BTest-1 systems use an Altera FPGA to implement that CaFE ASIC (which interfaces the camera, NAND flash and SD slot), which will not be available until the BTest-2 build. This has allowed us to test the design of CaFE and to build early systems more than 6 weeks sooner. Using an FPGA has several consequences: the FPGA consumes considerable power, and it is relatively slow. CaFE's NAND flash controller, while several times faster than on the Geode's controller on ATest boards, is still very slow relative to what it will be when implemented as an ASIC; similarly the SD controller is also slow relative to its eventual performance, both due the limitations on the speed of the FPGA, and since high speed mode for SD is just now being implemented in the device driver.
The hardware specification is elsewhere in the wiki.
Hardware Release Notes
Our master list of hardware and mechanical issues and status can be found in the trac system we use. Please check this list before entering new issues: but please do enter issues you discover. The items below are the most significant from the list.
- Keyboard keys occasionally stop working, and sometimes the machine does not reboot.
- (ESD problem with the embedded controller.) One of the most irritating and noticeable problems is a static discharge problem that can lockup pins or entirely crash the embedded controller, causing some or all of the keyboard keys or touchpad to stop functioning. Power the machine off and on again to reset it (Note: you may need to remove and re-insert the battery to reset the EC completely). If your machine won't power on at all, remove the battery and make sure the machine is unplugged. Wait up to 10 minutes. We're not kidding; the EC takes very little power, and it can take a long time before everything has reset. Then replace the battery and plug it into the wall.
- The resistive sensor does not work
- (for use with a stylus for writing), due to a design flaw: The stylus pad area was disabled and should be fixed in BTest-2 machines
- The arrow keys ("game keys") cannot be distinguished from the arrow keys on the keyboard
- This will be fixed on BTest-2 system.
- Manufacturing data values are in the wrong order
- This will be fixed the first time we update the BIOS SPI ROM.
- Power management is as yet unimplemented
- Therefore you cannot suspend and resume the machine (yet).
- The battery charging algorithms have problems
- These will be fixed as part of BIOS updates, which include the code for the ENE embedded controller used to control battery charging.
- The screen is covered by a plastic film by mistake
- With care, it can be removed. Not every machine has this film and it is probably not worth the risk of damaging your machine to remove it if it is not really there to begin with. Better diagnostics will be posted ASAP.
Design Release Notes
The BTest-1 systems do not have textured plastic: this is intended for future builds.
- Other design issues are also under investigation
- Note that design is always an over constrained problem: it is often not possible to get every thing you would like in a design, though you can usually get most or all of what you value most.
Software
These are very early days for the OLPC software (alpha test).
Installation
How to upgrade the OS image
Upgrading the OS is currently a multi-step process. The first step is to obtain a USB disk, install an OS image to the disk, and boot the laptop off of the USB disk. Instructions for installing an OS image to the USB disk can be found here. Once the laptop has booted off the USB disk, the image that's on the laptop itself can be upgraded. Instructions for upgrading the internal OS image can be found here.
Manual updates to the BIOS and wireless firmware should happen automatically when using a new OS image.
Device Driver Notes
- The sensor input mode of the audio hardware is not supported in the audio driver of build 185
- The code for this awaits merging shortly.
- SD high speed mode is not yet supported in the driver in Build 185
- High speed cards themselves work fine, but will not get above 8MB/second transfer rate.
- Suspend/Resume not yet implemented
- This is up next on our agenda.
- Functional Wireless Driver
- The driver is functional, though still has issues, and it is still undergoing major work. The Marvell's wireless chip's boot2 code has yet to be deployed. The boot code on the Marvell wireless interface has previously caused serious USB problems; BTest-1 hardware can now reset of the device to stop the USB problems until the new boot2 code is well enough tested to be deployed.
- LED illumination driver needs writing
- We'd like this for BTest-2, if we can.
- Want interrupt on power/battery status change
- We have the embedded controller code for this, along with the lid-switch, and the ebook mode, but it isn't yet hooked up to the Linux framework, nor integrated into the UI.
X Window System
The X Window System does not yet support the RandR extension, (rotation of the screen).
If a console application manages to somehow modify the colormap, the system won't recover without rebooting the machine.
We are not happy with the behavior of the touchpad: how much of this is hardware and how much software remains to be determined. The writing (stylus) mode of the touchpad has been disabled in the BTest-1 units, as the hardware does not work properly and is being redesigned.
Much performance optimization work is possible, and awaits our time or volunteers to work on.
The X Window System Xvideo extension is supported in the X server; note that a slightly different colormap is loaded while video is playing to improve video quality; other colors in use may become slightly strange during this period.
- The keymaps for our initial set of keyboards are only installed when Build 185 is installed
- There are known issues with the keyboard descriptions. Thai-keyboard support only appears in builds 187+.
User Interface
Sugar
The "Sugar" user interface environment for children is in place. The OLPC Human Interface Guidelines should be observed when building or repackaging applications. Conventional human interface guidelines have been designed for first world office workers, and are totally unsuitable for children who are just learning to read in any part of the world. As young children are the many/most of the intended audience of our system, their needs are being met first.
Conversion of applications to function under Sugar is very straightforward and most applications can work with little change.
intent and goals
The core ideas: Activities, Not Applications; Presence is Always Present; Tools of Expression; and Journaling are detailed here.
Navigation, including the Zoom Metaphor and The Frame, is detailed here.
Release Notes
The Sugar activity launch has performance problems we are actively investigating. There are many user interface issues we intend to fix. Among the most notable issues are:
- Sugar seems to lock up with the frame out
- Pressing F5 allows the Sugar to unhang, and you can then launch applications again.
- Sugar needs a UI for controlling audio
- This needs to be written.
- Sugar presumes applications exit
- Usually, you can find some other way to cause an application to exit.
- Launching activities are slow
- This is under investigation.
- The timing of many of the user interactions, such as hover and the coming and going of the Frame are in need of fine-tuning.
Programming Sugar
Sugar Activity Bundles are explained in detail here.
Sugar interfaces
goocanvas
GTK+
Cairo
Pango/ATK
Activities
Web Browsing
Browser based on Xulrunner (Gecko engine used in Firefox).
No tabs
Does not ship with: Java or Flash
User experience has problems with pop windows, font size, Frame interfering with scrolling
Chat
Jabber-based client works (not pretty - but functional)
EToys
The EToys learning environment has been integrated into the Sugar environment, and you are encouraged both to visit the Squeakland site. Sugar EToys has information specific to EToys in our Sugar environment.
TamTam
The current TamTam is the first echo of a much more open-ended, collaborative, multiuser, music activity.
- TamTam doesn't seem to load all instruments initially
- Restarting TamTam solves the problem.
- The microphone ought to be controlled by TamTam itself
- You can use alsamixer in the meanwhile.
xbook
PDF viewer through the browser.
AbiWord
As a place-holder, a simplified version of AbiWord is provided, and efficient, light weight text editor. Some version of AbiWord will be included long term, at a minimum as a viewer, as AbiWord has the ability to read Microsoft .doc content well and there is a significant amount of web content in this form.
Terminal
The terminal (activity) does not appear on the Frame, but can be launched by typing Alt-Shift-F11. (F11 is found in the 3rd position from the left in the Volume Slider key).
Temporary placeholders and Missing Pieces
There is no user interface for controlling the audio input/output. The workaround right now is to use "alsamixer" in a terminal window.
There is no way to turn on/off the keyboard light: eventually it will be tied to Fn-space.
Our plans include a web server and wiki system and journal, with a simple what you see is what you get editor. These did not make BTest-1.
Backlight control
The backlight button on the bezel does not work yet, but the backlight can be controlled using F6 (dimmer) and F7 (brighter); F8 turns on color; F9 turns off color.
Video/Camera Player
The controls (brightness, hue, saturation) are not hooked up in the device driver or video player applcation in BTest-1 (build 185). The driver adding these controls to Alsa (the Advanced Linux Sound Architecture) will be merged in a build soon.
The camera is exhibiting more noise than expected in assembled units; whether this is hardware or software is to be determined.
We have used mplayer on the machine, but as it pulls in many dependencies, we put together a simple gstreamer based application for demonstration of the camera and video playing. Others have reported successful playback of videos and DVD's on the system, including RealNetwork formats and players.
The BTest-1 system does not have a LED to indicate if the camera or microphone is enabled. Such a LED will be present on a later system.
A camera application is under development.
Base system
OLPC Platform
Inventory of "permanent" packages Inventory of "debug" packages Inventory of "optional" packages (?)
Development environment
Languages - Logo, javascript, python Libraries Where to find source Internationalization/Localization
Other Multimedia Software
Other software that has been tested on the OLPC systems includes Adobe Flash, and Real's RealPlayer® and Helix player.
How to Contribute
dev.laptop.org
OLPC runs a development environment for hosting software and content development projects. As much as possible, we encourage you to do your development upstream in the original projects. However, some projects are OLPC specific, or need temporary development resources while being staged for our systems. An example is the Linux kernel tree where we maintain OLPC code before it is ready to submit to the main Linux kernel. This lets us easily share work on various aspects of the Linux kernel, while tracking Linus' tree reasonably closely, to aid in upstream submission of code.
We are happy to provide hosting resources on this system to those with OLPC related needs.
Source Code Management Systems
Since both the kernel and the X Window System use git as their development source code management systems, and we work on both, git is our SCM of choice. You can see the git trees hosted at dev.laptop.org.
The Fedora kernel is maintained at that project. For BTest-1 we are using a kernel from the olpc-2.6 tree, rather than a Fedora kernel. This may change at some future date.
Source RPMs for most OLPC-specific versions of code are also available from RedHat.
Bug Tracking System
OLPC maintains a bug tracking system called trac, which is also a wiki (though we discourage use of it as a wiki). To use it, you need to create an account for yourself. You can query it for open (or closed) bugs.
Wiki
The main public OLPC wiki is available for use to write about any ideas or efforts related to the project; or to categorize and develop content for the laptops. Some pages (prominently marked) are maintained by the core OLPC team. We prefer this wiki to the Trac wiki for most writing.
Pointers to Key Technology Organizations
OLPC depends on a number of key technologies and projects, including:
- Gnome
- GTK+ toolkit, Pango Text Layout Library
- Cairo Graphics Library
- X Window System
- Linux Kernel
- Gecko Rendering Engine of the Mozilla Foundation
- AbiWord word processor
- eToys
Contacts
The OLPC mailing lists cover a variety of topics.
General questions can go to info at laptop dot org
Snail mail please sent to: One Laptop per Child P.O. Box 425087 Cambridge, MA 02142 USA
IRC Chat
We primarily use IRC instant messaging, and can be found on irc.freenode.net, #OLPC and #sugar channels.