OpenBIOS

openbios@openbios.org

4297 discussions

Re: [OpenBIOS] OpenBIOS: reality check
by David Kennedy 24 Feb '98

24 Feb '98

On Tue, 24 Feb 1998, Stefan Reinauer wrote: > > 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. > > Wrong. Current BIOSs have a simple MSDOS system in their int-Code. MSDOS > even doesn't have it's own filesystem code afaik.. According to all the BIOS code I have read, BIOSs do not have any filesystem code. As outlined before, all they have is sector, cylinder and head code. > > 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. > > Again, modern PC Chipsets allow reading the exact RAM configuration out of > their registers Yes, in a proprietary way. 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.

2 1

Hard drives, CMOS/VRAM and some general ideas
by Alle Metzlar 24 Feb '98

24 Feb '98

This past weekend I have subscribed to the OpenBIOS mailinglist, and it took me some time to read all contributions, except for some in the archive. Following are my thoughts in this discussion: CMOS/NVRAM Older PCs use a CMOS of 64 bytes, newer (486 and up) use 128 bytes. Some other systems use up to 4K or 8K of CMOS (MCI/EISA). The first 16 bytes of CMOS are reserved for RTC use: 00h - 09h Time and date fields 0Ah Status Register A 0Bh Status Register B 0Ch Status Register C 0Dh Status Register D 0Eh Diagnostic Status Register 0Fh Shutdown Register The following 32 bytes are most commonly used for ISA configuration data, and the last 16 bytes are generally used for BIOS-specific configuration data, such as Boot sector virus-protection, security, ROM shadow config, and extended CMOS checksum. An additional 64 bytes may be available in the Extended CMOS RAM, incorporated in many chipsets to store advanced config info. >From space in CMOS RAM 16 bytes less are available. Hard disk drives BIOS CHS limits to 1024/255/63, thus supporting up to 8.0325 Gb. IDE CHS limits to 65,536/16/255, thus supporting up to 130.56 Gb. Thus the overall limits are 1024/16/63, supporting only up to 504 Mb. A little resize of storage in BIOS/CMOS would break those limitations, as Microid Research may have done with its MR BIOS. As far as I know the MR BIOS has CHS support for 16384/255?/63? (128.52 Gb). It already did in 1990! I have used a 2 Gb EIDE drive in an old 386DX (1989) ISA machine with an MR BIOS v1.51, though advanced PIO/DMA modes were not available. Some sort of translation is used however, but I haven't figured that out. It isn't LBA according to WD/Phoenix for sure. By the way, MR BIOS supports installation of 8 hard drives and 4 floppy drives, for some years now, and you can boot from all of these. OK, there is the idea of designing an OpenBIOS. Are there any general ideas on how this OpenBIOS should be designed? Most BIOSses still have the IBM compatibility, that is compatibility to the older PC and XT standards, by maintaining a list of vectors to the IBM-compatible vector (AMI calls this the ROM Compatibility Table, Phoenix calls this COMPAS or Compatibility Structure). And what about the INTs. As I recall, Intel reserved 32 ints to be CPU ints. With the 8088 just a few were used, and IBM began to use all non-used but reserved ints for their PC BIOS, which means that we now are stuck up with several ints being both BIOS and Hardware/CPU ints, such as 05h, 10h, 11h, and 12h. Are there any ideas on this, including some possible work-around? BIOS should at least consist of three parts: Power-On-Self-Test (test and initialize various components, and eventually the bootstrap loader), System BIOS (providing the interface between OS and hardware: interrupts), and a setup utility (system configuration). The setup util should be in the BIOS itself, or a special key(combination) should be available during POST if things go wrong, and you can't access the setup program on disk. The setup program should be functional, and doesn't have to have great looks (as the AMI WinBIOS?). -------------------------------------------------------------------------------------------- Alle Metzlar Matrix Technologies P.O. Box 40, NL 1724 ZG Oudkarspel The Netherlands Tel: (+31) 226 316889 Fax: (+31) 226 312157 EMail: matrix(a)xs4all.nl WWW: http://www.xs4all.nl/~matrix/ (Matrix Technologies' BIOS Web) -------------------------------------------------------------------------------------------- Author of: Het BIOS boekje, Uitg. Pim Oets, ISBN 90-5722-013X Das BIOS Buch, Franzis' Verlag, ISBN 3-7723-4832-7 Die BIOS CD-ROM, Franzis' Verlag, ISBN 3-7723-8612-1 --------------------------------------------------------------------------------------------

