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

[Richard Smith]

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.

-- 
Richard A. Smith
smithbone at gmail.com