WIP
This commit is contained in:
parent
46e774a62c
commit
312b458ec5
GPG Key ID:
57BC26A3687116F6
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:
|
||||
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
|
||||
|
|
|
|||
Binary file not shown.
|
|
@ -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}
|
||||
|
||||
|
|
@ -695,11 +695,11 @@ research and advocacy for free software-compatible hardware.
|
|||
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}). \\
|
||||
boundary (fig. \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.
|
||||
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). \\
|
||||
|
||||
|
|
@ -713,7 +713,7 @@ research and advocacy for free software-compatible hardware.
|
|||
\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
|
||||
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
|
||||
|
|
@ -722,52 +722,70 @@ research and advocacy for free software-compatible hardware.
|
|||
|
||||
\subsection{Bootblock stage}
|
||||
|
||||
The \textbf{bootblock} is the first stage executed after the CPU reset.
|
||||
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.
|
||||
\\
|
||||
|
||||
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. \\
|
||||
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
|
||||
|
|
@ -789,6 +807,16 @@ research and advocacy for free software-compatible hardware.
|
|||
|
||||
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}
|
||||
|
||||
The Advanced Configuration and Power Interface (ACPI) is a critical component
|
||||
|
|
@ -1587,3 +1615,4 @@ free software license, such as the GNU General Public License,
|
|||
to permit their use in free software.
|
||||
|
||||
\end{document}
|
||||
|
||||
|
|
|
|||
|
|
@ -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}%
|
||||
|
|
|
|||
|
|
@ -0,0 +1,4 @@
|
|||
void main(int a, int b)
|
||||
{
|
||||
return 0;
|
||||
}
|
||||
14
packages.tex
14
packages.tex
|
|
@ -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}
|
||||
|
|
@ -46,3 +48,13 @@
|
|||
\renewcommand{\familydefault}{\sfdefault}
|
||||
|
||||
\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