People,
I have been on this list for some time lurking - just because I think it is interesting that a bit of firmware can allow hardware to be actually useful! I haven't done more than read the occasional post that was of interest but the thought occurred to me again about replacing the BIOS that is on my current machine with something that is open so I went back to the OpenBIOS home page but was a bit puzzled to see on the Download page: "Do not try to put OpenBIOS in a real boot ROM, it will not work and may damage your hardware!". After a little more looking around I am still confused - the ultimate aim of this software is to eventually allow people to replace their proprietary BIOSes right? I have an Intel MB DG45ID but I couldn't Google much overlap with OpenBIOS . .
Thanks for any enlightenment!
Regards,
Phil.
On 2013-Dec-27, 21:41 , Philip Rhoades wrote:
I have been on this list for some time lurking - just because I think it is interesting that a bit of firmware can allow hardware to be actually useful! I haven't done more than read the occasional post that was of interest but the thought occurred to me again about replacing the BIOS that is on my current machine with something that is open so I went back to the OpenBIOS home page but was a bit puzzled to see on the Download page: "Do not try to put OpenBIOS in a real boot ROM, it will not work and may damage your hardware!". After a little more looking around I am still confused - the ultimate aim of this software is to eventually allow people to replace their proprietary BIOSes right? I have an Intel MB DG45ID but I couldn't Google much overlap with OpenBIOS . .
I'm not one of the OpenBios team (I do OpenBoot at what was Sun Microsystems, so I pipe up occasionally with tidbits I've seen), below is my understanding of the direction of OpenBios. One of the OpenBios folks might speak up and phrase it better.
There are two parts to a boot ROM - initializing the platform-specific hardware, and then booting the operating system. OpenBios fits in the latter part. Most x86 vendors have their boot ROMs containing highly proprietary code to initialize their CPUs, memory and io bridges, before they get to the common function of trying to boot their operating system.
Since the code for initializing cpu boards is so highly proprietary (and so different board from board), that kind of code isn't in OpenBios. If you flash OpenBios into your Boot ROM, your hardware won't get initialized and your system will perform the operation we call "turn into a brick".
On 28/12/13 02:41, Philip Rhoades wrote:
People,
I have been on this list for some time lurking - just because I think it is interesting that a bit of firmware can allow hardware to be actually useful! I haven't done more than read the occasional post that was of interest but the thought occurred to me again about replacing the BIOS that is on my current machine with something that is open so I went back to the OpenBIOS home page but was a bit puzzled to see on the Download page: "Do not try to put OpenBIOS in a real boot ROM, it will not work and may damage your hardware!". After a little more looking around I am still confused - the ultimate aim of this software is to eventually allow people to replace their proprietary BIOSes right? I have an Intel MB DG45ID but I couldn't Google much overlap with OpenBIOS . .
Thanks for any enlightenment!
Regards,
Phil.
Hi Phil,
Basically there are two parts to the problem here: one is the low-level hardware initialisation, while the second is adding the required support for boot.
For low-level hardware initialisation, you'd need to use coreboot and add OpenBIOS as an ELF payload - I did try this a few years back and managed to get a Forth prompt working under QEMU. But there are some things that OpenBIOS doesn't know, for example how much physical RAM is in the machine which at the moment is obtained through a QEMU-specific interface.
I suspect this is why the warning exists, as accessing these QEMU-specific addresses will have undefined behaviour on real hardware. So unless you can talk to coreboot then you'd need to hardcode some specific defaults (which I believe is probably the approach used by http://temlib.org to enable OpenBIOS to work on their SPARC board).
Finally if you are using Intel hardware then you'll find that the support is a lot weaker than other architectures (for example x86 OpenBIOS is currently real mode only, no PE support). My guess is that this is because for more modern hardware, people are focusing their efforts on developing open UEFI firmwares instead.
ATB,
Mark.
Mark,
On 2013-12-28 21:38, Mark Cave-Ayland wrote:
On 28/12/13 02:41, Philip Rhoades wrote:
People,
I have been on this list for some time lurking - just because I think it is interesting that a bit of firmware can allow hardware to be actually useful! I haven't done more than read the occasional post that was of interest but the thought occurred to me again about replacing the BIOS that is on my current machine with something that is open so I went back to the OpenBIOS home page but was a bit puzzled to see on the Download page: "Do not try to put OpenBIOS in a real boot ROM, it will not work and may damage your hardware!". After a little more looking around I am still confused - the ultimate aim of this software is to eventually allow people to replace their proprietary BIOSes right? I have an Intel MB DG45ID but I couldn't Google much overlap with OpenBIOS . .
Thanks for any enlightenment!
Regards,
Phil.
Hi Phil,
Basically there are two parts to the problem here: one is the low-level hardware initialisation, while the second is adding the required support for boot.
For low-level hardware initialisation, you'd need to use coreboot and add OpenBIOS as an ELF payload - I did try this a few years back and managed to get a Forth prompt working under QEMU. But there are some things that OpenBIOS doesn't know, for example how much physical RAM is in the machine which at the moment is obtained through a QEMU-specific interface.
I suspect this is why the warning exists, as accessing these QEMU-specific addresses will have undefined behaviour on real hardware. So unless you can talk to coreboot then you'd need to hardcode some specific defaults (which I believe is probably the approach used by http://temlib.org to enable OpenBIOS to work on their SPARC board).
Finally if you are using Intel hardware then you'll find that the support is a lot weaker than other architectures (for example x86 OpenBIOS is currently real mode only, no PE support). My guess is that this is because for more modern hardware, people are focusing their efforts on developing open UEFI firmwares instead.
Hmmm . . looks like I should be following tianocore on Sourceforge as well . .
Thanks,
Phil.
-
Mark Cave-Ayland -
Philip Rhoades -
Tarl Neustaedter