So this is likely a dumb question. But what is the difference between LinuxBIOS and OpenBIOS?
Dale Harris
On Mar 14, 2005, at 10:15 AM, Dale Harris wrote:
So this is likely a dumb question. But what is the difference between LinuxBIOS and OpenBIOS?
As far as my very limited knowledge goes, LinuxBIOS isn't a BIOS persay. It will initialize your hardware to a state that it can load a bootloader of sometype (or even just a program like memtest). When you are creating a linuxbios for a board/system. You will determine what payload(s) you want it to have. These payloads can be filo, etherboot a linux kernel, or ALDO or OpenBIOS.
OpenBIOS as far as I understand, is attempting to create a BIOS replica/replacement, and as such could be a payload to LinuxBIOS.
You might also want to check out the new site http://wiki.linuxbios.org/ which will probably have more definitive answers to your question.
On Mon, Mar 14, 2005 at 02:44:26PM -0800, Nathanael Noblet wrote:
On Mar 14, 2005, at 10:15 AM, Dale Harris wrote:
So this is likely a dumb question. But what is the difference between LinuxBIOS and OpenBIOS?
[..]
You might also want to check out the new site http://wiki.linuxbios.org/ which will probably have more definitive answers to your question.
This inspired me to touch up the general description of LinuxBIOS in the FAQ, to include mention of OpenBIOS and freebios. I realized that there's some disparity in the term LinuxBIOS, in what it covers.
It's good to use LinuxBIOS for the completed product, including payload and all. It looks good, feels good and is practical.
I would like to have a name for the part that isn't the payload. Suggestions? I've called it "the initialization part|code" but I don't like that too much.
//Peter
Peter Stuge wrote:
I would like to have a name for the part that isn't the payload. Suggestions? I've called it "the initialization part|code" but I don't like that too much.
How about Pre Payload Environment - PPE? Since PXE is already taken.
-Bari
On Mar 14, 2005, at 6:38 PM, Bari Ari wrote:
Peter Stuge wrote:
I would like to have a name for the part that isn't the payload. Suggestions? I've called it "the initialization part|code" but I don't like that too much.
How about Pre Payload Environment - PPE? Since PXE is already taken.
BSI Basic System Initialization
[B]MHI [Basic] Memory Hardware Initialization
HD[E|P] Hardware Discovery [Environment | Phase]
;)
HASH - Hardware And SHit
"LinuxBIOS begins in the HASH stage where it initializes the memory controller and CPU, scans system busses, etc. before booting a payload." We could call the bootloader stage BASH, external ROMs (SCSI, VGA) RASH, and any other software SASH. The -ASH ending is incredibly versatile.
Or if you prefer names without profanity: HIC: Hardware initialization code HEC: Hardware enabling code MIR: Mainboard Initialization Routines MIS: Mainboard Initialization Stuff NAB: Not A Bootloader NAP: Not A Payload
I'm still not entirely clear on why a new acronym is necessary, though. Perhaps we should try to clear up the definition of the word "payload" more than using another acronym to describe what is meant by the word "BIOS" since BIOS is already sort of a generic term for a wad of hardware initialization routines. Then we can explain why "Linux" is in the name of the project. Or perhaps the solution would be to change the name of the project back to FreeBIOS. If not that, we can call it Minnich's BIOS (Since it rhymes with LinuxBIOS) and pray that nobody calls it MinixBIOS :)
On Mon, 14 Mar 2005 19:00:06 -0800 Nathanael Noblet nathanael@gnat.ca wrote:
On Mar 14, 2005, at 6:38 PM, Bari Ari wrote:
Peter Stuge wrote:
I would like to have a name for the part that isn't the payload. Suggestions? I've called it "the initialization part|code" but I don't like that too much.
How about Pre Payload Environment - PPE? Since PXE is already taken.
BSI Basic System Initialization
[B]MHI [Basic] Memory Hardware Initialization
HD[E|P] Hardware Discovery [Environment | Phase]
;)
Nathanael D. Noblet Gnat Solutions 204 - 131 Gorge Road E Victoria, BC V9A 1L1
T 250.385.4613 C 250.893.4613 http://www.gnat.ca/
LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
On Mon, Mar 14, 2005 at 11:21:32PM -0700, David Hendricks wrote:
[..lots of good acronym ideas..]
I'm still not entirely clear on why a new acronym is necessary,
I was looking more for an official term, not neccessarily an acronym.
Perhaps we should try to clear up the definition of the word "payload" more than using another acronym to describe what is meant by the word "BIOS" since BIOS is already sort of a generic term for a wad of hardware initialization routines.
"BIOS" is quickly getting obsolete.. Plus LinuxBIOS as of now doesn't do much in the traditional BIOS sense; there are no callbacks, by design. It's a mainboard firmware rather than a BIOS. That's actually pretty good, "mainboard firmware" - but then I'm back at the original problem; what to call the non-payload part. Core? Hardware init?
Then we can explain why "Linux" is in the name of the project. Or perhaps the solution would be to change the name of the project back to FreeBIOS. If not that, we can call it Minnich's BIOS (Since it rhymes with LinuxBIOS) and pray that nobody calls it MinixBIOS :)
:) The name LinuxBIOS has catched on however, I recall Ron wrote that it catched on even among vendors, and changing it without a really good reason would just hurt in that case.
Terribly sorry if anyone thinks I'm splitting hairs. I just want to see what ideas are out there on this.
//Peter
pretty good, "mainboard firmware" - but then I'm back at the original problem; what to call the non-payload part. Core? Hardware init?
What about init phase? The whole pre-payload is basically just a per-subsystem init procedure. Be it CPU, memory, pci cards, or whatever.
Terribly sorry if anyone thinks I'm splitting hairs. I just want to see what ideas are out there on this.
I doubt anyone thinks that. I'm sure that most of us are just happy that someone _is_ thinking about these kind of things and actually doing something. This is exactly the type of info that a newbe needs. Attention to this type of stuff is what sets a good "Project" apart from just a pile of code.
And I personally don't see the problem with looking ahead to an acronym either, for what it's worth. Most concepts end up being abbreviated anyway.
jamie.
On Tue, 15 Mar 2005, Richard Smith wrote:
pretty good, "mainboard firmware" - but then I'm back at the original problem; what to call the non-payload part. Core? Hardware init?
What about init phase? The whole pre-payload is basically just a per-subsystem init procedure. Be it CPU, memory, pci cards, or whatever.
Terribly sorry if anyone thinks I'm splitting hairs. I just want to see what ideas are out there on this.
I doubt anyone thinks that. I'm sure that most of us are just happy that someone _is_ thinking about these kind of things and actually doing something. This is exactly the type of info that a newbe needs. Attention to this type of stuff is what sets a good "Project" apart from just a pile of code.
-- Richard A. Smith
LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
pretty good, "mainboard firmware" - but then I'm back at the original problem; what to call the non-payload part. Core? Hardware init?
What about init phase? The whole pre-payload is basically just a per-subsystem init procedure. Be it CPU, memory, pci cards, or whatever.
If I understand right, the "bootstrap" section (presently called LinuxBIOS) is essentially a stripped-down Linux kernel with some rather more in-depth device initialisation capabilities. Such a configuration does make sense, and would allow very flexible boot device support.
If this is true, then as a kernel it *does* have callbacks, and can justifiably be termed a BIOS in the strict sense of the word, even if it doesn't provide the legacy "IBM compatible" calls to run M$-DOS directly. Thus the name "LinuxBIOS" should probably stick.
Since I'm not heavily involved with the project, I might have got these details very wrong. Please don't shoot me too much.
The combination of LinuxBIOS with a trivial "chainloader" payload for booting a sophisticated OS directly, should probably stay as LinuxBIOS. As for the combination of LinuxBIOS with an OpenFirmware-like payload, I think it could be called LinuxFirmware.
The latter could be an extremely powerful system configuration tool. Certainly overclockers would love it, with a (relatively) universal interface to and support for their favourite tweaks. Sysadmins would like it too, if it contained sophisticated diagnostic routines (Memtest86 and 'badblocks' in firmware?) etc.
Eventually, even Intel will have to admit it's time to ditch the old, frequently buggy and restrictive AMI and Award BIOS structures. Goodness, BIOSes of both kinds have caused havoc when faced with a HD slightly larger than was expected at the time of manufacture, multiple times in recent history. The onus has largely been on the HD manufacturers to work around the BIOS bugs. That's just wrong.
-------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it.
On Tue, 15 Mar 2005, Jonathan Morton wrote:
If I understand right, the "bootstrap" section (presently called LinuxBIOS) is essentially a stripped-down Linux kernel with some rather more in-depth device initialisation capabilities. Such a configuration does make sense, and would allow very flexible boot device support.
such was the plan.
But the small flash size problem changed the plan
If this is true, then as a kernel it *does* have callbacks, and can justifiably be termed a BIOS in the strict sense of the word, even if it doesn't provide the legacy "IBM compatible" calls to run M$-DOS directly. Thus the name "LinuxBIOS" should probably stick.
yeah. I still think long term I want linux in there. The Intel EFI guys beat up on me a lot about this -- "LinuxBIOS has no API".
My response was, "of course it does -- it's called the linux system call layer".
But it's harder to make that case when there's no linux in there ...
Eventually, even Intel will have to admit it's time to ditch the old, frequently buggy and restrictive AMI and Award BIOS structures. Goodness, BIOSes of both kinds have caused havoc when faced with a HD slightly larger than was expected at the time of manufacture, multiple times in recent history. The onus has largely been on the HD manufacturers to work around the BIOS bugs. That's just wrong.
Intel has admitted that, long ago; it's just that their solution is utterly proprietary, which runs against the grain. At least my grain.
ron
yeah. I still think long term I want linux in there. The Intel EFI guys beat up on me a lot about this -- "LinuxBIOS has no API".
What do the EFI guys need and API for?
On Tue, 15 Mar 2005, Richard Smith wrote:
What do the EFI guys need and API for?
oh, goodness, that's the whole point of EFI. It has a very complex API, including timers, file systems, network protocols, and on and on. It's quite incredible.
ron
* Ronald G. Minnich rminnich@lanl.gov [050315 16:46]:
yeah. I still think long term I want linux in there. The Intel EFI guys beat up on me a lot about this -- "LinuxBIOS has no API".
My response was, "of course it does -- it's called the linux system call layer".
But it's harder to make that case when there's no linux in there ...
OpenBIOS is such an API. And it is an API created after an industry proven standard, not some proprietary monopoly game punching IEEE1275 with a big "NIH" ;-)
Well, if it only were complete...
Stefan
On Tue, Mar 15, 2005 at 03:00:06PM +0000, Jonathan Morton wrote:
pretty good, "mainboard firmware" - but then I'm back at the original problem; what to call the non-payload part. Core? Hardware init?
What about init phase? The whole pre-payload is basically just a per-subsystem init procedure. Be it CPU, memory, pci cards, or whatever.
If I understand right, the "bootstrap" section (presently called LinuxBIOS) is essentially a stripped-down Linux kernel with some rather more in-depth device initialisation capabilities. Such a configuration does make sense, and would allow very flexible boot device support.
Unfortunately not, as Ron said.
To further explain, a LinuxBIOS firmware image file (.bin, to be flashed into a flash ROM) currently has a couple of logical parts:
* RAM initialization * Hardware initialization of remaining things on the mainboard far enough for a Linux kernel to be able to find, further init and use. * Payload
The first two are developed in the freebios/freebios2 source tree that recently moved from SourceForge to OpenBIOS.org. The payload can come from a number of different places; it can be a Linux kernel, but can also be FILO, (loads a supposed OS kernel from a filesystem on a mass-storage device) Etherboot, (loads a supposed OS kernel from the network, but also includes a version of FILO) ADLO, (legacy compatibility layer that can be used to start up Windows 2000 and other products) memtest86 (tests RAM) and probably lots of other programs that I can't remember.
If this is true, then as a kernel it *does* have callbacks, and can justifiably be termed a BIOS in the strict sense of the word, even if it doesn't provide the legacy "IBM compatible" calls to run M$-DOS directly. Thus the name "LinuxBIOS" should probably stick.
With Linux as the payload, yes, definately. I do imagine other uses for it, although that is the primary goal.
//Peter
On Tue, Mar 15, 2005 at 07:18:33AM -0600, Richard Smith wrote:
pretty good, "mainboard firmware" - but then I'm back at the original problem; what to call the non-payload part. Core? Hardware init?
What about init phase? The whole pre-payload is basically just a per-subsystem init procedure. Be it CPU, memory, pci cards, or whatever.
I like that! Although a small alarm goes off in the back of my head since Linux and init are already pretty close to each other, at least in my memory bank. But perhaps hwinit or hardware init? Oh, that's the second time I come up with that.. :) "Hardware initialization phase" or hwinit for short, sounds good?
Terribly sorry if anyone thinks I'm splitting hairs. I just want to see what ideas are out there on this.
I doubt anyone thinks that. I'm sure that most of us are just happy that someone _is_ thinking about these kind of things and actually doing something. This is exactly the type of info that a newbe needs. Attention to this type of stuff is what sets a good "Project" apart from just a pile of code.
Thanks! That's very encouraging. :) I wish I had time and hardware to contribute to the code as well, but I don't mind working on "softer" matters.
//Peter
On Tue, Mar 15, 2005 at 10:57:56AM +0100, Peter Stuge wrote:
"BIOS" is quickly getting obsolete.. Plus LinuxBIOS as of now doesn't do much in the traditional BIOS sense; there are no callbacks, by design. It's a mainboard firmware rather than a BIOS. That's actually pretty good, "mainboard firmware" - but then I'm back at the original problem; what to call the non-payload part. Core? Hardware init?
I think the term "BIOS" means different things to different people. Some think of it as the POST stage - which is what LinuxBIOS replaces. Others would associate it with the old DOS callbacks (as you did). And yet others think of the menu screen in a COTS BIOS where boot options can be set.
Then we can explain why "Linux" is in the name of the project. Or perhaps the solution would be to change the name of the project back to FreeBIOS. If not that, we can call it Minnich's BIOS (Since it rhymes with LinuxBIOS) and pray that nobody calls it MinixBIOS :)
:) The name LinuxBIOS has catched on however, I recall Ron wrote that it catched on even among vendors, and changing it without a really good reason would just hurt in that case.
I wonder if the pain of changing names would be worth preventing the perpetual misunderstanding that the current name creates. LinuxBIOS right now has nothing to do with Linux. The misconception that Linux is in the firmware or that the firmware was derived from Linux comes up frequently. (See one of the replies in this thread..)
Interestingly, Linux is a trademarked term. If a manufacture ever started shipping LinuxBIOS, they'd need to put the little blurb about "Linux is a trademark owned by Linus Torvalds" in their promotional material -- even though Linus and Linux have nothing to do with the product.
Also, if LinuxBIOS+ADLO ever matures, one could get in the very awkward position of trying to explain to end users that they're really running Windows and not Linux. :-)
-Kevin
The name LinuxBIOS has catched on however, I recall Ron wrote that it catched on even among vendors, and changing it without a really good reason would just hurt in that case.
I wonder if the pain of changing names would be worth preventing the perpetual misunderstanding that the current name creates. LinuxBIOS right now has nothing to do with Linux. The misconception that Linux is in the firmware or that the firmware was derived from Linux comes up frequently. (See one of the replies in this thread..)
Yeah, point taken. Instead, how about OpenStrap for the bootstrap section? This could go with BeltStrap as the variant with OpenFirmware included. The latter has some subliminal connotations of performance...
-------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi@chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it.
On Wed, 16 Mar 2005, Jonathan Morton wrote:
Yeah, point taken. Instead, how about OpenStrap for the bootstrap section?
yuck. :=)
THe problem is this: linuxbios is a very catchy name, rolls off the tongue.
I've not found a better name.
ron
On Wed, 16 Mar 2005, Kevin O'Connor wrote:
Also, if LinuxBIOS+ADLO ever matures, one could get in the very awkward position of trying to explain to end users that they're really running Windows and not Linux. :-)
but what do we call it if we ever meet the end goal: linux is the bios.
ron
On Wed, Mar 16, 2005 at 09:45:19AM -0700, Ronald G. Minnich wrote:
On Wed, 16 Mar 2005, Kevin O'Connor wrote:
Also, if LinuxBIOS+ADLO ever matures, one could get in the very awkward position of trying to explain to end users that they're really running Windows and not Linux. :-)
but what do we call it if we ever meet the end goal: linux is the bios.
Ron, I think you just said it! (Well, wrote it.)
LitheBIOS
//Peter
On Wed, Mar 16, 2005 at 07:41:25AM -0500, Kevin O'Connor wrote:
On Tue, Mar 15, 2005 at 10:57:56AM +0100, Peter Stuge wrote:
"BIOS" is quickly getting obsolete.. Plus LinuxBIOS as of now doesn't do much in the traditional BIOS sense; there are no callbacks, by design. It's a mainboard firmware rather than a BIOS. That's actually pretty good, "mainboard firmware" - but then I'm back at the original problem; what to call the non-payload part. Core? Hardware init?
I think the term "BIOS" means different things to different people. Some think of it as the POST stage - which is what LinuxBIOS replaces. Others would associate it with the old DOS callbacks (as you did). And yet others think of the menu screen in a COTS BIOS where boot options can be set.
Right. Are there more fundamental blocks in a classic BIOS that I can't think of?
- Hardware init controlled by battery-backed NVRAM LinuxBIOS does this but it is instead controlled by compile-time options. What is the desired development of this part?
- Boot process controlled by NVRAM LinuxBIOS does this too, by loading a payload, and this is also controlled by compile-time options. What is the desired development of this part?
- Legacy services, and the only way BIOS is visible after OS loads LinuxBIOS does not, and should not, ever, do this. Right?
I'm not saying a LinuxBIOS firmware image cannot have callbacks, but they probably shouldn't be to this project, but rather, as Ron says, to the Linux kernel itself. I keep making this distinctions since we will not start developing the kernel "inside" LinuxBIOS, but a firmware image will instead be a marriage between LinuxBIOS parts and kernel parts.
I wonder if the pain of changing names would be worth preventing the perpetual misunderstanding that the current name creates.
Right. Perhaps it will.
LinuxBIOS right now has nothing to do with Linux. The misconception that Linux is in the firmware or that the firmware was derived from Linux comes up frequently. (See one of the replies in this thread..)
Right.
Interestingly, Linux is a trademarked term. If a manufacture ever started shipping LinuxBIOS, they'd need to put the little blurb about "Linux is a trademark owned by Linus Torvalds" in their promotional material -- even though Linus and Linux have nothing to do with the product.
This is also a reason to change the name. And a pretty good one IMHO.
Also, if LinuxBIOS+ADLO ever matures, one could get in the very awkward position of trying to explain to end users that they're really running Windows and not Linux. :-)
Yup.
//Peter
-
Bari Ari -
Dale Harris -
David Hendricks -
Jamie Rollins -
Jonathan Morton -
Kevin O'Connor -
Nathanael Noblet -
Peter Stuge -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer