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
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
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.
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
though, but that's what you get if you want
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