1 0

Re: [OpenBIOS] OpenBIOS: reality check
by Pascal Dornier 23 Feb '98

23 Feb '98

>Is your TinyBIOS commercial or is it somewhere available so that we could >have a look at it? ;-) tinyBIOS is a commercial product. At this point I don't think I can afford to give away the farm. I could potentially release the source for non-commercial use only, but not under GPL. >I thought about USB keyboards I think USB keyboards are a lousy idea. I'd rather use USB ports for devices that really need the bandwidth, and are a hassle to hook up otherwise, such as a scanner. Once you get above two USB devices, you will need a hub, and end up with a desk encrusted in USB cables... >Wrong. Current BIOSs have a simple MSDOS system in their int-Code. MSDOS >even doesn't have it's own filesystem code afaik.. News to me. My BIOS works pretty well without any file system. The only place where some kind of file system is needed is for CD-ROM boot, which I don't support at this point. >> 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. > >Again, modern PC Chipsets allow reading the exact RAM configuration out of >their registers Guess who sets this configuration ? The BIOS. Do you seriously think a PC manufacturer would waste $0.50 on a input port to read the presence detect bits, if he can detect the memory configuration in software, and avoid compatibility problems with SIMMs that don't have the right configuration ? PC designers would sell their grandmother for savings of $10 a system... -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)
by Ben Pfaff 23 Feb '98

23 Feb '98

> Why not? Award BIOS does this, Windows 95 does this. As we participate at > "The right thing to do[tm]" we should be allowed to do so, too. Microsoft does a lot of things the wrong way :) Microsoft flashes the BIOS? Then won't our BIOS, or part of it, get blown away, if we're not careful? I belive someone mentioned that there limits to how many times you can flash most chips. If so, then we definitly don't want to do it every bootup, especially if we are supporting DOS/Windows :) I don't believe that we were going to flash it every bootup, just every time that the user decides to changes his boot settings or whatnot. That should be fewer than 100,000 times, I think, normally. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)
by Chris Arguin 23 Feb '98

23 Feb '98

On Tue, 24 Feb 1998, Stefan Reinauer wrote: > On Fri, 20 Feb 1998, Chris Arguin wrote: > > > All things considered, you really don't want to flash the BIOS too often, > > and especially not behind the users back, so to speak. As pointed out > > before, we could always reserve a parition on the disk, which would allow > > for extra code and data. This just strikes me as kinda kludgy... > > Why not? Award BIOS does this, Windows 95 does this. As we participate at > "The right thing to do[tm]" we should be allowed to do so, too. Microsoft does a lot of things the wrong way :) > This allows having no disk at all. It could be possible, too, to receive > BIOS settings over the net (or from disk). Maybe this should be made > dependent on whether you have a disk or networking card or not. I think everyone has agreed that this will be modular enough that if you don't like a feature, don't use it. I belive someone mentioned that there limits to how many times you can flash most chips. If so, then we definitly don't want to do it every bootup, especially if we are supporting DOS/Windows :) -- Chris Arguin | "Multiple exclamation marks are a sure sign of a Chris.Arguin(a)unh.edu | diseased mind." - Eric, Terry Pratchett --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] Licensing of the code.
by Pavel Machek 23 Feb '98

23 Feb '98

Hi! > > > Or did you mean the actual microcode update, as opposed to the code which > > > loads it into the CPU? > > > > I mean the actual microcode update. > > So what is at issue? The only problem I can forsee is getting Intel to > give us the Microcode update, since they are not usually publically > available. Intel has had a Microcode fix to the F00F bug for awhile, but > is only releasing it to specific vendors, many of whom aren't even > bothering to use it. Wouldn't you like to be able to take that F00F kludge > out of Linux? Wrong. F00F workaround is not based on microcode update. And linux already does it :-). Pavel -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

