[coreboot] coreboot and embedded controllers, for example OLPC and its OpenEC code
c-d.hailfinger.devel.2006 at gmx.net
Thu Jul 17 23:49:09 CEST 2008
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
> 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
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
More information about the coreboot