[OLPC-devel] System software minutes, 2006-08-15

[Mitch Bradley]

Minutes from System Software conference call, 2006-08-15

Present: Jim, Zephaniah, Mitch

Mitch added some stuff to the wiki based on his experiences trying to get
LinuxBIOS loaded into the ROM emulator.  It's all working now.

It's important to use a powered USB 2.0 hub.  Some of the flakiness around
USB devices is related to power scarcity on the OLPC board.

Zephaniah: basic UI stuff like run-time calibration and finger controller
controlling tablet, without relying on 7.2.  There is no good over the wire
comm mechanism for doing either without restarting the server each time.
Some changes are in the works from two different sources, but neither
will work in a 7.1 server.  The changes are being developed in the input
hot plug branch.  Some are Daniel's patches, some are being developed
by a collaboration between Zephaniah and Daniel.

Should we go to 7.2?  Doing additional x wire protocol stuff with the 
current
code is messy.

Is Daniel adding DBUS support?  The hot plug stuff will require DBUS for
device enumeration.  Some things may require both DBUS and the X protocol.

When to decide on 7.1 vs. 7.2?  Zephaniah doesn't see any good way to
do the touchpad changes in 7.1.  Calibration could be done with preset
values that could be tweaked.

No major complaints from Chris about the possibility of using 7.2 .  He was
more concerned about the new Python.

The other good thing about 7.2 is support for multiple core input devices.
Pivoting works sanely - important for keyboard case and useful for mouse 
case.


Discussion with Mitch about how to do bringup tests on CaFe.

Mitch proposes his usual bringup strategy, which is to interact with
the hardware via little snippets of Forth code, until the basic hardware
functions have been verified.  Then try a Linux driver and iterate.

The main line Linux kernel has a driver for the SD HCI interface.
We primarily need support for SD memory, as a way to extend the
laptop's mass storage capacity.  SDIO, MMC, and CE-ATA are much less
critical, so if we put off testing them and find problems too late
to fix them, we could just say they aren't supported.

The Camera interface is basically a DMA engine that streams pixel data
into system memory.  We also need code to set up the camera chip.  That
setup data is communicated over a TwoWire serial bus.  We have drivers
for similar predecessor camera chips.

The NAND FLASH software interface is very simple.  The diagnostic driver 
will
be trivial.

OLPC interviewed Andre Solomon - former Debian kernel maintainer.