68 lines
2.5 KiB
Text
68 lines
2.5 KiB
Text
|
|
|
|
BIOS Device Mapping Techniques
|
|
|
|
|
|
NOTE: This is only necessary to do for hard disks. Floppies are
|
|
already easy to determine. (IDE are in the order of "Master from
|
|
controller on INT 14, Slave from controller on INT 14, Master from
|
|
controller on INT 15, and Slave from controller on INT 15, and
|
|
always come before SCSI)
|
|
|
|
|
|
Both of these techniques should be usable from any PC OS, and neither
|
|
require any special support in the drivers themselves. This document
|
|
will be flushed out into detailed explanations, particularly for #2
|
|
below.
|
|
|
|
The general rule is that technique #1 is the quick and dirty solution.
|
|
It works most of the time, but doesn't cover all the bases, and is
|
|
relatively simple.
|
|
|
|
Technique #2 is much more complex, but it has potential to solve the
|
|
problem under all conditions, plus allow access of the remaining
|
|
BIOS devices when not all of them have OS drivers.
|
|
|
|
|
|
-- BIOS device mapping technique #1 --
|
|
|
|
Before activating ANY of the device drivers, gather enough data
|
|
from similar sectors on each of the disks such that each one can be
|
|
uniquely identified.
|
|
|
|
After activating the device drivers, compare data from the drives
|
|
using the OS drivers. This should hopefully be sufficient to provide
|
|
such a mapping.
|
|
|
|
Problems: (1) The data on some BIOS devices might be identical (so
|
|
the part reading the drives from the BIOS should have some mechanism
|
|
to give up), and (2) There might be extra drives not accessible from
|
|
the BIOS which are identical to some drive used by the BIOS (so it
|
|
should be capable of giving up there as well).
|
|
|
|
|
|
-- BIOS device mapping technique #2 --
|
|
|
|
This first step may be unnecessary, but first create copy-on-write
|
|
mappings for the device drivers writing into PC RAM. Keep the original
|
|
copies for the "clean BIOS virtual machine" to be created later.
|
|
|
|
For each device driver brought online, determine which BIOS devices
|
|
become inaccessible by:
|
|
|
|
-- Creating a "clean BIOS virtual machine".
|
|
-- Set the I/O permission map for the I/O area claimed by the device driver
|
|
to no permissions (neither read nor write).
|
|
-- Access each device.
|
|
-- Record which devices succed, and those which try to access the
|
|
"restricted" I/O areas (hopefully, this will be an "xor" situation).
|
|
|
|
For each device driver, given how many of the BIOS devices were subsumed
|
|
by it (there should be no gaps in this list), it should be easy to
|
|
determine which devices on the controller these are.
|
|
|
|
In general, you have at most 2 disks from each controller given BIOS numbers,
|
|
but they pretty much always count from the lowest logically numbered devices
|
|
on the controller.
|
|
|
|
|