Is the intention to have much of the BIOS code on the hard drive with only the minimal amount of code on the EEPROM?
That is what I was thinking. I think this approach makes it much
easier to
modify, update and experiment with the BIOS.
What if you don't have a hard drive? I don't like this approach.
Another approach that could be used is to have a boot block sector of code. For those of you who have not programmed BIOS before I'll explain...
Most PCs shipping today come with boot block code in the EEPROM. A jumper (or switch) on the board is used to toggle between a boot block boot and a normal boot. Often this jumper is connected to a GPIO. Initial BIOS code reads the value of this GPIO and runs the appropriate code. The boot block code brings up the bare minimum amount of hardware in order to read a BIOS image off the floppy drive (memory and floppy). Once this image has been read into memory, the computer reruns the BIOS code using the image in memory to load the F000 and E000 segments (where BIOS code usually is run from) rather then the EEPROM. This is quite useful for testing BIOS code without modifying the code on the EEPROM.
A normal boot, however, would use the code from the EEPROM. By containing all of our BIOS code in the EEPROM, we allow an end user the use a system that does not have a hard drive (Net PC ring a bell?). Remember that we can compress most of the code on the EEPROM (with only the decompression algorithm and memory bring up code not compressed). This provides for plenty of code space, especially when you consider that modern EEPROMs shipping with systems are typically 512K bytes.
Eric R. Kern
On Wed, 10 Feb 1999, Eric R. Kern wrote:
This provides for plenty of code space, especially when you consider that modern EEPROMs shipping with systems are typically 512K bytes.
Sure? Does anyone have sort of a "table" showing which typical motherboard has which EEPROMs and its size?
I always thought of having only 128 kB of EEPROM memory. Well, if this would be 256 kB or even 512 kB (and, as you said, think of compression), then there would be no real need to have any code on the hard disk, I mean, to complete the BIOS code.
Well, this size ... could contain a miniature Linux kernel plus some applications to boot that system... oh, just a thought.
Winschdawos, - Matthias
Hi
Matthias Wächter wrote:
On Wed, 10 Feb 1999, Eric R. Kern wrote:
This provides for plenty of code space, especially when you consider that modern EEPROMs shipping with systems are typically 512K bytes.
Sure? Does anyone have sort of a "table" showing which typical motherboard has which EEPROMs and its size?
I always thought of having only 128 kB of EEPROM memory. Well, if this would be 256 kB or even 512 kB (and, as you said, think of compression), then there would be no real need to have any code on the hard disk, I mean, to complete the BIOS code.
Well, this size ... could contain a miniature Linux kernel plus some applications to boot that system... oh, just a thought.
At 512k you could get a complete Linux Kernel in it....
Yours
Matthew
Matthias Wächter wrote:
On Wed, 10 Feb 1999, Eric R. Kern wrote:
This provides for plenty of code space, especially when you consider that modern EEPROMs shipping with systems are typically 512K bytes.
ALL modern (P/P2) OEM motherboards that I have dealed with have 128KB Flash EEPROMS, I only have seen one with 256KB and all the old ones with 64KB proms. It is easy to have a survey by going at http://www.ping.be/bios/ and download some upgrades. But of course the modern BIOSes are composed of some archives that are expanded for specific purposes ex. the setup program, the ESCD updater, the BIOS itself and yes, even the little the EPA logo is stored in separate archives in LHA format in Award's case, YMMV. I remember one of the first coolest things that I do to my BIOS was to change the boot-up logo :). So, in the end don't count on more of 128KB of Flash on your typical motherboard.
Mircea C. P.S. I'm working at that, but don't expect to run dosemu on it ;)
Well, this size ... could contain a miniature Linux kernel plus some applications to boot that system... oh, just a thought.
Winschdawos,
- Matthias
-- Der Wein mit der Pille ist in dem Becher mit dem Fächer.
I just relised I sent to a person not the group, sorry.
My comment is at the end. <snip>
PS. A couple of you have mentioned Open Boot. Where can I find out more about it? Is Open Boot open as in open source or open as in marketing-buzzword "open". Could this be used as the boot loader part of the project? Is it something that we could build on?
I found something on the SUN server I think. Search there for it. I think it's of no use for us at least because the sources are not free.
It is open in the sense there is a standard. IEEE 1275.
All these issues have been thought about and dealt with. It is a used by sun and apple.
As the standard is in use by apple and sun, and as most open OS's work on these machines it will not be a difficult task to get the OS's ported ( remember you have nothing if you can't get anyone to port the OS). Well I will rephrase that, all you have is a lot of work and an end result you have nothing more than a boot loader. If that is your aim use the netbsd loader, they have a cut down version that can be used for this purpose ( they also support the Fcode drivers as specified in the PCI spec).
If the source was available there would be no need for OpenBIOS. Implementing openBOOT would be a worthwhile aim for this group.
If it was implemented in a CPU independent way ( possible if openBOOT) the efforts would move easily across the 64 bit transition that is looming.
Implementing something new will be a complete waste of time, and unlikely to get finished, and if anything more than a boot loader unlikely to be taken up by industry. And I ask, as netBSD has a perfectly good promable boot loader, why would they use the result of this effort.
Take a long hard look at linux, did it succeed because of inherent greatness, or because it implemented a current standard.
As an aside openboot gives us a clear aim "implement openBOOT". Anyone who has followed this even a little should be able to see the problem faced if a small tight specification is not forthcoming. All the time will be spent arguing what is required and nothing will get done.
some references
http://www.penton.com/ed/Pages/magpages/june2298/embed/0622es2.htm
http://playground.sun.com/pub/p1275/home.html
http://www.hal.com/support/dpfirmware/
I have seen the standard itself onthe net, but do you think I can find it ( still looking).
Another openboot reference.
http://www.at.netbsd.org/Hardware/ofw.html
This is the result of using a machine independent boot loader, supporting a OS across machines becomes simpler.
-
Charles Esson -
Eric R. Kern -
Matthew Sullivan -
Matthias Wächter -
Mircea Ciocan