BCOS Boot Catalogue Specification

BCOS Boot Catalogue Specification
Version 1.0
(Preliminary Draft)

Offset

Size

Description

0x00000000

32 bytes

As defined in the BCOS Native File Format Specification

0x00000020

8 bytes

Address of the first entry in the Boot Catalogue (see Section 2.4: Addresses).

0x00000028

4 bytes

Number of entries in the Boot Catalogue

0x0000002C

4 bytes

Platform ID (see Section 2.2: Platform ID)

Table 2.1 - Boot Catalogue Header

Note that the native file format header's "checksum" field is typically not used by boot code, and may be set to zero by any code that changes the Boot Catalogue to avoid calculating the CRC. However, code should not assume that previous pieces of code didn't set a correct CRC/checksum, and therefore code that modifies the Boot Catalogue must either make sure the checksum field is set to zero or update the CRC/checksum.

2.2 Platform ID

The platform ID is used to determine the format for Boot Catalogue Entries. The platform ID is a 4 character string (without a zero terminator).

Defined platform IDs are listed in Table 2.2: Platform IDs, including a reference to the section within this document that describes Boot Catalogue Entries for each platform ID.

Platform ID Section Platform Description

"8632"

Chapter 3: 80x86 Boot Catalogue Entry Reference

All 80x86 systems (including 64-bit 80x86 systems)

Table 2.2 - Platform IDs

2.3 Boot Catalogue Entries

The Boot Catalogue consists of a variable number of entries. Each entry begins with the header described in Table 2.3: Boot Catalogue Entry Header #1.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type

Table 2.3 - Boot Catalogue Entry Header #1

Some entry types contain the location (address) and size of a larger piece of data. All entry types that have the highest bit set (entry types 0x80000000 to 0xFFFFFFF) point to a larger piece of data and begin with a the header described in Table 2.4: Boot Catalogue Entry Header #2.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type

0x00000008

8 bytes

Address of the entry's data (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the entry's data in pages (e.g. 0x00000010 means 16 pages, or 64 KiB).

Table 2.4 - Boot Catalogue Entry Header #2

This allows code to work with the Boot Calalogue and any data referenced by Boot Catalogue Entries without understanding anything about the contents of each Boot Catalogue Entry.

2.4   Addresses

For the purpose of the Boot Catalogue, the term "address" has multiple meanings. It may be 64-bit or 32-bit (a 64-bit address where the upper 32-bits are known to be clear), it may be a physical address or a linear address, and it may be an offset from the beginning of the file.

Typically during early boot all addresses in the Boot Catalogue are 32-bit physical addresses, until the OS's Boot Manager is started. The Boot Manager determines if the kernel being booted uses 64-bit code (long mode) or not, and initializes 32-bit paging or 64-bit paging. When the Boot Manager does initialize paging it converts the 32-bit physical addresses in the Boot Catalogue into 32-bit linear addresses or 64-bit linear addresses. In all of these cases addresses may point to data placed anywhere in the address space.

If the Boot Catalogue is being stored as a file, then addresses are offsets from the beginning of the file. This means that the resulting file would contain the Boot Catalogue header, then the Boot Entries, then any data referenced by "addresses" within the Boot Entries.

3   80x86 Boot Catalogue Entry Reference

The following sections describe all defined Boot Catalogue Entries. Later versions of this specification may define new entries. If a piece of code doesn't recognise a boot entry it can use the Boot Catalogue Entry Header to skip the entry.

3.1   Type 0x00000001 - Boot Loader Identification Entry

This Boot Catalogue Entry is used to identify the type of boot loader that was used.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x00000001)

0x00000008

2 bytes

Boot loader type (see Table 3.2: Boot Loader Types)

0x0000000A

2 bytes

Reserved

Table 3.1 - Boot Loader Identification Entry Format (Type 0x00000001)

Value

Meaning

0x0000

Unknown

0x0100

Fast restart

0x0200

ROM Boot Loader

0x0300

PC BIOS Floppy Boot Loader

0x0301

PC BIOS PXE Boot Loader

0x0302

PC BIOS GRUB Boot Loader

0x0303

PC BIOS Partition Boot Loader

0x0304

PC BIOS CD-ROM Boot Loader

0x0400

EFI Boot Loader

Table 3.2 - Boot Loader Types

3.2 Type 0x00000003 - Trusted Area Entry

This Boot Catalogue Entry is used to let the operating system know details for an area of RAM that must work correctly for the computer to boot reliably. There may be none or more of these entries in a Boot Catalogue.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x00000003)

0x00000008

4 bytes

32-bit physical address of trusted area

0x0000000C

