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

[Ken.Fuchs at bench.com]

Richard Smith wrote:

> OpenEC progress:  OpenEC has stalled because the necessary 
> information on sequencing 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.

Of course it is ODM Quanta that requires this NDA.  It may have
been better to have a completely open hardware design and thus
no NDA to hold open source firmware hostage.  I engineering
design group with no vested interest in manufacturing would have
been a better choice for the XO both for the open source
community and the flexibility in who/how/where it got manufactured.

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

I agree that the power management should be quite easy.  it seems
to me that a clever engineer could empirically observe the power
sequencing of the closed source code and modify the open source
code mimic that. Some board designs even simplify the tasks of
the EC to the point that the EC can actually be replaced by one
or more finite state machines in CPLDs

If OLPC made OpenEC a priority, it would be done already.

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

OpenEC is almost a requirement for to get coreboot working
properly on laptops.  It needs to run on all the commonly
used ECs and not jut one of them.

Sounds like the closed source embedded controller code is in
worse shape than Legacy, Commercial BIOS code. :)

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

No doubt that ECs will be showing up on non-laptop mainboards.

They can help fix seriously botched designs like when a well
known processor vendor released a new processor with a chipset
that lacked SPI bus support.  Considering that FWH is close to
EOL, the SPI NOR flash is the only viable option for firmware
storage.  So, the solution is an EC that translates all LPC/FWH
accesses into the corresponding SPI accesses to the SPI NOR
flash.  BTW, a CPLD can solve this too in the read-only case.
The write implementation would be too complicated for a CPLD
solution though. 

The EC is basically the cure all device.  It does all the work
that's too complicated for a dumb device and it can help fix
design problems as well as implement special key functions
and power management.

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

I have had many years of experience using Sun's Open Boot Prom
(OPB) which is really the same as Open Firmware used in later
PPC Apple machines and recently the XO.  Although I agree that
field debug and diagnostics in firmware was an extreme positive,
I always questioned the choice of the Forth language for its
implementation.  Something that more people used may have been
a better choice; like Hush shell that is used in U-Boot for
example.  Lots more people know how to do shell programming
than Forth programming.  As far as I'm aware, their aren't
many applications still using Forth.

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

Mitch Bradley of Firmworks had the elegant idea of replacing
LinuxBIOS on the XO with a little assembly language program
that simply stuffed the correct values from a table into the
appropriate chipset registers, thus emulating what LinuxBIOS.
However, it did so by making the hardware initialization code
both trivial and impossible to understand at the same time.
No doubt it was primarily done to save code space for other
things.

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

What is LAB?

Why would one be limited to a 8 Mbit part?  SPI NOR flashes
typically have larger capacities than parallel NOR flashes.
An 8MB (64 Mbit) part seems quite typical now for low cost
with room to expand.

> Hope this helps,

Yes, thanks for the long write up.  Unfortunately, even a
longer write up wouldn't really do the subject justice,
but I'd say you came close to the final word on many of
the topics, at least as far as the XO is concerned.

Sincerely,

Ken Fuchs