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

[Carl-Daniel Hailfinger]

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