The purpose of a BIOS is to create independence between hardware and operating system.
A streamlined BIOS can be quite compact. For example, my own BIOS, tinyBIOS, is about 10k lines of assembly source, < 16KB of object code). The code is mostly 16 bit, with 32 bit code used where it makes sense (e.g. memory test) or is required (32 bit PCI entries). 16 bit code is more compact.
Assuming no unnecessary delays, system startup time is dominated by hard disk spinup time, and cannot be reduced any further.
If desired, custom boot loaders can be installed in the remaining flash space. I've done this for one of my customers (they're using their own non-UNIX kernel and file system).
reentrant BIOS code so we can leave out drivers from the kernel(s)?
Why bother ? We're talking about a few KB worth of code. On some platforms, execution out of BIOS space can be slower due to hardware constraints (cacheability of BIOS space etc). If you try to keep this code in the BIOS, you will have extra overhead for generic OS hooks etc.
On Systems with 4MBit Flash (are there any?): Kernel in Bios
What if the kernel gets any bigger ? Most boards have 1 Mbit or 2 Mbit flash anyway.
USB Support
Unless you need to boot through USB, probably bad idea. This belongs in the OS.
PCI/EISA/PnP Support
EISA ??? what's that <g> ? ISA PnP should be implemented at the OS level, if at all. PCI PNP is much simpler and more likely to be reliable.
MSDos Filesystem code
A standard BIOS doesn't know about the file system, all it does is load the first sector on the disk. The rest is up to the boot loader of the operating system.
repeat the same procedure for any cards which bring their own BIOS (SCSI, video, etc.)
Do you want to spend the rest of your life doing this ?
obtain complete documentation on how you query SIMMs/DIMMs/etc. (including common bugs)
This is generally based on a trial and error detection procedure (set biggest possible size, then find out how many address bits really work), rather than presence detect bits.
add some backward-compatibility interface for people needing DOS or one of its offsprings (Maybe not)
Highly desirable, DOS is a much easier environment for low level debug.
implement some clever auto-configuration mechanism
Yes, this is key. Setup screens are evil. My BIOS doesn't have one.
Finally, who are you writing this for ? For the individual user, I think it will be better to leave the BIOS on their system board alone. The savings in boot time etc. will never pay back for the effort spent playing with the BIOS.
For the industrial user (embedding Linux or FreeBSD in a custom designed system), they can easily afford to license a commercial product from the usual suspects (Award, AMI, Phoenix, Systemsoft, General Software, moi). In volume, this can be as low as $0.10 per unit. For small volume users, adaptation cost (either at the BIOS vendor or on their side) will be higher than the license cost.
If you want to make the UNIX platform more suitable for embedded use:
- Make the file system fault resilient. Existing boxes (e.g. http://www.whistle.com ) have to include a UPS to protect the file systems. Costs lots of money, and doesn't protect against software induced crashes.
- Flash file system support. Aggressively reduce size of minimum system (e.g. for routers). 1 MB = $5 or more. It's coming down, but slowly.
-------------------------------------------------------------------- Pascal Dornier pdornier@pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware --------------------------------------------------------------------
--- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
Hi!
The purpose of a BIOS is to create independence between hardware and operating system.
Used to be... :-(.
At least linux uses almost nothing off bios due to performance it costs.
A streamlined BIOS can be quite compact. For example, my own BIOS, tinyBIOS, is about 10k lines of assembly source, < 16KB of object code). The code is mostly 16 bit, with 32 bit code used where it makes sense (e.g. memory test) or is required (32 bit PCI entries). 16 bit code is more compact.
Hmm, nice. What license is tinyBIOS under? ;-).
Assuming no unnecessary delays, system startup time is dominated by hard disk spinup time, and cannot be reduced any further.
You do not need to spin up harddrives during bootup. At least not *all* hardrives.
Finally, who are you writing this for ? For the individual user, I think it will be better to leave the BIOS on their system board alone. The savings in boot time etc. will never pay back for the effort spent playing with the BIOS.
AmiWinbios is trash, and I'm stuck with it. It costed me about 2 days to make it work with big disk. You ask why? Well, to turn ON LBA in amiwinbios, you have to set 'Hard disc LBA setting' to OFF. Yes, it is their bug.
It would be nice if bios was able to netboot, for example. Serial console might be nice. (Below me is 386 which I can not setup because screen is set to VGA in bios and it has HGC attached. For a long time it had only serial line attached, so I was lucky it booted and was unable to touch anything.)
Pavel
On Mon, 23 Feb 1998, Pavel Machek wrote:
The purpose of a BIOS is to create independence between hardware and operating system.
Used to be... :-(.
At least linux uses almost nothing off bios due to performance it costs.
The performance hit is in two places. Currently you have to switch to real-mode, which I would propose we would fix. Secondly, if the BIOS isn't shawdowed you are using much slower accesses.
Assuming no unnecessary delays, system startup time is dominated by hard disk spinup time, and cannot be reduced any further.
You do not need to spin up harddrives during bootup. At least not *all* hardrives.
Interesting point... At the least, you don't really have to wait for them to be done until you actually go to load code off of them. Sure would speed up my boottime, since the SCSI drives take a while to get going.
AmiWinbios is trash, and I'm stuck with it. It costed me about 2 days to make it work with big disk. You ask why? Well, to turn ON LBA in amiwinbios, you have to set 'Hard disc LBA setting' to OFF. Yes, it is their bug.
Ouch! My BIOS doesn't boot SCSI, which is rather annoying.
-- Chris Arguin | "...All we had were Zeros and Ones -- And Chris.Arguin@unh.edu | sometimes we didn't even have Ones." +--------------+ - Dilbert, by Scott Adams http://leonardo.sr.unh.edu/arguin/home.html |
--- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
DK = David Kennedy dkennedy@engsoc.carleton.ca DK> A command line interface can be supplied, as well as some code that DK> would investigate the current hard drives, and their partition DK> tables. This could produce a BIOS that is similar to many older DK> "minicomputer" style BIOSs.
Actually, it's similar to a lot of modern microcomputer style BIOSes, too. H/P, DEC, Sun, and SGI (well, SGI's is GUI, of course :) all have some level of diagnostics and boot control in firmware. Doing something like those is one of the more frequent ideas that has appeared so far. :-)
DK> Since every single PC in existance has a ISA bus
Actually, that is incorrect. The ISA bus is fast becoming a thing of the past. Any modern system bridges the PCI bus to the core system bus, and then bridges the ISA bus to the PCI bus. That's at least two levels of seperation between the ISA bus and the CPU. Some systems are even shipping with no ISA bus at all. Microsoft's PC98 spec hints that ISA should be phased out totally by the year 2000 or so. So don't bet on ISA being around in new systems.
Of course, there are a huge number of older ISA systems that we shouldn't ignore.
DK> not all PCs have the same BIOS chip (not even the same number DK> of chips, or the same number of pins), this allows for better DK> distribution.
I think you're missing the key element of this effort: Flash ROM. This whole thing started because someone wrote a device driver for Linux that lets you get at the flash ROM the BIOS is stored in. The idea is we write replacement BIOS code that the user (or OEM) will blow into their flash ROMs. We're not talking replacing actual chips. Not for the most part, anyway. :-)
CA = Chris Arguin chris.arguin@unh.edu CA> That is a good solution as well. With most of the proposals we CA> have had, we have no use for the MBR anymore. Looking at the LILO CA> docs, it looks like we have 446 bytes, assuming we leave the CA> partition table intact... Not enough room to put in simple CA> filesystem calls, I think. Too bad.
I've been saying all along that if you're going to depend on something on the disk, you might as well just write a better bootloader and forget messing around with the BIOS. OpenBIOS is going to be a lot of work, and if we don't get some benefit out of it, it just isn't going to be worth it. And frankly, simply having the source to something that usually only gets used to load a loader isn't worth it. :-)
You can quite easily do most everything, with the exception of a totally diskless boot, by building a better bootloader. That includes a unified boot menu, filesystem support, network boot, Linux kernel support, and whatever else floats your boat. You can even add your own custom hardware abstraction API if you want (NT does a cheesy version of that now). But it can all be done simply by creating a new primary partition and putting your bootloader there (similar to IBM's Boot Manager).
If you don't want to spare the primary partition, you can do that, too. Leave some space unallocated to any partition at the start of your disk. Hack the MBR (that's what LILO does, after all) to load a secondary bootloader stored in that unallocated space. You can use as much space for your boot loader as you need, then.
I believe, that if we're going to go to the trouble of re-implementing all the BIOS interrupt services (and we're going to have to make this at all compatbile), in all its 16-bit real-mode glory, we should definately plan on including advanced features like: - Network boot - Booting from any partition - Booting a Linux kernel directly - Filesystem support, so we can easily specify above Linux kernel - A powerful BIOS UI (most likely command-line driven) - Extended hardware diagnostics in flash ROM - Multi-option boot menu - Enhanced security
Yes, they should all be user-selectable options, not forced upon them. And no, I don't know if any of these are actually possible. But that's the sort of thing I'm interested in. :-)
While the idea of implementing a whole new set of BIOS calls -- either to be more powerful or faster, or to run in protected-mode -- sounds appealing, it would be totally useless. DOS won't use it because DOS depends on the old calls, and runs mainly in real-mode anyway. LILO and other low-level bootloaders won't use it because they don't need to. Win95, NT, and Linux won't use it because they already bypass the BIOS and use their own drivers. The most we could hope to do is rewrite the existing drivers and stick them in flash. That just complicates things needlessly. It's easier to have those drivers in the OS to begin with.
In short, we don't have much hope of fixing the basic "unintelligent" nature of the PC hardware platform. :-)
If anyone can think of a *real* reason to create all those new BIOS calls, then please, let me know. :-)
CA> I tend to agree with you that it would be best to leave CA> filesystem code out of the bios.
I would really like to be able to boot a Linux kernel, specified by partition and filename, without needing a intermediate bootloader. But that is me. :)
-- Ben hawk@ttlc.net
--- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
On Tue, 24 Feb 1998, Benjamin Scott wrote:
DK = David Kennedy dkennedy@engsoc.carleton.ca DK> A command line interface can be supplied, as well as some code that DK> would investigate the current hard drives, and their partition DK> tables. This could produce a BIOS that is similar to many older DK> "minicomputer" style BIOSs.
Actually, it's similar to a lot of modern microcomputer style BIOSes, too. H/P, DEC, Sun, and SGI (well, SGI's is GUI, of course :) all have some level of diagnostics and boot control in firmware. Doing something like those is one of the more frequent ideas that has appeared so far. :-)
Yes. I put "minicomputer" in quotes because I wasn't sure of the correct term to use (with the dozens that are floating around).
DK> Since every single PC in existance has a ISA bus
Actually, that is incorrect. The ISA bus is fast becoming a thing of the past. Any modern system bridges the PCI bus to the core system bus, and then bridges the ISA bus to the PCI bus. That's at least two levels of seperation between the ISA bus and the CPU. Some systems are even shipping with no ISA bus at all. Microsoft's PC98 spec hints that ISA should be phased out totally by the year 2000 or so. So don't bet on ISA being around in new systems.
Hmm... I certainly hope that I never get a system without an ISA bus. I have way too many specialty cards that require it.
Of course, there are a huge number of older ISA systems that we shouldn't ignore.
Definately.
DK> not all PCs have the same BIOS chip (not even the same number DK> of chips, or the same number of pins), this allows for better DK> distribution.
I think you're missing the key element of this effort: Flash ROM. This whole thing started because someone wrote a device driver for Linux that lets you get at the flash ROM the BIOS is stored in. The idea is we write replacement BIOS code that the user (or OEM) will blow into their flash ROMs. We're not talking replacing actual chips. Not for the most part, anyway. :-)
Ah.. ok.. But the problem, again, that I see with this is the fact that you are going to replace the proprietary initialization code with a, hopefully compatible, generic initialization code. With the dozen or so PC chipsets out there, can all these differ- ent versions of the initialization code be effectively created?
I believe, that if we're going to go to the trouble of re-implementing all the BIOS interrupt services (and we're going to have to make this at all compatbile), in all its 16-bit real-mode glory, we should definately plan on including advanced features like:
- Network boot
This one has been done over and over. But it's done with a BIOS chip on the network card using the technique I discussed before. Again, because of the multitude of network boards, I forsee it being very difficult to offer this in a generic BIOS.
- Booting from any partition
This is a rather easy extension. But the more important one is to boot off of any controller type (SCSI, EIDE, ...)
- Booting a Linux kernel directly
- Filesystem support, so we can easily specify above Linux kernel
- A powerful BIOS UI (most likely command-line driven)
- Extended hardware diagnostics in flash ROM
Actually, all BIOSs (to my knowledge anyway) have extended hard- ware diagnostics. The problem is that nobody knows about it. The BIOS outputs sequential numbers out to a specific port, anal- ogous to the lights on the back of a Sun4, or on the front of an Apollo. A POST card can be obtained which will list the numbers as they arrive. Also, if an error occurs, it displays extended information that is send over the port. Of course, it would be better to have it display to the screen, but relying on the screen to work might be too much to ask.
- Multi-option boot menu
- Enhanced security
Unfortunately, enhanced security is not feasable, especially if someone reaches into the case and jumpers the "clear CMOS" jumper.
- Headless booting
I would spend good money on a machine that can boot without a graphics card, and a keyboard. That way, two wires come out the back, and the machine has room for all of my custom ISA cards.
While the idea of implementing a whole new set of BIOS calls -- either to be more powerful or faster, or to run in protected-mode -- sounds appealing, it would be totally useless. DOS won't use it because DOS depends on the old calls, and runs mainly in real-mode anyway. LILO and other low-level bootloaders won't use it because they don't need to. Win95, NT, and Linux won't use it because they already bypass the BIOS and use their own drivers. The most we could hope to do is rewrite the existing drivers and stick them in flash. That just complicates things needlessly. It's easier to have those drivers in the OS to begin with.
I don't see a need to reimplement all of those calls either. Es- pecially since most of them are kludged anyway. Rewriting them to new specs (in 386 Protected mode) could get rid of code bloat in the Linux kernel, and could pave the way for some tiny embed- ded OSs.
In short, we don't have much hope of fixing the basic "unintelligent" nature of the PC hardware platform. :-)
Yup. :)
If anyone can think of a *real* reason to create all those new BIOS calls, then please, let me know. :-)
CA> I tend to agree with you that it would be best to leave CA> filesystem code out of the bios.
I would really like to be able to boot a Linux kernel, specified by partition and filename, without needing a intermediate bootloader. But that is me. :)
Well, rudamentary filesystem code would be acceptible, I think. Enough to find the kernel. How does other command line BIOSs do it?
I can tell my posts are more negative than positive, but I'm not interested in bashing the idea. I'm interested in getting an idea that won't be fruitless, and if people let their imagination run wild (especially in the realm of the PC BIOS), a completely useless, really expensive (time wise that is) project will re- sult. Or that's the way I see it.
-
Benjamin Scott -
Chris Arguin -
David Kennedy -
Pascal Dornier -
Pavel Machek