RE: [OpenBIOS] User-extentions
by William A. Arbaugh 22 Feb '98

22 Feb '98

On Saturday, February 21, 1998 2:37 PM, Benjamin Scott [SMTP:hawk@ttlc.net] wrote: > >>> Remember that the CMOS settings are stored in the NVRAM, not the > >>> flash. Now the question is how big is the NVRAM? I don't think we > >>> have room for this. > >> > >> Why do these have to be stored in the NVRAM? Can't we reserve 1K or > >> so of flash for this sort of thing? Or can't you erase and replace > >> just a little bit of flash at a time? > > > > All things considered, you really don't want to flash the BIOS too > > often,and especially not behind the users back, so to speak > NVRAM varies from machine to machine some of the chips now have several K available since a number of BIOS' store the ESCD (needed for PnP) info in NVRAM rather than flash. Most of the flash ROMs support up to 100,000 reprogramming cycles. > Flashing the BIOS often would be a Bad Thing. There is a limit to how > often you can write flash ROM. It would take awhile to hit it, but it > is a real limit. Plus, I think you need to erase flash ROM in banks of > a certain size. At least, I've seen plenty of stuff that worked that > way and that way only. > You do need to flash in blocks. The size of the block depends on the chip with the modern chips now having small blocks for storing configuration information, e.g. the Intel 28F001BX-T (128K)has two 4KByte parameter blocks plush a 8KB boot block. The boot block has extra HW protection to prevent accidental reprogramming. This is how the Intel boards prevent you from completely trashing your bios by mistake and ruining the motherboard (since the flash chips are not removable on Intel boards). > If we're going to store boot configuration info on disk, we might as > well just go back to using LILO. I want something that can boot your > selected OS without the need of loading from the disk. > So do Microsoft and Intel. This is why they've put together the NetPC spec, and why there is etherboot and netboot now available for Linux. You can burn/flash a ROM today that you can put in your ethernet card's ROM socket and do a net boot with out every touching your hard disk. Take a look at http://www.slug.au/etherboot. Bill --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by Alexander Viro 22 Feb '98

22 Feb '98

