DK = David Kennedy dkennedy@engsoc.carleton.ca DK> Hmm... I certainly hope that I never get a system without an ISA DK> bus. I have way too many specialty cards that require it.
Well, I doubt ISA will ever go away totally, but you may see it relegated to specialty systems. Depending on your application, you may find your existing ISA system suitable forever. Or, it may be time to move your specialty cards over to PCI. :-)
DK> With the dozen or so PC chipsets out there, can all these differ- KD> ent versions of the initialization code be effectively created?
This is an important point. I don't know how things work at that low a level. It is entirely possible that we're biting off more then we can chew. On the other hand, the IBM-PC world is full of de facto standards. We may find much of the chipset support is the same.
DK> This one has been done over and over. But it's done with a BIOS DK> chip on the network card using the technique I discussed before.
I would like to have more control over the network boot process, including specifying host and boot image at boot time. I haven't seen anything that does this using the ROM on a netcard, though I am far from an expert. Being able to "ping" from the boot monitor prompt would be a handy tool, too.
DK> Again, because of the multitude of network boards, I forsee it DK> being very difficult to offer this in a generic BIOS.
We don't have to support every network card ever made. Supporting just a few (ie, NE2000, 35x9, etc) would get us support for a large number of systems. And it is a universal agreement that our firmware code should be modular, allowing the user to select which features (such as drivers) they wish to include in the final firmware image.
DK> This is a rather easy extension. But the more important one is DK> to boot off of any controller type (SCSI, EIDE, ...)
That's a little more complex, but should be doable. I don't think we have to support every SCSI card on the market -- I think it should be possible to select the interrupt services provided by disk controller BIOSes. I'm pretty sure that's what my BIOS does now by offering me a "Boot SCSI or EIDE first?" option.
DK> Actually, all BIOSs (to my knowledge anyway) have extended hard- DK> ware diagnostics. The problem is that nobody knows about it.
Which is effectively the same as not having them. :-) Perhaps it would be better to say "Extended hardware diagnostics which we can *use*". :-)
DK> Unfortunately, enhanced security is not feasable, especially if DK> someone reaches into the case and jumpers the "clear CMOS" DK> jumper.
"It is important to realize that any lock be be picked with a big enough hammer." -- Sun System and Network Admin Manual
In other words, it is impossible to make a system full-proof. But a more intelligent password system, encrypted BIOS passwords, and the like, would be one more step in the right direction. :-)
DK> I would spend good money on a machine that can boot without a DK> graphics card, and a keyboard.
Many systems can, if you set both keyboard and video to "Not Present" in BIOS setup (or with jumpers). But it should be possible to do a better job. Of course, some hardware may just flat-out not work without (for example) a VGA card present, but that's bad hardware, not our fault. :-)
DK> and the machine has room for all of my custom ISA cards.
What exactly do all these custom ISA cards *do*? <G>
me> While the idea of implementing a whole new set of BIOS calls -- either me> to be more powerful or faster, or to run in protected-mode -- sounds me> appealing, it would be totally useless.
DK> I don't see a need to reimplement all of those calls either. Es- DK> pecially since most of them are kludged anyway. Rewriting them DK> to new specs (in 386 Protected mode) could get rid of code bloat DK> in the Linux kernel, and could pave the way for some tiny embed- DK> ded OSs.
I think you missed me point entirely. What I said was, reimplementing all the BIOS calls (or creating new ones) to provide a protected-mode interface would be pointless. See my previous message for the reasons why. :-)
DK> Well, rudamentary filesystem code would be acceptible, I think. DK> Enough to find the kernel.
That's all I'm taking about. I don't mean full read/write/accounting support. Just enough to find the kernel file on disk, load it into memory, and boot it. Nothing more.
DK> How does other command line BIOSs do it?
Some just pass control to a secondary boot loader using a standard interface (I'm told Suns do it this way). Others (eg, MILO for the Alpha) actually include Linux filesystem drivers into the firmware, giving you the ultimate in flexability. I'm suggestion something in-between. :)
-- Ben hawk@ttlc.net
--- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com