Embedded controllers are being put on mainboards to add functionality that the chipset and other support chips can't easily provide. The most common application is keyboard handling on laptops. Another example is the embedded controllers added to servers for various management features. Embedded controllers seem to be showing up now for many Intel PC board designs for such things as power management and LPC to SPI interfacing to support SPI NOR flash booting of the BIOS/firmware.
I'm looking for an open source micro-controller project that could be adapted to for use on PC embedded controllers as described above.
What happened with the OLPC's OpenEC code? Was that ever completed? Did the name change to something else? Is it currently being developed?
Is there a viable alternative to OpenEC for embedded controller code? Will it work with coreboot or appropriate payloads?
Any comments regarding coreboot and embedded controllers?
Sincerely,
Ken Fuchs
On 18/06/08 15:45 -0500, Ken.Fuchs@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@laptop.org. As is often the case with 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.
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.
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.
Jordan
Hi,
Jordan Crouse schrieb:
On 18/06/08 15:45 -0500, Ken.Fuchs@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@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: http://wiki.laptop.org/go/OpenEC
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: http://dev.laptop.org/attachment/ticket/477/SCHEMATIC1%20_%2012%20--%20EC%20...
And flashing should not be a problem. At least for early XOs this only requires rather straightforward hardware: http://wiki.laptop.org/go/Image:Serial_adapter.jpg
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.
Greetings, Frieder
Just a little tidbit..
On Thu, Jun 19, 2008 at 01:22:47AM +0200, Frieder Ferlemann wrote:
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.
Me and Uwe ran into a desktop board with this SMSC superio..
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.
The superio included an 8051. The 8051 did not have it's own program memory, it's program was stored in the BIOS flash.
When the board powered up, only the 8051 was running. It needed software to do some stuff, and only then could it negotiate release of the main CPU reset.
We found some PDF files and it did seem within our reach to get the 8051 to at least power up the CPU, but it was the heart of the superio, so I believe most superio functions would be unavailable until there was more 8051 code.
Not so much fun.
//Peter
Hi Peter,
Peter Stuge schrieb:
Just a little tidbit..
On Thu, Jun 19, 2008 at 01:22:47AM +0200, Frieder Ferlemann wrote:
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.
Me and Uwe ran into a desktop board with this SMSC superio..
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.
The superio included an 8051. The 8051 did not have it's own program memory, it's program was stored in the BIOS flash.
When the board powered up, only the 8051 was running. It needed software to do some stuff, and only then could it negotiate release of the main CPU reset.
This seems close to the EC on the XO.
We found some PDF files and it did seem within our reach to get the 8051 to at least power up the CPU, but it was the heart of the superio, so I believe most superio functions would be unavailable until there was more 8051 code.
On the XO both the host CPU (Geode) and the EC could access special function registers (those which were mapped into xdata space on the EC). (Access to these registers was later switched off for the host CPU due to security implications)
Out of curiosity, which SMSC superio was it?
Greetings, Frieder
Hi,
On Thu, Jun 19, 2008 at 08:40:32AM +0200, Frieder Ferlemann wrote:
Me and Uwe ran into a desktop board with this SMSC superio..
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.
The superio included an 8051. The 8051 did not have it's own program memory, it's program was stored in the BIOS flash.
When the board powered up, only the 8051 was running. It needed software to do some stuff, and only then could it negotiate release of the main CPU reset.
This seems close to the EC on the XO.
We found some PDF files and it did seem within our reach to get the 8051 to at least power up the CPU, but it was the heart of the superio, so I believe most superio functions would be unavailable until there was more 8051 code.
On the XO both the host CPU (Geode) and the EC could access special function registers (those which were mapped into xdata space on the EC). (Access to these registers was later switched off for the host CPU due to security implications)
Out of curiosity, which SMSC superio was it?
The SMSC FDC37N958FR, a datasheet is on the web. See http://www.coreboot.org/Dell_Latitude_CPi_A366XT_Build_Tutorial for some more (but not too many) details.
HTH, Uwe.
Hi,
Uwe Hermann schrieb:
The SMSC FDC37N958FR, a datasheet is on the web. See http://www.coreboot.org/Dell_Latitude_CPi_A366XT_Build_Tutorial for some more (but not too many) details.
That one looks interesting - I did not expect the 8051 to be able to f.e. take over full control of the PC's parallel port!)
While control over the parallel port today probably only has some geek value it shows to me that some _serious_ tasks would have been possible with this (probably around 2001) hardware without switching on the main CPU. Likely the 8051 of that very hardware has comparable CPU power to early 198x home computer hardware. Not too bad!
This 2001 potential is simply not used / is not available to users of a 2008 (TwoThousandAndEight) PC or notebook. A rather long time in tech terms.. Worse: To my experience nowadays user is not even likely to be able to control what the system fan does. (Hmm, I admit this statement relates to my limited experience with a pretty recent Gigabyte AM2+ board.)
The disparity of the potential of the Embedded Controller and the things the user can actually do with it is (IMHO as things currently are) only bound to grow.
There are high hurdles to be taken but given this growing disparity at some point in time an Open Source EC simply _is_ attractive.
Greetings, Frieder
On Fri, Jun 27, 2008 at 01:02:18AM +0200, Frieder Ferlemann wrote:
Worse: To my experience nowadays user is not even likely to be able to control what the system fan does.
I think you may find this interesting: http://forum.thinkpads.com/viewtopic.php?t=20958
//Peter
On Fri, Jun 27, 2008 at 01:02:18AM +0200, Frieder Ferlemann wrote:
That one looks interesting - I did not expect the 8051 to be able to f.e. take over full control of the PC's parallel port!)
This is used to recover from bad BIOS flash using a floppy drive btw.
//Peter
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,
On 17.07.2008 07:58, Richard Smith wrote:
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.
So you'd have been happy with LLShell and RemoteBIOS. There are great tools available, the biggest problem is that nobody knows about them.
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.
Do you have any remaining features missing from 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.
Assuming 2 MByte/s throughput, dropping the VSA saved only 15 ms load time. Even the whole Linux kernel shouldn't have needed more than 1 second for loading and uncompressing. About the size problem: The 32k or so needed for the VSA are not really a blip on the radar compared to a full Linux kernel. The kernel itself is pretty massive, though, but that's what you get if you want decent hardware support. Fixing OFW to boot properly from all devices (USB disks, SD cards) supported by Linux is still ongoing AFAICS. It would be nice to have an embedded Linux variant which is small enough to be compressed into 512k, though.
Regards, Carl-Daniel
On Thu, Jul 17, 2008 at 5:03 AM, Carl-Daniel Hailfinger It would be
nice to have an embedded Linux variant which is small enough to be compressed into 512k, though.
Thats's easy. It's called 2.2 :-)
Thanks to Richard for the note!
ron
Carl-Daniel Hailfinger wrote:
interpreter or other some such would work too. FORTH is just one such interpreter that fills this roll very nicely.
So you'd have been happy with LLShell and RemoteBIOS. There are great tools available, the biggest problem is that nobody knows about them.
I remember LLShell from way long ago. At the time it was far too simplistic to compare with the likes of a forth engine. I've heard mention of RemoteBIOS but not looked at it.
Do both of these systems support looping & branching constructs?
For a real world example take a look at my batman.fth script. http://dev.laptop.org/~rsmith/batman.fth Even if you don't read much forth you can get a feel for the level of coding neeed.
batman.fth has been a life saver for me and OLPC's battery problems. Its possible that I could have written a userspace C program that did the same things as batman, but batman bitbangs the EC's 1-wire pin and the timing is very tight. I'm not sure I could get the microsecond level timing from userspace. Then I would have to have resorted to kernel level code which would have been icky.
free by switching but that was mostly icing. A lot of those type features are now in V3.
Do you have any remaining features missing from v3?
I don't know. I've not used v3 yet. I'm just going off of what I see in the mailing lists with the dt stuff, simplified build structure and LAR.
Assuming 2 MByte/s throughput, dropping the VSA saved only 15 ms load time. Even the whole Linux kernel shouldn't have needed more than 1 second for loading and uncompressing.
Using LAB there was a considerable delay so we must have not been anywhere near 2Mbyte/s.
About the size problem: The 32k or so needed for the VSA are not really a blip on the radar compared to a full Linux kernel. The kernel itself is pretty massive,
Yeah. Like I said we were _really_ close. That 32k might have been just enough.
though, but that's what you get if you want decent hardware support. Fixing OFW to boot properly from all devices (USB disks, SD cards) supported by Linux is still ongoing AFAICS.
There's 2 sides to that story. OFW talks to my Motorola razor phone mass storage fine yet my Ubuntu Hardy Laptop and Debian home system (2 different kernels) throw errors and bail.
OLPC's implementation tries to be optimized for speed rather than broad hardware support. Any device that's standards compliant works fine. You never hear about the 95% of devices that Just Work. Its the 5% funky non-standard ones that make all the noise.
And just because the kernel has broad support for various funky pieces of hardware does not mean using them is was without difficulty. Under LAB it was difficult for the userspace programs to know when the device was ready for use, properly mounted and what /dev/<bla> it was.
On 17.07.2008 19:17, Richard Smith wrote:
Carl-Daniel Hailfinger wrote:
interpreter or other some such would work too. FORTH is just one such interpreter that fills this roll very nicely.
So you'd have been happy with LLShell and RemoteBIOS. There are great tools available, the biggest problem is that nobody knows about them.
I remember LLShell from way long ago. At the time it was far too simplistic to compare with the likes of a forth engine. I've heard mention of RemoteBIOS but not looked at it.
Do both of these systems support looping & branching constructs?
I haven't worked with LLShell yet, but RemoteBIOS seems to support looping and branching.
In v3, you get the additional freedom to create a "module" loaded over serial which is linked against the existing in-ROM stuff and can contain arbitrary code.
For a real world example take a look at my batman.fth script. http://dev.laptop.org/~rsmith/batman.fth Even if you don't read much forth you can get a feel for the level of coding neeed.
batman.fth has been a life saver for me and OLPC's battery problems. Its possible that I could have written a userspace C program that did the same things as batman, but batman bitbangs the EC's 1-wire pin and the timing is very tight. I'm not sure I could get the microsecond level timing from userspace. Then I would have to have resorted to kernel level code which would have been icky.
With a coreboot module/payload/stage (whatever you want to call it) the timing constraints should be easily satisfiable.
free by switching but that was mostly icing. A lot of those type features are now in V3.
Do you have any remaining features missing from v3?
I don't know. I've not used v3 yet. I'm just going off of what I see in the mailing lists with the dt stuff, simplified build structure and LAR.
OK. If you have the time to use v3, please keep in mind that it's flexible and additional features can still get added.
Assuming 2 MByte/s throughput, dropping the VSA saved only 15 ms load time. Even the whole Linux kernel shouldn't have needed more than 1 second for loading and uncompressing.
Using LAB there was a considerable delay so we must have not been anywhere near 2Mbyte/s.
Hm. I recall these problems, but I never had the time to measure where all the time was spent. The biggest problem was using SPI instead of LPC for flash. That reduced throughput to 1/8 or so.
About the size problem: The 32k or so needed for the VSA are not really a blip on the radar compared to a full Linux kernel. The kernel itself is pretty massive,
Yeah. Like I said we were _really_ close. That 32k might have been just enough.
though, but that's what you get if you want decent hardware support. Fixing OFW to boot properly from all devices (USB disks, SD cards) supported by Linux is still ongoing AFAICS.
There's 2 sides to that story. OFW talks to my Motorola razor phone mass storage fine yet my Ubuntu Hardy Laptop and Debian home system (2 different kernels) throw errors and bail.
That would be a bug. Did you already report it?
OLPC's implementation tries to be optimized for speed rather than broad hardware support. Any device that's standards compliant works fine. You never hear about the 95% of devices that Just Work. Its the 5% funky non-standard ones that make all the noise.
And just because the kernel has broad support for various funky pieces of hardware does not mean using them is was without difficulty. Under LAB it was difficult for the userspace programs to know when the device was ready for use, properly mounted and what /dev/<bla> it was.
Every solution has its drawbacks. Personally, I prefer broad hardware support, as long as it is possible to work around usability issues in userspace.
Regards, Carl-Daniel
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
Peter Stuge wrote:
Just a little tidbit..
On Thu, Jun 19, 2008 at 01:22:47AM +0200, Frieder Ferlemann wrote:
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.
Me and Uwe ran into a desktop board with this SMSC superio..
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.
The superio included an 8051. The 8051 did not have it's own program memory, it's program was stored in the BIOS flash.
When the board powered up, only the 8051 was running. It needed software to do some stuff, and only then could it negotiate release of the main CPU reset.
We found some PDF files and it did seem within our reach to get the 8051 to at least power up the CPU, but it was the heart of the superio, so I believe most superio functions would be unavailable until there was more 8051 code.
Can you provide more details? Such as exactly which SMSC SuperIO? What was the embedded controller used for? Just perform basic SuperIO functions or something more? Which desktop board? Which processor and chipset?
coreboot needs to have a solution/framework/interface for dealing with embedded controllers. The trend seems to be that mainboards will have more of these as time goes by. For existing boards, coreboot may be able to load the existing embedded controller code, but for new designs with coreboot firmware, the embedded controller code will have to written from scratch and obviously will require a toolchain and debugging tools.
Here's a few resources that may be useful for working with EC (especially 8051/MCS 51):
http://www.8052.com/tutorial.phtml
http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51/
http://en.wikipedia.org/wiki/Intel_8051
Sincerely,
Ken Fuchs
On 19/06/08 15:23 -0500, Ken.Fuchs@bench.com wrote:
coreboot needs to have a solution/framework/interface for dealing with embedded controllers. The trend seems to be that mainboards will have more of these as time goes by. For existing boards, coreboot may be able to load the existing embedded controller code, but for new designs with coreboot firmware, the embedded controller code will have to written from scratch and obviously will require a toolchain and debugging tools.
When done right, the embedded controller will be transparent to coreboot. If you need a solution / framework / interface for dealing with custom embedded controller code, then the openEC project isn't doing a very good job.
Jordan
Jordan Crouse wrote:
On 19/06/08 15:23 -0500, Ken.Fuchs@bench.com wrote:
coreboot needs to have a solution/framework/interface for dealing with embedded controllers. The trend seems to be that mainboards will have more of these as time goes by. For existing boards, coreboot may be able to load the existing embedded controller code, but for new designs with coreboot firmware, the embedded controller code will have to written from scratch and obviously will require a toolchain and debugging tools.
When done right, the embedded controller will be transparent to coreboot. If you need a solution / framework / interface for dealing with custom embedded controller code, then the openEC project isn't doing a very good job.
Exactly!
What is the ultimate dream here? To develop replacement open firmware for existing embedded controllers that have been used for years mainly in laptops and servers?
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.
-Bari
On 19/06/08 15:55 -0500, bari wrote:
Jordan Crouse wrote:
On 19/06/08 15:23 -0500, Ken.Fuchs@bench.com wrote:
coreboot needs to have a solution/framework/interface for dealing with embedded controllers. The trend seems to be that mainboards will have more of these as time goes by. For existing boards, coreboot may be able to load the existing embedded controller code, but for new designs with coreboot firmware, the embedded controller code will have to written from scratch and obviously will require a toolchain and debugging tools.
When done right, the embedded controller will be transparent to coreboot. If you need a solution / framework / interface for dealing with custom embedded controller code, then the openEC project isn't doing a very good job.
Exactly!
What is the ultimate dream here? To develop replacement open firmware for existing embedded controllers that have been used for years mainly in laptops and servers?
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.
If you do s/embedded controller/BIOS/ in the paragraphs, the argument remains exactly the same. Lets face it, coreboot and an embedded controller project are birds of a feather. What I'm saying is that in an ideal world, they can both exist without being aware of each other.
Jordan
On Thu, Jun 19, 2008 at 03:55:53PM -0500, bari wrote:
Jordan Crouse wrote:
When done right, the embedded controller will be transparent to coreboot.
How common is that in your experience?
What is the ultimate dream here? To develop replacement open firmware for existing embedded controllers that have been used for years mainly in laptops and servers?
Yeah, in some cases..
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.
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..
Granted, those ECs don't seem to be so popular. (yet?)
Sorry - I don't remember which board or SMSC controller it was. Hopefully Uwe will see this thread and fill in.
//Peter
On 19/06/08 23:07 +0200, Peter Stuge wrote:
On Thu, Jun 19, 2008 at 03:55:53PM -0500, bari wrote:
Jordan Crouse wrote:
When done right, the embedded controller will be transparent to coreboot.
How common is that in your experience?
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.
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.
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.
Granted, those ECs don't seem to be so popular. (yet?)
They will be, sooner then you think.
Jordan
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
-
bari -
Carl-Daniel Hailfinger -
Frieder Ferlemann -
Jordan Crouse -
Ken.Fuchs＠bench.com -
Peter Stuge -
Richard Smith -
ron minnich -
Uwe Hermann