On Sun, 22 Feb 1998, Benjamin Scott wrote: > Pascal Dornier wrote: > > 1. DOS translates logical block address into Cylinder / Head / Sector > > based on BIOS parameters. This is constrained by the 10 bit limit > > on cylinder and 6 bit on sector number (and sector numbers start > > at 1, which further mucks things up). > > I never really thought about it, but yeah, I guess DOS's sector > numbers are a form of LBA, aren't they? Is the LBA DOS uses the same as > the LBA used by IDE? How could it be, given that DOS does start sector > numbers at 1. Does the BIOS provide an INT13 extension/alternative that > supports LBA directly? I've never looked at this stuff this closely > before. Pointers to info are also welcome. :) No, they aren't. DOS sectors are linear within the partition. And that's it. It uses damned amount of layers: linear in the partition -[int25/26]->3D-[BIOS Int13]-->3D----[IDE,EIDE] \->linear[EIDE,SCSI] For Linux: linear -[driver]-->3D----[IDE] \->linear[EIDE,SCSI] Moreover, BIOS in LBA mode means the following: translate DOS 3D into linear and use another set of hardware commands. Interface DOS/BIOS remains the same. > > > 2. The BIOS translates this either into another CHS > > What I don't understand is: If DOS and Linux coexisting on the same > system, and you have BIOS geometry translation on to support DOS, Linux > still works. But Linux doesn't use the BIOS. So how does that work? It uses either linear addresses or native drive CHS. All point of BIOS translation is to map CHS addresses provided by DOS into the real addresses. > Does Linux do the remapping instead of the BIOS? There must be a What should it remap? Who will feed CHS addresses to Linux driver? For Linux the disk is a 1-dimensional array of sectors. For DOS it's 3-dimensional one. Both are _ordered_. And there is a real disk geometry. It's also an ordered sequence of sectors. These orderings should be the same. Everything else is irrelevant. Driver (or BIOS, in DOS case) should get a position in array (1D for Linux, 3D for DOS) and transform it into the disk's one. And vice versa. All (E)IDE disks can be addressed as 3D arrays _and_ there is a command that makes disk to say you its dimensions. New disks can be addressed as 1D arrays. Now, for DOS we need to choose some dimensions suitable for DOS (Cyl<=1024, i.e.) and make a correspondence between DOS 3D coordinates and disk 3D or 1D. The only tricky part is choosing the dimensions for DOS, for correspondence should preserve the order and disk dimensions are known. That's the work of BIOS translation. For Linux we have to make either correspondence between 1D and 1D [preserving the order!], or correspondence between 1D and 3D with known dimensions [preserving the order, again]. If we know that the order is the same for DOS and Linux we can forget (in Linux) about DOS internal pecularities. And thus forget about BIOS translation. > standard method of geometry translation if that is the case (there > prolly is, I just never dug that far). > > > The only right thing to do is put up with this nonsense during boot, then use LBA mode. > > Or possibly, one of the things we can do in this project is implement > a new interface for the disk I/O, for use with advanced OSes and/or > bootloaders, which supports LBA directly, cleaning things up > considerably. Oh, sure, it would break some things horribly, but that's > why it would be an option. Hmm. Then you can take Linux IDE driver and put it into BIOS. Yep, it will break some things. DOS, for example. And Virus95, for it is loaded by BIOS drivers. And LILO (well, _that_ is not a problem for we have the source, but DOS & Virus...). NT will survive, for it uses its own loader. And consider the fact that BIOS access is _slow_. So Linux will still use its own driver (in regular RAM) for speed reasons. The only thing that will gain something would be LILO (rewritten, i.e.). > > We might even be able to implement a better partition table format > (like the BSD format). The MS partition table format is absolutely > horrid at times. Not a BIOS problem. For BIOS partitions don't exist. They are just linear chunks of disk. It's determined by OS. Even in case of DOS it is so (in MSDOS.SYS, as far as I remember). Oh, and boot loader have some reduced knowledge of these matters. Then it's a question of master boot loader. Al > > I know, I know, why reinvent the wheel. Because we can, dang it, > that's why! :-) > > -- Ben <hawk(a)ttlc.net> > > > --- > OpenBIOS -- http://www.linkscape.net/openbios/ > openbios-request(a)linkscape.net Body: un/subscribe > Problems? dcinege(a)psychosis.com > > --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by Pascal Dornier 22 Feb '98

22 Feb '98

From: Benjamin Scott <hawk(a)ttlc.net> To: openbios(a)linkscape.net <openbios(a)linkscape.net> Date: Sunday, February 22, 1998 6:03 Subject: Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...) > I think it might be better to say that re-implementing things like >INT13 in protected-mode would be pointless. The few things that modern >OSes actually do *use* the BIOS for are definate canidates for >improvement and possible protected-mode reimplementation. However, >"BIOS32" implies it may be protected-mode already. Anyone know more >about this? Yes, 32 bit protected mode. See the PCI BIOS spec. > While I do agree in theory, memory space limitations may force us to >link the BIOS together before programming the flash. Which isn't really >a big deal. If you own all the sources, you can save yourself the complexity of linking. I don't even use a object linker, my assembler is fast enough to assemble the whole BIOS in about 60 ms. > Actually, to the list in general: Does anyone know exactly *where and >how* geometry translation occurs? I've been thinking it must occur in >the motherboard BIOS for onboard EIDE controllers. But we already know >many OSes bypass the BIOS. I was assuming they were still talking to >the EIDE controller through the BIOS, just via a different route. Is >that correct? Or is geometry translation implemented in the EIDE >controller chipset itself? Or something else? There are multiple levels of geometry translation. It's a classic example of Winchester Mystery House software design. Read it and weep. 1. DOS translates logical block address into Cylinder / Head / Sector based on BIOS parameters. This is constrained by the 10 bit limit on cylinder and 6 bit on sector number (and sector numbers start at 1, which further mucks things up). 2. The BIOS translates this either into another CHS (the drive can only handle 4 bits for the head number, but 16 bits for the cylinder number, and 8 bits for the sector). Alternatively, the CHS value is converted into a logical block address. 3. The drive translates the CHS into a logical block number, then converts that into the real CHS values (which is not a straight division as the number of sectors per track varies). The only right thing to do is put up with this nonsense during boot, then use LBA mode. -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by Benjamin Scott 22 Feb '98