4 bytes

Size of trusted area in bytes

Table 3.3 - Trusted Area Entry Format (Type 0x00000003)

3.3 Type 0x00000020 - Selected Video Mode Entry

This Boot Catalogue Entry is used to let the operating system know details for the currently selected video mode, so that it can use the current video mode (via. a generic "framebuffer" video driver) if a video driver can't be found for the specific video controller. The Boot Loader must not attempt to select a video mode that is not listed in the Default Video Mode List, and must not attempt to select a video mode that has a reliability category of zero.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x00000020)

0x00000008

4 bytes

Video Mode Descriptor number

0x0000000C

1 byte

Pixel Format (see Subsection 3.15.3: Pixel Formats)

0x0000000D

3 byte

Reserved

0x00000010

4 bytes

Horizontal resolution

0x00000014

4 bytes

Vertical resolution

0x00000018

4 bytes

Address of video display memory

0x0000001C

4 bytes

Number of bytes between scan lines

Table 3.4 - Selected Video Mode Entry (Type 0x00000020)

The Video Mode Descriptor number corresponds to the Video Mode Descriptor in the Default Video Mode List (0 = first entry, 1 = second entry, etc). The information for the horizontal and vertical resolution must be identical to the same information in the Video Mode Descriptor.

Note: For video modes that use the the 4 bits per pixel format, the "Number of bytes between scan lines" field must contain the number of bytes between scan lines for one plane. For example, for the standard VGA "640 * 480, 4 BPP" video mode the "Number of bytes between scan lines" field would contain the value 80, representing 80 bytes between one scan line (of 8 bits/pixels per byte) to the next scan line in the same plane.

3.4 Type 0x00000030 - Motherboard Identification

This Boot Catalogue Entry is used to let the operating system know which motherboard is being used.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x00000030)

0x00000008

4 bytes

Offset from start of entry for ASCII manufacturer name string (0 if none)

0x0000000C

4 bytes

Offset from start of entry for ASCII product name string (0 if none)

0x00000010

4 bytes

Offset from start of entry for ASCII version string (0 if none)

0x00000014

4 bytes

Reserved

0x00000018

Varies

String data

Table 3.5 - Selected Video Mode Entry (Type 0x00000030)

3.5 Type 0x00000034 - PCI Hardware Characteristics

This Boot Catalogue Entry is used to let the operating system know how to access PCI configuration space.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x00000031)

0x00000008

4 bytes

PCI flags (see Table 3.7: PCI Flags)

Table 3.6 - Selected Video Mode Entry (Type 0x00000034)

Bit/s

Meaning

Set if Config Mechanism #1 is supported

Set if Config Mechanism #2 is supported

2 to 3

Reserved

Set if special cycle is supported by Config Mechanism #1

Set if special cycle is supported by Config Mechanism #2

6 to 31

Reserved

Table 3.7 - PCI Flags

3.6 Type 0x00000038 - Virtual Machine Type

This Boot Catalogue Entry is used to let the operating system know which virtual machine is being used.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x00000038)

0x00000008

4 bytes

Virtual Machine Type Code (see Table 3.9: Virtual Machine Type Codes)

0x0000000C

4 bytes

Product ID (meaning depends on virtual machine type)

0x00000010

4 bytes

Version ID (meaning depends on virtual machine type)

Table 3.8 - Selected Video Mode Entry (Type 0x00000038)

Code

Description

Product ID

Version ID

'Bchs'

Bochs

0x00000000

'HprV'

Hyper-V

0x00000000

High 16-bits = major version, low 16-bits = minor version

'LKVM'

Linux Kernel Virtual Machine

0x00000000

'Qemu'

Qemu

0x00000000

'VBox'

VirtualBox

0x00000000

'VMwr'

VMware

0x00000000 = unknown

0x00000000

0x00000001 = Express

0x00000000

0x00000002 = ESX

0x00000000

0x00000003 = GSX

0x00000000

0x00000004 = Workstation

0x00000000

'VrPC'

Virtual PC

0x00000000

'Xen-'

Xen

0x00000000

High 16-bits = major version, low 16-bits = minor version

Table 3.9 - Virtual Machine Type Codes

3.7 Type 0x80000001 - Faulty RAM List Entry

This Boot Catalogue Entry refers to the Faulty RAM List Entry that was loaded into RAM by the Boot Loader. There must be one Faulty RAM List Entry in any Boot Catalogue.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000001)

0x00000008

8 bytes

