WIP
This commit is contained in:
parent
46e774a62c
commit
312b458ec5
28
Makefile
28
Makefile
|
@ -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:
|
clean:
|
||||||
rm -rf *.log *.bak *.out *.xml *.gz *.aux *.bcf *.blg
|
rm -rf *.log *.bak *.out *.xml *.gz *.aux *.bcf *.blg
|
||||||
|
|
||||||
distclean: clean
|
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
|
$(DOC).bbl: $(DOC).bibready bibliographie.bib
|
||||||
biber hardware_init_review
|
biber $(DOC)
|
||||||
|
|
||||||
hardware_init_review.bcf:
|
$(DOC).pdf: $(DOC).bbl $(DOC).tex
|
||||||
xelatex hardware_init_review.tex
|
$(XELATEX) $(DOC).tex
|
||||||
|
|
||||||
hardware_init_review.toc:
|
force_update: $(DOC).toc
|
||||||
xelatex hardware_init_review.tex
|
$(XELATEX) $(DOC).tex
|
||||||
|
|
||||||
hardware_init_review.pdf: hardware_init_review.bbl hardware_init_review.toc
|
|
||||||
xelatex hardware_init_review.tex
|
|
||||||
|
|
Binary file not shown.
|
@ -8,9 +8,9 @@
|
||||||
% setup bibliography
|
% setup bibliography
|
||||||
\addbibresource{bibliographie.bib}
|
\addbibresource{bibliographie.bib}
|
||||||
|
|
||||||
% --------------------------------------------------------------------------------------
|
% ------------------------------------------------------------------------------
|
||||||
\begin{document}{
|
\begin{document}{
|
||||||
% --------------------------------------------------------------------------------------
|
% ------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
|
||||||
\sloppy % allow flexible margins
|
\sloppy % allow flexible margins
|
||||||
|
@ -18,22 +18,22 @@
|
||||||
\newpage
|
\newpage
|
||||||
|
|
||||||
% --------------------------------------------------------------------------------------
|
% --------------------------------------------------------------------------------------
|
||||||
% License page
|
% License header
|
||||||
% --------------------------------------------------------------------------------------
|
% --------------------------------------------------------------------------------------
|
||||||
|
|
||||||
\setcounter{page}{2}
|
\setcounter{page}{2}
|
||||||
\vspace*{\fill} % fill the page so that text is at the bottom
|
\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
|
Permission is granted to copy, distribute and/or modify this document
|
||||||
under the terms of the GNU Free Documentation License, Version 1.3
|
under the terms of the GNU Free Documentation License, Version 1.3
|
||||||
or any later version published by the Free Software Foundation;
|
or any later version published by the Free Software Foundation;
|
||||||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
|
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
|
A copy of the license is included in the section entitled "GNU
|
||||||
Free Documentation License".
|
Free Documentation License".
|
||||||
|
|
||||||
\newpage
|
\newpage
|
||||||
|
|
||||||
|
@ -46,44 +46,44 @@ Free Documentation License".
|
||||||
|
|
||||||
\addcontentsline{toc}{chapter}{Abstract}
|
\addcontentsline{toc}{chapter}{Abstract}
|
||||||
|
|
||||||
The global trend is towards the scarcity of free software-compatible hardware,
|
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
|
and soon there will be no computer that will work without software domination
|
||||||
by big companies, especially involving firmware like BIOSes. \\
|
by big companies, especially involving firmware like BIOSes. \\
|
||||||
|
|
||||||
A Basic Input Output System
|
A Basic Input Output System
|
||||||
(BIOS) was originally a set of low-level functions contained in the read-only
|
(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
|
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
|
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,
|
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
|
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
|
operating system boot loader. Nowadays, the bulk of the BIOS work is the
|
||||||
initialization and training of RAM. This means, for example, initializing the
|
initialization and training of RAM. This means, for example, initializing the
|
||||||
memory controller and optimizing timing and read/write voltage for optimal
|
memory controller and optimizing timing and read/write voltage for optimal
|
||||||
performance, making the code complex, as its role is to optimize several
|
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
|
parallel buses operating at high speeds and shared by many CPU cores, and make
|
||||||
them act as a homogeneous whole. \\
|
them act as a homogeneous whole. \\
|
||||||
|
|
||||||
This document is the product of a project hosted by the \textit{LIP6 laboratory}
|
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
|
and supported by the \textit{GNU Boot Project} and the \textit{Free Software
|
||||||
Foundation}. It delves into the importance of firmware in the hardware
|
Foundation}. It delves into the importance of firmware in the hardware
|
||||||
initialization of modern computers and explores various aspects of firmware,
|
initialization of modern computers and explores various aspects of firmware,
|
||||||
such as Intel Management Engine (ME), AMD Platform Security Processor (PSP),
|
such as Intel Management Engine (ME), AMD Platform Security Processor (PSP),
|
||||||
Advanced Configuration and Power Interface (ACPI), and System Management Mode
|
Advanced Configuration and Power Interface (ACPI), and System Management Mode
|
||||||
(SMM). Additionally, it provides an in-depth look at memory initialization and
|
(SMM). Additionally, it provides an in-depth look at memory initialization and
|
||||||
training algorithms, highlighting their critical role in system stability
|
training algorithms, highlighting their critical role in system stability
|
||||||
and performance. Examples of the implementation in the ASUS KGPE-D16 mainboard are
|
and performance. Examples of the implementation in the ASUS KGPE-D16 mainboard are
|
||||||
presented, describing its hardware characteristics, topology, and the crucial role
|
presented, describing its hardware characteristics, topology, and the crucial role
|
||||||
of firmware in its operation after the mainboard architecture is examined.
|
of firmware in its operation after the mainboard architecture is examined.
|
||||||
Practical examples illustrate the impact of firmware on hardware
|
Practical examples illustrate the impact of firmware on hardware
|
||||||
initialization, memory optimization, resource allocation, power management,
|
initialization, memory optimization, resource allocation, power management,
|
||||||
and security. Specific algorithms used for memory training and their outcomes
|
and security. Specific algorithms used for memory training and their outcomes
|
||||||
are analyzed to demonstrate the complexity and importance of firmware in
|
are analyzed to demonstrate the complexity and importance of firmware in
|
||||||
achieving optimal system performance.
|
achieving optimal system performance.
|
||||||
Furthermore, this document explores the relationship between firmware and
|
Furthermore, this document explores the relationship between firmware and
|
||||||
hardware virtualization, discussing how modern firmware supports and enhances
|
hardware virtualization, discussing how modern firmware supports and enhances
|
||||||
virtualized environments. Security considerations and future trends in
|
virtualized environments. Security considerations and future trends in
|
||||||
firmware development are also addressed, emphasizing the need for continued
|
firmware development are also addressed, emphasizing the need for continued
|
||||||
research and advocacy for free software-compatible hardware.
|
research and advocacy for free software-compatible hardware.
|
||||||
|
|
||||||
\chapter{Introduction to firmware and BIOS evolution}
|
\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}
|
\chapter{Characteristics of ASUS KGPE-D16 mainboard}
|
||||||
|
|
||||||
\begin{figure}[H]
|
\begin{figure}[H]
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=0.9\textwidth]{images/kgpe-d16.png}
|
\includegraphics[width=0.9\textwidth]{images/kgpe-d16.png}
|
||||||
\caption{The KGPE-D16 (CC BY-SA 4.0, 2021)}
|
\caption{The KGPE-D16 (CC BY-SA 4.0, 2021)}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
\newpage
|
\newpage
|
||||||
|
|
||||||
\section{Overview of ASUS KGPE-D16 hardware}
|
\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})
|
(fig. \ref{fig:opteron2600}, \ref{fig:opteron2600_diagram})
|
||||||
\cite{amd_6200}\cite{anandtech_bulldozer}.
|
\cite{amd_6200}\cite{anandtech_bulldozer}.
|
||||||
|
|
||||||
The architecture of the Opteron 6200 series is built around AMD's Bulldozer core
|
The architecture of the Opteron 6200 series is built around AMD's Bulldozer core
|
||||||
design, which uses Clustered Multithreading (CMT) to maximize resource
|
design, which uses Clustered Multithreading (CMT) to maximize resource
|
||||||
utilization. This is a technique where each processor
|
utilization. This is a technique where each processor
|
||||||
module contains two integer cores that share certain resources like the
|
module contains two integer cores that share certain resources like the
|
||||||
floating-point unit (FPU), L2 cache, and instruction fetch/decode stages. Unlike
|
floating-point unit (FPU), L2 cache, and instruction fetch/decode stages. Unlike
|
||||||
traditional multithreading, where each core handles multiple threads, CMT allows
|
traditional multithreading, where each core handles multiple threads, CMT allows
|
||||||
two cores to share resources to improve parallel processing efficiency. This
|
two cores to share resources to improve parallel processing efficiency. This
|
||||||
approach aims to balance performance and resource usage, particularly in multi-
|
approach aims to balance performance and resource usage, particularly in multi-
|
||||||
threaded workloads, though it can lead to some performance trade-offs in
|
threaded workloads, though it can lead to some performance trade-offs in
|
||||||
single-threaded tasks.
|
single-threaded tasks.
|
||||||
In the Opteron 6272, the processor consists of eight modules, effectively
|
In the Opteron 6272, the processor consists of eight modules, effectively
|
||||||
creating 16 integer cores. Due to the CMT architecture, each Opteron 6272 chip
|
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,
|
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
|
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
|
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.
|
two integer cores. The L3 cache is shared across these modules.
|
||||||
HyperTransport links provide high-speed communication between the two sockets of
|
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
|
the KGPE-D16. Shared L3 cache and direct memory access are provided by each
|
||||||
socket \cite{amd_6200}\cite{hill_impact_caching}. \\
|
socket \cite{amd_6200}\cite{hill_impact_caching}. \\
|
||||||
|
|
||||||
This architecture also integrates a quad-channel DDR3 memory controller directly
|
This architecture also integrates a quad-channel DDR3 memory controller directly
|
||||||
into the processor die, which facilitates high bandwidth and low latency access
|
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
|
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
|
connects directly to the memory modules via the memory bus. By integrating the
|
||||||
memory controller into the processor, the Opteron 6200 series reduces memory
|
memory controller into the processor, the Opteron 6200 series reduces memory
|
||||||
access latency, enhancing overall performance
|
access latency, enhancing overall performance
|
||||||
\cite{amd_6200}Is \cite{amd_ddr3_guide}. It is interesting to note that Opterons
|
\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
|
incorporate the internal northbridge that we cited previously. The traditional
|
||||||
northbridge functions, such as memory controller and PCIe interface management,
|
northbridge functions, such as memory controller and PCIe interface management,
|
||||||
are partially integrated into the processor. This integration reduces the
|
are partially integrated into the processor. This integration reduces the
|
||||||
distance data must travel between the CPU and memory, decreasing latency and
|
distance data must travel between the CPU and memory, decreasing latency and
|
||||||
improving performance, particularly in memory-intensive applications
|
improving performance, particularly in memory-intensive applications
|
||||||
\cite{amd_6200}. \\
|
\cite{amd_6200}. \\
|
||||||
|
|
||||||
|
|
||||||
\begin{figure}[H]
|
\begin{figure}[H]
|
||||||
|
@ -602,17 +602,17 @@ research and advocacy for free software-compatible hardware.
|
||||||
\label{fig:opteron2600_diagram}
|
\label{fig:opteron2600_diagram}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
Power efficiency was a key focus in the design of the Opteron 6200 series.
|
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
|
Despite the high core count, the processor includes several power management
|
||||||
features, such as Dynamic Power Management (DPM) and Turbo Core technology. These
|
features, such as Dynamic Power Management (DPM) and Turbo Core technology. These
|
||||||
features allow the processor to adjust power usage based on workload demands,
|
features allow the processor to adjust power usage based on workload demands,
|
||||||
balancing performance with energy consumption. However, the Bulldozer
|
balancing performance with energy consumption. However, the Bulldozer
|
||||||
architecture's focus on high clock speeds and multi-threaded performance resulted
|
architecture's focus on high clock speeds and multi-threaded performance resulted
|
||||||
in higher power consumption compared to competing architectures
|
in higher power consumption compared to competing architectures
|
||||||
\cite{anandtech_bulldozer}. A special model of the series,
|
\cite{anandtech_bulldozer}. A special model of the series,
|
||||||
called \textit{high efficiency} models, solve a bit this problem by proposing
|
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
|
a bit less performant processor but with a power consumption divided by a factor
|
||||||
from 1.5 to 2.0 in some cases. \\
|
from 1.5 to 2.0 in some cases. \\
|
||||||
|
|
||||||
The processor connected to the I/O hub is known as the Bootstrap
|
The processor connected to the I/O hub is known as the Bootstrap
|
||||||
Processor (BSP).
|
Processor (BSP).
|
||||||
|
@ -630,144 +630,162 @@ research and advocacy for free software-compatible hardware.
|
||||||
deciding which initialization procedures need to be executed
|
deciding which initialization procedures need to be executed
|
||||||
\cite{amd_bsp}\cite{BKDG}.
|
\cite{amd_bsp}\cite{BKDG}.
|
||||||
|
|
||||||
\section{Baseboard Management Controller}
|
\section{Baseboard Management Controller}
|
||||||
|
|
||||||
The Baseboard Management Controller (BMC) on the KGPE-D16 motherboard,
|
The Baseboard Management Controller (BMC) on the KGPE-D16 motherboard,
|
||||||
specifically the ASpeed AST2050, plays a role in the server's
|
specifically the ASpeed AST2050, plays a role in the server's
|
||||||
architecture by managing out-of-band communication and control of the hardware.
|
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
|
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 designed for embedded systems \cite{ast2050_architecture}. This
|
||||||
architecture is well-suited for BMCs due to its efficiency and capability to
|
architecture is well-suited for BMCs due to its efficiency and capability to
|
||||||
handle multiple management tasks concurrently without significant resource
|
handle multiple management tasks concurrently without significant resource
|
||||||
demands from the main system. \\
|
demands from the main system. \\
|
||||||
|
|
||||||
The AST2050 features several key components that contribute to its functionality.
|
The AST2050 features several key components that contribute to its functionality.
|
||||||
It includes an integrated VGA controller, which enables remote graphical
|
It includes an integrated VGA controller, which enables remote graphical
|
||||||
management through KVM-over-IP (Keyboard, Video, Mouse), a critical feature for
|
management through KVM-over-IP (Keyboard, Video, Mouse), a critical feature for
|
||||||
administrators who need to interact with the system remotely, including BIOS
|
administrators who need to interact with the system remotely, including BIOS
|
||||||
updates and troubleshooting \cite{ast2050_kvm}. Additionally, the AST2050
|
updates and troubleshooting \cite{ast2050_kvm}. Additionally, the AST2050
|
||||||
integrates a dedicated memory controller, which supports up to 256MB of DDR2 RAM.
|
integrates a dedicated memory controller, which supports up to 256MB of DDR2 RAM.
|
||||||
This allows it to handle complex tasks and maintain responsiveness during
|
This allows it to handle complex tasks and maintain responsiveness during
|
||||||
management operations \cite{ast2050_memory}.
|
management operations \cite{ast2050_memory}.
|
||||||
The BMC also features a network interface controller (NIC) dedicated to
|
The BMC also features a network interface controller (NIC) dedicated to
|
||||||
management traffic, ensuring that remote management does not interfere with the
|
management traffic, ensuring that remote management does not interfere with the
|
||||||
primary network traffic of the server. This separation is vital for maintaining
|
primary network traffic of the server. This separation is vital for maintaining
|
||||||
secure and uninterrupted system management, especially in environments where
|
secure and uninterrupted system management, especially in environments where
|
||||||
uptime is critical \cite{ast2050_nic}.
|
uptime is critical \cite{ast2050_nic}.
|
||||||
Another important architectural aspect of the AST2050 is its support for multiple
|
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
|
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
|
with various sensors and peripherals on the motherboard \cite{ast2050_io}. This
|
||||||
versatility enables comprehensive monitoring of hardware health, such as
|
versatility enables comprehensive monitoring of hardware health, such as
|
||||||
temperature sensors, fan speeds, and power supplies, all of which can be managed
|
temperature sensors, fan speeds, and power supplies, all of which can be managed
|
||||||
and configured through the BMC. \\
|
and configured through the BMC. \\
|
||||||
|
|
||||||
When combined with OpenBMC \cite{openbmc_wiki}, a libre firmware that can be
|
When combined with OpenBMC \cite{openbmc_wiki}, a libre firmware that can be
|
||||||
run on the AST2050 thanks to Raptor Engineering \cite{raptor_engineering},
|
run on the AST2050 thanks to Raptor Engineering \cite{raptor_engineering},
|
||||||
the architecture of the BMC becomes even more powerful. OpenBMC takes
|
the architecture of the BMC becomes even more powerful. OpenBMC takes
|
||||||
advantage of the AST2050's architecture, providing a flexible and
|
advantage of the AST2050's architecture, providing a flexible and
|
||||||
customizable environment that can be tailored to specific use cases. This
|
customizable environment that can be tailored to specific use cases. This
|
||||||
includes adding or modifying features related to security, logging, and network
|
includes adding or modifying features related to security, logging, and network
|
||||||
management, all within the BMC's ARM architecture framework
|
management, all within the BMC's ARM architecture framework
|
||||||
\cite{openbmc_customization}.
|
\cite{openbmc_customization}.
|
||||||
|
|
||||||
|
|
||||||
\chapter{Key components in modern firmware [WIP]}
|
\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
|
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
|
and optimization of the mainboard's hardware components. For this to be done
|
||||||
efficiently, \textit{coreboot} is organized in different stages (fig.
|
efficiently, \textit{coreboot} is organized in different stages (fig.
|
||||||
\ref{fig:coreboot_stages}) \cite{coreboot_docs}.
|
\ref{fig:coreboot_stages}) \cite{coreboot_docs}.
|
||||||
|
|
||||||
\begin{figure}[H]
|
\begin{figure}[H]
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=0.9\textwidth]{
|
\includegraphics[width=0.9\textwidth]{
|
||||||
images/fig9_coreboot_stages.png}
|
images/fig9_coreboot_stages.png}
|
||||||
\caption{\textit{coreboot}'s stages timeline, by \textit{coreboot} project (CC BY-SA 4.0, 2009)}
|
\caption{\textit{coreboot}'s stages timeline, by \textit{coreboot} project (CC BY-SA 4.0, 2009)}
|
||||||
\label{fig:coreboot_stages}
|
\label{fig:coreboot_stages}
|
||||||
\end{figure}
|
\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}
|
|
||||||
|
|
||||||
The \textbf{bootblock} is the first stage executed after the CPU reset.
|
Being a complex project with ambitious goals, \textit{coreboot} decided early on
|
||||||
The beginning of this stage is written in assembly language, and its main task is
|
to establish an file-system-based architecture for its images (also called ROMs).
|
||||||
to set everything up for a C environment. The rest, of course, is written in C.
|
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
|
\begin{figure}[H]
|
||||||
alignment, and the offset of the start of the first CBFS component in the ROM.
|
\centering
|
||||||
This block is a mandatory component of the ROM as it also contains the entry
|
\includegraphics[width=0.8\textwidth]{
|
||||||
point of the firmware. \\
|
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
|
Upon startup, this stage is responsible for the initial hardware setup, which
|
||||||
involves identifying and configuring the CPU. This process is particularly
|
involves identifying and configuring the CPU. This process is particularly
|
||||||
significant for AMD Family 10h/15h processors, where the firmware sets up the
|
significant for AMD Family 10h/15h processors, where the firmware sets up the
|
||||||
Bootstrap Processor (BSP) and executes the necessary initialization routines.
|
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
|
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
|
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
|
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
|
not available yet. This is done by programming the Memory Type Range
|
||||||
Registers} (MTRRs), which define how different ranges of system memory are
|
Registers (MTRRs), which define how different ranges of system memory are
|
||||||
accessed, such as whether they are cacheable or non-cacheable, used to optimize
|
accessed such as whether they are cacheable or non-cacheable, used to optimize
|
||||||
memory performance on normal operation.
|
memory performance on normal operation \cite{BKDG}.
|
||||||
The firmware will then set the stack pointer, allocate memory for the BSS, and
|
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
|
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
|
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
|
real mode to 32-bit protected mode. The bootblock is responsible for
|
||||||
loading the romstage, or the verstage if verified boot is enabled.
|
loading the romstage, or the verstage if verified boot is enabled
|
||||||
|
\cite{coreboot_docs}.
|
||||||
|
|
||||||
\subsection{Romstage}
|
\subsection{Romstage}
|
||||||
|
|
||||||
The firmware also configures the Advanced Programmable Interrupt Controller
|
The purpose of the romstage is the early initialization of peripherals,
|
||||||
(APIC), which manages how the processor handles interrupts to ensure
|
particularly system memory. The firmware also configures the Advanced
|
||||||
the system can respond efficiently to hardware and
|
Programmable Interrupt Controller (APIC), responsible in handling interrupts
|
||||||
software events. Lastly, it sets up the routing for HyperTransport (HT)
|
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
|
technology, a high-speed communication protocol used for data exchange between
|
||||||
the processor and the northbridge, ensuring that data flows smoothly
|
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
|
Memory training and optimization are key functions of the firmware. During this
|
||||||
process, the firmware adjusts memory settings, such as timings, frequencies, and
|
process, the firmware adjusts memory settings, such as timings, frequencies, and
|
||||||
voltages, to ensure that the installed memory modules operate efficiently and
|
voltages, to ensure that the installed memory modules operate efficiently and
|
||||||
stably. This step is crucial for achieving optimal performance, especially when
|
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
|
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}
|
\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
|
Effective resource allocation is essential for system stability, particularly in
|
||||||
complex configurations involving multiple CPUs and peripherals. The firmware
|
complex configurations involving multiple CPUs and peripherals. The firmware
|
||||||
manages resource allocation, resolving any conflicts between hardware components
|
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
|
maintain the integrity of its operations. This includes support for IOMMU, which
|
||||||
is crucial for preventing unauthorized direct memory access (DMA) attacks,
|
is crucial for preventing unauthorized direct memory access (DMA) attacks,
|
||||||
particularly in virtualized environments.
|
particularly in virtualized environments.
|
||||||
|
|
||||||
\subsection{Payload}
|
\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}
|
\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.
|
to permit their use in free software.
|
||||||
|
|
||||||
\end{document}
|
\end{document}
|
||||||
|
|
||||||
|
|
|
@ -1,38 +1,38 @@
|
||||||
\babel@toc {english}{}\relax
|
\babel@toc {english}{}\relax
|
||||||
\contentsline {chapter}{Abstract}{5}{chapter*.1}%
|
\contentsline {chapter}{Abstract}{4}{chapter*.1}%
|
||||||
\contentsline {chapter}{\numberline {1}Introduction to firmware and BIOS evolution}{6}{chapter.1}%
|
\contentsline {chapter}{\numberline {1}Introduction to firmware and BIOS evolution}{5}{chapter.1}%
|
||||||
\contentsline {section}{\numberline {1.1}Historical context of BIOS}{6}{section.1.1}%
|
\contentsline {section}{\numberline {1.1}Historical context of BIOS}{5}{section.1.1}%
|
||||||
\contentsline {subsection}{\numberline {1.1.1}Definition and origin}{6}{subsection.1.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}{7}{subsection.1.1.2}%
|
\contentsline {subsection}{\numberline {1.1.2}Functionalities and limitations}{6}{subsection.1.1.2}%
|
||||||
\contentsline {section}{\numberline {1.2}Modern BIOS and UEFI}{8}{section.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)}{8}{subsection.1.2.1}%
|
\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}}{8}{subsection.1.2.2}%
|
\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}{10}{section.1.3}%
|
\contentsline {section}{\numberline {1.3}Shift in firmware responsibilities}{9}{section.1.3}%
|
||||||
\contentsline {chapter}{\numberline {2}Characteristics of ASUS KGPE-D16 mainboard}{11}{chapter.2}%
|
\contentsline {chapter}{\numberline {2}Characteristics of ASUS KGPE-D16 mainboard}{10}{chapter.2}%
|
||||||
\contentsline {section}{\numberline {2.1}Overview of ASUS KGPE-D16 hardware}{12}{section.2.1}%
|
\contentsline {section}{\numberline {2.1}Overview of ASUS KGPE-D16 hardware}{11}{section.2.1}%
|
||||||
\contentsline {section}{\numberline {2.2}Chipset}{13}{section.2.2}%
|
\contentsline {section}{\numberline {2.2}Chipset}{12}{section.2.2}%
|
||||||
\contentsline {section}{\numberline {2.3}Processors}{15}{section.2.3}%
|
\contentsline {section}{\numberline {2.3}Processors}{14}{section.2.3}%
|
||||||
\contentsline {section}{\numberline {2.4}Baseboard Management Controller}{16}{section.2.4}%
|
\contentsline {section}{\numberline {2.4}Baseboard Management Controller}{15}{section.2.4}%
|
||||||
\contentsline {chapter}{\numberline {3}Key components in modern firmware [WIP]}{18}{chapter.3}%
|
\contentsline {chapter}{\numberline {3}Key components in modern firmware [WIP]}{17}{chapter.3}%
|
||||||
\contentsline {section}{\numberline {3.1}General structure of coreboot}{18}{section.3.1}%
|
\contentsline {section}{\numberline {3.1}General structure of coreboot}{17}{section.3.1}%
|
||||||
\contentsline {subsection}{\numberline {3.1.1}Bootblock stage}{19}{subsection.3.1.1}%
|
\contentsline {subsection}{\numberline {3.1.1}Bootblock stage}{18}{subsection.3.1.1}%
|
||||||
\contentsline {subsection}{\numberline {3.1.2}Romstage}{19}{subsection.3.1.2}%
|
\contentsline {subsection}{\numberline {3.1.2}Romstage}{18}{subsection.3.1.2}%
|
||||||
\contentsline {subsection}{\numberline {3.1.3}Ramstage}{20}{subsection.3.1.3}%
|
\contentsline {subsection}{\numberline {3.1.3}Ramstage}{19}{subsection.3.1.3}%
|
||||||
\contentsline {subsection}{\numberline {3.1.4}Payload}{20}{subsection.3.1.4}%
|
\contentsline {subsection}{\numberline {3.1.4}Payload}{19}{subsection.3.1.4}%
|
||||||
\contentsline {section}{\numberline {3.2}Advanced Configuration and Power Interface}{20}{section.3.2}%
|
\contentsline {section}{\numberline {3.2}Advanced Configuration and Power Interface}{19}{section.3.2}%
|
||||||
\contentsline {section}{\numberline {3.3}System Management Mode}{21}{section.3.3}%
|
\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 {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 {chapter}{\numberline {4}Memory initialization and training algorithms [WIP]}{22}{chapter.4}%
|
||||||
\contentsline {section}{\numberline {4.1}Importance of memory initialization}{23}{section.4.1}%
|
\contentsline {section}{\numberline {4.1}Importance of memory initialization}{22}{section.4.1}%
|
||||||
\contentsline {section}{\numberline {4.2}Memory training algorithms}{23}{section.4.2}%
|
\contentsline {section}{\numberline {4.2}Memory training algorithms}{22}{section.4.2}%
|
||||||
\contentsline {section}{\numberline {4.3}Practical examples}{24}{section.4.3}%
|
\contentsline {section}{\numberline {4.3}Practical examples}{23}{section.4.3}%
|
||||||
\contentsline {chapter}{\numberline {5}Firmware and hardware virtualization [WIP]}{25}{chapter.5}%
|
\contentsline {chapter}{\numberline {5}Firmware and hardware virtualization [WIP]}{24}{chapter.5}%
|
||||||
\contentsline {section}{\numberline {5.1}Introduction to hardware virtualization}{25}{section.5.1}%
|
\contentsline {section}{\numberline {5.1}Introduction to hardware virtualization}{24}{section.5.1}%
|
||||||
\contentsline {section}{\numberline {5.2}Role of BIOS/UEFI in virtualization}{25}{section.5.2}%
|
\contentsline {section}{\numberline {5.2}Role of BIOS/UEFI in virtualization}{24}{section.5.2}%
|
||||||
\contentsline {section}{\numberline {5.3}Security and freedom considerations}{25}{section.5.3}%
|
\contentsline {section}{\numberline {5.3}Security and freedom considerations}{24}{section.5.3}%
|
||||||
\contentsline {section}{\numberline {5.4}Future trends in firmware and virtualization}{25}{section.5.4}%
|
\contentsline {section}{\numberline {5.4}Future trends in firmware and virtualization}{24}{section.5.4}%
|
||||||
\contentsline {chapter}{Conclusion}{26}{chapter*.2}%
|
\contentsline {chapter}{Conclusion}{25}{chapter*.2}%
|
||||||
\contentsline {section}{\numberline {5.5}Summary of key points}{26}{section.5.5}%
|
\contentsline {section}{\numberline {5.5}Summary of key points}{25}{section.5.5}%
|
||||||
\contentsline {section}{\numberline {5.6}Call for action}{26}{section.5.6}%
|
\contentsline {section}{\numberline {5.6}Call for action}{25}{section.5.6}%
|
||||||
\contentsline {chapter}{Bibliography}{27}{section.5.6}%
|
\contentsline {chapter}{Bibliography}{26}{section.5.6}%
|
||||||
\contentsline {chapter}{GNU Free Documentation License}{32}{chapter*.4}%
|
\contentsline {chapter}{GNU Free Documentation License}{31}{chapter*.4}%
|
||||||
|
|
|
@ -0,0 +1,4 @@
|
||||||
|
void main(int a, int b)
|
||||||
|
{
|
||||||
|
return 0;
|
||||||
|
}
|
16
packages.tex
16
packages.tex
|
@ -13,9 +13,11 @@
|
||||||
\usepackage[T1]{fontenc}
|
\usepackage[T1]{fontenc}
|
||||||
\usepackage[english]{babel}
|
\usepackage[english]{babel}
|
||||||
\usepackage{graphicx}
|
\usepackage{graphicx}
|
||||||
\usepackage{listings}
|
\usepackage{listing}
|
||||||
|
\usepackage{minted}
|
||||||
\usepackage{xcolor}
|
\usepackage{xcolor}
|
||||||
\usepackage{chngcntr}
|
\usepackage{chngcntr}
|
||||||
|
\usepackage{changepage}
|
||||||
\usepackage[a4paper, portrait, margin=1.45cm]{geometry}
|
\usepackage[a4paper, portrait, margin=1.45cm]{geometry}
|
||||||
\title{Titre du mémoire}
|
\title{Titre du mémoire}
|
||||||
\author{Nom et prénom de l'auteur}
|
\author{Nom et prénom de l'auteur}
|
||||||
|
@ -45,4 +47,14 @@
|
||||||
\renewcommand{\cftchapafterpnum}{\vspace{\cftbeforechapskip}}
|
\renewcommand{\cftchapafterpnum}{\vspace{\cftbeforechapskip}}
|
||||||
\renewcommand{\familydefault}{\sfdefault}
|
\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
|
||||||
|
}
|
||||||
|
|
Loading…
Reference in New Issue