GNUBoot
/
hardware-init-review
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add more explanation on resident components

This commit is contained in:
Adrien Bourmault 2024-08-27 13:41:07 +02:00
parent 4b797e3d5c
commit 0dd7622794
Signed by: neox
GPG Key ID: 57BC26A3687116F6
1 changed files with 20 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
hardware_init_review.tex
View File

@ -793,7 +793,7 @@
study on the 4.11 version of \textit{coreboot} \cite{coreboot_4_11},
which is the last version that supported the ASUS KGPE-D16 mainboard. \\
For the firmware tasks to be done efficiently, \textit{coreboot} is
For the initialization tasks to be done efficiently, \textit{coreboot} is
organized in different stages (fig. \ref{fig:coreboot_stages})
\cite{coreboot_docs}.
@ -1045,7 +1045,10 @@
to the appropriate CPUs. Additionally, the firmware configures the
HyperTransport (HT) technology, a high-speed communication protocol
that facilitates data exchange between the processor and the
northbridge, ensuring smooth data flow between these components. \\
northbridge, ensuring smooth data flow between these components.
During this stage, microcode patches may be loaded into CPU and
remain resident, settings related to memory controllers and CPU
too. \\
The \textit{romstage} begins with a call to the
\path{_start} function, defined in
@ -1153,8 +1156,13 @@
x86), coreboot tables, and updates to the device tree (specific to
ARM). Additionally, the ramstage locks down the hardware and
firmware by applying write protection to boot media, locking
security-related registers, and locking SMM (specific to x86)
\cite{coreboot_docs}.
security-related registers, and locking SMM (specific to x86),
which is a resident component in a protected area.
\cite{coreboot_docs}. CBMEM data structures (like coreboot tables,
memory map, etc.) are populated during this stage and left resident
for the OS or payload to access, same for SMBIOS tables, ACPI tables
and eventually option ROMS. \\
Effective resource allocation is essential for system stability,
particularly in complex configurations involving multiple CPUs
and peripherals. This stage manages initial resource allocation,
@ -1179,7 +1187,9 @@
At its core,
ACPI is implemented through a series of data structures and
executable code known as ACPI tables, which are provided by the
system firmware and interpreted by the OS. These tables describe
system firmware and interpreted by the OS at runtime. It means
that these are components from the firmware that remain resident
while the OS runs. These tables describe
various aspects of the system, including hardware resources,
device power states, and thermal zones. The ACPI Specification
outlines these structures and provides the necessary
@ -1229,7 +1239,8 @@
applications. Introduced by Intel, SMM operates in an
environment separate from the main operating system, offering a
controlled space for executing sensitive operations
\cite{uefi_smm_security}. \\
\cite{uefi_smm_security}. This is another firmware component
that remains resident while the OS runs. \\
SMM is triggered by a System Management Interrupt (SMI), which
is a non-maskable interrupt that causes the CPU to save its
@ -1319,6 +1330,8 @@
BIOS routines used in legacy BIOS systems. With GOP drivers,
the system can initialize the GPU and display a graphical interface
even before the operating system loads \cite{osdev_gop}.
These are other examples of resident firmware components while the
OS is running. \\
Hardware manufacturers can distribute proprietary UEFI drivers as
part of firmware updates, making it straightforward for end-users
to install and use them. This is especially useful for specialized
@ -1326,7 +1339,7 @@
free software community. It also gives hardware vendors more control
over how their devices are initialized and used, which can be
an advantage for vendors but is a freedom and user control
limitation. \\
limitation.
Payloads are then definitely important parts of the firmware.