Address of the Faulty RAM List (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the Faulty RAM List in pages

Table 3.10 - Faulty RAM List Entry Format (Type 0x80000001)

The format used for a Faulty RAM List file is described in the BCOS Faulty RAM List File Format Specification.

3.8 Type 0x80000002 - Physical Address Space Map Entry

This Boot Catalogue Entry refers to the Physical Address Space Map that was generated from information from the hardware or firmware by the Boot Loader. There must be one Physical Address Space Map Entry in any Boot Catalogue.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000002)

0x00000008

8 bytes

Address of the Physical Address Space Map (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the Physical Address Space Map in pages

0x00000014

4 bytes

Number of entries in the Physical Address Space Map

0x00000018

1 byte

Physical Address Space Map detection method

0x00000019

1 byte

Reserved

0x0000001A

1 byte

A20 Gate Status

0x0000001B

1 byte

A20 Gate Change Method

Table 3.11 - Physical Address Space Map Entry Format (Type 0x80000002)

The contents of the A20 Gate Status and A20 Gate Change Method fields are defined in the A20 Gate Status include file.

The Physical Address Space Map itself consists of a number of entries. The format for entries in the Physical Address Space Map is defined in the Physical Address Space Map (PASM) include file.

3.9 Type 0x80000003 - Faulty Page Bitmap Entry

This Boot Catalogue Entry refers to the Faulty Page Bitmap that was created from the Faulty RAM List by the Boot Loader. There must be one Faulty Page Bitmap Entry in any Boot Catalogue.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000003)

0x00000008

8 bytes

Address of the Faulty Page Bitmap (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the Faulty Page Bitmap in pages

0x00000014

4 bytes

Faulty Page Bitmap Flags (see Table 3.13: Faulty Page Bitmap Flags)

Table 3.12 - Faulty Page Bitmap Entry Format (Type 0x80000003)

Bit/s

Description

Set if the Faulty Page Bitmap was modified, clear if the Faulty Page Bitmap is unchanged

Set if code used during boot doesn't tests pages before use, clear if code used during boot tests pages before use

1 to 31

Reserved (clear)

Table 3.13 - Faulty Page Bitmap Flags

The Faulty Page Bitmap is an array of bits, where each bit represents a page of physical RAM below 0x0000000100000000. The bit corresponding to a physical page is set to indicate that the page is faulty, and clear to indicate that the page is not faulty. When the Faulty Page Bitmap is created it is made large enough to cover all pages of RAM below 0x0000000100000000 and then rounded up to the nearest page. For example, if the highest area of RAM ends at 0x01FFFFFF, then the Faulty RAM Bitmap would need to contain 8192 bits (or 1024 bytes), so the actual size of the Faulty RAM Bitmap would be rounded up to 32768 bits (4096 bytes).

Bit 0 in the Faulty Page Bitmap Flags (see Table 3.13: Faulty Page Bitmap Flags) is used to indicate if the Faulty Page Bitmap was modified (e.g. new faulty pages have been found). The operating system uses this flag to determine if the Faulty RAM List is obsolete (e.g. if the Faulty RAM List on the boot device needs to be replaced by a new Faulty RAM List generated from the Faulty Page Bitmap).

Bit 1 in the Faulty Page Bitmap Flags (see Table 3.13: Faulty Page Bitmap Flags) is used as a quick way to determine if all faulty RAM testing is disabled in the Faulty RAM List. If all faulty RAM testing (the simple boot RAM test, the scheduled boot RAM test and the run-time RAM testing) is disabled in the Faulty RAM List then this bit is set to indicate that boot code can skip testing pages during boot. If any form of faulty RAM testing is enabled in the Faulty RAM List then this bit must remain clear and boot code must test pages before using them.

The size of the Faulty Page Bitmap must be equal to the size of the Free Page Bitmap.

3.10 Type 0x80000004 - Free Page Bitmap Entry

This Boot Catalogue Entry refers to the Free Page Bitmap that was originally created from the Physical Address Space Map and the Faulty Page Bitmap by the Boot Loader. There must be one Free Page Bitmap Entry in any Boot Catalogue.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000004)

0x00000008

8 bytes

