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
[EMAIL PROTECTED]
--
coreboot mailing list
[email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
