XO-2

[C. Scott Ananian]

On 5/22/08, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> This is not only a cost problem, but also a big power drain problem.
>  Besides that, GPS and GALILEO are similar enough that some manufacturers
>  claim they can support both with a software update. If a machine is
>  sitting in a deep valley, getting enough satellites into view for even
>  an inaccurate a position fix is a real challenge with only one satellite
>  fleet. Of course, having GPS in a school server will allow kids to
>  locate themselves on a world map with reasonable accuracy. Not perfect,
>  but better than nothing.

GPS enables a lot of mapping and geography-related educational
activities, which is why it was originally considered for the XO-1.
It would probably (like the camera) only be powered on when being used
(although the long lock-on time might make this user-unfriendly).
Google Earth-like applications are fantastic for giving students a
sense of their place on the earth, and there's a lot of economic
possibility inherent in allowing kids to create better maps for their
local neighborhoods.  But, the time/cost was not ripe for Gen 1, and
it may not be for Gen 2 either.

>  >  h) hardware-protected RTC (bitfrost desiderata)
> I'd be very interested in the reasons for that. P_THEFT is still mostly
>  unimplemented for cost reasons. A hardware-protected RTC will not
>  improve the current state at all as long as the hardware side of P_THEFT
>  is not implemented. It will certainly raise cost, though.

Not the case: epoxy-coating the motherboard was not cost-effective,
meaning that the cost of bypassing P_THEFT by circuit-board changes
was already expensive enough to be infeasible -- and of course epoxy
adds to manufacture, repair, and rework costs.  The economics weren't
with it.

We actually know exactly how much it costs to bypass P_THEFT in bulk,
since some of original manufacture run ended up with a firmware bug
which bricked them in exactly the way P_THEFT would.

Hardware-protected RTC helps with the security of ongoing
theft-deterrence, which is orthogonal to initial activitation security
(which it seems you are discussing).  Contrary to your claim, initial
activation security is being heavily deployed and does seem to be
successful.

>  >  i) better protection for firmware FLASH, to avoid the possibility of
>  > bricking a machine if the power is removed at the wrong time.
>
> Protection for firmware flashing against bricking is easy if the flash
>  chip is big enough. OTOH, performing an update of EC microcode is a much
>  more difficult thing to protect against failure.

Yes, there were some design details with Gen 1 hardware that turned
out to make it difficult to safely reflash, even though the flash chip
is big enough to accomodate a backup OFW.  The EC is perfectly capable
of recovering OFW, but the EC memory map coincides with the erase
block size of the SPI flash, unfortunately, so there's a critical
window during which all of the EC code must be erased.  We hope to fix
that with Gen 2.

>  >  k) more open software: we may not need an EC, and if we do we may be
>  > able to ensure its code is open.  We may change the wireless device,
>  > and/or be able to switch to open firmware for it.
>
> I believe item k) was already in the contracts with Quanta and Marvell,
>  unless the official announcements back then were wrong. It has been
>  stated repeatedly by OLPC officials that the only thing preventing a
>  full open source wireless firmware is the lack of time for porting the
>  code to another embedded OS. There were also statements like "We are
>  working with Quanta to release EC source code", so I think that's also
>  mostly a problem with lack of time.

Yes, it was intended, but the production schedule and component
availability forced us to build on some pre-existing closed-source
components, and now that we've reached this point in the manufacturing
cycle for XO-1, we have very little leverage left with Quanta.  We did
make our best effort, but there were also some unforeseen interactions
with the manufacturing contract we signed with Quanta.  Quanta
designed the motherboard and took responsibility for making
modifications for manufacturability and to address defects, and now
they've ended up with significant IP rights in our schematic.  This
has made it hard to properly support the open EC effort, since by the
terms of the contract we can't even show them the pinout of the EC.
We recently hired Paul Fox as firmware engineer, so we're still hard
at work on this.  We hope that we can work out agreements with Quanta
to publish at least pinout information for the EC.  It's complicated
by the fact that most of Quanta's team working on the XO-1 design has
moved on to other projects now.

The http://www.open80211s.org/ effort is being funded by OLPC to try
to address the wireless firmware issue (among other goals).  I don't
really know what mesh solutions are being considered for XO-2, but
there are more vendors with 802.11s solutions now than there were when
we designed the XO-1, so we have more choices and leverage.
  --scott

-- 
                         ( http://cscott.net/ )