Common Boot Platform
- Erin Shepherd
Purpose & Intent
To provide a shared "boot platform", which to some extent abstracts operating systems from the underlying system firmware
Components
The platform is divided into four components
Bootstrapper
Platform & File system dependent binaries
Takes control from the system's firmware, loads and passes control to the core runtime.
Provides the core with a file system driver, for the file system from which the core runtime itself was loaded from
On bare metal platforms, this may be the "system's firmware", in that it is the first component loaded at power on
Core Runtime
Platform dependent binary
Using the file system driver provided by the bootstrapper, loads the payload application
When the platform is UEFI or similar, which support passing command line arguments to applications, the runtime shall use that to determine which application to load. Otherwise, (i.e. in the cases of the PC BIOS/bare metal), the boot manager application shall be loaded.
The core runtime component is responsible for tracking platform information (e.g. ACPI tables). How it does this, and how the task of discovery is defined, is platform dependent (in general, it is the runtime's job to discover anything not disclosed by the firmware to the bootstrapper at startup)
Boot Manager
Platform independent
An application built upon the core runtime. Reads configuration files, and uses them to select which operating system to boot/present a menu of choices.
The configuration file offers the following parameters:
| Name | Description |
|---|---|
default | The default configuration to be loaded |
timeout | The amount of time for which the menu will be shown. If this is zero, the menu will only be shown if the user presses a special key (e.g. shift) |
Each boot configuration shall be described in its own file.
In addition, a file, named "bootnext", shall be read. If it exists, the boot manager is to behave as if the default variable was set to the contents of it, and the timeout variable set to zero. If the file system driver provides the capability to do so, the boot manager shall delete this file; otherwise, the operating system booted should do so. The purpose of this file is to enable temporary automatic starting of the OS, e.g. at the end of an installation processs
Applications
"Applications" can take many forms. They can be genuine applications (e.g. the aforementioned boot manager), or they can be operating system loaders.
In addition to the boot manager, the project should provide an application capable of loading kernels compliant with the GNU Multiboot standard (as supported by GRUB)
Runtime Provided Functionality
The runtime is designed to provide services for booting a fully fledged operating system; it is not designed to form one itself. The scope of it is therefore intentionally constrained to:
- The functionality provided by the C language standard, minus portions dealing with floating point numbers, threading and atomic operations
- An executable loader
- Functions for manipulating the architecture's page tables, plus one which enables these paging structures and jumps to a specified address with the specified parameter(s)