Re: [PATCH] EDD: Check for correct EDD 3.0 length

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> Phoenix BIOS (linked at the first mail of the thread) and it does not have
> enough info even for ATA.

<History lecture mode on>

In the beginning was the CMOS, and the CMOS was good.

Then people started adding extra drives and screwing around with mappings.

For this period there are a set of rituals (and I use the word
intentionally) for finding the geometry data and configuration mappings
which depend on which of the major religions your BIOS belonged to.

The entire thing got out of hand and so EDD was born

The base Phoenix spec is 1.1 not 3.0 and was published in 1995. It
assumes legacy mappings. It does have enough information for
compatibility mode ATA, which is all there was in the BIOS at the time.
Closely related to all this is the emergency of the Compaq/Phoenix/Intel
BIOS Boot Specification v1.01 (1996).

The follow on Phoenix spec is 3.0 (rev 0.8) and was published in
1998. That one addresses IEEE 1394 and some other bits. It does support
PCI bus device paths and lun identification to some extent but isn't
adequate for all complex topologies but is for most.

The T13 draft D3186 was published in 2000 and leads on to the EDD 4.0
proposal of 2008 which generally is what people consider EDD 3.0

So I think you have your specifications confused too.

I would suggest you read and compare the documents. In particular please
read Phoenix EDD 3.0 and pay attention to the sections 5.8-5.8.3 which
cover the device path and explain how EDD3.0 describes the actual device
to BIOS mapping. In particular the DPT interface path identifies the PCI
bus/devfn and the DPT device path identifiers if the unit is master or
slave.

In the absence of the device/interface path being entirely unique (or
indeed present at all) you use the DPTE words 0-3 to identify the mapping
for any SFF style ATA interface. This is sufficient to identify all non
MMIO configurations. The DPTE in 3.0 doesn't allow for pure MMIO
controllers. You just walk the address back to a device mapping and to
the controller/port in question.

</>



Alan