Chapter 5
Industry Standard Initialization
Beware of geeks bearing formulas.
—Warren Buffett
As the previous chapter begins to highlight, the industry standards that can be applied to today’s computing systems are vast and varied. Understanding their impact on systems and devices is key to creating a robust and stable pre-OS firmware. By some counts, it can be up to 70 specifications that apply:
1.UEFI
a.UEFI Specification Unified Extensible Firmware Interface Specification v2.7
b.Platform Initialization Specification v1.2 (for UEFI)
2.PCI
a.PCI Express Base Specification
b.PCI Local Bus Specification
c.PCI-to-PCI Bridge Architecture Specification
d.PCI Hot-Plug Specification
e.PCI Bus Power Management Interface Specification
f.PCI BIOS Specification
g.PCI Firmware Specification
h.PCI Standard Hot-Plug Controller and Subsystem Specification
i.PCI-X Addendum to the PCI Local Bus Specification
j.PCI Express to PCI/PCI-X Bridge Specification
3.IDE
a.ATA/ATAPI 6
b.ATA/ATAPI 7
c.Programming Interface for Bus Master IDE Controller
d.PCI IDE Controller Specification
e.Serial ATA: High Speed Serialized AT Attachment
f.Serial ATA International Organization: Serial ATA
g.Serial ATA Advanced Host Controller Interface (AHCI)
h.ATAPI Removable Media Device BIOS Specification
i.El Torito Bootable CD-ROM Format Specification
4.USB
a.Universal Serial Bus Specification
b.Universal Host Controller Interface (UHCI) Design Guide
c.Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID)
d.Universal Serial Bus (USB) HID Points of Sale Usage Tables Version 1.01
e.Universal Serial Bus (USB) HID Usage Tables
f.Universal Serial Bus Mass Storage Class Specification Overview
g.Universal Serial Bus (USB) Device Class Definition for Physical Interface Devices (PID)
h.Universal Serial Bus Mass Storage Class Bulk-Only Transport
i.Universal Serial Bus Mass Storage Class Control/Bulk/Interrupt (CBI) Transport
j.Universal Serial Bus Mass Storage Class UFI Command Specification
k.Enhanced Host Controller Interface (EHCI) Specification for Universal Serial Bus
5.Advanced Configuration and Power Interface (ACPI)
a.ACPI Specification 2.0
b.ACPI Specification 3.0
c.ACPI Specification 4.0
d.ACPI Specification 5.0
e.ACPI Specification 6.0 (and 6.1 and 6.2)
6.Small Computer System Interface (SCSI)
7.BIOS Boot Specification
8.System Management Bus (SMBus) Specification (not related to SMBIOS)
9.Formatting
a.FAT: General Overview of On-Disk Format Version 1.03
b.PE-COFF Specification
10.Unicode Standard Version 4.0.0
11.POST Memory Manager Specification
12.Debug Port Table Spec
13.TPM Specification
14.PC Client Specific TPM Interface Specification (TIS)
15.Watchdog Timer Description Table Specification
16.IA-PC HPET (High Precision Event Timers) Specification
17.Serial Port Console Redirection Table Specification
18.Static Resource Affinity Table Specification
19.Hardware Watchdog Timers Design Specification
20.System Management BIOS (SMBIOS) Reference Specification
21.Alert Standard Format (ASF) Specification
22.IPMI Specification
23.Intel® Virtualization Technology for Directed I/O Architecture Specification
24.Intel® 64 and IA-32 Architectures Software Developer’s Manual
25.Intel® Itanium® Architecture Software Developer’s Manual
26.EISA Specification
27.VESA - BIOS Extension (VBE) Core Functions Standard
28.VESA - Enhanced EDID Implementation Guide
29.Boot Integrity Services (BIS) Application Programming Interface
30.Preboot Execution Environment (PXE) Specification
31.BIOS Enhanced Disk Drive Specification
32.Multi-Processor Specification
33.PCMCIA
34.SD Card
35.IPv4, IPv6, and TCP
36.PC SDRAM Serial Presence Detect (SPD) Specification 37. RFC 791, 792, 768, 793, 862, 1122, 1122, 1323, 1350,
37.1531, 1783, 1784, 2090, 2131, 2581, 2988, 3782
38.38. AC’97
Let’s take a high-level look at the four most important industry specifications beyond UEFI from a system firmware and BIOS perspective:
- PCI
- SATA (formerly known as ATA, IDE)
- USB
- ACPI
PCI
PCI is the single strongest hardware standard of the Intel-architecture-based platform. All the key I/O controllers on the platform, including the embedded memory controllers, system agents, and the graphics ports on Intel CPUs, are either PCI or PCI Express (PCIe) devices.
The PCI standard is divided into several generations of key specifications. The latter generations are, for the most part, backward compatible with previous generations. If you join the PCI Special Interest Group (SIG) at www.pcisig.com, you will have access to all the latest PCI industry standard specifications. The following paragraphs highlight some of the PCI pre-OS key points, but are by no means exhaustive (please download and read/memorize these specifications). Also, it should be well understood that exceptions will occur for specific devices, as with any standard.
Understanding the PCI Local Bus Specification is the first step to understanding the bus transactions and protocols necessary to communicate with hardware or software driver designers and help debug platform level issues. There are several PCI standard configuration header registers listed in the specification that are key to PCI enumeration, which must be completed prior to a common off-the-shelf OS to load properly on the platform. Several devices are PCI enumerated in the OS.
Some real-time operating systems may have enough a priori knowledge of the PCI subsystem to hard code the needed values in order to boot and load drivers and may not require full PCI enumeration. While some of off- the-shelf operating systems repeat some of the PCI enumeration during OS load time, without a basic level PCI enumeration, none of the devices on the Intel architecture platform will function, including the OS storage device. Full enumeration on today’s components only takes 20 milliseconds (ms) and the flexibility it provides outweighs hardcoding of values per board/system.
Besides the main PCI Local specification, there are also PCI Bridge specifications, PCI Hot Plug specifications, and PCI Power Management specifications that play roles in pre-OS PCI programming and compatibility. Up to a point in PCI history, most of the pre-OS required details are outlined in the PCI BIOS Specification 2.1.
Here are some of the basic requirements from the PCI-SIG specifications for pre-OS firmware and BIOS.
Note: Again, this laundry list does not replace the PCI specification. Please get the specifications and read copiously! Read The Friendly Manual!
PCI Device Enumeration
For dynamic PCI enumeration, the pre-OS firmware must scan the PCI bus for devices and bridges. To do this, the BIOS must start looking for devices at the host to PCI bridge (PCI Bus 0, PCI Device 0, PCI function 0), and start scanning or “walking through” the devices, methodically looking for PCI devices and PCI bridges. When function 0 is not present in the system, it is assumed that the functions 1 through 7 of that device are not incorporated. For each PCI device/function found, the BIOS must:
–Examine the header type register to determine if the device is a PCI- to-PCI bridge. The Header Type field at register offset 0x0A will indicate type 0 for devices and type 1 for bridges.
–For Type 0 headers:
o Assign Standard Base Address Registers
▪ Prefetchable Memory
▪ Non-Prefetchable Memory
▪ Legacy I/O ranges to device
o Enable Bus Mastering, memory, and I/O ranges as needed in the configuration register
o Program Master Latency Timer Register
o Program Cache Line size
o Program Min Grant and Max Latency values (not used for PCI Express)
o Program Subsystem Vendor and Device IDs
o Assign PCI IRQs and INTA, INTB, INTC, or INTD lines. Care should be taken to read the schematics on down PCI devices and PCI slots, as the IRQs are board-specific. Internal PCI controller devices in the PCH or CPU have programmable IRQs assignments as well.
o Flag any PCI Expansion option ROMs (or UEFI driver) that needs to be executed for initialization or shadowed and programming the Expansion ROM BAR. These may not be executed during PCI enumeration, but will likely be dealt with in a later stage of the BIOS.
o Program any Error registers to trigger the proper error handler response
–For Type 1 Headers, when a PCI bridge is found, several registers’ programming is similar to that of any other device, but there are marked differences:
o Local Memory BARs for the bridge device itself
o Configuration register for the bridge
o Primary and secondary bus latency timers
o Cache line size
o Primary bus register, secondary bus register, subordinate bus assignments must be made, and then the devices behind the bridge(s) must be discovered and enumerated.
o After the PCI bus/device network under a bridge is completely enumerated, assigning of nested Memory, and I/O ranges must be made to PCI bridges
o Bridge Control Register
While there are up to 256 buses on PCI, the minimum granularity of the I/O base and limit registers of 4 KB really limit that to approximately 16 bridges possible (assuming each has some amount of I/O required).
When configuring the PCI devices of the chipset and CPU, there will be several private registers above 0x3F in PCI and in the PCI Express ranges that will need to be programmed for specific purposes. Also, in the chipset, memory-mapped I/O configuration spaces are mapped by the Root Complex Base Address register at Bus 0, Device 31, Function 0, Offset 0xF0. It specifies the physical address of Chipset Configuration space. Also used in “RCBA xxxxh,” where xxxxh is the offset of a particular register location in the Chipset Configuration space.
For static PCI enumeration, a designer can define a specific mapping and hard-code the standard registers for a particular system. But that is not the right way. While some believe that this saves time in walking the buses dynamically, the entire bus scan should take on the order of 20 ms. The benefits of doing it dynamically will likely outweigh the return of saving 20 ms and hand-coding the map statically for every closed-box configuration. If there are any expansion slots on PCIe buses on the system, then static enumeration is really not an option.
PCI BIOS
PCI BIOS Specification v2.1 spells out PCI BIOS calls via legacy software interrupt Int 1Ah; however, legacy calls are fast becoming obsolete in the modern world of UEFI. PCI BIOS (Int 1Ah) function calls are listed in Table 5.1.
Table 5.1: PCI BIOS (Int 1Ah) Function Calls
| Function | AH | AL |
| PCI_FUNCTION_ID | B1h | |
| PCI_BIOS_PRESENT | 01h | |
| FIND_PCI_DEVICE | 02h | |
| FIND_PCI_CLASS_CODE | 03h | |
| GENERATE_SPECIAL_CYCLE | 06h | |
| READ_CONFIG_BYTE | 08h | |
| READ_CONFIG_WORD | 09h | |
| READ_CONFIG_DWORD | 0Ah | |
| WRITE_CONFIG_BYTE | 0Bh | |
| WRITE_CONFIG_WORD | 0Ch | |
| WRITE_CONFIG_DWORD | 0Dh | |
| GET_IRQ_ROUTING_OPTIONS | 0Eh | |
| SET_PCI_IRQ | 0Fh |
Most operating systems today can access PCI devices directly with their own class driver. As the PCI bus is completely discoverable (unless hidden by the BIOS for a board-specific reason), then through that class driver they can access PCI devices, class codes, as well as read and write configuration registers as needed.
The more useful calls are Get_IRQ_Routing_Options and Set_PCI_IRQ, which some operating systems still use.
Get PCI Interrupt Routing Options
This routine returns the PCI interrupt routing options available on the system motherboard and the current state of what interrupts are currently exclusively assigned to PCI. Routing information is returned in a data buffer that contains an IRQ routing for each PCI device or slot. The format of an entry in the IRQ routing table is shown in Table 5.2.
Table 5.2: Format of an Entry in the IRQ Routing Table
| Offset | Size | Description |
| 0 | Byte | PCI Bus Number – The bus number of the slot. |
| 1 | Byte | PCI Device Number (in upper five bits) – The device number of the slot (shifted left 3 bits) |
| 2 | Byte | Link Value for INTA# – A value of zero means this interrupt pin is not connected to any other interrupt pins and is not connected to any of the Interrupt Router’s interrupt pins. The nonzero link values are specific to a chipset and decided by the chipset vendor. A value of 1 through the number of interrupt pins on the Interrupt Router means the pin is connected to that PIRQn# pin of the Interrupt Router. A value larger than the number of interrupt pins on the Interrupt Router means the pin is wire OR’d together with other slot interrupt pins, but the group is not connected to any PIRQn# pin on the Interrupt Router. |
| 3 | Word | IRQ Bitmap for INTA# – This value shows which of the standard AT IRQs this PCI’s interrupts can be routed to. This provides the routing options for one particular PCI interrupt pin. In this bitmap, bit 0 corresponds to IRQ0, bit 1 to IRQ1, and so on. A 1 bit in this bitmap indicates that routing is possible; a 0 bit indicates that no routing is possible. This bitmap must be the same for all pins that have the same link number. |
| 5 | Byte | Link Value for INTB# |
| 6 | Word | IRQ Bitmap for INTB# |
| 8 | Byte | Link Value for INTC# |
| 9 | Word | IRQ Bitmap for INTC# |
| 11 | Byte | Link Value for INTD# |
| 12 | Word | IRQ Bitmap for INTD# |
| 14 | Byte | Slot Number – This value is used to communicate whether the table entry is for a system-board device or an add-in slot. For system-board devices, the slot number should be set to zero. For add-in slots, the slot number should be set to a value that corresponds with the physical placement of the slot on the system board. This provides a way to correlate physical slots with PCI device numbers. |
| 15 | Byte | Reserved |
Set PCI Hardware Interrupt
Set PCI hardware is intended to be used by a configuration utility or a Plug- N-Play operating system like Windows* 98 or higher. It can assign a specific IRQ to an interrupt pin on a particular Bus and Device number.
Per Microsoft’s PCI IRQ Routing Table Specification 1.0, the PCI IRQ Routing Table is in system memory from F0000h to FFFFFh on a 16-byte boundary. It begins with a signature of $PIR, and the resulting table output is compatible with the formatting of the buffer pointing to Int 1Ah Get_PCI_interupt_routing_options call above.
The PCI IRQ Routing Table ($PIR) has the header structure shown in Table 5.3.
Table 5.3: Header Structure of the PCI IRQ Routing Table ($PIR)
Figure 5.1 is an example of the $PIR table.
Figure 5.1: An Example of the $PIR Table
The $PIR table is not the only way to describe the IRQ routing to the operating system. Microsoft Windows 2000 and later versions of Windows use ACPI tables and methods to determine the IRQ mapping supported per PCI devices. The ACPI table FADT will show which mode.
PCI IRQ Routing with ACPI Methods
As multiprocessor systems introduced APICs, starting with ACPI Specification, Revision 1.0b, Multiprocessor Specification, Version 1.4, was superseded. The table information contained in the MP specification was carried over into the ACPI Specification. The interrupt routing to IOxAPICs is now described in the ACPI namespace using ASL. For details, please refer to the latest ACPI specification online.
PCI Recommendation
As the PCI specifications have progressed, the PCI Express Specification and the PCI Firmware Specification have become supersets of previous PCI local bus specification and PCI BIOS specifications. The PCI Express Specification is similar and has backward compatibility to the PCI Bus Specification. For this reason, developers should implement section 7 of the latest PCIe Specification. Several implementation notes are also included in the PCIe specification to avoid common pitfalls.
PCI Power Management
PCIe ASPM – Active State Power Management
a. PCI Express Base Specification
b. PCI Local Bus Specification
c. PCI-to-PCI Bridge Architecture Specification
d. PCI Hot-Plug Specification
e. PCI Bus Power Management Interface Specification
f. PCI BIOS Specification
g. PCI Firmware Specification
h. PCI Standard Hot-Plug Controller and Subsystem Specification
i. PCI-X Addendum to the PCI Local Bus Specification
j. PCI Express to PCI/PCI-X Bridge Specification
USB Enumeration and Initialization
In the USB world, there has been a progression from UHCI to ECHI to XHCI as speeds have gotten faster, smarter, and USB devices are now ubiquitous. OHCI exists but is not widely supported on Intel architecture. There are varying degrees of support to handle USB pre-OS. In order, the BIOS must:
- Supply PCI resources for onboard USB controllers and wait for the OS drivers to load and enumerate the USB devices before they are usable. The USB controllers or devices may also be armed to wake the system via ACPI.
- Add a USB stack in the firmware to enumerate the USB bus and allow for limited functionality pre-OS for such things as HID devices (keyboard/mouse) or storage devices (boot to USB).
- Add an SMI handler to allow for OS Bootloader and OS runtime support on OSes that do not have a native USB driver stack. This is also known as “legacy USB support.”
These are the basics that have existed since USB started in the 1990s. Adding this USB pre-OS support to a firmware stack is a substantial effort (multiple-man months). The additional boot times involved can also be inhibitive, several hundred milliseconds to several seconds depending on the number of USB ports/devices/usages enabled.
In addition to the USB pre-OS support listed above, there are a few other areas of USB that can be explored for additional value to the platform:
- Pre-boot authentication (PBA) may also require USB support and that is an additional concern that must worked out with the PBA vendors and the OEM of the system.
- Trusted USB, where there is an established root of trust from the boot vector and where a USB device is not allowed to function unless it is authenticated and/or secured in some manner in either the BIOS hardened firmware and/or the operating system.
PBA devices and Trusted USB share some common and interesting traits, but we will focus on the non-secure USB enumeration and initialization in this book.
There are different versions of USB controllers implemented in the Intel chipsets and systems on chips. Here we will focus on the PCH.
PCI Enumeration and Initialization of USB Controllers
The simplest form of USB support is basic PCI support with no additional USB network initialization. During the PCI enumeration in the BIOS flow, the USB controllers’ BARS are assigned, IRQs are provided, and memory and I/O space may be enabled. Additionally, the system firmware can also hide controllers, disable ports, and arm for ACPI wake events.
Hiding USB Controllers’ PCI Space
Depending on the number of ports routed and utilized on the platform, some number or types of USB controllers may be hidden or disabled to save PCI resources and, depending on the chip, for power savings. When a device is hidden, an OS is incapable of both discovering and using the hidden device via PCI configuration space. To hide a host controller, the BIOS must program the Function Disable register at (RCBA + 3418h). See the PCH datasheet for a description of the register.
When disabling UHCI host controllers, the USB 2.0 EHCI Structural Parameters Registers must be updated by the system BIOS with coherent information in “Number of Companion Controllers” and “N_Ports” fields, which are:
–(Device26)/(Device29):F0:04h[15:12]
–D26/29:F0:04h[3:0], respectively.
It is important to note a quirk here that the BIOS cannot configure the device to provide UHCI support only in the Intel USB controllers on the PCH. This configuration is prevented per the PCI Specification requirements; that is, PCI devices must always implement function 0. Therefore, the UHCI host controller support must always be accompanied by support by at least one EHCI host controller (D29/26 Function #0).
To ensure that a disabled USB function cannot initiate transactions for USB transfers or be the target of memory or I/O requests, the system BIOS must also ensure the controller memory, and I/O control bits are disabled prior to hiding the function. Also, the USB functionality is disabled in the controller’s registers:
–Clear the Run/Stop bit and verify that the HCHalted bit becomes set (EHCI and UHCI)
–Set the Interrupt disable bit, PCI Cfg offset 04h[10] (EHCI and UHCI)
–Clear Asynchronous schedule enable bit, USB20 MEM_BASE 20h[5], and Periodic schedule enable bit, USB20 MEM_BASE 20h[4]
–Wake capabilities (UHCI, GPE0_EN, and EHCI, D26/D29:F0:62h)
Once set, the device will be disabled until the next platform reset occurs. The policy to disable the EHCI functionality is not a dynamic one. This restriction also applies to subsequent warm boots.
Disabling USB Ports
System BIOS may choose to disable individual USB ports to save power or for security purposes. Each of the USB ports has a corresponding bit within the PCH USB Port Disable Override Register (RCBA + 359Ch). The PCH USB Port Disable Override Register can be locked by setting the Write Enable bit of the PCH USB Per-Port Register Write Control Register, PMBASE + 3Ch[1]. Refer to the PCH datasheet for more details on these registers.
USB Wake from ACPI Sx (S3, S4, S5 to S0)
The EHCI host controllers may generate the wake from the internally routed PME signal. An enable/disable bit (PME_B0_EN) is provided to support the resume events from Bus#0 using the PME signal. For supporting EHCI host controller wake in an ACPI environment the _PRW ACPI method package to describe the “Wake from USB 2.0” functionality should also be present under PCI Bus#0 for each of the EHCI host controllers.
USB Enumeration
The system BIOS initializes the EHCI hardware in two phases, PCI enumeration as outlined above and EHCI initialization outlined next.
EHCI initialization places the EHCI in a fully functional state. While the operating system USB driver will repeat these steps for its own stack, it is required for the BIOS to perform for any pre-OS USB functional support.
- Program Port Routing and ModPhy settings.
- Perform a Host Controller (HC) Reset.
- Delay required (X ms).
- EHCI requires detection for companion controller (UHCI) initialization.
- Check number of ports, scan connection status.
a.If devices/hubs are connected, do a root port reset.
b.Root port reset is driven for a required time. This short duration is needed to suppress any possible resume signals from the devices during initialization. Per the EHCI version, the BIOS needs to track duration and clear the bit at the proper time. (XHCI version will clear the bit by itself and the BIOS only needs to poll.)
6.The BIOS must poll for port enable bit to be set. While the specification says 2 ms, the completion will happen sooner than that for Intel PCHs.
7.Perform speed detection.
8.Perform a reset; recovery timing is 10 ms.
9. EHCI version – proceed to get a descriptor to know what is connected to root port. Two potential answers:
–Hub – if Hub, configure it for address, wait 10 ms per specification (may not need to for Intel component). Get delay needed for power on delay. Wait for that delay then configure each of the ports
–Root port 0 index – ID as hub. Then configure USB network downstream
It is recommended that the BIOS enable all the root ports in parallel, to avoid the otherwise additive serial time delays and then go deeper into the hub/device layer as required for the platform. This is in some ways a platform policy decision.
If the BIOS finds a USB Device—get the ID from the descriptor, then set the address. Depending on the device type, we may need to get a further descriptor and configure as needed. What interface to query is next.
These steps are repeated for each root port.
SATA
Intel components have supported ATA controllers in one form or another since early 1990s chipsets. These have converted over time from Parallel ATA to Serial ATA. Today most Intel platforms support only SATA controllers, up to a maximum of six SATA ports. It is possible to still find PATA-supported chips in the market either as integrated controllers or as discrete PCI devices. Intel datasheets have complete details on number and types of controllers, number of ports, and available configurations and SATA-generation support per component, as well as complete set of registers.
SATA controllers support the ATA/IDE programming interface and may support Advanced Host Controller Interface (AHCI), not available on all chips. In this section, the term “ATA-IDE Mode” refers to the ATA/IDE programming interface that uses standard task file I/O registers or PCI IDE Bus Master I/O block registers. The term “AHCI Mode” refers to the AHCI programming interface that uses memory-mapped register/buffer space and a command-list-based model.
SATA Controller Initialization
The general guidelines for initializing the SATA controller during POST (S4/S5) and S3 resume are described below. Upon resuming from S3, System BIOS is responsible for restoring all registers that it initialized during POST.
Setting the SATA Controller Mode
The system BIOS must program the SATA controller mode prior to beginning any other initialization steps or attempting to communicate to the drives. The SATA controller mode is set on mainstream PCHs by programming the SATA Mode Select (SMS) field of the Port Mapping register (Device31: Function 2: offset 90h, bit[7:6]).
There are three modes that software could be operating in:
–AHCI
–RAID
–IDE (compatible) modes
Not every mode is supported on every component. Depending on which version of the component (mobile or desktop, RAID or non-RAID), the allowed configurations vary.
RAID and AHCI modes require specific OS driver support and are identical except for differences in PI and CC.SCC values. IDE mode does not have any special OS requirements and is sometimes termed compatible mode. In addition to the three operation modes above, software can choose to operate SATA ports under a single controller mode or dual controller mode.
Software, typically the BIOS, decides up front which controller mode the system should be operating in before handing over the control to the OS.
If system BIOS is enabling AHCI Mode or RAID Mode, then it must disable the second SATA controller on the part (Device 31, Function 5) by setting the SAD2 bit, RCBA 1 3418h[25]. System BIOS must ensure that memory space, I/O space, and interrupts for this device are also disabled prior to disabling the device in PCI configuration space.
IDE (Compatible) Mode
IDE mode is selected by programming the SMS field, D31:F2:90h[7:6] to 00b. In this mode, the SATA controller is set up to use the ATA/IDE programming interface. In this mode, the SATA ports are controlled by two SATA functions. One function routes up to four SATA ports, D31:F2, and the other routes up to two SATA ports, D31:F5 (this is for desktop SKUs only). In IDE mode, the Sub Class Code, D31:F2:0Ah and D31:F5:0Ah will be set to 01h. This mode may also be referred to as compatibility mode as it does not have any special OS driver requirements.
AHCI Mode
AHCI mode is selected by programming the SMS field, D31:F2:90h[7:6], to 01b. In this mode, the SATA controller is set up to use the AHCI programming interface. The six SATA ports are controlled by a single SATA function, D31:F2. In AHCI mode, the Sub Class Code, D31:F2:0Ah, will be set to 06h. This mode does require specific OS driver support.
RAID Mode
RAID mode is enabled only on certain SKUs of the Intel components and requires an additional option ROM, available from Intel.
When supported, RAID mode is selected by programming the SMS field, D31:F2:90h[7:6] to 10b. In this mode, the SATA controller is set up to use the AHCI programming interface. The SATA ports are controlled by a single SATA function, D31:F2. In RAID mode, the Sub Class Code, D31:F2:0Ah, will be set to 04h. This mode does require specific OS driver support.
In order for the RAID option ROM to access all 6/4 SATA ports, the RAID option ROM enables and uses the AHCI programming interface by setting the AE bit, ABAR 04h[31]. One consequence is that all register settings applicable to AHCI mode set by the BIOS must be set in RAID as well. The other consequence is that the BIOS is required to provide AHCI support to ATAPI SATA devices, which the RAID option ROM does not handle.
PCH supports stable image compatible ID. When the alternative ID enable, D31 :F2 :9Ch [7] is not set, PCH SATA controller will report Device ID as 2822h for desktop SKU.
SATA Mode Default Settings
The system BIOS may implement a setup option that provides the user with the ability to select the SATA controller mode. This ensures that the operating system can be loaded and made operational on the platform if the required device driver support is not available. For embedded devices, of course, this is unlikely, but can be implemented via a tool-tunable NVRAM variable.
Enabling SATA Ports
SATA drives cannot start to spin-up or start to become data-ready until the SATA port is enabled by the controller. In order to reduce drive detection time, and hence the total boot time, system BIOS should enable the SATA port early during POST (for example, immediately before memory initialization) by setting the Port x Enable (PxE) bits of the Port Control and Status registers, D31:F2:92h and D31:F5:92h, to initiate spin-up of such drive(s).
In IDE mode, the system BIOS must program D31:F2:92h[3:0] to 0Fh and D31:F5:92h[1:0] to 3 for a SKU with six ports to enable all ports. If no drive is present, the system BIOS may then disable the ports.
In AHCI and RAID modes, the system BIOS must program D31:F2:92h[5:0] to 3Fh for six ports and 0Fh for four ports. In AHCI-enabled systems, the PCS register must always be set this way. The status of the port is controlled through AHCI memory space.
If Staggered Spin Up support is desired on the platform due to system power load concerns, the BIOS should enable one port at a time, poll the Port Present bit of the PCS register and Drive Ready bit of task file status register before enabling the next port.
The ATA/ATAPI-7 specification recommends a 31-second timeout before assuming a device is not functioning properly. Intel recommends implementing a ten-second timeout and if the device fails to respond within the first ten seconds, then the system BIOS should reinitiate the detection sequence. If the device fails to respond within an additional ten seconds, the system BIOS should reinitiate the detection sequence again. If the device fails to respond within ten more seconds, the system BIOS can assume the device is not functioning properly.
It is recommended that software or system BIOS clear Serial ATA Error Register (PxSERR) after port reset happens by writing 1 to each implemented bit location.
Setting the Programming Interface
The SATA controller supports three combinations of programming interfaces to access the maximum number of 6/4 SATA ports: a combination of legacy and native IDE, native IDE only, and AHCI.
Using the combination of the legacy and native IDE is possible only when the SATA controller is operating in IDE mode. The programming interface is selected by setting the PCI standard programming interface register, D31:F2:09h, appropriately. There are two native mode enable bits in the PI register to control the primary and secondary channels of SATA1, D31:F2:09h[2,0]; these bits must always be programmed identically. The PI register is found in both the SATA functions, but only SATA1 can be set to use legacy IDE, SATA2 supports native IDE only, and the PI register is read-only. If legacy IDE use is intended, the system BIOS must set the decode-enable bits in the IDE Timing Registers (D31:F2:40h[15] and D31:F5:42h[15]).
When the SATA controller is configured as RAID or AHCI mode, the PI register becomes read-only and the controller can use native IDE access mechanisms until the AE bit, ABAR 04h[31] is set. It is important to realize that in RAID and AHCI mode, native IDE will allow access only to the first four ports of the controller; to access the maximum of six ports, AHCI access mechanisms must be used.
Initializing Registers in AHCI Memory-Mapped Space
When the SATA controller is configured to operate in RAID or AHCI mode, the system BIOS must initialize the following memory-mapped AHCI registers specified by ABAR, D31:F2:24h:
–CAP register, Host Capabilities register (ABAR + 00h).
o Set SSS (ABAR 00h[27]) to enable SATA controller supports staggered spin-up on its ports, for use in balancing power spikes.
–Clear ABAR A0h [2][0] to 0b
–Clear ABAR 24h [1] to 0b
–PxCMD register (ABAR 118h, 198h, 218h, 298h, 318h, 398h).
After the BIOS issues the initial write to AHCI Ports Implemented (PI), ABAR 0Ch, register (after any PLTRST#), there is a request for the BIOS to issue two reads to the AHCI Ports Implemented (PI) register.
Some of the bits in these registers are platform specific and must be programmed in accordance with the requirements of the platform. The details regarding how these registers must be programmed can be found in the Serial ATA Advanced Host Controller Interface (AHCI) specification.
Some of the bits in these registers are implemented as read/write-once (R/WO). It is a requirement that the system BIOS programs each bit at least once, even if the default setting of the bit is the desired value (that is, system BIOS must write 0 to a bit, even if the hardware reset value is 0). Doing so will ensure that the bit is unchangeable by software that is not system BIOS. Please refer to the PCH EDS to determine which bits are R/WO.
Registers containing multiple R/WO bits must be programmed in a single atomic write. Failure to do so will result in nonprogrammable bits.
RAID Mode Initialization
When the SATA controller is initialized in RAID mode, the system BIOS needs to initialize the SATA controller and attached SATA devices as stated in the previous sections, with the following exceptions:
–The system BIOS does not need to initialize DMA mode for hard disk drives (HDDs) discovered behind the SATA controller when in RAID mode. The RAID option ROM will provide the initialization.
–SATA HDDs discovered by the system BIOS behind the SATA controller in RAID mode must not be added to the hard drive count at 40h:75h. The RAID option ROM will enumerate those drives and update the 40h:75h value accordingly. Updating the drive count at 40h:75h by the BIOS will make it appear that more drives are attached to the system than are actually available.
–System BIOS must not install INT 13h support for the SATA HDD devices discovered, nor may it treat such devices as BAID (BIOS-Aware Initial Program Load) devices, as the RAID option ROM implements the necessary INT 13h support for them.
–ATAPI devices attached to the SATA controller must be under the full control of the system BIOS and treated as BAID as they are in non-RAID mode.
–The system BIOS must load the RAID option ROM when the controller’s SCC (D31:F2:0Ah) returns 04h and VenderID/DeviceID match that of PCHR RAID SKU (refer to the PCH EDS or EDS specification update for DID/VID information).
RAID Option ROM
The Intel® Rapid Storage Technology RAID option ROM is a PnP option ROM that adds the Int13h services and provides a pre-OS user interface for the RAID implementation. The option ROM’s Int13h services are used up to the point where the PCH RAID OS driver takes over.
The RAID option ROM is delivered as a single uncompressed binary image compiled for the 16-bit real mode environment. To conserve system flash space, the integrator may compress the image for inclusion into the system BIOS. System memory is taken from conventional DOS memory, attached to the EBDA, and is not returned.
The RAID option ROM will first attempt to rely on the interrupt-driven mechanism handled by system BIOS and then will fall back to the polling mechanism if the system BIOS does not support the interrupt-driven mechanism. The determination is made via a memory semaphore at location 40:8E in the BIOS Data Area (BDA).
Initialization
RAID mode initialization occurs as follows:
–System BIOS configures the SATA controller for RAID mode, initializes IO BARs and ABAR, and assigns an IRQ to the controller. System BIOS optionally sets up an ISR for the SATA controller and enables interrupts for the SATA controller.
–System BIOS loads the RAID option ROM (OROM).
Int13h Drive Access to an ATA Device. System BIOS control flow: if the system BIOS uses the interrupt mechanism, then the system BIOS ISR gets control.
–If this is an unexpected interrupt, the system BIOS assumes this is a RAID request.
–The system BIOS clears the Interrupt status in the SATA/RAID controller.
–The system BIOS does not mask the IRQ in the PIC.
–The system BIOS sets byte 40h:8Eh to a nonzero byte value.
–The system BIOS issues an EOI and IRET.
If the system BIOS does not use the interrupt mechanism, then the system BIOS does not receive this INT13h request; therefore, it does nothing.
Int13h Drive Access to a SATA ATAPI Device. System BIOS control flow: system BIOS can choose any method to access the ATAPI drive (interrupt or polling).
–System BIOS completes the INT13h service request.
–Contact your Intel Representative to get the RAID option ROM.
Enable Flexible RAID OROM Features
Panther Point with RAID-capable SKU can customize the RAID features through setting the Intel® RST Feature Capabilities (RSTF) register before loading the RAID option ROM. The RAID OROM will enable the desired features based on the setting in that register; please refer to the Panther Point EDS for more details.
For example, if the platform-desired features are RAID0, RAID1, RAID5 and RAID10, system BIOS should set RSTF (ABAR + C8h [15:0]) to 002Fh before loading RAID OROM.
Additional Programming Requirements During SATA Initialization
System BIOS must execute several other part-specific steps as part of system BIOS initialization of the SATA controller on both cold boot (G3/S5) and S3/S4 resume path. The bit settings are required for basic operation. Please refer to the PCH datasheet for the SATA initialization settings and the actual register indexes/values to be programmed.
External SATA Programming
If an external SATA port is implemented in the system, there are additional steps that need to be followed.
–Follow steps in 13.1.6 for additional programming to external SATA port.
–Enable the port through the corresponding bits (example: D31:F2:92[5:0]).
–Put the port into Listen Mode (refer to AHCI specification for Listen Mode information), which achieves similar power savings as if the port is in SATA Slumber power state.
Compliance with Industry Specifications
To ensure a satisfactory user experience and to provide the RAID option ROM implementation with a “well-known” framework under which it can operate, the system BIOS and option ROM need to be implemented in accordance with the following specifications:
Advanced Configuration and Power Interface (ACPI)
ACPI consists of tables and namespace. While many people equate this with simple power management descriptions of system and device power management features, ACPI as an industry standard has usurped several other legacy system tables over time to become the unified method for describing the platform capabilities to the operating system.
ACPI Tables
There are ACPI tables to describe every aspect of the system hardware and its preferred capabilities to an ACPI-aware OS. The ACPI tables that matter are:
–Root System Description Pointer (RSDP). The Main ACPI table that points to all the other tables, the Root System Descriptor Table (RSDP) is located either at E0000-FFFFF in legacy BIOS or can be located elsewhere as specified in the UEFI system table.
–System Description Table Header. Common structure that is at the top of every table, except FACS.
–Root System Description Table (RSDT). A 32-bit table that is becoming obsolete and may no longer be used in modern systems. It still can be used to point to many of the other tables listed below, but the system may lack certain feature compatibility. Older ACPI-aware operating systems may require this for functionality.
–Extended System Description Table (XSDT). Replaces RSDT and supports both 32/64-bit systems. It points to all other tables (see below).
–Fixed ACPT Description Table (FADT). Provides fixed addresses for key ACPI hardware registers, including GPE block, PM block, and ACPI Timer. It also provides I/O port details to access or enable SMI ports, which turns on ACPI mode (and the value written), and the Port address and value to reset the system.
The FADT was previously known as FACP and is pointed to by the XSDT, and in turn the FADT points to the DSDT and FACS tables.
–Firmware ACPI Control Structure (FACS). Hardware signature, waking vector of the 32-bit real mode, and 64-bit physical address resume vectors and global lock support.
–Differentiated System Description Table (DSDT). Main table for AML, not changing once loaded and exit boot services is called (or Int 19h).
–Secondary System Description Table (SSDT). Modular extensions of the DSDT. These are used for multiple hardware support. Example: depending on the CPU installed, they may have different features that must be defined. They also can be used per OS expectation to allow for new features for newer operating systems and backward compatibility for older ones.
–Multiple APIC Description Table (MADT). Describes IOxAPICs and Local CPU APICs. In PIC mode versus APIC mode.
–Smart Battery Table (SBST). OEM-specific table depending on the battery mated to the system.
–Embedded Controller Boot Resources Table (ECDT). Optionally describes resources used by the embedded controller. The table provides earlier access to the EC than if the system has to wait until the OS loads the EC drivers later in the boot.
–Boot Graphics Resource Table (BGRT). Describes location of the board splash screen for OS to load during OS boot to provide a seamless boot experience between the BIOS and OS.
–Firmware Performance Data Table (FPDT). Describes pre-OS firmware execution time to the OS or tools without the need for a wall clock or stopwatch.
There are many server and NUMA system tables that provide the operating system with enhanced details of the capabilities of dual and multisocketed systems. These tables include the System Locality Distance Information Table (SLIT) and the System Resource Affinity Table (SRAT).
There are some newer tables defined in the ACPI 5.0 specification that do not deal with Intel architecture (such as GTDT) and can be excluded from the firmware image.
Most of the ACPI tables do not change for the life of the platform and can be considered static. There may be some tables that are ported from board to board (like PCI IRQ routing _PRT). Some tables (such as SSDT) can be dynamically created, loaded, or enabled, depending on the hardware discovered during the system boot and depending on the operating system and/or the usage model requirements. For dynamic SSDTs, “Load” and “Load Table” can be used to update tables during OS load or even runtime before being interpreted by the OS. This allows for hot plugging of docking stations, socketed processors, proprietary daughter cards, and so on, where modular add-in tables make a single firmware image scalable. This SSDT table technique also can be used for dynamically adding instrumentation for debug and performance measurements.
ACPI Namespace
ACPI Namespace is an outline of a system. It is divided into high-level scopes, where nothing exists outside of a scope. A scope is equivalent to a directory, hence the dir tree model in the specification. The base of the tree is the Root Scope. The system bus (SB) scope is for everything physically on the system board. PR is for Processor tree.
ACPI Name space includes both objects (either dynamic or static) and methods (dynamically called by the OS drivers as needed).
Device Objects are defined through ASL-specific language. They are either ACPI enumerated (has an HID for a device) or an _ADR, which is used to supply OSPM with the address of a device on its parent bus. An _ADR object is used when specifying the address of any device on a bus that has a standard enumeration algorithm.
Objects can be a sum of the DSDT and any loaded SSDTs. But what does that mean? And how do we generate it?
You can create DSDT or SSDT from an ASL (ACPI Source Language) source file and generate AML (ACPI Machine Language) using an ASL compiler. Microsoft has a few versions of the compiler and Intel has an ASL compiler called IASL.exe. There are 64- and 32-bit versions of the compiler tools, but even the 32-bit version of the tool will generate a 64-bit version of the ASL code. The ACPICA project (www.acpica.org) also has source to generate a new compiler tool for various operating systems.
On a Windows machine, by looking into a device manager and picking Devices by connection, one can see the results of the ACPI namespace. To actually look at a representation of ASL code on a real machine, the Intel ASL compiler also includes a disassembler and an extractor to pull it from a local machine.
For more information on ACPI:
–For a starting point for ACPI, start with the ACPI specification; it has ample example code at www.apci.info.
–Discover more data at the ACPI Component Architecture website (www.acpica.org). It has the ACPI Component Architecture User Guide and Programmer Reference Manual and the ACPI Source Language Optimizing Compiler and Disassembler User Guide.
–A currently obsolete-but-still-applicable ACPI Implementer’s Guide also can be found (still) on the Web. It was produced in the early v1.0 days of the ACPI specification. After the initial industry enabling efforts, it was inactivated. Just make sure that what you find is at least a document from 1998 or later.
Summary
This section covered basic programming for PCI, SATA, USB, and ACPI standards as they apply to the BIOS. Please check on the latest standards through the standards bodies as they are constantly changing. More complete and lower level programming details are available in the respective industry specifications. More complete details about certain characteristics of IO BIOS programming also can be obtained through BIOS specifications, which may be available online.
In the BIOS, standard enumeration algorithms can eliminate much extra work between revisions of boards or systems. These standards can also be tuned, as we will see later per board or per silicon components for best fit and performance.