[coreboot] Fw: Re: coreboot and embedded controllers, ?for example OLPC and its?OpenEC code

Jordan Crouse jordan.crouse at amd.com
Thu Jun 19 01:30:05 CEST 2008

This was sent to just me, but I think there is information here
that would be interesting to the group.

----- Forwarded message from Frieder Ferlemann <frieder.ferlemann at web.de> -----

From: Frieder Ferlemann <frieder.ferlemann at web.de>
Date: Thu, 19 Jun 2008 01:17:17 +0200
To: Jordan Crouse <jordan.crouse at amd.com>
Subject: Re: [coreboot] coreboot and embedded controllers, for example OLPC
	and its OpenEC code


Jordan Crouse schrieb:
> On 18/06/08 15:45 -0500, Ken.Fuchs at bench.com wrote:
>> What happened with the OLPC's OpenEC code?  Was that
>> ever completed?  Did the name change to something else?
>> Is it currently being developed?
> I'm not sure what the current status is, you may want to
> ask on devel at laptop.org.  As is often the case with

there is currently no active development done on OpenEC I'm afraid.

I jumped in to provide a framework which would allow for a GPL'ed
firmware for the Embedded controler in the XO of the
One-Laptop-per-Child project.

But it turned out I was the only one contributing code.
And having no access to up to date schematics and only a very
terse data sheet of the controller (and still nobody joining)
I felt I could not complete within the time-scale that
would matter for the OLPC project.

So for now OpenEC is not being worked on. But I think the project
(while in its early stages) is now adequately positioned as a
starting point for an Embedded Controler firmware.

Current status is best seen at:

> projects like these, there is no shortage of people
> eager to begin reverse engineering closed source firmware but few of 
> them stick around when they discover
> the complexity of the task at hand.

I knew before, just speculated on others joining:)

> In short, embedded controller code is dark magic.  You need
> detailed schematics of your board, a clear indication of the
> API that the BIOS requires, a JTAG debugger and a lot of time.
> If you think that coreboot is too platform specfic, then you haven't 
> seen anything yet.
> Aas far as coreboot is concerned, we just don't have access to
> information for any EC enabled platform that we might otherwise
> support.  The only platform we would come even close to being
> in the ballpark of supporting would be the OLPC, but even then
> we are missing the schematics and the hardware bits needed to
> flash the ROM.

OLPC is slightly better, there is a publically available
(but outdated (and only one page out of many)) schematic:

And flashing should not be a problem. At least for early XOs
this only requires rather straightforward hardware:

> What we need is a freely available EC chip that we can easily
> hack on without complex or expensive hardware.  Then the task will
> be to come up with a reasonable operating system to provide timers
> and provide a general platform for development.  Once you get to
> that point, then I think there is a real chance that an OpenEC solution 
> could win.  Until then, its going to be black hole that
> makes everybody cringe.

Yep, let's see what happens. OpenEC is GPL'ed so it is there
to stay and it is waiting for a slightly better chance than
OLPC turned out to be.

And OpenEC was written with portability in mind. While it
specifically targets an ENE KB3700 (with its 8051 based core)
the source is also compileable with gcc.


----- End forwarded message -----

Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.

More information about the coreboot mailing list