Address of the Free Page Bitmap (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the Free Page Bitmap in pages

0x00000014

4 bytes

Total number of free pages

0x00000018

4 bytes

Total number of allocated pages

0x0000001C

4 bytes

Total number of faulty pages

0x00000020

4 bytes

Total number of non-RAM pages

Table 3.14 - Free Page Bitmap Entry Format (Type 0x80000004)

The Free Page Bitmap is an array of bits, where each bit represents a page of physical RAM below 0x0000000100000000. The bit corresponding to a physical page is set to indicate that the page is free (can be allocated), and clear to indicate that the page is not free. When the Free Page Bitmap is created it is made large enough to cover all pages of RAM below 0x0000000100000000 and then rounded up to the nearest page. For example, if the highest area of RAM ends at 0x01FFFFFF, then the Faulty RAM Bitmap would need to contain 8192 bits (or 1024 bytes), so the actual size of the Faulty RAM Bitmap would be rounded up to 32768 bits (4096 bytes).

The "Total number of faulty pages" field only includes pages that would have been usable RAM if the corresponding bit in the Faulty RAM Bitmap was clear. The "Total number of non-RAM pages" includes RAM that is reserved by firmware.

The sum of all free, allocated, faulty and non-RAM pages must equal the number of pages covered by the Free Page Bitmap, which can be found with "(Size of the Free Page Bitmap in pages) << (12 + 3)". If these values aren't equal, then there's been errors in code that accounts for page usage.

The size of the Free Page Bitmap must be equal to the size of the Faulty Page Bitmap.

3.11 Type 0x80000005 - Boot Script Entry

This Boot Catalogue Entry refers to the Boot Script that was loaded into RAM by the Boot Loader. There must be one Boot Script Entry in any Boot Catalogue.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000005)

0x00000008

8 bytes

Address of the Boot Script (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the Boot Script in pages

Table 3.15 - Boot Script Entry Format (Type 0x80000005)

The Boot Script is a plain text file (which conforms to the BCOS Plain Text File Format Specification) mainly consisting of "<variable_name> = <variable_value>" lines. For a complete description of the content of this file, please see documentation for BCOS Boot Scripts in the user's manual.

3.12 Type 0x80000006 - Boot Image Entry

This Boot Catalogue Entry refers to the Boot Image that was loaded into RAM by the Boot Loader. There must be one Boot Image Entry in any Boot Catalogue.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000006)

0x00000008

8 bytes

Address of the Boot Image (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the Boot Image in pages

Table 3.16 - Boot Image Entry Format (Type 0x80000006)

The format used for a Faulty RAM List file is described in the BCOS Boot Image File Format Specification.

3.13 Type 0x80000007 - Boot Log Entry

This Boot Catalogue Entry refers to the Boot Log. The Boot Log is created very early during boot, and new data is continually appended to it by different pieces of code until the OS has completed booting. After the OS has completed booting the operating system may continue using this log (e.g. as a System Log) or save it to disk as a plain text file.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000007)

0x00000008

8 bytes

Address of the Boot Log (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the Boot Log in pages

0x00000014

4 bytes

Size of the Boot Log in bytes

Table 3.17 - Boot Log Entry Format (Type 0x80000007)

The Boot Log is just a long string of UTF8 characters. Some characters within the boot log have special meaning - see the Boot Log/System Log include file for details.

The Boot Log is not "zero terminated" (the last byte is not zero to mark the end of the log). Instead the end of the log is found using the "Size of the Boot Log in bytes" field. Also note that if new data is being appended to the end of the Boot Log, code needs to check if more pages will be needed and allocate a larger area for the Boot Log before appending the data.

3.14 Type 0x80000020 - Primary Monitor EDID Entry

This Boot Catalogue Entry refers to the EDID data from the primary monitor. The EDID data itself is the raw data from the monitor, in one or more 128-byte blocks.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000020)

0x00000008

8 bytes

