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