22 Feb '98

WA = William A. Arbaugh <waa(a)dsl.cis.upenn.edu> WA> Not true actually, Linux does use some bios32 functions for PCI WA> support. My guess is that they'll still need some BIOS level support WA> for PnP, Power management, and not to mention DPMI etc. You're right of course. I had forgotten about the PnP stuff entirely. I'm not sure how DPMI works, but it's a fair bet it needs BIOS support, too. I think it might be better to say that re-implementing things like INT13 in protected-mode would be pointless. The few things that modern OSes actually do *use* the BIOS for are definate canidates for improvement and possible protected-mode reimplementation. However, "BIOS32" implies it may be protected-mode already. Anyone know more about this? DW = David Woodhouse <Dave(a)imladris.demon.co.uk> CA = Chris Arguin <Chris.Arguin(a)unh.edu> DW> Regarding the module support: DW> We can either link them at flash time, or have the BIOS search through DW> the available modules when it boots. I prefer the latter, While I do agree in theory, memory space limitations may force us to link the BIOS together before programming the flash. Which isn't really a big deal. DW>> Other than that, I don't see any point in extra protected-mode DW>> functionality - as you rightly say, anything running in protected mode DW>> is going to have its own drivers already. CA> Not to be too purest... but is that the "Right Way"? The BIOS is CA> *supposed* to abstract that away. It doesn't. Maybe it should... Originally, yes, the IBM-PC BIOS was a hardware abstraction layer. Rather then, say, having disk device drivers, you called INT13 and got support that way. Now, the original IBM-PC platform has been extended so much about the only thing *left* is the original BIOS service code, like INT13. One might argue we should "fix" that, that we should put all that hardware abstraction back in. Other platforms (the Mac comes to mind) accomplish this very well. A standard hardware abstraction API has obvious advantages. However, it is typcially accomplished by providing a low-level API in firmware to which devices talk to. Each device implements the support for this API. Due to the open nature of the IBM-PC platform, this is obviously not going to happen. The only other way to do it would be to write device drivers for each and every device on the system, incorporate them into firmware, and let the OS call our new hardware abstraction API. Besides the fact that this would be totally redundent, I don't know that we have the flash ROM space to accomplish this. Even more important, I don't think it *would* be the Right Thing to do. The IBM-PC mindset has become such that device abstraction occurs at the OS level. This allows greater flexability and faster development, something that has kept the IBM-PC line going where others have failed. Software is easier to change then firmware. I don't really think that we should try to go back to the "old way" of doing things, despite the advantages. If you really want hardware abstraction in firmware, buy a Mac. <grin> CA> On a related note, I just bought a 8 Gig SCSI disk. CA> Due to limitations of my SCSI controller, [snip] CA> I now have an 8GB Linux Disk. That is not a bad thing, but it wasn't CA> what I was intending. So there is another bug for us to fix :) I don't know that we can. Geometry translation for SCSI would be handled by your SCSI controller and its BIOS, not the motherboard BIOS (which would only control EIDE gemometry translation). Actually, to the list in general: Does anyone know exactly *where and how* geometry translation occurs? I've been thinking it must occur in the motherboard BIOS for onboard EIDE controllers. But we already know many OSes bypass the BIOS. I was assuming they were still talking to the EIDE controller through the BIOS, just via a different route. Is that correct? Or is geometry translation implemented in the EIDE controller chipset itself? Or something else? -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Jump to page: