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

[Ken.Fuchs at bench.com]

To simplify the discussion, let's restrict EC to those
used in laptops.  Here is a description of the embedded
controller paragraph in the OLPC from the URI
http://wiki.laptop.org/go/Power_Management.

Assuming the specific processor and embedded controller
could be replaced by others, this is the definition of
an embedded controller that coreboot must deal with to be
taken seriously in the laptop or mobile computing markets:

>  Embedded controller
>
> The embedded controller, an ENE KB3700: Image:KB3700-ds-01.pdf,
> is used to charge the battery, emulate various legacy devices
> (e.g. PS/2), add more GPIO pins (since the Geode does not have
> enough pins, some signals have to be routed through the EC),
> boot the system (the SPI flash used to store the firmware is a
> serial ROM attached to the EC), wake up the system under
> various circumstances, and other miscellaneous functions.  The
> EC specification contains detailed information about the
> commands and protocol used to communicate with the EC. A number
> of buttons (game pad and buttons, etc.), are interfaced to the
> EC, and also generate scan codes as though they were keyboard
> keys, to simplify the programming interface. SCI events are
> also generated at times to inform the CPU of events, so that
> the XO-1 can avoid polling interfaces that would otherwise
> require periodic wake ups.
>
> See also OpenEC

Note that such an EC will be running prior to the processor.
As stated above it monitors several devices, processor and
board signals and activates some in response.  It may also
have about a hundred processor initiated commands that it
executes (http://wiki.laptop.org/go/Ec_specification).

------

> > > Jordan Crouse wrote:
> > > > When done right, the embedded controller will be transparent to
> > > > coreboot.
> > 
> > How common is that in your experience?

Jordan Crouse wrote:
 
> Very common.  But I have to qualify my answer - when I say 
> transparent, 
> I don't mean that there might not be special registers implemented
> by the embedded controller for that particular platform.
> 
> What I mean by "transparent" is that it shouldn't matter to coreboot
> if the embedded controller is running OpenEC or a proprietary version.
> It should look and feel the same.

It might be possible that coreboot can avoid accessing the EC
in the case that nothing needs to be initialized after a power
on/reset event until the payload is loaded.  However, coreboot's
payload at a very minimum must be able to handle the EC and the
EC's devices.

When the power button is pressed, the EC will turn on the
appropriate power planes, wait for while, release the processor
from reset.  Next, the EC will wait for an LPC read, access its
SPI NOR flash for the required data and place the data on the
LPC bus and repeat.  coreboot may need to communicate with the
EC to initialize devices it controls.  When the firmware boot
completes, it may be necessary to command the EC to go into
a run mode.  Note that we may have to deal with poorly
designed/implemented proprietary EC code, so some unnecessary
handshaking between the processor and the EC may be required.

> > On Thu, Jun 19, 2008 at 03:55:53PM -0500, bari wrote:
> > >
> > > To develop open firmware for embedded controllers that oem's and
> > > odm's will use in new designs in the future?
> > > 
> > > I understand why someone that enjoys tinkering with laptops and
> > > servers might like this. I'm not sure that the odm's and 
> > > oem's will
> > > be interested in an open solution unless it is very 
> > > stable and very
> > > well supported.

I agree that the EC code must be extremely stable, since it
must handle many critical laptop devices like SPI NOR flash,
power management (sleep/standby/resume), battery charging/status,
and maybe thermal management, in addition to the non-critical
PS/2 and keyboard devices.

For laptops, ODMs like Quanta are exactly the companies that
must be convinced that open source EC code is better than IBV
written EC code.

Why is open source EC code important for coreboot?  Well, for
all mainboards with an embedded controller, coreboot with an
appropriate payload(s) would not constitute a complete open
source BIOS/firmware when the EC still contains proprietary
code.

> On 19/06/08 23:07 +0200, Peter Stuge wrote:
> > 
> > Well there's still the binary blob problem.
> > 
> > If the EC has it's own firmware then coreboot just needs to know how
> > to cooperate with it, but for ones where EC firmware is 
> stored in the
> > BIOS flash - there's a bit of a problem with coreboot..
> 
> Let us be careful with definitions.  None of these things are problems
> with the coreboot code itself, but rather with the management of the
> ROM in general.  And yes, we have problems with figuring out ROM
> partitioning and management, but we are working on those.

I'm not sure it is that clear cut.  If a mainboard contains
an EC (open source or proprietary), coreboot may have to
handle it similar to any other ancillary chip (such as a
SuperIO) that is required to boot.  It could be something
that can be delayed and handled later by a payload, but the
EC may not necessarily be ignored by coreboot without at
least some lost of functionality.

------

OpenFirmware & OLPC:

I heard that LinuxBIOS was replaced by Firmworks' OpenFirmware
due to the resume being too slow.  Here's an interesting
interview with Firmworks' Mitch Bradley that is primarily
about the OLPC and firmware, but doesn't say much about the
EC code, expect that it was proprietary and the source of
many problems that were far more difficult simply because
the EC source code was closed.

http://howsoftwareisbuilt.com/2008/03/27/interview-with-mitch-bradley-fi
rmware-olpc/

I highly recommend this interview, especially starting with
the first question regarding OLPC through the end.

Sincerely,

Ken Fuchs