BCOS Home » ... » ... » ... » BCOS Boot Transition State Specifications for 80x86

BCOS 80x86 Boot Transition State 1 Specification

Preliminary Draft

Project Map

Contents:

Tables:

Figures:

Chapter 1: Overview

This document describes the transition from a boot loader to the Boot Abstraction Layer. It is intended to ensure compatiblity between different boot loaders and different implementations of the Boot Abstraction Layer.

Chapter 2: Specification Change Policy

Any changes made in future versions of this specification are not guaranteed to be backward or forward compatible (however changes may be backward or forward compatible if possible).

In general, this specification is not expected to change in future, and if it does all boot loaders and all Boot Abstraction Layers will need to be updated at the same time.

Chapter 3: Hardware State

3.1. CPUs

One CPU must be nominated as the "boot strap processor" (BSP). All other CPUs (if any) must be in the "wait for SIPI" state and not running.

The BSP's state is described by Table 3-1. BSP State for all calls to the Boot Abstraction Layer's entry point (which is used as an API).

Table 3-1. BSP State
ItemDescription
Processor modeProtected mode with "plain 32-bit paging" enabled
CSSet to a flat 32-bit code segment
DS, ES, FS, GS, SSSet to a flat 32-bit data segment
General purpose registersAs described by Chapter 4: Boot Abstraction Layer API
ESP/stackSet to point to a valid stack with at least 4 KiB of space
FPU, MMX, SSE, AVXUndefined (not used by BAL during transition)

3.2. Other hardware

All other hardware is assumed to be "owned" by the firmware or boot loader, and may be in any state that the firmware or boot loader requires. The Boot Abstraction Layer shall not make any assumptions about the state of any other hardware (including A20 gate, PIC chips, PCI devices, etc).

3.3. Physical Memory

The physical memory layout is undefined. The Boot Abstraction Layer shall not make any assumptions about the physical address space.

3.4. Virtual Memory

Due to the "symbiotic" relationship between boot loaders and the Boot Abstraction Layer, the virtual address space changes as the transition progresses.

At the beginning of the transition the virtual memory shall be configured as described by Figure 3-1. Initial Virtual Memory Layout.

Figure 3-1. Initial Virtual Memory Layout
  Top of virtual space 
Subsection 3.4.2. Paging Structure Mapping Area 0xFF7FF000
Subsection 3.4.3. Event Log 0xF0000000
 
 0xC0040000
Subsection 3.4.4. Boot Abstraction Layer Code and Data 0xC0000000
Reserved 0xBF800000
Subsection 3.4.5. Boot Information Page 0xBF7FF000
Subsection 3.4.6. Physical Page State Map 0xBF6FF000
Subsection 3.4.7. Faulty RAM List File 0xBF600000
 
 0x40000000
Reserved for boot loader's private use 0x00000000
 
Note: Not to scale.

When the transition is complete, the virtual memory shall be configured as described by Figure 3-2. Final Virtual Memory Layout.

Figure 3-2. Final Virtual Memory Layout
  Top of virtual space 
Subsection 3.4.2. Paging Structure Mapping Area 0xFF7FF000
Subsection 3.4.3. Event Log 0xF0000000
Boot Abstraction Layer's use 0xC0040000
Subsection 3.4.4. Boot Abstraction Layer Code and Data 0xC0000000
Reserved (becomes message buffer area) 0xBF800000
Subsection 3.4.5. Boot Information Page 0xBF7FF000
Subsection 3.4.6. Physical Page State Map 0xBF6FF000
Subsection 3.4.7. Faulty RAM List File 0xBF600000
Subsection 3.4.8. Physical Address Space Map 0xBF5D0000
Subsection 3.4.9. Trusted Memory List 0xBF5C0000
Subsection 3.4.10. Boot Script 0xBF5B0000
Subsection 3.4.11. Boot Variables 0xBF5A0000
Subsection 3.4.12. System Management BIOS Tables 0xB4000000
Subsection 3.4.13. MultiProcessor Specification Table 0xB0000000
Subsection 3.4.14. ACPI Tables 0xA0000000
Subsection 3.4.15. Reserved For Native Boot Table 0x9C000000
Subsection 3.4.16. Memory Mapped PCI Configuration Space Access Area List 0x98000000
Subsection 3.4.17. CPU Information Table 0x97000000
Reserved for CPU Description Table 0x94000000
Subsection 3.4.18. Locality Information Table 0x90000000
Subsection 3.4.20. Video Information 0x8F000000
 
Subsection 3.4.21. Boot Image 0x40000000
Reserved for boot loader use 0x00000000
 
Note: Not to scale.

3.4.1. Page Permissions and Attributes

All paging structure tables shall be created as "user, read/write, present"; except for anything withing the paging structure mapping area which shall be "supervisor, read/write, present".

All pages except for pages used by the event log (see Subsection 3.4.3. Event Log) shall be "supervisor, present", and all pages for the event log shall be "user, read only, present". This allows boot modules to read from the event log directly (but not modify it). Caching is left enabled for all pages.

To minimise the risk of CPU errata, and to improve performance by avoiding unnecessary atomic writes done by the CPU, the accessed and dirty flags are always set whenever any page or page table is mapped into the virtual address space. Note: See "Revision Guide for AMD Family 10h Processors", errata #298.

3.4.2. Paging Structure Mapping Area

All paging structures are mapped into the virtual address space (into the paging structure mapping area) to make modifying virtual memory mappings easier. The paging structure mapping area is different depending on whether "plain 32-bit paging" and "Physical Address Extensions (PAE)" are being used. The boot loader is responsible for detecting if the CPU supports PAE and shall use PAE if it is supported (and will only use "plain 32-bit paging" if PAE is not supported).

3.4.2.1. Paging Structure Mapping Area for "Plain 32-bit Paging"

When "plain 32-bit paging" is being used the paging structure mapping area shall be configured as described by Figure 3-3. Paging Structure Mapping Area Layout for "Plain 32-bit Paging".

Figure 3-3. Paging Structure Mapping Area Layout for "Plain 32-bit Paging"
  Top of virtual space 
Page directory mapping 0xFFFFF000
Page table mapping 0xFFC00000
Unused 0xFF7FF000
 
Note: Not to scale.
3.4.2.2. Paging Structure Mapping Area for PAE

When PAE is being used the paging structure mapping area shall be configured as described by Figure 3-4. Paging Structure Mapping Area Layout for PAE.

Figure 3-4. Paging Structure Mapping Area Layout for PAE
  Top of virtual space 
Page directory 3 mapping 0xFFFFF000
Page directory 2 mapping 0xFFFFE000
Page directory 1 mapping 0xFFFFD000
Page directory 0 mapping 0xFFFFC000
Page table mapping 0xFF800000
Page directory pointer table mapping 0xFF7FF000
 
Note: Not to scale.

3.4.3. Event Log

The event log is defined by the BCOS Event Log Specification.

3.4.4. Boot Abstraction Layer Code and Data

This area contains the Boot Abstraction Layer's code and data. The Boot Abstraction Layer's file shall comply with BCOS Boot Module File Format Specification; and (due to the relatively simple file format used) the Boot Abstraction Layer's file is mostly just loaded and mapped into this area "as is".

However; the boot loader is responsible for stripping any sub-files, and allocating pages for the Boot Abstraction Layer's "uninitialised data" area and ensuring the entire Boot Abstraction Layer's "uninitialised data" area is cleared to zero.

The boot loader is also responsible for checking that the Boot Abstraction Layer's CRC (if present) is correct, and checking that the Boot Abstraction Layer's digital signature matches the public key built into the boot loader. If any of these checks fail the boot loader must not execute the Boot Abstraction Layer (e.g. refuse to boot).

3.4.5. Boot Information Page

The Boot Information Page contains various variables and other data that is shared by both the boot loader and Boot Abstraction layer. Its format is described in Table 3-2. Boot Information Page Format.

