[OpenBIOS] BIOS extensions are pointless (was: More comments...)

Alexander Viro viro at math.psu.edu
Sun Feb 22 14:39:18 CET 1998



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 at ttlc.net>
> 
> 
> ---
> OpenBIOS -- http://www.linkscape.net/openbios/
> openbios-request at linkscape.net   Body: un/subscribe
> Problems?  dcinege at psychosis.com
> 
> 


---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request at linkscape.net   Body: un/subscribe
Problems?  dcinege at psychosis.com



More information about the openbios mailing list