Chapter 3
System Firmware Terms and Concepts
For anyone new to Intel® architecture, the concepts behind three-letter acronyms can be a bit overwhelming. This chapter explains numerous concepts that should help set up the basic terminology used in future chapters. Many concepts are introduced, and it is best to refer to this chapter as you progress through the book.
Typical PC/Intel® Architecture Overview
By design, Intel architecture is unique and somewhat complicated. To boot, firmware must initialize the hardware by using either a Basic Input Output System (BIOS) or a custom boot loader solution. Certain subsystems, either integrated in silicon or added as a peripheral, may require additional firmware, which is obtained from that vendor.
Figure 3.1 illustrates the hardware components that typically make up a PC. The BIOS or boot loader is typically kept in flash.
Memory Types
Traditionally, there is ROM and RAM. We will define them for the purist, but today most people get the concepts.
ROM. Read-only memory (ROM) is locked memory that is not updatable without an external ROM burner. It never loses its context once it is programmed. Logistically it makes development and bug fixes in the field much costlier. It is hard to find true ROMs today, as flash technology has provided programmability during runtime. Of course, you can have things like EEPROMs, which have ROM in the name and are programmable, but see NVRAM below.
It is possible for silicon to have embedded ROM inside of it to enable must-have interfaces, such as a NAND controller interface, if your required boot firmware solution is sitting behind it.
RAM. Random access memory (RAM) does not retain its contents once power is removed. This type of memory is also referred to as volatile. There are many types of RAM, such as static RAM (SRAM) and dynamic RAM (DRAM). In the context of this book, system memory and sometimes memory refer to any of the available types of RAM.
NVRAM. Flash technologies have improved since the time of the dinosaur PC AT. Instead of ROMs, which store things like system BIOS, or RAM, which loses its mind when you power down, most systems today contain a piece of programmable and nonvolatile RAM known as NVRAM. If you have a flash upgrade utility for a device, it is likely to be nonvolatile RAM, not formal ROM.
Two basic technologies cover NVRAM types—NAND and NOR.
NAND stands for “Not AND” technology. NAND flash, which resembles traditional NAND gates, has become prevalent with the advent of USB sticks in the market and flash cards for cameras. Now they have grown up into full-blown solid-state drives. NAND flash requires a controller to be located between the bus and the memory itself. The controller manages and maintains the NAND flash, which is a black art unto itself. That controller must be configured before accessing the memory behind it. A database and maintenance algorithms must be loaded before accessing memory behind it. The flash cells are good only for so many read/write cycles, so there are wear- leveling algorithms to keep things “good.” If you keep asking experts questions, eventually someone says, “I don’t know how it works.” While the technology is more metastable than magnetic media, it is so fast, and so big for the price, that nobody notices. Chances are you will upgrade your drives long before the NAND flash drive decides to wear out.
NOR stands for “Not OR” technology. Firmware hubs and SPI devices are examples of NOR flash.
Besides the NAND controller initialization, the two technologies differ in two main ways that we care about as firmware developers:
- Access: NAND reads require access in pages of data, while NOR can be read by byte. If you are reading pages of data, you will have to have somewhere to store that (SRAM or cache). NOR can be executed in place, which makes it slower and cheaper to implement for little tasks.
- Size: NAND tends to be much larger than NOR. While NOR flash is in the order of megabytes, NAND is on the order of gigabytes.
Other platform design considerations need to be handled because of the differences between the technologies, but that could fill another book.
Several types of memory are used in system firmware: processor cache, system main memory, CMOS, small NVRAM flash chips, and large disk drives.
Processor Cache
Processors have local memory on them. While not normally thought about as memory, it is akin to “short-term memory” for the system. During runtime, the processor manages the cache per ranges that the system BIOS or operating system configure. Caching of information provides the best access times you can get. Cache used to be disabled by default, but these days, cache is enabled when the processor is powered.
During early system BIOS phases, the cache can be configured to provide a small stack space for firmware to execute as soon as possible. Cache must be set to avoid evictions and then disabled after main memory is up, but for a short time using more advanced algorithms. More on this “cache as RAM” potential later.
System Memory
When you buy memory for a computer or other expandable device, people think about modular DIMMs. There have been many technology changes over the years, from EDO to BEDO to SDRAM to RDRAM and back to SDRAM in the form of DDR, DDR2, DDR3, and, coming soon, DDR4. In the future, there is a roadmap of memory that will make today’s best seem like EDO or ROM. On a scale of fastest to slowest in the system, main system memory is in the middle.
Access time to this memory is typically faster than from NVRAM (disk- or SPI-based), but slower than CPU cache. It is sized for the platform market to be ideal for execution of operating system and applications during runtime. Memory DIMMs required a memory controller, formerly in the north bridge of the chipset, now integrated into the processor. Memory initialization can take between several milliseconds to several seconds, depending on the transition state of the system (coming from off or a sleep state). During the normal boot flow, once main memory is initialized by the system BIOS, the shadowing of the “rest of the BIOS” can take place. The memory is divided into a memory map for various usages by different subsystems; not all memory is used or available by the operating system. Eventually, the OS is loaded into main memory and the system is then “booted” from a BIOS point of view. Of course, the OS may need to load the drivers and applications … but that is its own book.
Complementary Metal-Oxide Semiconductor (CMOS)
In a BIOS context, the 512 bytes of CMOS is RTC battery-backed SRAM that is in the south bridge of the chipset. Although it is not NVRAM, it is used to store the setup menu and other user-dependent or board data that needs to be retained across power state transitions (when the system is off). Depending on the system BIOS implementation, CMOS may not be used except for clock data storage. Over time, the setup menu data became too complex, and the bitmap of 512 bytes got too tight. Tiano-based iterations started use of flash memory storage that is not limited by SRAM sizes.
System BIOS Flash Memory (NVRAM, FWH, or SPI)
A small nonvolatile RAM (NVRAM) chip is used for storing BIOS code data. Flash Memory is used to store the BIOS or boot loader. One advantage of flash memory is that it can be written to as the system powers up. This allows either the BIOS or boot loader to be stored in flash, as well as any data that the BIOS or boot loader may need during the boot process. Flash memory may also be used to store an OS as well, but depending on the technology of flash used, it may be cost prohibitive to do so. The packages that the flashes have come in over the years have been in the form of firmware hubs (FWH) and Serial Presence.
Real-Time Clock (RTC)
The RTC is available in most PC systems, and the RTC’s internal registers and RAM are organized as two banks of 128 bytes each. The RTC contains the CMOS, as well as a real-time clock. The RTC consists of 14 bytes that are used to set the time and date.
The backup battery and the RAM is referred to as the CMOS battery and CMOS, respectively.
System Memory Map
A 32-bit Intel architecture system has up to 4 GB of address space. If the Physical Address Extensions (PAE) feature is available in the processor, up to 36 address bits are available, however, increasing the possible addressable memory space. The address space for the Intel® System Controller Hub is illustrated in Figure 3.2 as an example for this section.
The memory map contains specific regions used for specific purposes.
Legacy Address Range
The Legacy Address Range is used for multiple things in legacy systems. The Interrupt Vector Table (IVT) is located at physical address 0. Interrupts were discussed in depth in Chapter 2. The video BIOS gets loaded at 0xC000:0 and the video buffer resides in the 0xA000 segment. The 0xC800:0 through 0xD000 segments can be used for option ROMs. The 0xE000 and 0xF000 segments are typically reserved for any runtime BIOS or boot loader code or data.
Main Memory Address Range
The Main Memory Address Range, referred to earlier as system memory, is the memory available to the OS. Parts of the Main Memory Address Range may not be available for the OS to use, such as Stolen Memory or ACPI tables. This will be discussed in more detail in Chapter 8, which describes OS handoff structures.
PCI Memory Address Range
The PCI Memory Address Range is used during PCI enumeration to assign any requested memory-mapped input/output (MMIO). This memory is used to access registers in a specific PCI device.
For systems that have 4 GB or greater of system memory, the PCI Memory Address Range still resides just below 4 GB. In order to avoid losing access to the system memory in the location of the PCI MMIO, the memory is remapped just above 4 GB. Figure 3.3 illustrates how memory remapping works.
Splash Screen
Today, most system firmware hides the diagnostic information behind a bitmap with the company logo or any other image that the PC vendor deems suitable. These bitmaps are also known as splash screens—screens that keep the user’s eyes occupied until the OS can load. They serve no other purpose normally than a bit of marketing/brainwashing. It is common for BIOS or boot loaders to use splash screens to hide the boot process from users and to give them something to look at.
They are popular for embedded systems where the user is accustomed to some type of feedback as soon as they turn on the system. A set-top box is an example of this; if users do not get visual feedback almost immediately, they would assume that something was wrong.
Status and Error Messages
The following are types of status and error messages that provide information during the initialization process.
Display Messages
The diagnostic information hidden by splash screens can prove very useful in determining the state of the machine, should there be problems caused by an initialization issue, such as the inability to boot the PC to an OS.
These status and error messages are communicated to the user in different ways. The most obvious is by printing messages on the screen. Typically, the BIOS has an option for turning off the splash screen in order to display these diagnostic messages.
Most people have seen the memory test performed by the BIOS in much older systems where you see the message count to the size of memory in the system before printing that the memory test passed.
Beep Codes
There are times when a hardware failure occurs before the graphics device is initialized so that messages printed to the display device are useless. In this case, the BIOS or boot loader displays beep codes in order to help the user determine what has gone wrong. Of course, beep codes are not at all obvious but can be referenced in the BIOS documentation.
POST Codes
For firmware developers working on a motherboard, processor, or chipset power-on, a POST code display is used to indicate the last code that is executed. This method helps the developer determine where the failure occurred, regardless of whether it was caused in the hardware or in the firmware.
POST codes are typically displayed on two seven-segment displays. The displays are written to I/O port 0x80. Almost all BIOS or boot loaders use this method for debugging. Debug methods will be covered in depth in a later chapter.
Master Boot Record
The Master Boot Record (MBR) is on the first sector of a partitioned mass storage device. It contains the partition table, as well as boot code. The boot code is OS-dependent code whose primary purpose is to load the OS into memory. Once the BIOS, firmware, or boot loader reads the MBR, it will verify that “0xAA55”, the MBR signature, is present, as shown in Table 3.1. The BIOS or boot loader will then load the boot code to memory location 0x7C0:0 and will jump to that location.
| Address (in hex) | Description |
| 0 | Boot code |
| 0x1B8 | Optional signature |
| 0x1BC | 0x0 |
| 0x1BE | Partition table |
| 0x1FE | 0xAA55 |
GUID Partition Table
The GUID Partition Table (GPT), part of the UEFI specification, has replaced the Master Boot Record (MBR) in part because MBR is limited in size to 2.2TB. As drives have grown in size, the GPT allows for a maximum disk and partition size of 9.4 zettabytes. Most modern operating systems support and/or require a GPT above and beyond a legacy MBR. The Legacy MBR is located in LBA0, and the GPT header is located in LBA1, followed by the partition table itself.
Real Mode
Real Mode is 16-bit code created to work with 16-bit registers. Real Mode allows the accessing of only 1 MB of memory. Memory is accessed in the following format: segment : offset. The physical address is calculated by shifting the segment left by four bits and adding the offset to it. Figure 3.4 shows an example of calculating the physical address.
Protected Mode
Protected mode was introduced to address memory above 1 MB. Protected mode also allows 32-bit code to execute. Protected mode uses the segment register content as selectors or pointers into descriptor tables. Descriptors provide 24-bit base addresses with a physical memory size of up to 16 MB, support for virtual memory management on a segment swapping basis, and several protection mechanisms. The descriptors referred to are part of the Interrupt Descriptor Table (IDT) and Global Descriptor Tables (GDT). They are beyond the scope of this book. For more details on the GDT/IDT refer to the Intel® 64 and IA-32 Architectures Software Developer’s Manual online.
Logical Addressing
The segment selector identifies the segment to be accessed, and the offset identifies the offset in that segment. The logical address is formed by adding the base of the segment selector to the offset. The processor translates the logical address to a physical address, making the conversion transparent to software.
Flat Protected Mode
The preferred mode for system firmware is flat protected mode. This mode allows addressing memory above 1 MB, but does not require a logical-to-physical conversion. The GDT is set up so that the memory maps 1:1, meaning that the logical and physical addresses are identical.
Reset Vector
When an Intel architecture boot-strap processor (BSP) powers on, the first address fetched and executed is at physical address 0xFFFFFFF0, also known as the reset vector. This accesses the ROM or flash device at the top of the ROM: 0x10. The boot loader must always contain a jump to the initialization code in these top 16 bytes.
Programmable Interrupt Controller
The Programmable Interrupt Controller (PIC), or 8259, contains two cascaded 8259s with sixteen available IRQs. The PIC provides ISA-compatible interrupts and can support PCI-based interrupts by mapping the PCI interrupt onto the compatible ISA interrupt line. Table 3.2 shows the ISA compatible IRQ assignments.
The priority of the interrupts available in the 8259 is defined by the IRQ number itself, with 0 being the highest priority. The timer interrupt, or IRQ0, has the highest.
Advanced Programmable Interrupt Controller
There are two types of Advanced Programmable Interrupt Controllers (APIC), the I/OxAPIC, and the Local APIC.
The I/OxAPIC
The I/OxAPIC is contained in the south bridge, or ICH. It expands the number of IRQs available and allows an interrupt priority scheme that is independent of the interrupt number. For example, interrupt 9 can have a higher priority than interrupt 4.
Each IRQ has an associated redirection table entry that can be enabled or disabled and selects the IDT vector for the associated IRQ. The I/O APIC is only available when running in protected mode.
Table 3.2: PIC ISA-Compatible IRQ Assignments
| 8259 | IRQ number | ISA Interrupt Function |
| Master | 0 | Internal Timer (PIT) |
| Master | 1 | Keyboard |
| Master | 2 | Cascade interrupt to slave 8259 |
| Master | 3 | Serial Port A |
| Master | 4 | Serial Port B |
| Master | 5 | Parallel Port |
| Master | 6 | Floppy |
| Master | 7 | Parallel Port |
| Slave | 8 | RTC |
| Slave | 9 | Generic |
| Slave | 10 | Generic |
| Slave | 11 | Generic |
| Slave | 12 | PS2 mouse |
| Slave | 13 | Coprocessor |
| Slave | 14 | Hard disk |
| Slave | 15 | Hard disk |
The Local APIC
The local APIC is contained inside the processor and controls the interrupt delivery to the processor. Each local APIC contains its own set of associated registers, as well as a Local Vector Table (LVT). The LVT specifies the way the interrupts are delivered to each processor core.
Summary
Now that the basic terminology is clear, we can discuss more advanced items.