Address of the EDID data (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the EDID data in pages

0x00000014

4 bytes

Number of 128-byte blocks of EDID data present

Table 3.18 - Primary Monitor EDID Entry Format (Type 0x80000020)

Note: The "number of extended blocks" field at offset 0x7E in the first block (actually labelled as "Extension Flag" in the VESA specifications) should never be used. The "number of extended blocks" field at offset 0x7E in the first block should be one less than the "Number of 128-byte blocks of EDID data present" field in the Boot Catalogue entry. However in some cases (e.g. where one or more extended blocks fail the checksum) all of the extended blocks may have been discarded. In this case the "Number of 128-byte blocks of EDID data present" field in the Boot Catalogue entry will be set to one (so that the first block of EDID data can be used on it's own as a fallback) and the "number of extended blocks" field at offset 0x7E in the first block will remain unchanged.

3.15 Type 0x80000021 - Default Video Mode List Entry

This Boot Catalogue Entry refers to the Default Video Mode List for the primary video controller and the primary monitor. The Default Video Mode List itself consists of a list of Video Mode Descriptors (see Table 3.20: Video Mode Descriptor Format), where each descriptor in the list describes a video mode that is supported by the primary video controller.

The Default Video Mode List is intended to allow the operating system to choose a different default video mode which will be selected as the current video mode next time the operating system boots. If the generic "framebuffer" video driver is being used then selecting a video mode from this list and rebooting the operating system is the only way to change video modes. If a video driver for the specific video controller is being used then the Default Video Mode List can be used to select a video mode during boot that is the same or similar to a video mode that's often used after boot, to minimize the effects of video mode switching when the video driver is started.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000021)

0x00000008

8 bytes

Address of the Default Video Mode List (see Section 2.4: Addresses)

0x00000010

4 bytes

Size of the Default Video Mode List in pages

0x00000014

4 bytes

Number of descriptors in the Default Video Mode List

Table 3.19 - Default Video Mode List Entry Format (Type 0x80000021)

Offset

Size

Description

0x00000000

2 bytes

Mode attributes (see Subsection 3.15.1: Mode Attributes)

0x00000002

1 byte

Pixel format (see Subsection 3.15.3: Pixel Formats)

0x00000003

1 byte

Reliability category (see Subsection 3.15.4: Reliability Category)

0x00000004

4 bytes

Horizontal resolution

0x00000008

4 bytes

Vertical resolution

0x0000000C

4 bytes

Vertical field rate * 65536 (0 if unknown)

0x00000010

4 bytes

Pixel clock frequency (0 if unknown)

0x00000014

12 bytes

Reserved for boot code use

Table 3.20 - Video Mode Descriptor Format

3.15.1 Mode Attributes

The Mode Attributes field in the Video Mode Descriptor is a set of flags used to define the type of video mode. For a description of each flag see Table 3.21: Mode Attribute Flags.

Bit

Meaning if set

Interlaced video mode

Double scanned video mode

Video mode uses fixed timings

Video mode uses default GTF

Video mode uses secondary GTF

Video mode uses CVT (without reduced blanking)

Video mode uses CVT with reduced blanking

7 to 15

Unused/reserved

Table 3.21 - Mode Attribute Flags

3.15.2 Video Mode Restrictions

Boot code must also ensure that all pixel data can be accessed and that the horizontal resolution is acceptable for the pixel format. See Paragraph 3.15.3.1: 4 Bits Per Pixel,Paragraph 3.15.3.2: 8 Bits Per Pixel, Paragraph 3.15.3.3: 15 Bits Per Pixel, Paragraph 3.15.3.4: 16 Bits Per Pixel, Paragraph 3.15.3.5: 24 Bits Per Pixel and Paragraph 3.15.3.6: 32 Bits Per Pixel for information on these restrictions. In addition, regardless of pixel format the horizontal resolution must not be smaller than 320 pixels and the vertical resolution must not be smaller than 200 pixels (e.g. "320 * 200, 4 bits per pixel" is the least detailed video mode possible).

The video display memory must be treated as "write only" by all code that uses the selected video mode.

3.15.3 Pixel Formats

The Pixel Format field in the Video Mode Descriptor determines the colour depth of the video mode, the arrangement of pixel data in display memory, the memory model used for accessing display memory, the horizontal resolution restrictions and the restrictions on display memory access. For the values associated with with each supported pixel format and see Table 3.22: Pixel Formats.

Value

Description

0x00

4 bits per pixel (see Paragraph 3.15.3.1: 4 Bits Per Pixel)

0x01

8 bits per pixel (see Paragraph 3.15.3.2: 8 Bits Per Pixel)

0x02

15 bits per pixel (see Paragraph 3.15.3.3: 15 Bits Per Pixel)

0x03

16 bits per pixel (see Paragraph 3.15.3.4: 16 Bits Per Pixel)

0x04

24 bits per pixel (see Paragraph 3.15.3.5: 24 Bits Per Pixel)

0x05

32 bits per pixel (see Paragraph 3.15.3.6: 32 Bits Per Pixel)

0x06 to 0xFF

Unused/reserved

Table 3.22 - Pixel Formats

3.15.3.1   4 Bits Per Pixel

For the 4 bits per pixel format, video display memory is arranged in 4 separate planes (in order: one plane for blue, one for green, one for red and one for intensity), where each individual pixel is represented by one bit in each plane. A write to display memory must set all bits at the target address in the currently selected plane (e.g. if the "blue" plane is selected then writing 0xFFFFFFFF would effect 32 separate pixels). It must be possible for video code to change the currently selected plane by writing to I/O port 0x03C5 (where writing 0x01 selects the "blue" bit plane, 0x02 selects the "green" bit plane, etc).

For standard VGA, the code that sets the video mode is responsible for making sure that Write Mode 0 is selected (lowest 2 bits in the Mode Register at index 0x05 in the Graphics Controller), that the Bit Mask Register is set to 0xFF (index 0x08 in the Graphics Controller), and that the Graphics Controller Address Register is left set to index 0x08 (so that writes to I/O port 0x03C5 go to the Set/Reset Register without the need to check or set the index). It's unlikely that this pixel format will be usable if the video mode is not VGA compatible.

The horizontal resolution must be a multiple of 32, to allow a 32-bit write to effect (one bit in each of) 32 adjacent pixels. All bits in one plane must be accessible without bank switching or other techniques.

3.15.3.2   8 Bits Per Pixel

For the 8 bits per pixel format, each byte of display memory corresponds to a pixel, and adjacent bytes in display memory correspond to adjacent pixels.

If necessary, the code that sets the video mode is responsible for setting a suitable pallette, so that each pixel is in the "3R:3G:2B" format (where the colour 0xE0 is red, 0x1C is green and 0x03 is blue).

The horizontal resolution must be a multiple of 8, to allow a 64-bit write to effect 8 adjacent pixels. All pixels must be accessible without bank switching or other techniques.

3.15.3.3   15 Bits Per Pixel

For the 15 bits per pixel format, each word of display memory corresponds to a pixel, and adjacent words in display memory correspond to adjacent pixels.

Each pixel must be in the "0:5R:5G:5B" format (where the colour 0x7C00 is red, 0x03E0 is green and 0x001F is blue), where the highest bit is always clear.

The horizontal resolution must be a multiple of 4, to allow a 64-bit write to effect 4 adjacent pixels. All pixels must be accessible without bank switching or other techniques.

3.15.3.4   16 Bits Per Pixel

For the 16 bits per pixel format, each word of display memory corresponds to a pixel, and adjacent words in display memory correspond to adjacent pixels.

Each pixel must be in the "5R:6G:5B" format (where the colour 0xF800 is red, 0x07E0 is green and 0x001F is blue).

The horizontal resolution must be a multiple of 4, to allow a 64-bit write to effect 4 adjacent pixels. All pixels must be accessible without bank switching or other techniques.

3.15.3.5   24 Bits Per Pixel

For the 24 bits per pixel format, each group of 3 bytes of display memory corresponds to a pixel, and adjacent groups of 3 bytes in display memory correspond to adjacent pixels.

Each pixel must be in the "8R:8G:8B" format (where the colour 0xFF0000 is red, 0x00FF00 is green and 0x0000FF is blue).

The horizontal resolution must be a multiple of 4, to allow a 96-bit write (either 3 dwords or a dword and a qword) to effect 4 adjacent pixels. All pixels must be accessible without bank switching or other techniques.

3.15.3.6   32 Bits Per Pixel

For the 32 bits per pixel format, each dword of display memory corresponds to a pixel, and adjacent dwords in display memory correspond to adjacent pixels.

Each pixel must be in the "0:8R:8G:8B" format (where the colour 0x00FF0000 is red, 0x0000FF00 is green and 0x000000FF is blue), where the highest 8-bits are always clear.

The horizontal resolution must be a multiple of 2, to allow a 64-bit write to effect 2 adjacent pixels. All pixels must be accessible without bank switching or other techniques.

3.15.4   Reliability Category

The Default Video Mode List is used by the Boot Loader to select a suitable default video mode to be used later during boot and potentially while the OS is running. Because of this it is important that the selected video mode works reliably with the current monitor (if it doesn't work, then there may be no usable video at all). Unfortunately in some likely situations the Boot Loader may not have enough information to determine if a video mode will work or not, even with full EDID parsing. In these situations it's useful to allow the Boot Loader to estimate how likely it is that a video will work correctly with the current monitor.

Each video mode is given a reliability category. This is intended to allow code to make more intelligence choices when selecting a default video mode (for example, only allowing "low risk" video modes, with preference given to the lowest risk video modes).

Value

Description

0x00

Video mode will not work with the current monitor

0x01 to 0x7F

Video mode probably won't work with the current monitor

0x80 to 0xFE

Video mode probably will work with the current monitor

0xFF

Video mode is guaranteed to work with the current monitor

Table 3.23 - Reliability Categories

Where possible the reliability category is derived from EDID information. Note: If VESA BIOS Extensions are being used then boot code must not assume that the monitor supports any video mode that is listed as supported by VBE. Video card ROM's do not limit the list of available modes according to what the monitor supports, and therefore boot code must do this itself (if possible).

3.16 Type 0x80000022 - Boot Script Workspace Entry

This Boot Catalogue Entry refers to the Boot Script Workspace. The Boot Script Workspace is created during boot by parsing the Boot Script.

During boot different pieces of code may create new boot variables, modify the values stored in existing boot variables and remove boot variables. After boot, if the Boot Script Workspace was changed (either by the boot code or later by an administrator/user) the OS uses the Boot Script Workspace to create a new Boot Script and installs it.

In addition, the Boot Script Workspace is used to speed up common operations done on boot variables (e.g. using a variable's name to search for a variable's value).

Note: The Boot Script is only meant to contain a small number of boot variables (typically none), and is not meant to be used as an alternative to auto-detection. Because the Boot Script is meant to be small there is no real need for using hash tables or binary searches to improve performance.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000022)

0x00000008

8 bytes

Address of the Boot Script Workspace (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the Boot Script Workspace in pages

0x00000014

4 bytes

Size of the Boot Script Workspace in bytes

0x00000018

4 bytes

Number of boot variables

0x0000001C

4 bytes

Flags (see Table 3.25: Boot Script Flags)

Table 3.24 - Boot Script Workspace Entry Format (Type 0x80000022)

Note: The size of the Boot Script Workspace may be zero. In this case the Address of the Boot Script Workspace field must not be relied on.

Bit/s

Description

Set if boot variables changed, clear if original Boot Script still current

1 to 31

Unused/reserved

Table 3.25 - Boot Script Flags

3.16.1 Boot Script Workspace Format

The Boot Script Workspace itself consists of a variable number of variable length Boot Variable Entries, where each entry begins with a header (described in Table 3.26: Boot Variable Entry Header.

Offset

Size

Description

0x00000000

2 bytes

Size of entry in bytes

0x00000002

2 bytes

Boot Variable Entry key (see Paragraph 3.16.1.1: Boot Variable Entry Keys)

0x00000004

2 bytes

Length of boot variable name string, including zero terminator

0x00000006

Varies

Boot variable name string (excluding initial type character)

Varies

Boot variable data (see Paragraph 3.16.1.2: Boot Variable Data Formats)

Table 3.26 - Boot Variable Entry Header

3.16.1.1 Boot Variable Entry Keys

The Boot Variable Entry Key is used for 3 different purposes:

•	to store a quick hash of the boot variable's name
•	to store the boot variable's type
•	to store the flags for the boot variable

The format of a Boot Variable Entry Key is described in Table 3.27: Boot Variable Entry Key Format.

Bit/s

Description

Set if this boot variable has been accessed or modified, clear if this boot variable hasn't been used

Set if this boot variable has been modified, clear if this boot variable is the same as it was in the original Boot Script

2 to 4

Boot variable type: 00b = boolean, 01b = string, 10b = file name, 11b = integer

5 to 15

10-bit sum of each character in boot variable name (excluding initial type character)

Table 3.27 - Boot Variable Entry Key Format

3.16.1.2 Boot Variable Data Formats

Depending on the boot variable type (stored in the Boot Variable Entry Key), the format of the boot variable data is different.

Key

Size

Data format

00b

1 byte

Boolean State Byte (see Table 3.29: Boolean State Byte Format)

01b

Varies

Zero terminated UTF-8 string

10b

Varies

Zero terminated UTF-8 file name string (see BCOS Native File System Attributes Application Note, Chapter 5: File and Directory Names)

11b

8 bytes

64-bit unsigned integer

Table 3.28 - Boot Variable Data Format

Bit/s

Description

0 to 1

Format hint: 00b = use '0' or '1', 01b = use "no" or "yes", 10b = use "false" or "true", 11b = use "disabled" or "enabled"

2 to 6

Unused/reserved

State of boolean value (set means 1/yes/true/enabled, clear means 0/no/false/disabled)

Table 3.29 - Boolean State Byte Format

The format hint in a Boolean State Byte is intended to make boolean variables easier to read by humans. For example, a boolean variable that controls whether EDID information is obtained during boot could be expressed as "%disableEDID = yes" or "%EDIDusage = disabled" rather than just "%disableEDID = 1" or "%EDIDusage = 0".

3.17 Type 0x80000030 - ACPI Data Entry

This Boot Catalogue Entry refers to the ACPI Data. The ACPI Data is provided by firmware, and each table is copied one after the other into the Boot Catalogue's ACPI Data (without the RSDP, the RSDT or the XSDT).

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000030)

0x00000008

8 bytes

Address of the ACPI Data (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the ACPI Data in pages

0x00000014

4 bytes

Number of ACPI tables in the ACPI Data

Table 3.30 - ACPI Data Entry Format (Type 0x80000030)

3.18 Type 0x80000031 - MP Specification Data Entry

This Boot Catalogue Entry refers to the MP Specification Data. The MP Specification Data is provided by firmware, and each structure is copied one after the other into the Boot Catalogue's MP Specification Data (without any "MP Configuration Table Header" structure). To make it faster to search for a structure of a specific type, each structure is preceded by an extra 32-bit length field that can be used to determine the size of structure and used to find the next structure. The actual MP Specification structure starts after the extra 32-bit length field.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000031)

0x00000008

8 bytes

Address of the MP Specification Data (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the MP Specification Data in pages

0x00000014

4 bytes

Number of MP Specification structures in the MP Specification Data

0x00000018

4 bytes

Feature flags (MP Specification feature bytes 2 to 5)

0x0000001C

1 byte

MP Specification minor version (e.g. 0x04 for "version 1.4")

0x0000001D

1 byte

MP Specification major version (e.g. 0x01 for "version 1.4")

0x0000001E

2 bytes

Reserved

0x00000020

4 bytes

Address of local APICs

Table 3.31 - MP Specification Data Entry Format (Type 0x80000031)

The MP Specification Data Entry (intentionally) does not support "default configurations". To simplifiy things for later code; boot code that is responsible for contructing the MP Specification Data Entry in the Boot Catalogue is expected to supply the full MP Specification Data when the firmware's MP Floating Pointer Structure contains a default configuration.

WARNING: Software must not rely on the "CPU signature" or "CPU features" fields in the MP Specification Processor Entry - a few well known emulators get it wrong, and it's much better to get this information directly from the CPU (if possible) instead. For these reasons, if the firmware uses a "default configuration" then is boot code may set these fields to zero (rather than attempting to detect this information from the CPU).

3.19 Type 0x80000032 - SMBIOS Data Entry

This Boot Catalogue Entry refers to the SMBIOS Data. The SMBIOS Data is provided by firmware, and each structure is copied one after the other into the Boot Catalogue's SMBIOS Data (without any "Inactive" or "End-of-table" structures). To make it faster to search for a structure of a specific type, each structure is preceded by an extra 32-bit length field that can be used to determine the size of structure (including all strings) and used to find the next structure. The actual SMBIOS structure starts after the extra 32-bit length field.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000032)

0x00000008

8 bytes

Address of the SMBIOS Data (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the SMBIOS Data in pages

0x00000014

4 bytes

Number of SMBIOS structures in the SMBIOS Data

Table 3.32 - SMBIOS Data Entry Format (Type 0x80000032)

3.20 Type 0x80000040 - CPU Description Entry

This Boot Catalogue Entry refers to the CPU Description data. The CPU Description data is collected by stage 2 code (e.g. the stage 2 CPU Detection Module), and each unique structure is copied one after the other into the Boot Catalogue's CPU Description data. The format for each CPU Description structure is described in the include file "bcos/80x86/inc/kernel/cpu.inc".

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000040)

0x00000008

8 bytes

Address of the CPU Description structures (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the CPU Description structures in pages

0x00000014

4 bytes

Number of CPU Description structures in the CPU Description

0x00000018

4 bytes

Size of each CPU Description structure in bytes

Table 3.33 - CPU Description Entry Format (Type 0x80000040)

3.21 Type 0x80000041 - CPU Information Entry

This Boot Catalogue Entry refers to the CPU Information data. The CPU Information data is collected by stage 2 code (e.g. the stage 2 CPU Detection Module), and each structure is copied one after the other into the Boot Catalogue's CPU Information data. The format for each CPU Information structure is described in Table 3.35: CPU Information Structure Format.

Offset

Size

Description

0x00000000

4 bytes

Size of entry in bytes

0x00000004

4 bytes

Entry type (0x80000041)

0x00000008

8 bytes

Address of the CPU Information structures (see Section 2.4: Addresses).

0x00000010

4 bytes

Size of the CPU Information structures in pages

0x00000014

4 bytes

Number of CPU Information structures in the CPU Information

0x00000018

4 bytes

Size of each CPU Information structure in bytes

Table 3.34 - CPU Information Entry Format (Type 0x80000041)

Offset

Size

Description

0x00000000

4 bytes

Offset of CPU Description structure for this CPU in CPU Description structures

0x00000004

4 bytes

APIC ID for this CPU

0x00000008

4 bytes

ACPI ID for this CPU (0x00000000 if ACPI not present)

0x0000000C

4 bytes

Address of this CPU's stack (0x00000000 for BSP)

0x00000010

4 bytes

NUMA domain for this CPU

0x00000014

4 bytes

Package number for this CPU

0x00000018

4 bytes

Core number within package for this CPU

0x0000001C

4 bytes

CPU number within core for this CPU

Table 3.35 - CPU Information Structure Format

Generated on Mon Nov 9 12:20:50 2009