bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

about BIOS drive mapping


From: Yoshinori K. Okuji
Subject: about BIOS drive mapping
Date: Thu, 10 Jan 2002 12:18:40 +0900
User-agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryoae) APEL/10.3 Emacs/20.7 (i686-pc-linux-gnu) MULE/4.0 (HANANOEN)

Although the current draft version of the Multiboot Specification says
that a boot loader can pass I/O ports used by BIOS drives (so that a
kernel utilize the information to map BIOS drives to OS devices more
reliably), I'm thinking of a different thing.

As you know, the I/O ports method isn't perfect (for example, you
cannot distinguish which drive is a master or a slave). The right way
is to investigate BIOS drives in more details (e.g. which bus a drive
is attached). One way is to do that in the OS level. That is to say, a
kernel makes a vm86 environment on its own (as FreeBSD and Linux do),
writes magic code to fixed locations of devices, uses BIOS calls to
determine which BIOS drive corresponds to which device, and restores
the original data.

As that above is an OS-level solution, we should consider another
approach (I'm not sure if we should, really). Then, I find that INT
13, AH = 48h (GET DRIVE PARAMETERS) gets rich information on a BIOS
drive, if your BIOS supports IBM/MS INT 13 Extensions version 2.0 or
above. The parameter table supported by 2.0 or above contains the
physical I/O port address, disk-drive control port address, etc. With
version 3.0, it gets even the interface type (such as "ATA").

Of course, this solution is only for newer machines. But, if there is
no perfect way, isn't that acceptable?

Okuji



reply via email to

[Prev in Thread] Current Thread [Next in Thread]