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.