Table 3-2. Boot Information Page Format
OffsetSizeCreatorDescription
0x0001024 bytesBoot loaderLookup table for CRC32
0x400256 bytesBoot loaderLookup table for SHA256
0x500256 bytesBoot loaderRSA2048 modulos (from boot loader's public key)
0x6004 bytesBoot loaderRSA2048 exponent (from boot loader's public key)
0x6044 bytesBoot loaderCurrent pseudorandom number generator seed
0x6084 bytesBoot loaderCurrent Event Log End Address
0x60C1 byteBoot loaderCurrent Event Log Status (0 = OK, 1 = failed and warning not issued, 2 = failed and warning issued)
0x60D1 byteReserved/unused
0x60E1 byteBoot loaderA20 gate method (0 = none, 1 = firmware, 2 = keyboard controller, 3 = fastA20)
0x60F1 byteBoot loaderA20 gate state (0 = unknown, 1 = enabled, 2 = disabled)
0x6101 byteBoot loaderRAM test mode (from Faulty RAM List file, see BCOS Faulty RAM List File Format Specification, Subsection 4.2.2. RAM Test Mode)
0x6111 byteBoot loaderRAM test control flags (from Faulty RAM List file, see BCOS Faulty RAM List File Format Specification, Subsection 4.2.3. RAM Test Control Flags)
0x6121 byteBoot loaderFaulty RAM List file state (0 = original is still current, 1 = original needs to be updated because something changed)
0x6131 byteReserved/unused
0x6144 bytesBoot loaderRun-time check target frequency in seconds (0 = disabled, see Subsubsection 3.4.5.1. Boot Information Page, Run-Time Check Target Frequency Field)
0x6184 bytesBoot loaderScheduled boot RAM test passes (from Faulty RAM List file, see BCOS Faulty RAM List File Format Specification, Subsection 4.2.5. Scheduled Boot RAM Test Passes)
0x61C4 bytesBoot loaderCurrent Physical Page State Map size in bytes/entries (or total pages covered by Physical Page State Map)
0x6204 bytesBoot loaderNumber of unusable pages in the Physical Page State Map
0x6244 bytesBoot loaderNumber of free pages in the Physical Page State Map
0x6284 bytesBoot loaderNumber of allocated pages in the Physical Page State Map
0x62C4 bytesBoot loaderPage number for "lowest possibly free page" in the Physical Page State Map (used to reduce allocation times)
0x63016 bytesReserved
0x6404 bytesBALNumber of entries in the Physical Address Space Map
0x6444 bytesBALAddress of the byte after the last entry in Physical Address Space Map
0x6481 byteBALPhysical Address Space Map detection mechanism (see Subsubsection 3.4.5.2. Physical Address Space Map Detection Mechanism)
0x6493 bytesReserved/unused
0x64C4 bytesBALNumber of entries in the Trusted Memory List
0x6504 bytesBALAddress of the byte after the last entry in the Trusted Memory List
0x6541 byteBALBoot script file state (0 = original is still current, 1 = original needs to be updated because something changed)
0x6553 bytesReserved/unused
0x6584 bytesBALNumber of ignored (malformed, duplicated or unknown) entries/variables in boot script
0x65C4 bytesBALCurrent number of boot variables
0x6604 bytesBALAddress of the byte after the last entry in the Boot Variable area
0x6644 byteBALSystem Management BIOS table size (including index area)
0x6684 bytesBALNumber of structures in the System Management BIOS table (no table if zero)
0x66C1 byteBALSystem Management BIOS document revision
0x66D1 byteBALSystem Management BIOS minor version
0x66E1 byteBALSystem Management BIOS major version
0x66F1 byteReserved/unused
0x6704 bytesBALNumber of entries in the MultiProcessor Specification table (no table if zero)
0x6744 bytesBALMultiProcessor Specification flags
0x6781 byteBALMultiProcessor Specification minor version
0x6791 byteBALMultiProcessor Specification major version
0x67A2 bytesReserved/unused
0x67C4 bytesBALNumber of tables in the ACPI area
0x6804 bytesBALReserved for Native Boot Table Size
0x6844 bytesBALNumber of entries in the Memory Mapped PCI Configuration Space Access Area list
0x6881 byteBALPCI Configuration Space Access Mechanism (0 = no PCI, 1 = mechanism #2, 2 = mechanism #1 without memory mapped access, 3 = mechanism #1 with memory mapped access)
0x68C4 bytesReserved/unused
0x6908 bytesBALLocal APIC base address (0xFFFFFFFFFFFFFFFF if no local APIC)
0x6984 bytesBALNumber of entries in CPU Information Table
0x69C4 bytesBALNumber of CPUs currently online
0x6A04 bytesBALHighest NUMA Domain
0x6A41 byteBALLocality Information Type (see Subsection 3.4.19. Locality Information)
0x68C3 bytesReserved/unused
0x6A84 bytesBALDefault Cross-Domain Latency (see Subsection 3.4.19. Locality Information)
0x6AC20 bytesReserved/unused
0x6C04 bytesBALAddress of the byte after the last used byte in the Video Information area
0x6C44 bytesBALTotal number of video heads
3.4.5.1. Boot Information Page, Run-Time Check Target Frequency Field

The value in this field is 0x00000000 if the run-time check is disabled (by the RAM test mode). Otherwise the value if calculated from the corresponding value in the Faulty RAM List file (see BCOS Faulty RAM List File Format Specification, Subsection 4.2.4. Run Time Check Target Frequency) by adding 1 and then multiplying by 60 (to convert "minutes" into "seconds").

3.4.5.2. Physical Address Space Map Detection Mechanism

This field is used to determine where the Physical Address Space Map data originally came from, and is set by the boot loader when the Physical Address Space Map is finalised (see Section 5.4. 0x00000004 - Physical Address Space Map Finalise). Valid values are shown in Table 3-3. Physical Address Space Map Detection Mechanism Values.

Table 3-3. Physical Address Space Map Detection Mechanism Values
NameValueDescription
PASMDETECT_unknown0x00Unknown
PASMDETECT_probing0x01Manual probing
PASMDETECT_CMOS0x02CMOS locations 0x17 and 0x18
PASMDETECT_CMOS_probe16MB0x03CMOS locations 0x17 and 0x18 with probing above 16 MiB
PASMDETECT_CMOS_probe64MB0x04CMOS locations 0x17 and 0x18 with probing above 64 MiB
PASMDETECT_int15_880x05BIOS interrupt 0x15 (AH=0x88)
PASMDETECT_int15_88_probe16MB0x06BIOS interrupt 0x15 (AH=0x88) with probing above 16 MiB
PASMDETECT_int15_88_probe64MB0x07BIOS interrupt 0x15 (AH=0x88) with probing above 64 MiB
PASMDETECT_int15_DA880x08BIOS interrupt 0x15 (AX=0xDA88)
PASMDETECT_int15_DA88_probe16MB0x09BIOS interrupt 0x15 (AX=0xDA88) with probing above 16 MiB
PASMDETECT_int15_8A0x0ABIOS interrupt 0x15 (AH=0x8A)
PASMDETECT_int15_8A_probe16MB0x0BBIOS interrupt 0x15 (AH=0x8A) with probing above 16 MiB
PASMDETECT_int15_C70x0CBIOS interrupt 0x15 (AH=0xC7)
PASMDETECT_int15_E8010x0DBIOS interrupt 0x15 (AX=0xE801)
PASMDETECT_int15_E8020x0EBIOS interrupt 0x15 (AX=0xE802)
PASMDETECT_int15_E8810x0FBIOS interrupt 0x15 (AX=0xE881)
PASMDETECT_int15_E8200x10BIOS interrupt 0x15 (EAX=0xE820)
PASMDETECT_int15_E820_ACPI10x11BIOS interrupt 0x15 (EAX=0xE820, ACPI 1.0)
PASMDETECT_int15_E820_ACPI30x12BIOS interrupt 0x15 (EAX=0xE820, ACPI 3.0)
PASMDETECT_int15_E820_ACPI40x13BIOS interrupt 0x15 (EAX=0xE820, ACPI 4.0)
PASMDETECT_UEFI0x80From EFI/UEFI
PASMDETECT_embedded0xFFFrom embedded ROM

3.4.6. Physical Page State Map

The Physical Page State Map is used for physical memory management (allocating free pages that aren't faulty or suspect and de-allocating them). It is a simple "one byte per page" array. The byte for each page contains the flags described in Table 3-4. Physical Page State Map Values.

Table 3-4. Physical Page State Map Values
Bit/sDescription
0 to 2Unused/reserved
3Page is allocated if set
4Page is suspect if set
5Page is faulty if set
6Unused/reserved
7Page is not usable RAM if set

The total number of pages covered by the Physical Page State Map is determined by the appropriate field in the Boot Information Page, and always begins with the page at physical address 0x00000000. Normally the boot loader only initialises a tiny part of the Free Page Map (e.g. corresponding to the first 512 KiB of the physical address space), and the Boot Abstraction Layer extends the Physical Page State Map later (when the Physical Address Space Map is finalised). The Physical Page State Map is never used for pages with physical addresses above 0xFFFFFFFF, so its absolute maximum size is 4 MiB.

Note that the Boot Information Page also includes several fields for accounting purposes (total number of pages in the free page map, number of allocated pages, number of unusable pages) and these fields are used for consistency checking, both against themselves (e.g. the sum of all types of pages is equal to the total pages) and against the Physical Page State Map.

When the Physical Page State Map is created by the boot loader or extended by the Boot Abstraction Layer, the Faulty RAM List must be consulted to determine if each page is considered faulty or suspect, regardless of the value in the "RAM Test Mode" field in the Faulty RAM List's extended header.

If the value in the "RAM Test Mode" field of the Faulty RAM List's extended header indicates that any RAM testing is to be done (not "Performance Mode" and not any of the "ECC modes"); then all physical pages described as "free and usable RAM" in the Physical Page State Map must be filled with a special 32-bit value. This value is determined by the page's physical address using the following formula:

Also, if the value in the "RAM Test Mode" field of the Faulty RAM List's extended header indicates that any RAM testing is to be done (not "Performance Mode" and not any of the "ECC modes"); both the boot loader and the Boot Abstraction Layer must test pages when they are allocated, including checking that the page is still filled with its special 32-bit value. If anything is found wrong with the page, it is marked as faulty or suspect (as appropriate) in the Physical Page State Map and not used.

3.4.7. Faulty RAM List File

This area contains the original Faulty RAM List File loaded by the boot loader. See BCOS Faulty RAM List File Format Specification.

3.4.8. Physical Address Space Map

The Physical Address Space Map is a variable length array of entries, where each entry describes an area of the physical address space, and where all entries cover the entire 64-bit virtual address space without any gaps. It is created by the Boot Abstraction Layer acting on behalf of the boot loader (via. the Boot Abstraction Layer's API).

The format of an entry in the PASM is described by Table 3-5. Physical Address Space Map Entry Format.

Table 3-5. Physical Address Space Map Entry Format
OffsetSizeDescription
0x008 bytesStarting address for this area (also "end address of previous area + 1")
0x084 bytesArea type flags (see Table 3-6. Physical Address Space Map Area Type Flags)
0x0C4 bytesNUMA domain for area (0xFFFFFFFF if unknown)
Table 3-6. Physical Address Space Map Area Type Flags
Bit/sDescription
31Reserved, used to mark "temporary" areas by Boot Abstraction Layer until Physical Address Space Map is finalised
30Mixed (reported as different types that are incompatible and can't be merged). Note: This should cause boot failures.
29Mixed (reported as different types that can be merged safely)
28Reserved
27Area is usable
26Area will become usable after the transition is complete and boot loader is discarded
25Area is RAM (including RAM that is reserved by firmware and can't be used by OS)
24Reserved
23Area has unclassified faults (that may effect addressing or contents)
22Area has faults effecting addressing (e.g. bus faults where replacing the device won't help)
21Area has faults effecting the contents (e.g. internal faults where replacing the device will fix the problem)
20Reserved
19Area is non-volatile (e.g. ROM or non-volatile RAM)
18Area is has higher than normal access times ("slow")
17Area is used by firmware (e.g. system ROM)
16Area must be saved when computer moved to "hibernate" (suspend to disk) state
3 to 15Reserved
2Area is hot-plug when set
0 to 1Hot-plug status (00b = not present, 01b = offline, 10b = changing between online and offline, 11b = present and usable). Reserved if the "area is hot-plug" flag clear.

Note: "usable" means that the OS can use it. For areas that are RAM this means that the RAM can be used by the OS; and for areas that are not RAM it means that the OS can use the area for memory mapped PCI devices.

3.4.9. Trusted Memory List

The Trusted Memory List is a list of areas (in the physical address space) that must be trusted to work correctly (up until the Faulty RAM List can be used to avoid using faulty areas). This should include all areas of RAM that the boot loader uses before Faulty RAM List is loaded and the physical memory manager initialised; and should also include any other areas of RAM that the boot loader can determine were relied on by whatever preceded the boot loader (e.g. areas that the firmware used). It is created by the Boot Abstraction Layer acting on behalf of the boot loader (via. the Boot Abstraction Layer's API).

Each entry in the Trusted Memory List has the format shown in Table 3-7. Trusted Memory List Entry Format.

Table 3-7. Trusted Memory List Entry Format
OffsetSizeDescription
0x0008 bytes64-bit address of first byte in area
0x0088 bytes64-bit address of last byte in area

3.4.10. Boot Script

The Boot Script area simply contains the Boot Script's file. This file must comply with BCOS Boot Script File Format Specification.

3.4.11. Boot Variables

The Boot Variables area is created by the Boot Abstraction Layer as a result of parsing/processing the Boot Script; and then managed by the Boot Abstraction Layer. The contents are a list of variable length entries that use the same format as used for variables in the boot script itself (described in BCOS Boot Script File Format Specification, Section 3.2. Script Data).

3.4.12. System Management BIOS Tables

This area contains a copy of the System Management BIOS tables. For a description of the contents of this area, see Section 5.10. 0x00000030 - Initialise System Management BIOS Tables.

3.4.13. MultiProcessor Specification Table

This area contains a copy of the MultiProcessor Specification table (as defined by the MultiProcessor Specification). For default configurations see Section 5.11. 0x00000031 - Set System Management BIOS Tables.

3.4.14. ACPI Tables

This area contains a copy of the ACPI tables. For a description of the contents of this area, see Section 5.14. 0x00000038 - Initialise ACPI Tables.

3.4.15. Reserved For Native Boot Table

This area is currently reserved.

The Native Boot Table is intended to be used in specific scenarios (e.g. "boot from ROM" boot loaders); where the boot loader provides minimal information needed by the operating system before a motherboard driver is started and then the motherboard driver provides information needed from that point on; and where System Management BIOS Tables, MultiProcessor Specification Table and ACPI Tables aren't relied on by the motherboard driver (and therefore don't need to be provided by the boot loader).

The information needed by the operation system before a motherboard driver is started that has to be provided by the Native Boot Table includes:

However it is likely that some "currently unforeseeable" information will also be needed, and for this reason the Native Boot Table hasn't been designed yet.

3.4.16. Memory Mapped PCI Configuration Space Access Area List

This area contains a list of areas used for memory mapped PCI configuration space access. If it is used it's either created by the boot loader and checked by the Boot Abstraction Layer (see Section 5.17. 0x00000041 - Set Memory Mapped PCI Configuration Space Access Area List), or created by the Boot Abstraction Layer (see Section 5.16. 0x00000040 - Set PCI Configuration Space Access Mechanism Hint).

Each entry in this list describes a memory mapped PCI configuration space access area and has the format shown in Table 3-8. Memory Mapped PCI Configuration Space Access Area List Entry Format.

Table 3-8. Memory Mapped PCI Configuration Space Access Area List Entry Format
OffsetSizeDescription
0x008 bytes64-bit physical address for the start of the area
0x082 bytesPCI Segment Group
0x091 byteStarting PCI bus number for this area
0x0A1 byteEnding PCI bus number for this area
0x0C4 bytesNUMA domain for area (0xFFFFFFFF if unknown)

3.4.17. CPU Information Table

This area contains one entry per CPU. Entries in this table have the format shown in Table 3-9. CPU Information Table Entry Format. The reserved fields are not set during Transition State 1 (and are set after Transition State 1 has completed and before Transition State 2 is started, when thorough CPU feature and topology detection are performed).

Table 3-9. CPU Information Table Entry Format
OffsetSizeDescription
0x004 bytesAPIC ID
0x042 bytesReserved for CPU description number within CPU Description Table
0x061 byteCPU state (see Table 3-10. CPU State Values)
0x071 byteReserved for CPU number within core
0x082 byteReserved for Core number within physical package
0x0A2 byteReserved for Physical package within system
0x0C4 bytesNUMA domain (0xFFFFFFFF if unknown)
Table 3-10. CPU State Values
ValueMeaning
0x00Unstarted
0x01Physically removed
0x02Hard offline
0x03Soft offline
0x04Online
0x80Was unstarted, but currently changing to a new state
0x81Was physically removed, but currently changing to a new state
0x82Was hard offline, but currently changing to a new state
0x83Was soft offline, but currently changing to a new state
0x84Was online, but currently changing to a new state

3.4.18. Locality Information Table

This area contains information about any additional latency costs when accessing something in one NUMA domain from another NUMA domain. The data in this area depends on the Locality Information Type field in the Boot Information Page, and is described in Subsection 3.4.19. Locality Information.

3.4.19. Locality Information

For NUMA systems, resources (CPUs, memory, devices, etc) exist within NUMA domains, and when something in one NUMA domain accesses something in another NUMA domain there is an additional latency cost called the "cross-domain latency". To improve performance for this situation the operating system needs to know which resources are in which NUMA domain and what the cross-domain latency is between NUMA domains. The information about which resources are in which NUMA domain is part of the information about the resource itself (e.g. built into Physical Address Space Map entries, CPU Information Table entries, etc).

How the cross-domain latency information is represented depends on the Locality Information Type field in the Boot Information Page.

3.4.19.1. Locality Information Type 0x00, No Information

Type 0x00 is used when there is no cross-domain latency information, either because the system only has one NUMA domain, the firmware provided none, or the information provided can't be converted into a suitable format.

3.4.19.2. Locality Information Type 0x10, Simple Relative Information

Type 0x10 is used when the cross-domain latency is always the same. In this case the Locality Information Table is not used and the Default Cross-Domain Latency field in the Boot Information Page contains the relative latency penalty (see Subsubsection 3.4.19.6. Locality Information, Relative Latency Penalties) between all NUMA domains (excluding between a NUMA domain and itself, which is always "none").

Note: Where possible; after Transition State 1 has completed and CPUs have been started, the Boot Abstraction Layer may use direct measurement to convert Simple Relative Information into another/better (absolute) Locality Information Type. This is beyond the scope of this specification.

3.4.19.3. Locality Information Type 0x11, Simple Absolute Information

Type 0x11 is used when the cross-domain latency is always the same. In this case the Locality Information Table is not used and the Default Cross-Domain Latency field in the Boot Information Page contains the absolute latency penalty (see Subsubsection 3.4.19.7. Locality Information, Absolute Latency Penalties) between all NUMA domains (excluding between a NUMA domain and itself, which is always "none").

3.4.19.4. Locality Information Type 0x20, Grid Relative Information

For type 0x20, the Default Cross-Domain Latency field in the Boot Information Page is ignored, and Locality Information Table contains a "max. domains * max. domains" grid of (4 byte) relative latency penalties (see Subsubsection 3.4.19.6. Locality Information, Relative Latency Penalties).

Note: Where possible; after Transition State 1 has completed and CPUs have been started, the Boot Abstraction Layer may use direct measurement to convert Grid Relative Information into another/better (absolute) Locality Information Type. This is beyond the scope of this specification.

3.4.19.5. Locality Information Type 0x21, Grid Absolute Information

For type 0x20, the Default Cross-Domain Latency field in the Boot Information Page is ignored, and Locality Information Table contains a "max. domains * max. domains" grid of (4 byte) absolute latency penalties (see Subsubsection 3.4.19.7. Locality Information, Absolute Latency Penalties).

3.4.19.6. Locality Information, Relative Latency Penalties

Relative latency penalty values are 4 byte values described by Table 3-11. Relative Latency Penalty Values.

Table 3-11. Relative Latency Penalty Values
Value/sMeaning
0xFFFFFFFFUnreachable (something in one NUMA domain can't access anything in the other)
0xFFFFFFFEThe penalty is unknown (assumed to be "very high latency")
0x00000100 to 0xFFFFFFFDInvalid/reserved
0x00000001 to 0x000000FFRelative latency penalty (0x01 = "relatively low latency", 0xFF = "relatively high latency")
0x00000000No latency penalty

Note: The operating system does not support systems where something in one NUMA domain can't access anything in another NUMA domain; except for the purpose of "hot-plug NUMA" (e.g. where a NUMA domain is not present and can't be accessed from anything in any NUMA domain).

3.4.19.7. Locality Information, Absolute Latency Penalties

Absolute latency penalty values are 4 byte values described by Table 3-12. Absolute Latency Penalty Values.

Table 3-12. Absolute Latency Penalty Values
Value/sMeaning
0xFFFFFFFFUnreachable (something in one NUMA domain can't access anything in the other)
0xFFFFFFFEThe penalty is unknown (assumed to be "very high latency")
0x00000001 to 0xFFFFFFFDLatency penalty in nanoseconds
0x00000000No latency penalty

Note: The operating system does not support systems where something in one NUMA domain can't access anything in another NUMA domain; except for the purpose of "hot-plug NUMA" (e.g. where a NUMA domain is not present and can't be accessed from anything in any NUMA domain).

3.4.20. Video Information

This area contains a linked list of video head entries. The format of each entry is shown in Table 3-13. Video Head Entry Format.

Table 3-13. Video Head Entry Format
OffsetSizeDescription
0x004 bytesAddress of next video head entry in the list (0 if none)
0x042 bytesDisplay Vendor ID (0xFFFF if unknown)
0x062 bytesDisplay Product ID (0xFFFF if unknown)
0x084 bytesNumber of video mode entries
0x0C4 bytesAddress of video mode entry for selected video mode (0x00000000 if none)
0x104 bytesBoot module number (0xFFFFFFFF if none)
0x14VariesVideo mode entries (see Subsubsection 3.4.20.1. Video Mode Entries)
3.4.20.1. Video Mode Entries

Each video mode that can be set by the boot loader is described by a video mode entry. The format of a video mode entry is described by Table 3-14. Video Mode Entry Format.

Table 3-14. Video Mode Entry Format
OffsetSizeDescription
0x0004 bytesBoot loader's "video mode ID" (Subsubsection 3.4.20.3. Video Mode Entry Mode ID)
0x0042 bytesFlags (Subsubsection 3.4.20.4. Video Mode Entry Flags)
0x0061 byteReliability rating (Subsubsection 3.4.20.5. Video Mode Entry Reliability Ratings)
0x0071 byteReliability rating for derived video modes (Subsubsection 3.4.20.5. Video Mode Entry Reliability Ratings)
0x0081 byteMonitor reliability rating (Subsubsection 3.4.20.5. Video Mode Entry Reliability Ratings)
0x0091 bytePixel format (Subsubsection 3.4.20.8. Video Mode Entry Pixel Format)
0x00A2 bytesHorizontal Resolution (Subsubsection 3.4.20.9. Video Mode Entry Horizontal and Vertical Resolution)
0x00C2 bytesVertical Resolution (Subsubsection 3.4.20.9. Video Mode Entry Horizontal and Vertical Resolution)
0x00E2 bytesFrame rate (Subsubsection 3.4.20.10. Video Mode Entry Frame Rate)
0x0104 bytesPhysical address of frame buffer
0x0144 bytesBytes between lines
0x0184 bytesMaximum supported pixel clock frequency in Hz (0x0000000 if unknown)
0x01C1 byteReserved or Signal type (Subsubsection 3.4.20.11. Video Mode Entry Signal Type, Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
0x01D1 byteMonitor preference rating (Subsubsection 3.4.20.6. Video Mode Entry Monitor Preference)
0x01E2 bytesFinal Rating (Subsubsection 3.4.20.7. Video Mode Entry Final Rating)
0x0204 bytesReserved or Pixel clock frequency in Hz (Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
0x0242 bytesReserved or Horizontal left and right margin width in pixels (Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
0x0262 bytesReserved or Horizontal back porch width in pixels (Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
0x0282 bytesReserved or Horizontal sync width in pixels (Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
0x02A2 bytesReserved or Horizontal front porch width in pixels (Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
0x02C2 bytesReserved or Vertical top and bottom margin width in pixels (Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
0x02E2 bytesReserved or Vertical back porch width in pixels (Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
0x0302 bytesReserved or Vertical sync width in pixels (Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
0x0322 bytesReserved or Vertical front porch width in pixels (Subsubsection 3.4.20.2. Video Mode Entry Reserved or Used Fields)
3.4.20.2. Video Mode Entry Reserved or Used Fields

Various fields in the video mode entry are either reserved or used depending on the situation.

When the boot loader informs the Boot Abstraction Layer about a video mode (see Section 5.22. 0x00000088 - Add Video Mode), if the boot loader has set bit 6 in the flags field (to indicate that video mode timing is known) then these fields must be set correctly by the boot loader. Otherwise (if bit 6 was not set) the boot loader may only provide a short video mode entry (without the "reserved or used" fields) and the Boot Abstraction Layer must treat these fields as "not present" (and fill the missing fields with zeros when copying it).

When the boot loader tells the Boot Abstraction Layer to prepare a video mode (Section 5.23. 0x0000008E - Prepare Video Mode) and the Boot Abstraction Layer informs the boot loader which video mode it has prepared for (by returning the address of the selected video mode entry); if the Boot Abstraction Layer has set bit 15 in the flags field (to indicate that video mode timing is being specified by the Boot Abstraction Layer) then these fields must be set correctly by the Boot Abstraction Layer. Otherwise (if bit 15 was not set) the boot loader must treat these fields as reserved.

3.4.20.3. Video Mode Entry Mode ID

This field contains an arbitrary ID that the boot loader uses to identify the video mode. The Boot Abstraction Layer does not use this field.

3.4.20.4. Video Mode Entry Flags

The flags field is described in Table 3-15. Video Mode Entry Flags.

Table 3-15. Video Mode Entry Flags
Bit/sMeaning
0Pixel doubling (horizontal resolution halved) can be enabled/disabled if set
1Double scanning (vertical resolution halved) can be enabled/disabled if set
2Interlaced operation can be enabled/disabled if set
3 to 5Reserved/unused
6Timing is known if set ("reserved or used" fields set by boot loader)
7Timing can be specified if set
8Pixel double (horizontal resolution halved) used if set
9Double scanning (vertical resolution halved) used if set
10Interlaced operation used if set
11 to 14Reserved/unused
15Timing is specified if set ("reserved or used" fields set by Boot Abstraction Layer)

The boot loader provides these flags initially. If allowed (by bits 0 to 7) the Boot Abstraction Layer can create entries for derived video modes with different values in bits 8 to 15. If the Boot Abstraction Layer creates an entry for a derived video mode that has bit 15 set, the Boot Abstraction Layer must also set the "reserved or optional" fields to indicate the video mode timing it is requesting.

3.4.20.5. Video Mode Entry Reliability Ratings

These fields contain a value from 0x00 to 0xFF. The boot loader provides reliability rating for the base video mode and derived video modes to indicate how reliable the boot loader thinks the video mode will be (where 0x00 means the boot loader thinks the video card will fail to support this video mode correctly, and 0xFF means the boot loader thinks the video card will definately support this video mode correctly). When the Boot Abstraction Layer created a derived video mode, it copies the reliability rating for derived video modes into the base video mode reliability rating field.

The monitor reliability rating is determined by the Boot Abstraction Layer, by using information from the monitor's "Display Identification Data" file (see BCOS Display Identification Data File Format Specification) or conservative hueristics (if no monitor information is present).

3.4.20.6. Video Mode Entry Monitor Preference

This field contains a value from 0x00 to 0xFF representing the monitor's preference for the video mode; where 0x00 means the monitor would prefer any other video mode and 0xFF represents the best possible video mode for the monitor (e.g. likely representing the display's native resolution).

The monitor's preference is determined by the Boot Abstraction Layer, by using information from the monitor's "Display Identification Data" file (see BCOS Display Identification Data File Format Specification) or conservative hueristics (if no monitor information is present).

3.4.20.7. Video Mode Entry Final Rating

This field contains a value from 0x0000 to 0xFFFF representing the final rating for the video mode. This rating is calculated by the Boot Abstraction Layer using the following formulas:

When choosing a video mode, the Boot Abstraction Layer choosese the video mode with the highest final rating. If something goes wrong (e.g. the boot loader reports that it failed to set the chosen video mode via Section 5.24. 0x0000008F - Video Mode Status) the Boot Abstraction Layer changes the video mode's final rating to zero and chooses another video mode.

3.4.20.8. Video Mode Entry Pixel Format

The possible values for pixel formats are described in Table 3-16. Video Mode Entry Pixel Format Values.

Table 3-16. Video Mode Entry Pixel Format Values
ValueDescription
0x008 bits per pixel, in "0:3:3:2" format (highest 3 bits used for first colour channel, etc)
0x0115 bits per pixel, in "1:5:5:5" format (highest bit reserved, next 5 bits used for first colour channel, etc)
0x0216 bits per pixel, in "0:5:6:5" format (highest 5 bits used for first colour channel, etc)
0x0324 bits per pixel, in "0:8:8:8" format (highest 8 bits used for first colour channel, etc)
0x0432 bits per pixel, in "8:8:8:8" format (highest 8 bits reserved, next 8 bits used for first colour channel, etc)
3.4.20.9. Video Mode Entry Horizontal and Vertical Resolution

For video modes there are 2 different resolutions - one that is used for video mode timing, and one that is used for software. When pixel doubling and double scanning aren't being used, these resolutions are the same.

When pixel doubling is used, the horizontal resolution field of the video mode entry contains the horizontal resolution used for video mode timing, and the horizontal resolution used by software is half of the value stored in this field.

When double scanning is used, the vertical resolution field of the video mode entry contains the vertical resolution used for video mode timing, and the vertical resolution used by software is half of the value stored in this field.

3.4.20.10. Video Mode Entry Frame Rate

This field contains an estimate of the video mode's frame rate in 256ths of a Hertz units (or Hertz in 8.8 fixed point format). For example, the value 0xFFFF represents 255.996 Hz and the value 0x3C00 represents 60.000 Hz. The value 0x0000 represents "unknown".

3.4.20.11. Video Mode Entry Signal Type

The signal type determines various characteristics of the signals used, and is described by Table 3-17. Video Mode Entry Signal Type Values.

Table 3-17. Video Mode Entry Signal Type Values
ValueDescription
0x00Analogue composite sync without serrations, sync on green signal only
0x01Analogue composite sync without serrations, sync on all video signals
0x02Analogue composite sync with serrations, sync on green signal only
0x03Analogue composite sync with serrations, sync on all video signals
0x40Bipolar analogue composite sync without serrations, sync on green signal only
0x41Bipolar analogue composite sync without serrations, sync on all video signals
0x42Bipolar analogue composite sync with serrations, sync on green signal only
0x43Bipolar analogue composite sync with serrations, sync on all video signals
0x80Digital composite sync without serrations, horizontal sync is negative
0x81Digital composite sync without serrations, horizontal sync is positive
0x82Digital composite sync with serrations, horizontal sync is negative
0x83Digital composite sync with serrations, horizontal sync is positive
0xC0Digital seperate sync, vertical sync is negative, horizontal sync is negative
0xC1Digital seperate sync, vertical sync is negative, horizontal sync is positive
0xC2Digital seperate sync, vertical sync is positive, horizontal sync is negative
0xC3Digital seperate sync, vertical sync is positive, horizontal sync is positive

3.4.21. Boot Image

The Boot Image area simply contains the Boot Image's file. This file must comply with BCOS Boot Image File Format Specification.

Chapter 4: Boot Abstraction Layer API

The Boot Abstraction Layer's entry point is actually the entry point for the Boot Abstraction Layer API intended to be used by boot loaders. The boot loader simply calls the address provided in the Boot Abstraction Layer's header. Parameters are passed in registers. For input parameters, EAX always contains the function number, and all other general purpose registers are either used as described by the documentation for that function below or are not used. For output parameters, EAX always contains the function's status code, and all other general purpose registers are either used as described by the documentation for that function below or are not used and returned unmodified.

Please note that the Boot Abstraction Layer API function's are mostly intended to be used by the boot loader in ascending numerical order; and higher numbered functions may fail simply because prequisites (lower numbered functions) weren't used first.

4.1. Boot Abstraction Layer API Status Codes

The status codes that may be returned by a Boot Abstraction Layer API is different for each function (and described by the documentation for that function below).

There is a common set of status codes that the Boot Abstraction Layer's API may return, to make it easier to display/report any error to the user. This set of status codes is described in Table 4-1. Boot Abstraction Layer API Status Codes.

Table 4-1. Boot Abstraction Layer API Status Codes
NameValueDescription
0x00000000No error
BALERR_unknown0x00000001An unknown error occured
BALERR_unknownFunction0x00000002The function number (from EAX) isn't known or supported
BALERR_sequenceError0x00000003The function number (from EAX) was used out of sequence (prerequisites not met)
BALERR_badParameter0x00000004An input parameter was bad
BALERR_physMemCorruption0x00000005The Boot Abstraction Layer detected that physical memory management has become corrupted
BALERR_noMem0x00000006Not enough memory
BALERR_badNFFheader0x00000007A file's native file format header didn't comply with the BCOS Native File Format Specification
BALERR_badFileSize0x00000008A file's native file format header had a bad file size
BALERR_badFileCRC0x00000009A file's native file format header had a bad CRC
BALERR_badFileType0x0000000AA file's native file format header had a bad file type
BALERR_badExtendedHeader0x0000000BA file's extended file format header didn't comply with the file format's specification
BALERR_badFileData0x0000000CA file had bad file data
BALERR_notFound0x0000000DSomething was not found (e.g. when updating or deleting something)
BALERR_exists0x0000000ESomething already exists (e.g. when creating something new)
BALERR_tooMany0x0000000FToo many of something (e.g. when creating something new)
BALERR_permissionDenied0x00000010The function failed due to permission checks
BALERR_badData0x00000011The function failed due to bad data
BALERR_bootModuleCrashed0x00000012A boot module crashed

Chapter 5: Boot Abstraction Layer API Function Reference

5.1. 0x00000000 - Initialise

The Boot Abstraction Layer initialises itself, checks the boot loader's physical memory manager initialisation (the Physical Page State Map and related statistics in the Boot Information Page) and resets the Physical Address Space Map. The Boot Abstraction Layer may also check other data provided by the boot loader to ensure correctness.

Inputs:

Outputs:

The "test page" is a virtual page that the Boot Abstraction Layer can use for testing for faulty RAM (or anything else where a physical page needs to be temporarily mapped). The boot loader must guarantee that any page tables are already allocated for the address provided. The Boot Abstraction Layer must assume that the boot loader has used the test page area between any BAL API functions. The boot loader must assume that the Boot Abstraction Layer has used the test page area during any BAL API functions.

5.1.1. Boot Loader's "Get Elapsed Time" function

The Boot Abstraction Layer makes no assumptions about the use or availability of any time source (until after the boot loader is terminated and the Boot Abstraction Layer assumes ownership of all hardware). Instead, to obtain elapsed time the Boot Abstraction Layer uses a function provided by the boot loader. This is primarily to allow the Boot Abstraction Layer to create entries in the event log.

The boot loader's function has no input parameters, and all registers that aren't used for output parameters must remain unchanged. The output parameters are:

5.2. 0x00000001 - Physical Address Space Map Reset

The Boot Abstraction Layer resets the Physical Address Space Map to safe defaults. The safe defaults are described in Figure 5-1. Default Physical Address Space Map.

Figure 5-1. Default Physical Address Space Map
  0xFFFFFFFFFFFFFFFF 
Nothing, usable for memory mapped PCI (temporary) 0x0000000100000000
Nothing, not usable (temporary) 0x00000000FE000000
Nothing, usable for memory mapped PCI (temporary) 0x0000000001000000
Nothing, not usable (temporary) 0x0000000000000000
Note: Not to scale.

Inputs:

Outputs:

5.3. 0x00000002 - Physical Address Space Map Add Area

The Boot Abstraction Layer merges the details for the area being added into the Physical Address Space Map.

Inputs:

Outputs:

5.4. 0x00000004 - Physical Address Space Map Finalise

The Boot Abstraction Layer converts any Physical Address Space Map entries marked as "temporary" (that haven't been overwritten by added areas) into equivelent non-temporary types, and simplifies the Physical Address Space Map (e.g. joining adjacent areas, etc).

Before calling this function, the boot loader is expected to set the A20 gate state field and the A20 gate method field in the Boot Information Page. These fields (and the A20 gate) must remain unchanged after the Physical Address Space Map has been finalised.

Inputs:

Outputs:

5.5. 0x00000008 - Extend Physical Page State Map

The Boot Abstraction Layer uses the Physical Address Space Map to determine the new size of the Physical Page State Map, then (if the size of the Physical Address Space Map needs to be increased):

Note: In rare cases it is possible that the initial (small) Physical Address Space Map doesn't have enough free pages, causing this function to be unable to allocate pages needed to increase the size of the Physical Address Space Map. To minimise the chance of this happening the Boot Abstraction Layer typically extends the Physical Address Space Map in many stages - e.g. extending it to fill the currently allocated pages, then allocating one page and extending it to fill that page, then allocating another page and extending it a little more, and so on until the Physical Address Space Map reaches the appropriate size.

Inputs:

Outputs:

5.6. 0x00000010 - Add Trusted Memory Area

The Boot Abstraction Layer merges the details for the area being added into the Trusted Memory List.

Inputs:

Outputs:

5.7. 0x00000012 - Trusted Memory List Finalise

The Boot Abstraction Layer:

Note: These checks ignore suspect pages (which may be working correctly); as the risk of problems caused by firmware using a "known suspect but actually faulty" page is considered less significant than the problems caused by refusing to boot in the "suspect but working correctly" case.

Inputs:

Outputs:

5.8. 0x00000020 - Initialise Boot Script

The Boot Abstraction Layer checks the boot script to ensure it is valid/usable; then parses the boot script, creates the "boot variable" data (see Subsection 3.4.11. Boot Variables, and sets the corresponding fields in the Boot Information Page ("boot script file state", "number of ignored boot variables" and "current number of boot variables"). Any entries in the boot script that are malformed are skipped/ignored, and don't cause an error, and don't cause a boot failure.

The boot loader needs to load the boot script into the virtual address space before calling this function.

Inputs:

Outputs:

5.9. 0x00000024 - Initialise Boot Image

The Boot Abstraction Layer determines if the boot image is compressed and decompresses it if necessary; then checks the boot image to ensure it is valid/usable.

The boot loader needs to load the (compressed or uncompressed) boot image into the virtual address space before calling this function.

Inputs:

Outputs:

5.10. 0x00000030 - Initialise System Management BIOS Tables

The Boot Abstraction Layer checks the System Management BIOS tables and either accepts or rejects them.

The boot loader needs to copy the firmware's System Management BIOS tables "as is" into normal pages of RAM mapped into the "System Management BIOS Tables" area (described in Figure 3-2. Final Virtual Memory Layout) before calling this function. If the system has no System Management BIOS tables this function should not be used. If this function returns BALERR_badData the Boot Abstraction Layer will free any pages in the System Management BIOS Tables area.

Sadly, the System Management BIOS are extremely poorly designed (finding anything involves a linear search of structures where you have to scan bytes to determine the end of the last string in every structure). To avoid that, if the Boot Abstraction Layer accepts the System Management BIOS tables it must move the tables to create space for an index, and create the index while reformatting the table. The format of an index entry is described in Table 5-1. SMBIOS Index Entry Format.

Table 5-1. SMBIOS Index Entry Format
OffsetSizeDescription
0x0001 byteEntry type (e.g. 0 = BIOS information, 1 = system information, etc)
0x0011 byteLength of the structure's "formatted area"
0x0022 bytesNumber of ASCIIZ strings after the structure's "formatted area"
0x0044 bytesOffset of the entry within the "System Management BIOS Tables" area

The table's entries immediately follow the last index entry. To reformat the table's entries, the Boot Abstraction Layer discards the first 2 bytes of the entry (it's type and formatted area length, which are in the index), and either discards the 2 byte "structure terminator" (if there are no strings) or discards the 1 byte "set of strings terminator" (if there are strings). The Boot Abstraction Layer may insert zero bytes at the end of structures to align the next structure to a 2 byte (or larger) boundary, however there is little benefit in aligning the end of structures too much because the System Management BIOS specifications use "random misalignment" within structures. The Boot Abstraction Layer should also remove the "End of Table" structure while reformatting the table.

If the System Management BIOS Tables are accepted, after the Boot Abstraction Layer has reformatted the tables it should free any unnecessary pages (e.g. between the new end of the structures and the old address determined from "size of tables" provided by the boot loader), and must set the fields in the Boot Information Page (the "number of structures in the System Management BIOS table" field and the "System Management BIOS major/minor/revision" fields).

Inputs:

Outputs:

5.11. 0x00000031 - Set System Management BIOS Tables

The Boot Abstraction Layer checks the System Management BIOS tables and either accepts or rejects them.

The boot loader needs to provide System Management BIOS tables that have already been indexed and reformatted (as described by Section 5.10. 0x00000030 - Initialise System Management BIOS Tables) in normal pages of RAM mapped into the "System Management BIOS Tables" area (described in Figure 3-2. Final Virtual Memory Layout) before calling this function. If the system has no System Management BIOS tables this function should not be used. If this function returns BALERR_permissionDenied the Boot Abstraction Layer will free any pages in the System Management BIOS Tables area.

If the System Management BIOS Tables are accepted, the Boot Abstraction Layer must set the relevant fields in the Boot Information Page (the "number of structures in the System Management BIOS table" field and the "System Management BIOS major/minor/revision" fields).

Note: This function is provided as an alternative for "fast reboot" scenarios (where one instance of the OS boots another instance of the OS without doing a full reboot and without involving the firmware).

Inputs:

Outputs:

5.12. 0x00000034 - Initialise MultiProcessor Specification Table

The Boot Abstraction Layer checks the MultiProcessor Specification table and either accepts or rejects it.

If the table is accepted; the Boot Abstraction Layer must check for I/O Interrupt Assignment Entries and Local Interrupt Assignment Entries that use "conforms to the specification of the bus" for the trigger mode or polarity fields and replace them with correct information for the bus (and update the checksum), such that all trigger mode fields contain either 01b (edge-triggered) or 11b (level-triggered) and all polarity fields contain either 01b (active high) or 11b (active low). This allows the operating system to treat them as 1-bit fields (and ignore the least significant bit). If the MultiProcessor Specification table is accepted, the Boot Abstraction Layer must also set the relevant fields in the Boot Information Page (the "number of entries in the MultiProcessor Specification table" field, the "MultiProcessor Specification flags" field and the "MultiProcessor Specification major/minor" fields).

The boot loader needs to copy the firmware's MultiProcessor Specification table into normal pages of RAM mapped into the "MultiProcessor Specification Table" area (described in Figure 3-2. Final Virtual Memory Layout) before calling this function.

If the system has no MultiProcessor Specification table this function should not be used. If this function returns BALERR_badData the Boot Abstraction Layer will free any pages in the MultiProcessor Specification Table area.

Inputs:

Outputs:

5.13. 0x00000035 - Set Default MultiProcessor Specification Table

The Boot Abstraction Layer uses the provided default configuration number to create a MultiProcessor Specification table, so that it looks like a full configuration table was provided even though it wasn't.

If default configuration number is accepted the Boot Abstraction Layer must make sure that, in I/O Interrupt Assignment Entries and Local Interrupt Assignment Entries, all trigger mode fields contain either 01b (edge-triggered) or 11b (level-triggered) and all polarity fields contain either 01b (active high) or 11b (active low). This allows the operating system to treat them as 1-bit fields (and ignore the least significant bit). If default configuration number is accepted the Boot Abstraction Layer must also set the relevant fields in the Boot Information Page (the "number of entries in the MultiProcessor Specification table" field, the "MultiProcessor Specification flags" field and the "MultiProcessor Specification major/minor" fields).

Inputs:

Outputs:

5.14. 0x00000038 - Initialise ACPI Tables

The Boot Abstraction Layer checks the ACPI tables and either accepts or rejects them.

If the ACPI tables are accepted; the Boot Abstraction Layer must check the APIC/MADT table (if present) for Interrupt Source Override Structures, Non-Maskable Interrupt Source Structures, Local APIC NMI Structures, Platform Interrupt Sources Structures and Local x2APIC NMI Structures that use "conforms to the specification of the bus" for the trigger mode or polarity fields and replace them with correct information for the bus (and update the APIC/MADT table's checksum), such that all trigger mode fields contain either 01b (edge-triggered) or 11b (level-triggered) and all polarity fields contain either 01b (active high) or 11b (active low). This allows the operating system to treat them as 1-bit fields (and ignore the least significant bit). Note: In all cases where ACPI allows "conforms to the specification of the bus", either the "source bus" must be ISA (Interrupt Source Override Structures) or there is no mention of what type of bus the interrupt comes from (and ISA is the "least likely to be wrong" assumption).

If the ACPI tables are accepted, the Boot Abstraction Layer must also set the relevant field in the Boot Information Page (the "number of tables in the ACPI area" field).

The boot loader needs to build an index of the ACPI tables at the start of the ACPI area (described in Figure 3-2. Final Virtual Memory Layout), and copy the firmware's ACPI tables into normal pages of RAM immediately after the index. Each index entry has the format shown in Table 5-2. ACPI Table Index Entry Format.

Table 5-2. ACPI Table Index Entry Format
OffsetSizeDescription
0x0004 bytesACPI table signature
0x0044 bytesOffset of table in ACPI area

The boot loader should not include the RSDP, RSDT or XSDT in the ACPI table area - the index that the boot loader build makes these tables unnecessary. The boot loader's index must be in the same order as the entries in the ACPI area, so that it's easier for the Boot Abstraction Layer to check that the index doesn't describe entries that overlap or have other problems.

If the system has no ACPI tables this function should not be used. If this function returns BALERR_badData the Boot Abstraction Layer will free any pages in the ACPI Tables area.

Inputs:

Outputs:

5.15. 0x0000003C - Reserved for Set Native Boot Table

This function is currently reserved. See Subsection 3.4.15. Reserved For Native Boot Table for more information.

5.16. 0x00000040 - Set PCI Configuration Space Access Mechanism Hint

The Boot Abstraction Layer is responsible for detecting the PCI Configuration Space Access mechanism. This involves information from the boot loader, information from ACPI tables (if present) and information from manual probing (if necessary); plus testing to ensure it actually works.

The boot loader provides a hint that is intended to minimise the work that the Boot Abstraction Layer needs to do to determine the PCI configuration space access mechanism. Valid values for these hints are shown in Table 5-3. PCI Configuration Space Access Mechanism Hint Values.

Table 5-3. PCI Configuration Space Access Mechanism Hint Values
ValueMeaning
0x00Boot loader doesn't know if PCI exists or not (no hint)
0x01Boot loader knows that PCI does not exist
0x02Boot loader knows that PCI exist, but doesn't know which access mechanism it uses
0x03Boot loader knows that system uses PCI access mechanism #2
0x04Boot loader knows that system uses PCI access mechanism #1 but doesn't know if the memory mapped access mechanism is supported or not
0x05Boot loader knows that system uses PCI access mechanism #1 only (memory mapped access mechanism is not supported)
0x06Boot loader knows that system uses PCI access mechanism #1 and the memory mapped access mechanism

Inputs:

Outputs:

5.17. 0x00000041 - Set Memory Mapped PCI Configuration Space Access Area List

The Boot Abstraction Layer checks the boot loader's memory mapped PCI configuration space access area list and either accepts or rejects it.

Each entry in this list describes a memory mapped PCI configuration space access area and has the format shown in Table 3-8. Memory Mapped PCI Configuration Space Access Area List Entry Format.

The entries in this list must be in "Starting PCI bus number" order, to make it easier for the Boot Abstraction Layer to detect overlaps and other problems (e.g. same PCI bus covered by multiple areas).

If this function returns `BALERR_permissionDenied` the Boot Abstraction Layer will free any pages in the memory mapped PCI configuration space access area list. If this function succeeds the boot loader should not attempt to set a PCI configuration space access mechanism hint and the Boot Abstraction Layer will assume "system uses PCI access mechanism #1 and the memory mapped access mechanism".

Note: This function is primarily intended for "boot from ROM" boot loaders, where the information can be stored in the firmware and provided by the boot loader instead of providing ACPI tables. For normal boot loaders this function wouldn't be used (and the Boot Abstraction Layer would obtain the information from ACPI tables, if present).

Inputs:

Outputs:

5.18. 0x00000050 - Finalise Tables

The Boot Abstraction Layer processes various information provided by the Native Boot Table, MultiProcessor Specification Table, ACPI tables and/or Memory Mapped PCI Configuration Space Access Area List. The actions performed by the Boot Abstraction Layer are split into "stages", and performed in ascending order of "stage number". Each stage is detailed below.

To allow the boot loader to display more descriptive errors, if anything goes wrong the Boot Abstraction Layer returns a "stage number".

Inputs:

Outputs:

5.18.1. Stage 0x00000001, Memory Mapped PCI Configuration Space Access Area Check

For this stage the Boot Abstraction Layer checks that no part of any area described by the Memory Mapped PCI Configuration Space Access Area List is marked as "usable" in the Physical Address Space Map (see Subsection 5.18.9. PASM "Usable" Checking).

5.18.2. Stage 0x00000002, Local APIC Area Check

For this stage the Boot Abstraction Layer checks that no part of any area described as "used for local APIC" by the Native Boot Table, ACPI's APIC/MADT or the MultiProcessor Specification Table are marked as "usable" or "will become usable" in the Physical Address Space Map (see Subsection 5.18.9. PASM "Usable" Checking). The Boot Abstraction Layer must also set the "Local APIC base address" field in the Boot Information Page.

5.18.3. Stage 0x00000003, IO APIC Area Check

For this stage the Boot Abstraction Layer checks that no part of any area described as "used for IO APIC" by the Native Boot Table, ACPI's APIC/MADT or the MultiProcessor Specification Table are marked as "usable" or "will become usable" in the Physical Address Space Map (see Subsection 5.18.9. PASM "Usable" Checking).

5.18.4. Stage 0x00000004, HPET Area Check

For this stage the Boot Abstraction Layer checks that no part of any area described as "used for HPET" by the Native Boot Table or ACPI tables are marked as "usable" or "will become usable" in the Physical Address Space Map (see Subsection 5.18.9. PASM "Usable" Checking).

5.18.5. Stage 0x00000010, Initialise CPU Information Table

For this stage the Boot Abstraction Layer uses the Native Boot Table, ACPI's APIC/MADT or the MultiProcessor Specification Table (whichever works first) to initialise the CPU Information Table (see Subsection 3.4.17. CPU Information Table). This initialisation will be limited to the CPU's APIC ID, current state and NUMA domain (and excludes the reserved fields that aren't set until after Transition State 1 is completed). The Boot Abstraction Layer must also set the "number of entries in CPU Information Table" field and "number of CPUs currently online" field in the Boot Information Page.

5.18.6. Stage 0x00000011, Merge SRAT Information

For this stage the Boot Abstraction Layer checks if there is a Native Boot Table, and if there is no Native Boot Table it checks for an ACPI "SRAT" table and merges the NUMA information and hot-plug information from this table into the Physical Address Space Map and the CPU information table.

Note: if there is a Native Boot Table, NUMA information and hot-plug information is expected to be provided when the Physical Address Space Map and CPU Information Table are first created. This stage is purely a work-around for poorly designed firmware interface that scatter information in multiple places (e.g. some information in ACPI's "APIC/MADT" and some information in ACPI's "SRAT").

The Boot Abstraction Layer must also set the "highest NUMA domain" field in the Boot Information Page.

5.18.7. Stage 0x00000012, Initialise Locality Information

For this stage the Boot Abstraction Layer uses the Native Boot Table or ACPI's "SLIT" (whichever works first) to initialise Locality Information (see Subsection 3.4.19. Locality Information).

5.18.8. Stage 0x00000013, Configure "No NUMA"

For this stage the Boot Abstraction Layer checks the "Highest NUMA Domain" field in the Boot Information Page, and if this field is non-zero the Boot Abstraction Layer does nothing.

If the "Highest NUMA Domain" field is zero (either because nothing mentioned NUMA domain information or because everything that did mention a NUMA domain said "NUMA domain 0x00000000") then the Boot Abstraction Layer sets the NUMA domain fields in Physical Address Space Map entries and CPU Information Table entries to 0x00000000; and set the ""Locality Information Type" field to 0x11 ("Simple Absolute Information") and the Default Cross-Domain Latency field to zero in the Boot Information Page. This ensures that "no NUMA" systems can be treated as "one NUMA domain" systems.

5.18.9. PASM "Usable" Checking

Multiple stages involve checking that one or more areas are not marked as "usable" in the Physical Address Space Map; to ensure that area/s used for special hardware (e.g. Memory Mapped PCI Configuration Space Access, an IO APIC, a local APIC, HPET, etc) are not marked as "usable RAM" or "usable for memory mapped PCI devices".

Ideally the Boot Abstraction Layer would check if the area is marked as "area is usable" or "area will become usable after the transition is complete and boot loader is discarded" and return an error if there is a conflict.

Unfortunately the memory map information provided by firmware on some computers fails to report some areas as "reserved", which causes the Boot Abstraction Layer to think that areas are usable for memory mapped PCI devices when they are not. To work around this problem, if an area that is used for special hardware is marked as "usable, not RAM" (usable for memory mapped PCI devices) in the Physical Address Space Map then the Boot Abstraction Layer may add a warning to the event log (to describe the problem) and force that area to be marked as "not usable" in the Physical Address Space Map.

5.19. 0x00000080 - Add Head

Each video adapter has one or more "heads". Each head is an independent video output (e.g. hopefully attached to a seperate monitor). The boot loader calls this function none or more times (once for each head it's capable of configuring). If EDID is requested by the Boot Abstraction Layer, the boot loader must attempt to satisfy that request (see Section 5.20. 0x00000081 - Set EDID By Shorthand and Section 5.21. 0x00000082 - Set Full EDID) before adding any video modes to the head. If EDID is not requested by the Boot Abstraction Layer, the boot loader must not attempt to provide EDID information and only needs to add any video modes to the head.

Note: If a boot loader knows that a head exists and thinks that it will be able to obtain video modes for the head it will add the head; however (after adding the head) it might not be able to find any suitable video modes for it and might not add any video modes. This is the only case where boot loader is allowed to add a head without adding video modes to it.

Inputs:

Outputs:

5.20. 0x00000081 - Set EDID By Shorthand

If the Boot Abstraction Layer requested EDID (see Section 5.19. 0x00000080 - Add Head) the boot loader must use this function. The Boot Abstraction Layer uses the Manufacturer, product code and date code to find a file (in the boot image) containing EDID information. If no file exists, the Boot Abstraction Layer requests full EDID information and the boot loader must use Section 5.21. 0x00000082 - Set Full EDID to satisfy that additional request.

If the boot loader is unable to obtain any EDID information it sets EBX to 0xFFFFFFFF. In this case the Boot Abstraction Layer considers the EDID request satisfied.

Inputs:

(taken directly from the 4 bytes at offset 0x008 in the first block of EDID, but where the lowest 2 bytes are switched). 0xFFFFFFFF if no EDID can be obtained.

Outputs:

5.21. 0x00000082 - Set Full EDID

If the Boot Abstraction Layer requested full EDID (see Section 5.20. 0x00000081 - Set EDID By Shorthand) the boot loader must use this function. The Boot Abstraction Layer uses the provided raw EDID information to generate a DID file (see BCOS Display Identification Data File Format Specification) and inserts that DID file into the boot image, and uses the DID information for the current head (instead of using the shortcut or boot variables to determine which DID file to use).

If the boot loader is unable to obtain any EDID information it may set ECX to zero; and in this case the Boot Abstraction Layer considers the request for full EDID satisfied. However; this should never happen in practice as the boot loader must have already got one block of EDID before the request for full EDID was made.

Inputs:

Outputs:

5.22. 0x00000088 - Add Video Mode

This function is used by the boot loader none or more times for each head, to tell the Boot Abstraction Layer about each video mode that it is able to setup for the most recently added head. The format for the video mode descriptor is the same as the format for the video mode entry described in Subsubsection 3.4.20.1. Video Mode Entries.

Inputs:

Outputs:

5.23. 0x0000008E - Prepare Video Mode

Once all video modes have been added to a head; the boot loader uses this function to allow the Boot Abstraction Layer to prepare to take control of the head (via. a raw framebuffer). The Boot Abstraction Layer must:

After this function returns the boot loader must attempt to set the video mode selected by the Boot Abstraction Layer and then inform the Boot Abstraction Layer if it succeeded or not (see Section 5.24. 0x0000008F - Video Mode Status).

Inputs:

Outputs:

If the Boot Abstraction Layer returns BALERR_notFound, then the boot loader assumes that this video head is finished and moves on to the next video head (if any). If the boot module returns BALERR_notFound for any reason, the Boot Abstraction Layer returns BALERR_unknown instead (to ensure that BALERR_notFound always means its safe for boot loader to retry).

If the Boot Abstraction Layer returns any other error (not BALERR_notFound) then boot loader should abort boot.

5.24. 0x0000008F - Video Mode Status

The function is used by the boot loader to tell the Boot Abstraction Layer that the video mode it has prepared for has been set, or couldn't be set. If the video mode has been set, the Boot Abstraction Layer informs the "boot video interface" module for handling the current head that it is now active (and that "boot video interface" module is responsible for displaying the event log, etc. for the head from this point on). In this case the boot loader assumes that this video head is finished and moves on to the next video head (if any).

If the video mode could not be set, the Boot Abstraction Layer terminates the "boot video interface" module that was prepared, marks the chosen video mode as "unusable" in the list of video modes for the head, then waits for the boot loader to prepare another video mode (using Section 5.23. 0x0000008E - Prepare Video Mode).

Inputs:

Outputs:

5.25. 0x00000090 - Flush Event Log

If the boot loader adds any information to the event log after one or more "boot video interface" modules have successfully taken control of a video adapter's head it must use this function so that the Boot Abstraction Layer can inform any/all "boot video interface" modules to update their display. This function can be used by the boot loader at any time - if no "boot video interface" modules have successfully taken control of a video adapter's head then the Boot Abstraction Layer will do nothing.

Inputs:

Outputs:

Generated at 02:22:03 on the 21st of June, 2017 (UTC)