ROM Content
Multiple Code Images
The PCI spec permits the inclusion of more than one code image in a PCI device ROM. Each code image would contain a copy of the device driver in a specific machine code, or in interpretive code (explained later). The configuration software can then scan through the images in the ROM and select the one best suited to the system processor type. The ROM might contain drivers for various types of devices made by this device's vendor. The code image copied into main memory should match up with the function's ID. To this end, each code image also contains:
the Vendor ID and Device ID.
This is useful for matching up the driver with a function that has a vendor/device match.
the Class Code.
This is useful if the driver is a Class driver that can work with any compatible device within a Class/SubClass. For more information, see "Class Code Register" on page 774.
Figure 23-3 on page 877 illustrates the concept of multiple code images embedded within a device ROM. Each image must start on an address evenly-divisible by 512. Each image consists of two data structures, as well as a run-time code image and an initialization code image. The configuration software interrogates the data structures in order to determine if this is the image it will copy to main memory and use. If it is, the configuration software:
Copies the image to main memory, Disables the expansion ROM's address decoder, Executes the initialization code, If the initialization code shortens the length indicator in the data structure, the configuration software deallocates the area of main memory that held the initialization portion of the driver (in Figure 23-4 on page 879, notice that the initialization portion of the driver is always at the end of the image).
The area of main memory containing the image is then write-protected.
The sections that follow provide a detailed discussion of the code image format and the initialization process.
Format of a Code Image
General
Figure 23-4 on page 879 illustrates the format of a single code image. The image consists of the following components:
ROM Header.
Described in "ROM Header Format" on page 879. Also contains a 16-bit pointer to the ROM data structure.
ROM Data Structure.
Described in "ROM Data Structure Format" on page 881. Contains information about the device and the image.
Run-time code.
This is the portion of the device driver that remains in main memory after the OS loads and that remains available for execution on an on-going basis.
Initialization code.
This is the portion of the device driver that is called and executed immediately after loading the driver into main memory. It completes the setup of the device and enables it for normal operation. It must always reside at the end of the image so it can be abbreviated or discarded after its initial execution at system startup.
ROM Header Format
The ROM Header must be located at the very start of each image within the ROM (so a better name for it might be the Code Image Header). Table 23-1 on page 880 defines the format of the Header and the purpose of each field is further defined in the paragraphs that follow. The offset specified in the table is the offset from the first location in this ROM code image.
Table 23-1. PCI Expansion ROM Header Format|
00h | 1d | 55h | ROM signature byte one. The first two bytes must contain AA55h, identifying this as a device ROM. This has always been the signature used for a device ROM in any PC-compatible machine. | 01h | 1d | AAh | ROM signature byte two. | 02h - 17h | 22d | n | Reserved for processor architecture unique data. See Table 23-2 on page 881. This block of 22d locations is reserved for processor/architecture unique data. For PC-compatible environments and images that identify the code as Intel x86-compatible in the Code Type field (see "Code Type" on page 885) of the ROM data structure, the PCI spec defines the structure of the processor/architecture unique data area in the image Header. For non-PC compatible environments, the content of this structure is architecture-specific. Table 23-2 on page 881 defines the fields that must be supplied for PC-compatibility. The offset specified in the table is the offset from the first location of this ROM code image. | 18h - 19h | 2d | n | Pointer to PCI Data Structure. Since this is a 16-bit pointer, the data structure can be anywhere within 64K forward of the first location in this code image. This is the 16-bit offset (in little-endian format) to the ROM data structure within this code image. It is an offset from the start address of this code image. Because this is only a 16-bit offset from the first location of this code image, the data structure must reside within 64KB forward of the first location of this code image. |
Table 23-2. PC-Compatible Processor/Architecture Data Area In ROM Header|
02h | 1 | Overall size of the image (in 512 byte increments). The total size of the runtime code plus the initialization code (runtime code + initialization code = initialization size). This sum is not necessarily the "overall size of the image." The overall size of the image (Image Length) could be greater than the initialization size. The Image Length or Image size is what specifies where the next image in the ROM starts, while the Initialization size (a better name for this field) is the actual code size that is copied into RAM. | 03h-05h | 3 | Entry point for the initialization code. Contains a three-byte, x86 short jump to the initialization code entry point. The POST performs a far call to this location to initialize the device. | 06h-17h | 18d | Reserved (for application-unique data, such as the copyright notice). |
ROM Data Structure Format
As stated earlier, the ROM Data Structure associated with each code image must reside within the first 64KB of each code image. The Data Structure must reside within the run-time code (assuming there is one). It's possible that a ROM may not contain a device driver for the device, but only an initialization module that tests the device and gets it ready for normal operation. If there isn't a run-time code module, the Data Structure must reside within the initialization code. The Data Structure's format is defined in Table 23-3 on page 882 and the purpose of each field is further defined in the sections that follow the table.
Table 23-3. PCI Expansion ROM Data Structure Format|
00h | 4 | Signature consisting of the ASCII string "PCIR" (PCI ROM). | 04h | 2 | Vendor ID.
This is a duplication of the Vendor ID found in the function's configuration Vendor ID register (see "Vendor ID Register" on page 773). The ROM may contain multiple code images of the desired Code Type (e.g., x86 code), but they may be for different devices produced by the same (or a different) vendor.
In order to ensure that it loads the correct one, the configuration software compares the Vendor ID, Device ID, and Class Code values contained in this Data Structure to those found in the function's Vendor ID, Device ID, and Class Code configuration registers. | 06h | 2 | Device ID.
This is a duplication of the Device ID found in the function's configuration Device ID register (see "Device ID Register" on page 773). See explanation of Vendor ID field in this table. | 08h | 2 | Reserved. Was the Pointer to the Vital Product Data.
The pointer to the optional VPD is provided as an offset from the start location of the code image. The 2.2 PCI spec redefined this as a Reserved bit field and the optional VPD (if present) was moved to the device's configuration registers. Refer to "Vital Product Data (VPD) Capability" on page 848. | 0Ah | 2 | PCI Data Structure Length in bytes, little-endian format. | 0Ch | 1 | PCI Data Structure Revision.
The Data Structure format shown in this table is revision zero. | 0Dh | 3 | Class Code.
This is a duplication of the Class Code found in the function's configuration Class Code register (see "Class Code Register" on page 774). See explanation of Vendor ID field in this table. | 10h | 2 | Image length.
Code image length in increments of 512 bytes (little-endian format). The total size of the runtime code plus the initialization code (runtime code + initialization code = initialization size). This sum is not necessarily the "overall size of the image." The overall size of the image (Image Length) could be greater than the initialization size. The Image Length or Image size is what specifies where the next image in the ROM starts, while the Initialization size (a better name for this field) is the actual code size that is copied into RAM. | 12h | 2 | Revision level of code/data in this code image. | 14h | 1 | Code type.
See "Code Type" on page 885. | 15h | 1 | Indicator byte.
Bit 7 indicates whether this is the last code image in the ROM (1 = last image). Bits [6:0] are reserved and must be zero. | 16h | 2 | Reserved. |
ROM Signature
This unique signature identifies the start of the PCI Data Structure. The "P" is stored at offset 00h, the "C" at offset 01h, etc. "PCIR" stands for PCI ROM.
Vendor ID field in ROM data structure
As stated in Table 23-3 on page 882, the configuration software does not select a code image to load into system memory unless it is the correct Code Type and the Vendor ID, Device ID, and Class Code in the image's Data Structure match the function's respective configuration registers. The ROM may contain code images for variations on the device, either from the same vendor or supplied by different vendors.
Device ID in ROM data structure
Refer to the description of the Vendor ID field in the previous section.
Pointer to Vital Product Data (VPD)
The 2.2 PCI spec defined this as a Reserved field and the optional VPD (if present) was moved to the device's configuration registers. Refer to "Vital Product Data (VPD) Capability" on page 848. The following description is only provided as historical information.
The VPD pointer is the offset (from the start of the code image) to the Vital Product Data area. The offset was stored in little-endian format. Because the offset is only 16-bits in size, the Vital Product Data area had to reside within the first 64KB of the image. A value of zero indicates that the image contains no Vital Product Data. The revision 2.0 PCI spec said that the pointer was required, but the 2.1 PCI spec removed that requirement. If no device ROM was present on a device other than the one containing the VPD, there was only one image and it contained the VPD. If multiple code images were present, each image contained VPD for that device. The VPD data that described the device may be duplicated in each code image, but the VPD that pertains to software may be different for each code image.
PCI Data Structure Length
This 16-bit value is stored in the little-endian format. It defines the length (in bytes) of the PCI Data Structure for this image.
PCI Data Structure Revision
This 8-bit field reflects the revision of the image's Data Structure. The currently-defined data structure format (as of revision 2.2 PCI spec) is revision zero.
Class Code
The 24-bit class code field contains the same information as the Class Code configuration register within the function's configuration header. The configuration software examines this field to determine if this is a VGA-compatible interface. If it is, the ROM code image must be copied into system memory starting at location 000C0000h (for compatibility). Otherwise, it will typically be copied into the C0000h-through-DFFFFh region in a PC-compatible machine. Also refer to "Vendor ID field in ROM data structure" on page 883.
Image Length
This two-byte field indicates the length of the entire code image (refer to Figure 23-4 on page 879) in increments of 512 bytes. It is stored in little-endian format. The total size of the runtime code plus the initialization code (runtime code + initialization code = initialization size). This sum is not necessarily the "overall size of the image." The overall size of the image (Image Length) could be greater than the initialization size. The Image Length or Image size is what specifies where the next image in the ROM starts, while the Initialization size (a better name for this field) is the actual code size that is copied into RAM.
Revision Level of Code/Data
This two-byte field reflects the revision level of the code within the image.
Code Type
This one-byte field identifies the type of code contained in this image as either executable machine language for a particular processor/architecture, or as interpretive code.
Code Type 00h = Intel x86 (IBM PC-AT compatible) executable code. Code Type 01h = OpenBoot interpretive code. The Open Firmware standard (reference IEEE standard 1275-1994) defines the format and usage of the interpretive code. A basic description of the Open Firmware standard can be found in "Introduction to Open Firmware" on page 888. Code Type 02h = HP PA/RISC executable code (added in the 2.2 PCI spec). Code Type 03h = Extensible Firmware Interface (EFI).
The values from 04h-through-FFh are reserved.
Indicator Byte
Only bit seven is currently defined.
Bits [6:0] are reserved.
| 
No comments:
Post a Comment