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