Mitch Bradley wrote:
On 3/11/2011 3:01 AM, Mark Morgan Lloyd wrote:
Given a copy of OFW booted from floppy on a PC, is there a comparatively straightforward way of using it to boot an OS or loader from other block devices or over the LAN, in the way that I'm used to on Sun kit?
Yes, you just say, for example,
That assumes that the support for the Linux file format has been included in the OFW build. It also assumes that your linux kernel is in on the first partition of the primary IDE disk (the default target of the "c" devalias) in a supported filesystem like FAT or ext2.
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.
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.
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, nobody's paying us for it and I'm really just trying to "grease the wheels" for some other internal projects. However I'd like to thing that once I'm up to speed I might be able to contribute usefully in some small way.