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

WIP

This commit is contained in:
Adrien Bourmault 2024-08-21 21:27:29 +02:00
parent 46e774a62c
commit 312b458ec5
Signed by: neox
GPG Key ID: 57BC26A3687116F6
6 changed files with 300 additions and 253 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
Makefile
View File

@ -1,23 +1,25 @@
.PHONY: clean distclean all bibliography
.PHONY: clean distclean all force_update
all: hardware_init_review.pdf
XELATEX=xelatex -shell-escape
DOC=hardware_init_review
all: $(DOC).pdf
clean:
rm -rf *.log *.bak *.out *.xml *.gz *.aux *.bcf *.blg
distclean: clean
rm -rf *.bbl *.pdf *.toc
rm -rf *.bbl *.pdf *.toc $(DOC).bibready
bibliography: hardware_init_review.bbl
$(DOC).bibready:
$(XELATEX) $(DOC).tex
touch $(DOC).bibready
hardware_init_review.bbl: bibliographie.bib hardware_init_review.bcf
biber hardware_init_review
$(DOC).bbl: $(DOC).bibready bibliographie.bib
biber $(DOC)
hardware_init_review.bcf:
xelatex hardware_init_review.tex
$(DOC).pdf: $(DOC).bbl $(DOC).tex
$(XELATEX) $(DOC).tex
hardware_init_review.toc:
xelatex hardware_init_review.tex
hardware_init_review.pdf: hardware_init_review.bbl hardware_init_review.toc
xelatex hardware_init_review.tex
force_update: $(DOC).toc
$(XELATEX) $(DOC).tex

BIN
hardware_init_review.pdf
View File

Binary file not shown.

433
hardware_init_review.tex
View File

