Mitch Bradley wrote:
Booting Windows is not supported in the PC demonstration build, but is possible with a fair amount of effort. It requires ACPI and numerous other accomodations for Windows' use of conventional BIOS. We support it on the One Laptop Per Child systems.
At present things I'm likely to want to boot are Linux and DOS, although I'm currently trying to evaluate ReactOS and Sanos so I can report back to another group of developers.
DOS and ReactOS are going to have the same problem as Windows, namely that they expect to do conventional 16-bit BIOS calls. The OFW demo version does not support that.
Are you considering using OFW on both x86 and ARM systems, or is the x86 work just for exploration?
x86 really just for exploration, but I could say much the same for ARM.
Bearing in mind that I've not really used Forth since doing my Masters [mumble] years ago, and that my use of Sun's implementation was mostly pretty trivial, I think I need an idiot's guide as to what can be done from the command line e.g. how to get aliases populated. At the very least so that I can ask questions intelligently.
Thanks, I'd missed that and had been working through the IEEE doc.
I've really only got OFW working today, I tried (on some different systems) a few months ago but I suspect that the "Making a Prototype Floppy Image with Linux Commands" didn't work properly for me.
Now that I am able to run successfully on a PC, is there a standard config that I can use which will allow me to dump boot sectors etc. on BIOS-supported discs (i.e. preferably both IDE and SCSI)?
I'm hoping to eventually put it on some ARM-based development boards as an interactive layer before they boot Linux (etc.) from disc.
My current work at One Laptop Per Child is ARM-based, so the OFW ARM port is being actively maintained and enhanced. I have versions that you can load from uboot and others that run directly with no underlying firmware. The latter, of course, requires that you take responsibility for the low-level issues of memory controller and DRAM initialization.
If you are a consumer of the board, then it's probably better to use whatever firmware is already there as the initial loader, using OFW as the boot manager as you say. If you are developing your own hardware, it starts to make sense to use OFW from the ground up.
Feel free to contact me directly if you need additional guidance. At this point I'm more interested in the ARM version than the x86 version, so the sooner you get onto ARM, the more help I'll be able to offer.
Bear in mind that I'm doing this on spec,
Effectively, so am I. The existence of other open source firmware solutions such as uboot and coreboot (formerly linuxbios) and bootloaders like GRUB have made it difficult bordering on impossible to make money with Open Firmware, except via consulting, and the market for that is rather limited.
Although I think that OFW is about the only one that has the potential for doing things like listing the partition table (and associated code).