XO-2

[John Watlington]

On May 22, 2008, at 11:01 AM, C. Scott Ananian wrote:

> 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.

Probably not.   Remember the accusations that we already
HAVE a GPS unit in the XO, and are using it to track everybody...
Would we have to have a hardware-only light that indicates that
the GPS unit has been used to locate the laptop ?

>>>  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/ )
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel