Hi.
I would like to take this opportunity now to stop and as "Why?" I'm sure it's been brought up, but I don't see the need to rein- vent the wheel when it comes to BIOSs. First off, don't all PCs come with BIOSs? Second, writing a generic BIOS that will encom- pass all the new motherboards, IMO, will be a wasted effort. Aren't the majority of PC chipsets proprietary on how they are initialized for caching, memory configurations, et al? Personal- ly, I see this project as a waste of programming power. As it was said earlier, the only forseeable benefit is to LILO (ini- tially). I don't see much support after that either, unfortu- nately.
The idea of replicating the BIOS programming interface is not a worthy effort either, IMO. Everyone agrees that it is old, ante- quated, and kludged. The idea of rewriting all the BIOS routines anew without the legacy baggage is a good idea, but I don't think that you should "hide" the fact that you are doing it. I think, if you are going to rewrite the BIOS routines correctly, a unused interrupt vector should be chosen, and a completely new set of routines should be written. Or perhaps, simply writing a com- plete set of routines to be loaded overtop of the BIOS, so that any programming wanting the GNU BIOS routines would simply in- clude the object file, and call a initialization routine or two (provided of course they are taking complete control of the sys- tem). Those are my ideas for the current project.
As an offshoot from this project, I have an idea that I can per- sonally use (or, more specifically, that I wanted to use). Ac- cording to the documentation I have, memory locations from C8000h to E0000h are checked at 2k intervals for the sequence "0xAA55" If it is found, the next byte is a "length indicator representing the number of 512-byte blocks in the ROM." Following that is a far code entry point. The entire ROM also has to be checksummed modulo hex 100 and come up to 0. I think this interface can be used to produce a LILO of sorts that can replace the initial boot loader. A command line interface can be supplied, as well as some code that would investigate the current hard drives, and their partition tables. This could produce a BIOS that is simi- lar to many older "minicomputer" style BIOSs. This interface is checked after all of the initialization sequence occured, and be- fore any bootstrapping. That way, a more modern BIOS can be written without the worry of compatibility between all sorts of different hardware. This has other practical values as well. Since every single PC in existance has a ISA bus, but not all PCs have the same BIOS chip (not even the same number of chips, or the same number of pins), this allows for better distribution. It allows faster development time, since you can easily remove a card to boot the machine to a useable state again. (as opposed to gerryrigging some sort of external platform with a mechanical switch.) Also, hardware illiterites are more comfortable in- stalling an ISA card, as opposed to removing chips off of the motherboard.
As for my experience, I have been programming in Assembly lan- guage for 7 years now, concentrating on low level VGA program- ming, rudamentary OS code, as well as custom cards. I have two BIOS listings, one is a 386+ BIOS reverse engineered (obtained freely from x2ftp.oulu.fi I believe). The other is in the back of the IBM Technical Reference Personal Computer AT, 1985. This code is original IBM BIOS code for the 286. (Did you know that they tested each register, conditional jumps and the BOUND in- struction?)
Whichever way the project desides to go, I wouldn't mind helping out. I have experience in this area, and I would like to prac- tice my skills in something, that might, quite possibly, do some- thing, for someone, somewhere. ;)
-- David Kennedy Vic/Linux and Pet/Linux: RPMs coming soon.
I'm quite new to this mailing list, and indeed I was a bit confused about what was going on, but I would like to give some of my thoughts concerning the above discussion...
I believe the main problem of today's BIOSes is that they're designed to run in real mode. A protected mode OS will either have to switch to and from real and protected mode to perform I/O (which isn't very neat, and incurs quite a lot of execution overhead) or ignore the BIOS entirely and provide its own I/O routines (which is a waste of coding effort). It'll be good if there's a BIOS that can provide some sort of protected mode framework (possibly amounting to a microkernel?) within which an OS can access BIOS services in true protected mode. (Proprietary ROM BIOS extension cards will probably have to be modified to fit into this scheme, but that's another story...)