[openfirmware] Using Open Firmware as a boot manager

Mark Morgan Lloyd markMLl.openfirmware at telemetry.co.uk
Sat Mar 12 15:14:20 CET 2011


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.
> 
> 
> http://www.firmworks.com/QuickRef.html

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).

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]



More information about the openfirmware mailing list