[coreboot] coreboot and embedded controllers, for example OLPC and its OpenEC code

[Richard Smith]

You guys will have to forgive my tardyness.  I barely keep up with my 
mail load at OLPC so the coreboot list tends to get neglected.  I'm a 
good month or 2 behind on reading the list.

As OLPC's EC guy I feel I should probably comment on this thread. :)

OpenEC progress:  OpenEC has stalled because the necessary information 
on sequenceing the voltage regulators to turn on the main CPU can only 
be found in the closed source EC code and in the schematics.  Things 
which are only available to people under NDA.   It saddens me because I 
could have OpenEC powering up an XO in a matter of hours but I can't 
contribute to the project cause I'm tainted by my access and involvement 
with the proprietary code.

OpenEC quality:  Trust me when I tell you that the greatest thing that 
could ever happen to PC embedded controller code is a new clean open 
base.  The code I work with literally has _decades_ of legacy cruft in 
it.  Its fragile.  Balsa wood fragile.  I still don't understand what 
60% of the keyboard handler code is for.  Its 60k (C code size) of 
nested if() else()'s and messing with it breaks it in all sorts of 
strange ways.
An interesting note is the the KB3700 is very, very similar to the 
KB3920 and the 3920 was/is used on a _lot_ of laptops.  A working OpenEC 
would go a long way toward getting coreboot on a laptop.

Interaction of coreboot and the EC:  On the XO OWF has to issue commands 
to the EC to read the game buttons.  Depending on what buttons are 
pressed the firmware does different things.  This is completely platform 
specific.  On a straight plane Jane system coreboot would never know the 
EC is there but you add some special platform stuff and I think there 
will always be some sort of interaction between the firmware and 
coreboot.  Will more special stuff start showing up on PC motherboards? 
I Dunno.

Replacement of LinuxBIOS with OFW:  Many moons ago when this happened I 
said I was going to write up all the whys.  But I never did. My bad. 
/me smacks self.  So I'm not surprised to see various bits of 
speculation as to why.  As one of the decision makers for this switch 
I'll summarize.

The absolute top reason was for field debug and diagnostics.  I've head 
the FORTH folk mention this a few times but now having lived it for 
almost 2 years I grok. There is no substitute for having a low level 
simple yet powerful interpreter when you are debugging hardware level 
problems.  I use it daily.  Now before a FORTH is/is not flame war 
ensues note that this is not FORTH specific. An embedded BASIC 
interpreter or other some such would work too.  FORTH is just one such 
interpreter that fills this roll very nicely.

Everything else was secondary.  We could have coded around all the other 
issues we had with LinuxBIOS [1] it would have just taken time and 
effort.  OFW also had some other nice features that we got for free by 
switching but that was mostly icing.  A lot of those type features are 
now in V3.

[1] One area where this was not strictly true was size. Using LAB we 
were pushing the limit of the 8 Mbit part and still had to integrate the 
wireless firmware.  Dropping the VSA would have helped but I'm not sure 
if it would have been enough.  The larger size directly translated into 
a longer firmware boot time due to the extra data we had to uncompress.

Hope this helps,

-- 
Richard A. Smith
smithbone at gmail.com