@ -8,9 +8,9 @@
% setup bibliography
\addbibresource{bibliographie.bib}
% --------------------------------------------------------------------------------------
% ------------------------------------------------------------------------------
\begin{document}{
% --------------------------------------------------------------------------------------
% ------------------------------------------------------------------------------
\sloppy % allow flexible margins
@ -18,22 +18,22 @@
\newpage
% --------------------------------------------------------------------------------------
% License page
% License header
% --------------------------------------------------------------------------------------
\setcounter{page}{2}
\vspace*{\fill} % fill the page so that text is at the bottom
This is Edition 0.0. \newline
This is Edition 0.0. \newline
Copyright (C) 2024 Adrien 'neox' Bourmault \href{mailto:neox@gnu.org}{<neox@gnu.org>} \newline
Copyright (C) 2024 Adrien 'neox' Bourmault \href{mailto:neox@gnu.org}{<neox@gnu.org>} \newline
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
\newpage
@ -46,44 +46,44 @@ Free Documentation License".
\addcontentsline{toc}{chapter}{Abstract}
The global trend is towards the scarcity of free software-compatible hardware,
and soon there will be no computer that will work without software domination
by big companies, especially involving firmware like BIOSes. \\
The global trend is towards the scarcity of free software-compatible hardware,
and soon there will be no computer that will work without software domination
by big companies, especially involving firmware like BIOSes. \\
A Basic Input Output System
(BIOS) was originally a set of low-level functions contained in the read-only
memory of a computer's mainboard, enabling it to perform basic operations when
powered up. However, the definition of a BIOS has evolved to include what used
to be known as Power On Self Test (POST) for the presence of peripherals,
allocating resources for them to avoid conflicts, and then handing over to an
operating system boot loader. Nowadays, the bulk of the BIOS work is the
initialization and training of RAM. This means, for example, initializing the
memory controller and optimizing timing and read/write voltage for optimal
performance, making the code complex, as its role is to optimize several
parallel buses operating at high speeds and shared by many CPU cores, and make
them act as a homogeneous whole. \\
A Basic Input Output System
(BIOS) was originally a set of low-level functions contained in the read-only
memory of a computer's mainboard, enabling it to perform basic operations when
powered up. However, the definition of a BIOS has evolved to include what used
to be known as Power On Self Test (POST) for the presence of peripherals,
allocating resources for them to avoid conflicts, and then handing over to an
operating system boot loader. Nowadays, the bulk of the BIOS work is the
initialization and training of RAM. This means, for example, initializing the
memory controller and optimizing timing and read/write voltage for optimal
performance, making the code complex, as its role is to optimize several
parallel buses operating at high speeds and shared by many CPU cores, and make
them act as a homogeneous whole. \\
This document is the product of a project hosted by the \textit{LIP6 laboratory}
and supported by the \textit{GNU Boot Project} and the \textit{Free Software
Foundation}. It delves into the importance of firmware in the hardware
initialization of modern computers and explores various aspects of firmware,
such as Intel Management Engine (ME), AMD Platform Security Processor (PSP),
Advanced Configuration and Power Interface (ACPI), and System Management Mode
(SMM). Additionally, it provides an in-depth look at memory initialization and
training algorithms, highlighting their critical role in system stability
and performance. Examples of the implementation in the ASUS KGPE-D16 mainboard are
presented, describing its hardware characteristics, topology, and the crucial role
of firmware in its operation after the mainboard architecture is examined.
Practical examples illustrate the impact of firmware on hardware
initialization, memory optimization, resource allocation, power management,
and security. Specific algorithms used for memory training and their outcomes
are analyzed to demonstrate the complexity and importance of firmware in
achieving optimal system performance.
Furthermore, this document explores the relationship between firmware and
hardware virtualization, discussing how modern firmware supports and enhances
virtualized environments. Security considerations and future trends in
firmware development are also addressed, emphasizing the need for continued
research and advocacy for free software-compatible hardware.
This document is the product of a project hosted by the \textit{LIP6 laboratory}
and supported by the \textit{GNU Boot Project} and the \textit{Free Software
Foundation}. It delves into the importance of firmware in the hardware
initialization of modern computers and explores various aspects of firmware,
such as Intel Management Engine (ME), AMD Platform Security Processor (PSP),
Advanced Configuration and Power Interface (ACPI), and System Management Mode
(SMM). Additionally, it provides an in-depth look at memory initialization and
training algorithms, highlighting their critical role in system stability
and performance. Examples of the implementation in the ASUS KGPE-D16 mainboard are
presented, describing its hardware characteristics, topology, and the crucial role
of firmware in its operation after the mainboard architecture is examined.
Practical examples illustrate the impact of firmware on hardware
initialization, memory optimization, resource allocation, power management,
and security. Specific algorithms used for memory training and their outcomes
are analyzed to demonstrate the complexity and importance of firmware in
achieving optimal system performance.
Furthermore, this document explores the relationship between firmware and
hardware virtualization, discussing how modern firmware supports and enhances
virtualized environments. Security considerations and future trends in
firmware development are also addressed, emphasizing the need for continued
research and advocacy for free software-compatible hardware.
\chapter{Introduction to firmware and BIOS evolution}
@ -416,13 +416,13 @@ research and advocacy for free software-compatible hardware.
\chapter{Characteristics of ASUS KGPE-D16 mainboard}
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{images/kgpe-d16.png}
\caption{The KGPE-D16 (CC BY-SA 4.0, 2021)}
\end{figure}
\newpage
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{images/kgpe-d16.png}
\caption{The KGPE-D16 (CC BY-SA 4.0, 2021)}
\end{figure}
\newpage
\section{Overview of ASUS KGPE-D16 hardware}
@ -559,39 +559,39 @@ research and advocacy for free software-compatible hardware.
(fig. \ref{fig:opteron2600}, \ref{fig:opteron2600_diagram})
\cite{amd_6200}\cite{anandtech_bulldozer}.
The architecture of the Opteron 6200 series is built around AMD's Bulldozer core
design, which uses Clustered Multithreading (CMT) to maximize resource
utilization. This is a technique where each processor
module contains two integer cores that share certain resources like the
floating-point unit (FPU), L2 cache, and instruction fetch/decode stages. Unlike
traditional multithreading, where each core handles multiple threads, CMT allows
two cores to share resources to improve parallel processing efficiency. This
approach aims to balance performance and resource usage, particularly in multi-
threaded workloads, though it can lead to some performance trade-offs in
single-threaded tasks.
In the Opteron 6272, the processor consists of eight modules, effectively
creating 16 integer cores. Due to the CMT architecture, each Opteron 6272 chip
functions as two CPUs within a single processor, each with its own set of cores,
L2 caches, and shared L3 cache. Here, one CPU is made by four modules, each
module in it sharing certain components, such as the FPU and L2 cache, between
two integer cores. The L3 cache is shared across these modules.
HyperTransport links provide high-speed communication between the two sockets of
the KGPE-D16. Shared L3 cache and direct memory access are provided by each
socket \cite{amd_6200}\cite{hill_impact_caching}. \\
The architecture of the Opteron 6200 series is built around AMD's Bulldozer core
design, which uses Clustered Multithreading (CMT) to maximize resource
utilization. This is a technique where each processor
module contains two integer cores that share certain resources like the
floating-point unit (FPU), L2 cache, and instruction fetch/decode stages. Unlike
traditional multithreading, where each core handles multiple threads, CMT allows
two cores to share resources to improve parallel processing efficiency. This
approach aims to balance performance and resource usage, particularly in multi-
threaded workloads, though it can lead to some performance trade-offs in
single-threaded tasks.
In the Opteron 6272, the processor consists of eight modules, effectively
creating 16 integer cores. Due to the CMT architecture, each Opteron 6272 chip
functions as two CPUs within a single processor, each with its own set of cores,
L2 caches, and shared L3 cache. Here, one CPU is made by four modules, each
module in it sharing certain components, such as the FPU and L2 cache, between
two integer cores. The L3 cache is shared across these modules.
HyperTransport links provide high-speed communication between the two sockets of
the KGPE-D16. Shared L3 cache and direct memory access are provided by each
socket \cite{amd_6200}\cite{hill_impact_caching}. \\
This architecture also integrates a quad-channel DDR3 memory controller directly
into the processor die, which facilitates high bandwidth and low latency access
to memory. This memory controller supports DDR3 memory speeds up to 1600 MHz and
connects directly to the memory modules via the memory bus. By integrating the
memory controller into the processor, the Opteron 6200 series reduces memory
access latency, enhancing overall performance
\cite{amd_6200}Is \cite{amd_ddr3_guide}. It is interesting to note that Opterons
incorporate the internal northbridge that we cited previously. The traditional
northbridge functions, such as memory controller and PCIe interface management,
are partially integrated into the processor. This integration reduces the
distance data must travel between the CPU and memory, decreasing latency and
improving performance, particularly in memory-intensive applications
\cite{amd_6200}. \\
This architecture also integrates a quad-channel DDR3 memory controller directly
into the processor die, which facilitates high bandwidth and low latency access
to memory. This memory controller supports DDR3 memory speeds up to 1600 MHz and
connects directly to the memory modules via the memory bus. By integrating the
memory controller into the processor, the Opteron 6200 series reduces memory
access latency, enhancing overall performance
\cite{amd_6200}Is \cite{amd_ddr3_guide}. It is interesting to note that Opterons
incorporate the internal northbridge that we cited previously. The traditional
northbridge functions, such as memory controller and PCIe interface management,
are partially integrated into the processor. This integration reduces the
distance data must travel between the CPU and memory, decreasing latency and
improving performance, particularly in memory-intensive applications
\cite{amd_6200}. \\
\begin{figure}[H]
@ -602,17 +602,17 @@ research and advocacy for free software-compatible hardware.
\label{fig:opteron2600_diagram}
\end{figure}
Power efficiency was a key focus in the design of the Opteron 6200 series.
Despite the high core count, the processor includes several power management
features, such as Dynamic Power Management (DPM) and Turbo Core technology. These
features allow the processor to adjust power usage based on workload demands,
balancing performance with energy consumption. However, the Bulldozer
architecture's focus on high clock speeds and multi-threaded performance resulted
in higher power consumption compared to competing architectures
\cite{anandtech_bulldozer}. A special model of the series,
called \textit{high efficiency} models, solve a bit this problem by proposing
a bit less performant processor but with a power consumption divided by a factor
from 1.5 to 2.0 in some cases. \\
Power efficiency was a key focus in the design of the Opteron 6200 series.
Despite the high core count, the processor includes several power management
features, such as Dynamic Power Management (DPM) and Turbo Core technology. These
features allow the processor to adjust power usage based on workload demands,
balancing performance with energy consumption. However, the Bulldozer
architecture's focus on high clock speeds and multi-threaded performance resulted
in higher power consumption compared to competing architectures
\cite{anandtech_bulldozer}. A special model of the series,
called \textit{high efficiency} models, solve a bit this problem by proposing
a bit less performant processor but with a power consumption divided by a factor
from 1.5 to 2.0 in some cases. \\
The processor connected to the I/O hub is known as the Bootstrap
Processor (BSP).
@ -630,144 +630,162 @@ research and advocacy for free software-compatible hardware.
deciding which initialization procedures need to be executed
\cite{amd_bsp}\cite{BKDG}.
\section{Baseboard Management Controller}
The Baseboard Management Controller (BMC) on the KGPE-D16 motherboard,
specifically the ASpeed AST2050, plays a role in the server's
architecture by managing out-of-band communication and control of the hardware.
The AST2050 is based on an ARM926EJ-S processor, a low-power 32-bit ARM
architecture designed for embedded systems \cite{ast2050_architecture}. This
architecture is well-suited for BMCs due to its efficiency and capability to
handle multiple management tasks concurrently without significant resource
demands from the main system. \\
\section{Baseboard Management Controller}
The Baseboard Management Controller (BMC) on the KGPE-D16 motherboard,
specifically the ASpeed AST2050, plays a role in the server's
architecture by managing out-of-band communication and control of the hardware.
The AST2050 is based on an ARM926EJ-S processor, a low-power 32-bit ARM
architecture designed for embedded systems \cite{ast2050_architecture}. This
architecture is well-suited for BMCs due to its efficiency and capability to
handle multiple management tasks concurrently without significant resource
demands from the main system. \\
The AST2050 features several key components that contribute to its functionality.
It includes an integrated VGA controller, which enables remote graphical
management through KVM-over-IP (Keyboard, Video, Mouse), a critical feature for
administrators who need to interact with the system remotely, including BIOS
updates and troubleshooting \cite{ast2050_kvm}. Additionally, the AST2050
integrates a dedicated memory controller, which supports up to 256MB of DDR2 RAM.
This allows it to handle complex tasks and maintain responsiveness during
management operations \cite{ast2050_memory}.
The BMC also features a network interface controller (NIC) dedicated to
management traffic, ensuring that remote management does not interfere with the
primary network traffic of the server. This separation is vital for maintaining
secure and uninterrupted system management, especially in environments where
uptime is critical \cite{ast2050_nic}.
Another important architectural aspect of the AST2050 is its support for multiple
I/O interfaces, including I2C, GPIO, UART, and USB, which allow it to interface
with various sensors and peripherals on the motherboard \cite{ast2050_io}. This
versatility enables comprehensive monitoring of hardware health, such as
temperature sensors, fan speeds, and power supplies, all of which can be managed
and configured through the BMC. \\
When combined with OpenBMC \cite{openbmc_wiki}, a libre firmware that can be
run on the AST2050 thanks to Raptor Engineering \cite{raptor_engineering},
the architecture of the BMC becomes even more powerful. OpenBMC takes
advantage of the AST2050's architecture, providing a flexible and
customizable environment that can be tailored to specific use cases. This
includes adding or modifying features related to security, logging, and network
management, all within the BMC's ARM architecture framework
\cite{openbmc_customization}.
The AST2050 features several key components that contribute to its functionality.
It includes an integrated VGA controller, which enables remote graphical
management through KVM-over-IP (Keyboard, Video, Mouse), a critical feature for
administrators who need to interact with the system remotely, including BIOS
updates and troubleshooting \cite{ast2050_kvm}. Additionally, the AST2050
integrates a dedicated memory controller, which supports up to 256MB of DDR2 RAM.
This allows it to handle complex tasks and maintain responsiveness during
management operations \cite{ast2050_memory}.
The BMC also features a network interface controller (NIC) dedicated to
management traffic, ensuring that remote management does not interfere with the
primary network traffic of the server. This separation is vital for maintaining
secure and uninterrupted system management, especially in environments where
uptime is critical \cite{ast2050_nic}.
Another important architectural aspect of the AST2050 is its support for multiple
I/O interfaces, including I2C, GPIO, UART, and USB, which allow it to interface
with various sensors and peripherals on the motherboard \cite{ast2050_io}. This
versatility enables comprehensive monitoring of hardware health, such as
temperature sensors, fan speeds, and power supplies, all of which can be managed
and configured through the BMC. \\
When combined with OpenBMC \cite{openbmc_wiki}, a libre firmware that can be
run on the AST2050 thanks to Raptor Engineering \cite{raptor_engineering},
the architecture of the BMC becomes even more powerful. OpenBMC takes
advantage of the AST2050's architecture, providing a flexible and
customizable environment that can be tailored to specific use cases. This
includes adding or modifying features related to security, logging, and network
management, all within the BMC's ARM architecture framework
\cite{openbmc_customization}.
\chapter{Key components in modern firmware [WIP]}
\section{General structure of coreboot}
\section{General structure of coreboot}
The firmware of the ASUS KGPE-D16 is crucial in ensuring the proper functioning
and optimization of the mainboard's hardware components. For this to be done
efficiently, \textit{coreboot} is organized in different stages (fig.
\ref{fig:coreboot_stages}) \cite{coreboot_docs}.
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{
images/fig9_coreboot_stages.png}
\caption{\textit{coreboot}'s stages timeline, by \textit{coreboot} project (CC BY-SA 4.0, 2009)}
\label{fig:coreboot_stages}
\end{figure}
Being a complex project with ambitious goals, \textit{coreboot} decided early on
to establish an file-system-based architecture for its images (also called ROMs).
This special file-system is CBFS (which stands for coreboot file system).
The CBFS architecture consists of a binary image that can be interpreted as a
physical disk, referred to here as ROM. A number of independent components, each
with a header added to the data, are located within the ROM. The components are
nominally arranged sequentially, although they are aligned along a predefined
boundary \ref{fig:coreboot_diagram}). \\
Each stage is compiled as a separate binary and inserted into the CBFS with
custom compression. The \textbf{bootblock} is usually not compressed, while the
\textbf{ramstage} and the \textbf{payload} are compressed with LZMA.
Each stage loads the next stage at a given address (possibly decompressing it
in the process). \\
\begin{figure}[H]
\centering
\includegraphics[width=0.8\textwidth]{
images/fig8_coreboot_architecture.png}
\caption{\textit{coreboot} ROM architecture (CC BY-SA 4.0, 2024)}
\label{fig:coreboot_diagram}
\end{figure}
Some stages are relocatable and can be placed anywhere in the RAM. These stages
are typically cached in the \textbf{CBMEM} for faster loading times during
wake-up. The CBMEM is a specific memory area used by the
\textit{coreboot} firmware to store important data structures and logs during the
boot process. This area is typically allocated in the system's RAM and is used to
store various types of runtime information that it might need to reference
after the initial boot stages.
\subsection{Bootblock stage}
\caption{\textit{coreboot}'s stages timeline, by \textit{coreboot} project (CC BY-SA 4.0, 2009)}
\label{fig:coreboot_stages}
\end{figure}
The \textbf{bootblock} is the first stage executed after the CPU reset.
The beginning of this stage is written in assembly language, and its main task is
to set everything up for a C environment. The rest, of course, is written in C.
\\
Being a complex project with ambitious goals, \textit{coreboot} decided early on
to establish an file-system-based architecture for its images (also called ROMs).
This special file-system is CBFS (which stands for coreboot file system).
The CBFS architecture consists of a binary image that can be interpreted as a
physical disk, referred to here as ROM. A number of independent components, each
with a header added to the data, are located within the ROM. The components are
nominally arranged sequentially, although they are aligned along a predefined
boundary (fig. \ref{fig:coreboot_diagram}). \\
Each stage is compiled as a separate binary and inserted into the CBFS with
custom compression. The bootblock stage is usually not compressed, while the
ramstage and the payload are compressed with LZMA.
Each stage loads the next stage at a given address (possibly decompressing it
in the process). \\
The \textbf{bootblock} occupies the last 20k and within it is a main
header containing information about the ROM, including the size, component
alignment, and the offset of the start of the first CBFS component in the ROM.
This block is a mandatory component of the ROM as it also contains the entry
point of the firmware. \\
\begin{figure}[H]
\centering
\includegraphics[width=0.8\textwidth]{
images/fig8_coreboot_architecture.png}
\caption{\textit{coreboot} ROM architecture (CC BY-SA 4.0, 2024)}
\label{fig:coreboot_diagram}
\end{figure}
Some stages are relocatable and can be placed anywhere in the RAM. These stages
are typically cached in the CBMEM for faster loading times during
wake-up. The CBMEM is a specific memory area used by the
\textit{coreboot} firmware to store important data structures and logs during the
boot process. This area is typically allocated in the system's RAM and is used to
store various types of runtime information that it might need to reference
after the initial boot stages.
\subsection{Bootblock stage}
The bootblock is the first stage executed after the CPU reset.
The beginning of this stage is written in assembly language, and its main task is
to set everything up for a C environment. The rest, of course, is written in C.
This stage occupies the last 20k (fig. \ref{fig:coreboot_diagram}) of the image
and within it is a main header containing information about the ROM, including
the size, component alignment, and the offset of the start of the first CBFS
component in the ROM.
This block is a mandatory component as it also contains the entry point of the
firmware. \\
Upon startup, this stage is responsible for the initial hardware setup, which
involves identifying and configuring the CPU. This process is particularly
significant for AMD Family 10h/15h processors, where the firmware sets up the
Bootstrap Processor (BSP) and executes the necessary initialization routines.
Using the BSP, it enables the processor's cache, a small but fast type of memory
Bootstrap Processor (BSP) and executes the necessary initialization routines:
using the BSP, it enables the processor's cache, a small but fast type of memory
that stores frequently accessed data, improving overall system speed by reducing
data access time. However, the cache is there used as memory since DDR DIMMs are
not available yet. It is done by programing the \textbf{Memory Type Range
Registers} (MTRRs), which define how different ranges of system memory are
accessed, such as whether they are cacheable or non-cacheable, used to optimize
memory performance on normal operation.
not available yet. This is done by programming the Memory Type Range
Registers (MTRRs), which define how different ranges of system memory are
accessed such as whether they are cacheable or non-cacheable, used to optimize
memory performance on normal operation \cite{BKDG}.
The firmware will then set the stack pointer, allocate memory for the BSS, and
decompress and load the next stage. On x86 platforms, this process also includes
updating the CPU microcode, initializing the timer, and transitioning from 16-bit
real mode to 32-bit protected mode. The \textbf{bootblock} is responsible for
loading the romstage, or the verstage if verified boot is enabled.
real mode to 32-bit protected mode. The bootblock is responsible for
loading the romstage, or the verstage if verified boot is enabled
\cite{coreboot_docs}.
\subsection{Romstage}
The firmware also configures the Advanced Programmable Interrupt Controller
(APIC), which manages how the processor handles interrupts to ensure
the system can respond efficiently to hardware and
software events. Lastly, it sets up the routing for HyperTransport (HT)
The purpose of the romstage is the early initialization of peripherals,
particularly system memory. The firmware also configures the Advanced
Programmable Interrupt Controller (APIC), responsible in handling interrupts
correctly across multiple CPUs, particularly in systems that use Symmetric
Multiprocessing (SMP).
In this phase, \textit{coreboot} sets up the APIC to manage interrupt routing,
which includes configuring the Local APIC on each processor and the IOAPIC, part
of the southbridge, for routing interrupts from peripherals to the appropriate
CPUs.
Lastly, it sets up the routing for HyperTransport (HT)
technology, a high-speed communication protocol used for data exchange between
the processor and the northbridge, ensuring that data flows smoothly
between these components.
between these components. \\
Memory training and optimization are key functions of the firmware. During this
process, the firmware adjusts memory settings, such as timings, frequencies, and
voltages, to ensure that the installed memory modules operate efficiently and
stably. This step is crucial for achieving optimal performance, especially when
dealing with large amounts of RAM for a large amount of CPU cores, as
supported by the KGPE-D16. \\
supported by the KGPE-D16. We will dive into this topic later on. \\
\subsection{Ramstage}
The ramstage performs the general initialization of all peripherals, including
the initialization of PCI devices, on-chip devices, the TPM (if not done by
verstage), graphics (optional), and the CPU (setting up the System Management
Mode). After this initialization, tables are written to inform the payload or
operating system about the existence and current state of the hardware. These
tables include ACPI tables (specific to x86), SMBIOS tables (specific to 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). \\
Effective resource allocation is essential for system stability, particularly in
complex configurations involving multiple CPUs and peripherals. The firmware
manages resource allocation, resolving any conflicts between hardware components
@ -784,10 +802,20 @@ research and advocacy for free software-compatible hardware.
maintain the integrity of its operations. This includes support for IOMMU, which
is crucial for preventing unauthorized direct memory access (DMA) attacks,
particularly in virtualized environments.
\subsection{Payload}
TODO
TODO
\begin{listing}[H]
\begin{adjustwidth}{0.5cm}{0.5cm}
\inputminted{c}{listings/test.c}
\end{adjustwidth}
\caption{\textit{Example Python functions}}
\label{lst:python_code}
\end{listing}
We saw that in (lst. \ref{lst:python_code}).
\section{Advanced Configuration and Power Interface}
@ -1587,3 +1615,4 @@ free software license, such as the GNU General Public License,
to permit their use in free software.
\end{document}

72
hardware_init_review.toc
View File

@ -1,38 +1,38 @@
\babel@toc {english}{}\relax
\contentsline {chapter}{Abstract}{5}{chapter*.1}%
\contentsline {chapter}{\numberline {1}Introduction to firmware and BIOS evolution}{6}{chapter.1}%
\contentsline {section}{\numberline {1.1}Historical context of BIOS}{6}{section.1.1}%
\contentsline {subsection}{\numberline {1.1.1}Definition and origin}{6}{subsection.1.1.1}%
\contentsline {subsection}{\numberline {1.1.2}Functionalities and limitations}{7}{subsection.1.1.2}%
\contentsline {section}{\numberline {1.2}Modern BIOS and UEFI}{8}{section.1.2}%
\contentsline {subsection}{\numberline {1.2.1}Transition from traditional BIOS to UEFI (Unified Extensible Firmware Interface)}{8}{subsection.1.2.1}%
\contentsline {subsection}{\numberline {1.2.2}An other way with \textit {coreboot}}{8}{subsection.1.2.2}%
\contentsline {section}{\numberline {1.3}Shift in firmware responsibilities}{10}{section.1.3}%
\contentsline {chapter}{\numberline {2}Characteristics of ASUS KGPE-D16 mainboard}{11}{chapter.2}%
\contentsline {section}{\numberline {2.1}Overview of ASUS KGPE-D16 hardware}{12}{section.2.1}%
\contentsline {section}{\numberline {2.2}Chipset}{13}{section.2.2}%
\contentsline {section}{\numberline {2.3}Processors}{15}{section.2.3}%
\contentsline {section}{\numberline {2.4}Baseboard Management Controller}{16}{section.2.4}%
\contentsline {chapter}{\numberline {3}Key components in modern firmware [WIP]}{18}{chapter.3}%
\contentsline {section}{\numberline {3.1}General structure of coreboot}{18}{section.3.1}%
\contentsline {subsection}{\numberline {3.1.1}Bootblock stage}{19}{subsection.3.1.1}%
\contentsline {subsection}{\numberline {3.1.2}Romstage}{19}{subsection.3.1.2}%
\contentsline {subsection}{\numberline {3.1.3}Ramstage}{20}{subsection.3.1.3}%
\contentsline {subsection}{\numberline {3.1.4}Payload}{20}{subsection.3.1.4}%
\contentsline {section}{\numberline {3.2}Advanced Configuration and Power Interface}{20}{section.3.2}%
\contentsline {section}{\numberline {3.3}System Management Mode}{21}{section.3.3}%
\contentsline {chapter}{Abstract}{4}{chapter*.1}%
\contentsline {chapter}{\numberline {1}Introduction to firmware and BIOS evolution}{5}{chapter.1}%
\contentsline {section}{\numberline {1.1}Historical context of BIOS}{5}{section.1.1}%
\contentsline {subsection}{\numberline {1.1.1}Definition and origin}{5}{subsection.1.1.1}%
\contentsline {subsection}{\numberline {1.1.2}Functionalities and limitations}{6}{subsection.1.1.2}%
\contentsline {section}{\numberline {1.2}Modern BIOS and UEFI}{7}{section.1.2}%
\contentsline {subsection}{\numberline {1.2.1}Transition from traditional BIOS to UEFI (Unified Extensible Firmware Interface)}{7}{subsection.1.2.1}%
\contentsline {subsection}{\numberline {1.2.2}An other way with \textit {coreboot}}{7}{subsection.1.2.2}%
\contentsline {section}{\numberline {1.3}Shift in firmware responsibilities}{9}{section.1.3}%
\contentsline {chapter}{\numberline {2}Characteristics of ASUS KGPE-D16 mainboard}{10}{chapter.2}%
\contentsline {section}{\numberline {2.1}Overview of ASUS KGPE-D16 hardware}{11}{section.2.1}%
\contentsline {section}{\numberline {2.2}Chipset}{12}{section.2.2}%
\contentsline {section}{\numberline {2.3}Processors}{14}{section.2.3}%
\contentsline {section}{\numberline {2.4}Baseboard Management Controller}{15}{section.2.4}%
\contentsline {chapter}{\numberline {3}Key components in modern firmware [WIP]}{17}{chapter.3}%
\contentsline {section}{\numberline {3.1}General structure of coreboot}{17}{section.3.1}%
\contentsline {subsection}{\numberline {3.1.1}Bootblock stage}{18}{subsection.3.1.1}%
\contentsline {subsection}{\numberline {3.1.2}Romstage}{18}{subsection.3.1.2}%
\contentsline {subsection}{\numberline {3.1.3}Ramstage}{19}{subsection.3.1.3}%
\contentsline {subsection}{\numberline {3.1.4}Payload}{19}{subsection.3.1.4}%
\contentsline {section}{\numberline {3.2}Advanced Configuration and Power Interface}{19}{section.3.2}%
\contentsline {section}{\numberline {3.3}System Management Mode}{20}{section.3.3}%
\contentsline {section}{\numberline {3.4}AMD Platform Security Processor and Intel Management Engine}{21}{section.3.4}%
\contentsline {chapter}{\numberline {4}Memory initialization and training algorithms [WIP]}{23}{chapter.4}%
\contentsline {section}{\numberline {4.1}Importance of memory initialization}{23}{section.4.1}%
\contentsline {section}{\numberline {4.2}Memory training algorithms}{23}{section.4.2}%
\contentsline {section}{\numberline {4.3}Practical examples}{24}{section.4.3}%
\contentsline {chapter}{\numberline {5}Firmware and hardware virtualization [WIP]}{25}{chapter.5}%
\contentsline {section}{\numberline {5.1}Introduction to hardware virtualization}{25}{section.5.1}%
\contentsline {section}{\numberline {5.2}Role of BIOS/UEFI in virtualization}{25}{section.5.2}%
\contentsline {section}{\numberline {5.3}Security and freedom considerations}{25}{section.5.3}%
\contentsline {section}{\numberline {5.4}Future trends in firmware and virtualization}{25}{section.5.4}%
\contentsline {chapter}{Conclusion}{26}{chapter*.2}%
\contentsline {section}{\numberline {5.5}Summary of key points}{26}{section.5.5}%
\contentsline {section}{\numberline {5.6}Call for action}{26}{section.5.6}%
\contentsline {chapter}{Bibliography}{27}{section.5.6}%
\contentsline {chapter}{GNU Free Documentation License}{32}{chapter*.4}%
\contentsline {chapter}{\numberline {4}Memory initialization and training algorithms [WIP]}{22}{chapter.4}%
\contentsline {section}{\numberline {4.1}Importance of memory initialization}{22}{section.4.1}%
\contentsline {section}{\numberline {4.2}Memory training algorithms}{22}{section.4.2}%
\contentsline {section}{\numberline {4.3}Practical examples}{23}{section.4.3}%
\contentsline {chapter}{\numberline {5}Firmware and hardware virtualization [WIP]}{24}{chapter.5}%
\contentsline {section}{\numberline {5.1}Introduction to hardware virtualization}{24}{section.5.1}%
\contentsline {section}{\numberline {5.2}Role of BIOS/UEFI in virtualization}{24}{section.5.2}%
\contentsline {section}{\numberline {5.3}Security and freedom considerations}{24}{section.5.3}%
\contentsline {section}{\numberline {5.4}Future trends in firmware and virtualization}{24}{section.5.4}%
\contentsline {chapter}{Conclusion}{25}{chapter*.2}%
\contentsline {section}{\numberline {5.5}Summary of key points}{25}{section.5.5}%
\contentsline {section}{\numberline {5.6}Call for action}{25}{section.5.6}%
\contentsline {chapter}{Bibliography}{26}{section.5.6}%
\contentsline {chapter}{GNU Free Documentation License}{31}{chapter*.4}%

4
listings/test.c Normal file
View File

@ -0,0 +1,4 @@
void main(int a, int b)
{
return 0;
}

16
packages.tex
View File

@ -13,9 +13,11 @@
\usepackage[T1]{fontenc}
\usepackage[english]{babel}
\usepackage{graphicx}
\usepackage{listings}
\usepackage{listing}
\usepackage{minted}
\usepackage{xcolor}
\usepackage{chngcntr}
\usepackage{changepage}
\usepackage[a4paper, portrait, margin=1.45cm]{geometry}
\title{Titre du mémoire}
\author{Nom et prénom de l'auteur}
@ -45,4 +47,14 @@
\renewcommand{\cftchapafterpnum}{\vspace{\cftbeforechapskip}}
\renewcommand{\familydefault}{\sfdefault}
\setlength\parindent{0pt}
\setlength\parindent{0pt}
\usemintedstyle{solarized-light}
\definecolor{bg}{HTML}{FAF9F6}
\definecolor{linenumcolor}{rgb}{0.6, 0.6, 0.6} % Light gray color
%\renewcommand{\theFancyVerbLine}{\textcolor{linenumcolor}{\arabic{FancyVerbLine}}}
\setminted{
linenos,
numbersep=5pt,
bgcolor=bg
}