diff --git a/bibliographie.bib b/bibliographie.bib index aedd2e4..a9ef0a8 100644 --- a/bibliographie.bib +++ b/bibliographie.bib @@ -1156,3 +1156,61 @@ note = "[Online; accessed 17-August-2024]" pages={210-225}, year={2019} } + +@misc{burnett_ddr3, + author = {Jon Burnett}, + title = {DDR3 Design Considerations for PCB Applications (AN111)}, + year = {2009}, + month = {July}, + howpublished = {Presentation at Freescale Technology Forum}, + note = {Freescale Semiconductor, Inc.}, +} + +@inproceedings{kim2010design, + author = {Kim, Dong-Seok and Oh, Dong-Seok and Lee, Seok-Hoon}, + title = {Design DDR3 ZQ Calibration having improved impedance matching}, + booktitle = {Proceedings of the 2010 Fall Conference on Semiconductor and Display Technology}, + year = {2010}, + address = {Seoul, South Korea}, + pages = {191-192}, + publisher = {Hanyang University}, + note = {Retrieved from https://koreascience.kr/article/CFKO200835536002505.pdf} +} + +@mastersthesis{gopikrishna2021novel, + title = {A Novel Impedance Calibration Method for Low Cost Memory Applications}, + author = {Gopikrishna, Siddula}, + year = {2021}, + school = {International Institute of Information Technology, Hyderabad}, + type = {Master of Science Thesis}, + address = {Hyderabad, India}, + month = {February}, + url = {https://cdn.iiit.ac.in/cdn/web2py.iiit.ac.in/research_centres/publications/download/mastersthesis.pdf.a761b452d5c4ae57.476f70696b726973686e615f4d537468657369735f3230303935303034392e706466.pdf}, + note = {Accessed: 2024-08-24} +} + +@misc{osdev_uefi_memory, + author = "{OSDev Wiki contributors}", + title = "{UEFI - OSDev Wiki}", + year = "2024", + url = "https://wiki.osdev.org/UEFI#Memory", + note = "[Online; accessed 25-August-2024]" +} + +@manual{intel_acpi_introduction_2023, + title = {Introduction to ACPI}, + author = {Intel Corporation}, + year = {2023}, + month = {April}, + note = {Accessed: 2024-08-24}, + url = {https://cdrdv2.intel.com/v1/dl/getContent/772721} +} + +@manual{intel_acpi_programming_2023, + title = {ACPI Programming Reference}, + author = {Intel Corporation}, + year = {2023}, + month = {April}, + note = {Accessed: 2024-08-24}, + url = {https://cdrdv2.intel.com/v1/dl/getContent/772726} +} diff --git a/hardware_init_review.bbl b/hardware_init_review.bbl index ba62c88..f24c138 100644 --- a/hardware_init_review.bbl +++ b/hardware_init_review.bbl @@ -139,7 +139,6 @@ \field{number}{AN-520-1.0} \field{title}{DDR3 SDRAM Memory Interface Termination and Layout Guidelines} \field{year}{2008} - \true{nocite} \endentry \entry{amd_ddr3_guide}{manual}{} \name{author}{1}{}{% @@ -531,6 +530,30 @@ \field{pages}{45\bibrangedash 56} \range{pages}{12} \endentry + \entry{burnett_ddr3}{misc}{} + \name{author}{1}{}{% + {{hash=70ed1943e8d3a50c06615ef57a082097}{% + family={Burnett}, + familyi={B\bibinitperiod}, + given={Jon}, + giveni={J\bibinitperiod}}}% + } + \strng{namehash}{70ed1943e8d3a50c06615ef57a082097} + \strng{fullhash}{70ed1943e8d3a50c06615ef57a082097} + \strng{bibnamehash}{70ed1943e8d3a50c06615ef57a082097} + \strng{authorbibnamehash}{70ed1943e8d3a50c06615ef57a082097} + \strng{authornamehash}{70ed1943e8d3a50c06615ef57a082097} + \strng{authorfullhash}{70ed1943e8d3a50c06615ef57a082097} + \field{sortinit}{B} + \field{sortinithash}{d7095fff47cda75ca2589920aae98399} + \field{labelnamesource}{author} + \field{labeltitlesource}{title} + \field{howpublished}{Presentation at Freescale Technology Forum} + \field{month}{7} + \field{note}{Freescale Semiconductor, Inc.} + \field{title}{DDR3 Design Considerations for PCB Applications (AN111)} + \field{year}{2009} + \endentry \entry{chang2013}{article}{} \name{author}{2}{}{% {{hash=701500fa4f83c75c8ce39152916ce4e4}{% @@ -691,6 +714,37 @@ \verb https://doc.coreboot.org/memory-map.html \endverb \endentry + \entry{intel_acpi_programming_2023}{manual}{} + \name{author}{1}{}{% + {{hash=42af28f239d9ce2a4d0f9a032741150e}{% + family={Corporation}, + familyi={C\bibinitperiod}, + given={Intel}, + giveni={I\bibinitperiod}}}% + } + \strng{namehash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{fullhash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{bibnamehash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{authorbibnamehash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{authornamehash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{authorfullhash}{42af28f239d9ce2a4d0f9a032741150e} + \field{extraname}{1} + \field{sortinit}{C} + \field{sortinithash}{4d103a86280481745c9c897c925753c0} + \field{labelnamesource}{author} + \field{labeltitlesource}{title} + \field{month}{4} + \field{note}{Accessed: 2024-08-24} + \field{title}{ACPI Programming Reference} + \field{year}{2023} + \true{nocite} + \verb{urlraw} + \verb https://cdrdv2.intel.com/v1/dl/getContent/772726 + \endverb + \verb{url} + \verb https://cdrdv2.intel.com/v1/dl/getContent/772726 + \endverb + \endentry \entry{intel_acpi_spec}{book}{} \name{author}{1}{}{% {{hash=42af28f239d9ce2a4d0f9a032741150e}{% @@ -708,7 +762,7 @@ \strng{authorbibnamehash}{42af28f239d9ce2a4d0f9a032741150e} \strng{authornamehash}{42af28f239d9ce2a4d0f9a032741150e} \strng{authorfullhash}{42af28f239d9ce2a4d0f9a032741150e} - \field{extraname}{1} + \field{extraname}{2} \field{sortinit}{C} \field{sortinithash}{4d103a86280481745c9c897c925753c0} \field{labelnamesource}{author} @@ -736,7 +790,7 @@ \strng{authorbibnamehash}{42af28f239d9ce2a4d0f9a032741150e} \strng{authornamehash}{42af28f239d9ce2a4d0f9a032741150e} \strng{authorfullhash}{42af28f239d9ce2a4d0f9a032741150e} - \field{extraname}{2} + \field{extraname}{3} \field{sortinit}{C} \field{sortinithash}{4d103a86280481745c9c897c925753c0} \field{labelnamesource}{author} @@ -751,6 +805,37 @@ \verb https://software.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf \endverb \endentry + \entry{intel_acpi_introduction_2023}{manual}{} + \name{author}{1}{}{% + {{hash=42af28f239d9ce2a4d0f9a032741150e}{% + family={Corporation}, + familyi={C\bibinitperiod}, + given={Intel}, + giveni={I\bibinitperiod}}}% + } + \strng{namehash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{fullhash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{bibnamehash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{authorbibnamehash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{authornamehash}{42af28f239d9ce2a4d0f9a032741150e} + \strng{authorfullhash}{42af28f239d9ce2a4d0f9a032741150e} + \field{extraname}{4} + \field{sortinit}{C} + \field{sortinithash}{4d103a86280481745c9c897c925753c0} + \field{labelnamesource}{author} + \field{labeltitlesource}{title} + \field{month}{4} + \field{note}{Accessed: 2024-08-24} + \field{title}{Introduction to ACPI} + \field{year}{2023} + \true{nocite} + \verb{urlraw} + \verb https://cdrdv2.intel.com/v1/dl/getContent/772721 + \endverb + \verb{url} + \verb https://cdrdv2.intel.com/v1/dl/getContent/772721 + \endverb + \endentry \entry{intel_smm}{report}{} \name{author}{1}{}{% {{hash=42af28f239d9ce2a4d0f9a032741150e}{% @@ -765,7 +850,7 @@ \strng{authorbibnamehash}{42af28f239d9ce2a4d0f9a032741150e} \strng{authornamehash}{42af28f239d9ce2a4d0f9a032741150e} \strng{authorfullhash}{42af28f239d9ce2a4d0f9a032741150e} - \field{extraname}{3} + \field{extraname}{5} \field{sortinit}{C} \field{sortinithash}{4d103a86280481745c9c897c925753c0} \field{labelnamesource}{author} @@ -795,7 +880,7 @@ \strng{authorbibnamehash}{42af28f239d9ce2a4d0f9a032741150e} \strng{authornamehash}{42af28f239d9ce2a4d0f9a032741150e} \strng{authorfullhash}{42af28f239d9ce2a4d0f9a032741150e} - \field{extraname}{4} + \field{extraname}{6} \field{sortinit}{C} \field{sortinithash}{4d103a86280481745c9c897c925753c0} \field{labelnamesource}{author} @@ -818,7 +903,7 @@ \strng{authorbibnamehash}{91da9dc9e484daf8dc9ed72055907025} \strng{authornamehash}{91da9dc9e484daf8dc9ed72055907025} \strng{authorfullhash}{91da9dc9e484daf8dc9ed72055907025} - \field{extraname}{5} + \field{extraname}{7} \field{sortinit}{C} \field{sortinithash}{4d103a86280481745c9c897c925753c0} \field{labelnamesource}{author} @@ -1166,6 +1251,42 @@ \field{title}{Fire in the Valley: The Birth and Death of the Personal Computer} \field{year}{2000} \endentry + \entry{gopikrishna2021novel}{thesis}{} + \name{author}{1}{}{% + {{hash=9867142dbcfb52fac76189436d952c3c}{% + family={Gopikrishna}, + familyi={G\bibinitperiod}, + given={Siddula}, + giveni={S\bibinitperiod}}}% + } + \list{institution}{1}{% + {International Institute of Information Technology, Hyderabad}% + } + \list{location}{1}{% + {Hyderabad, India}% + } + \strng{namehash}{9867142dbcfb52fac76189436d952c3c} + \strng{fullhash}{9867142dbcfb52fac76189436d952c3c} + \strng{bibnamehash}{9867142dbcfb52fac76189436d952c3c} + \strng{authorbibnamehash}{9867142dbcfb52fac76189436d952c3c} + \strng{authornamehash}{9867142dbcfb52fac76189436d952c3c} + \strng{authorfullhash}{9867142dbcfb52fac76189436d952c3c} + \field{sortinit}{G} + \field{sortinithash}{32d67eca0634bf53703493fb1090a2e8} + \field{labelnamesource}{author} + \field{labeltitlesource}{title} + \field{month}{2} + \field{note}{Accessed: 2024-08-24} + \field{title}{A Novel Impedance Calibration Method for Low Cost Memory Applications} + \field{type}{Master of Science Thesis} + \field{year}{2021} + \verb{urlraw} + \verb https://cdn.iiit.ac.in/cdn/web2py.iiit.ac.in/research_centres/publications/download/mastersthesis.pdf.a761b452d5c4ae57.476f70696b726973686e615f4d537468657369735f3230303935303034392e706466.pdf + \endverb + \verb{url} + \verb https://cdn.iiit.ac.in/cdn/web2py.iiit.ac.in/research_centres/publications/download/mastersthesis.pdf.a761b452d5c4ae57.476f70696b726973686e615f4d537468657369735f3230303935303034392e706466.pdf + \endverb + \endentry \entry{blackhat_me_hack}{article}{} \name{author}{2}{}{% {{hash=e450be1043f8bd6abbfc1a479f2d7700}{% @@ -1419,7 +1540,6 @@ \field{number}{TN-41-02} \field{title}{Technical Note: DDR3 ZQ Calibration} \field{year}{2008} - \true{nocite} \endentry \entry{intel_me}{misc}{} \name{author}{1}{}{% @@ -1566,6 +1686,47 @@ \verb 10.1145/2851141.2851148 \endverb \endentry + \entry{kim2010design}{inproceedings}{} + \name{author}{3}{}{% + {{hash=8220787d0eaa6f1c680840bf616c1cf4}{% + family={Kim}, + familyi={K\bibinitperiod}, + given={Dong-Seok}, + giveni={D\bibinithyphendelim S\bibinitperiod}}}% + {{hash=296a3e46de4ab457e55baf6264bb8637}{% + family={Oh}, + familyi={O\bibinitperiod}, + given={Dong-Seok}, + giveni={D\bibinithyphendelim S\bibinitperiod}}}% + {{hash=f73fbd8e5fd85d5a4945843500511870}{% + family={Lee}, + familyi={L\bibinitperiod}, + given={Seok-Hoon}, + giveni={S\bibinithyphendelim H\bibinitperiod}}}% + } + \list{location}{1}{% + {Seoul, South Korea}% + } + \list{publisher}{1}{% + {Hanyang University}% + } + \strng{namehash}{c95e43f58c55dbd4375f1961197becbf} + \strng{fullhash}{c95e43f58c55dbd4375f1961197becbf} + \strng{bibnamehash}{c95e43f58c55dbd4375f1961197becbf} + \strng{authorbibnamehash}{c95e43f58c55dbd4375f1961197becbf} + \strng{authornamehash}{c95e43f58c55dbd4375f1961197becbf} + \strng{authorfullhash}{c95e43f58c55dbd4375f1961197becbf} + \field{sortinit}{K} + \field{sortinithash}{c02bf6bff1c488450c352b40f5d853ab} + \field{labelnamesource}{author} + \field{labeltitlesource}{title} + \field{booktitle}{Proceedings of the 2010 Fall Conference on Semiconductor and Display Technology} + \field{note}{Retrieved from https://koreascience.kr/article/CFKO200835536002505.pdf} + \field{title}{Design DDR3 ZQ Calibration having improved impedance matching} + \field{year}{2010} + \field{pages}{191\bibrangedash 192} + \range{pages}{2} + \endentry \entry{uefi_smm_security}{book}{} \name{author}{3}{}{% {{hash=0f5d712d2df5a2eb138c92b8957c02fe}{% @@ -1838,7 +1999,6 @@ \field{number}{TN-41-02} \field{title}{DDR3 SDRAM Specification Rev 1.4} \field{year}{2011} - \true{nocite} \endentry \entry{blobs}{misc}{} \name{author}{1}{}{% @@ -2347,6 +2507,33 @@ \verb https://wiki.osdev.org/GOP \endverb \endentry + \entry{osdev_uefi_memory}{misc}{} + \name{author}{1}{}{% + {{hash=981adb9ea98beb2d8a06e293991365f1}{% + family={{OSDev Wiki contributors}}, + familyi={O\bibinitperiod}}}% + } + \strng{namehash}{981adb9ea98beb2d8a06e293991365f1} + \strng{fullhash}{981adb9ea98beb2d8a06e293991365f1} + \strng{bibnamehash}{981adb9ea98beb2d8a06e293991365f1} + \strng{authorbibnamehash}{981adb9ea98beb2d8a06e293991365f1} + \strng{authornamehash}{981adb9ea98beb2d8a06e293991365f1} + \strng{authorfullhash}{981adb9ea98beb2d8a06e293991365f1} + \field{sortinit}{O} + \field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae} + \field{labelnamesource}{author} + \field{labeltitlesource}{title} + \field{note}{[Online; accessed 25-August-2024]} + \field{title}{{UEFI - OSDev Wiki}} + \field{year}{2024} + \true{nocite} + \verb{urlraw} + \verb https://wiki.osdev.org/UEFI#Memory + \endverb + \verb{url} + \verb https://wiki.osdev.org/UEFI#Memory + \endverb + \endentry \entry{pearson2014}{inproceedings}{} \name{author}{1}{}{% {{hash=0cb7f02abd4eddb75a923fdbd4722b97}{% @@ -2858,7 +3045,6 @@ \field{title}{Memory Errors in Modern Systems: The Good, The Bad, and The Ugly} \field{volume}{43} \field{year}{2015} - \true{nocite} \field{pages}{297\bibrangedash 310} \range{pages}{14} \endentry @@ -3339,7 +3525,6 @@ \field{note}{[Online; accessed 8-May-2024]} \field{title}{DDR3 SDRAM --- {Wikipedia}{,} The Free Encyclopedia} \field{year}{2024} - \true{nocite} \verb{urlraw} \verb https://en.wikipedia.org/w/index.php?title=DDR3_SDRAM&oldid=1207641521 \endverb @@ -3858,6 +4043,7 @@ \field{title}{Modern Boot Firmware: Moving from BIOS to UEFI} \field{volume}{39} \field{year}{2006} + \true{nocite} \field{pages}{42\bibrangedash 47} \range{pages}{6} \verb{doi} diff --git a/hardware_init_review.pdf b/hardware_init_review.pdf index 0f64c35..367b656 100644 Binary files a/hardware_init_review.pdf and b/hardware_init_review.pdf differ diff --git a/hardware_init_review.tex b/hardware_init_review.tex index 0f7e535..ae2f1d6 100644 --- a/hardware_init_review.tex +++ b/hardware_init_review.tex @@ -10,6 +10,10 @@ \input{packages.tex} +\title{Hardware initialization of modern computers} +\author{Adrien 'neox' Bourmault} +\date{\today} + % setup things \setcounter{secnumdepth}{4} \setcounter{tocdepth}{4} @@ -22,14 +26,13 @@ \begin{document}{ % ------------------------------------------------------------------------------ - \sloppy % allow flexible margins \input{titlepage.tex} % import titlepage \newpage -% -------------------------------------------------------------------------------------- +% ------------------------------------------------------------------------------ % License header -% -------------------------------------------------------------------------------------- +% ------------------------------------------------------------------------------ \setcounter{page}{2} \vspace*{\fill} % fill the page so that text is at the bottom @@ -48,13 +51,20 @@ \newpage -% Table of contents -\tableofcontents +% ------------------------------------------------------------------------------ +% ACKNOWLEDGMENTS +% ------------------------------------------------------------------------------ +\chapter*{Acknowledgments} +\addcontentsline{toc}{chapter}{Acknowledgments}} + +Thanks, I guess ? (TODO) \newpage +% ------------------------------------------------------------------------------ +% ABSTRACT +% ------------------------------------------------------------------------------ \chapter*{Abstract} - \addcontentsline{toc}{chapter}{Abstract} The global trend is towards the scarcity of free software-compatible @@ -87,7 +97,7 @@ 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 + 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 @@ -97,6 +107,27 @@ in firmware development are also addressed, emphasizing the need for continued research and advocacy for free software-compatible hardware. +\newpage + +% ------------------------------------------------------------------------------ +% Table of contents +% ------------------------------------------------------------------------------ +\tableofcontents +\newpage + +% List of figures +\addcontentsline{toc}{chapter}{List of Figures} +\listoffigures +\newpage + +% List of figures +\addcontentsline{toc}{chapter}{List of Listings} +\listoflistings +\newpage + +% ------------------------------------------------------------------------------ +% CHAPTER 1: Introduction to firmware and BIOS evolution +% ------------------------------------------------------------------------------ \chapter{Introduction to firmware and BIOS evolution} \section{Historical context of BIOS} @@ -117,10 +148,10 @@ Being a critical component for the startup of personal computers, acting as an intermediary between the computer's hardware and its operating system, the BIOS is embedded on a chip on the motherboard - and is the first code that runs when a PC is powered on. The concept + and is the first code that runs when a PC is powered on. The concept of BIOS has its roots in the early days of personal computing. It was first developed by IBM for their IBM PC, which was introduced - in 1981 \cite{freiberger2000fire}. The term BIOS itself was + in 1981 \cite{freiberger2000fire}. The term BIOS itself was coined by Gary Kildall, who developed the CP/M (Control Program for Microcomputers) operating system \cite{shustek2016kildall}. In CP/M, BIOS was used to describe a component that interfaced directly @@ -141,7 +172,7 @@ (PC), introduced in 1981. This architecture is characterized by the use of off-the-shelf components and publicly available specifications, which allowed other manufacturers to create compatible hardware - and software. It was in fact a departure from the proprietary + and software. It was in fact a departure from the proprietary systems prevalent at the time, where companies closely guarded their designs to maintain control over the hardware and software ecosystem. For example, IBM used the Intel 8088 CPU, a well-documented and widely @@ -167,10 +198,10 @@ This process ensures that all essential hardware components are operational before the system attempts to load the operating system. If any issues are detected, the BIOS generates error messages or - beep codes to alert the user. Following the successful completion + beep codes to alert the user. Following the successful completion of POST, the BIOS runs the bootstrap loader, a small program that identifies the operating system's bootloader on a storage device, - such as a hard drive, floppy disk, or optical drive. The bootstrap + such as a hard drive, floppy disk, or optical drive. The bootstrap loader then transfers control to the OS bootloader, initiating the process of loading the operating system into the computer's memory and starting it. This step effectively bridges the gap @@ -206,28 +237,28 @@ PC models, which included a limited set of peripherals and expansion options. As new hardware components and peripherals were developed, the BIOS often needed to be updated to support them, which was not - always feasible or timely. Performance bottlenecks were another + always feasible or timely. Performance bottlenecks were another limitation. The BIOS provided basic input/output operations that were often slower than direct hardware access methods. For example, disk I/O operations through BIOS interrupts were slower compared to later direct access methods provided by operating systems, resulting in performance bottlenecks, especially for disk-intensive operations. This inflexibility restricts the ability to support new - hardware and technologies efficiently\cite{anderson_2018}. Early BIOS + hardware and technologies efficiently\cite{anderson_2018}. Early BIOS implementations also had minimal security features. There were no mechanisms to verify the integrity of the BIOS code or to protect against unauthorized modifications, leaving systems vulnerable to attacks that could alter the BIOS and potentially compromise the - entire system, such as rootkits and firmware viruses. Added to that, + entire system, such as rootkits and firmware viruses. Added to that, the traditional BIOS operates in 16-bit real mode, a constraint that limits the amount of code and memory it can address. This limitation hinders the performance and complexity of firmware, making it less - suitable for modern computing needs \cite{intel_uefi}. Additionally, + suitable for modern computing needs \cite{intel_uefi}. Additionally, BIOS relies on the Master Boot Record (MBR) partitioning scheme, which supports a maximum disk size of 2 terabytes and allows only four primary partitions \cite{uefi_spec}\cite{russinovich2012}. This constraint has become a significant drawback as storage - capacities have increased. Furthermore, the traditional BIOS has + capacities have increased. Furthermore, the traditional BIOS has limited flexibility and is challenging to update or extend. This inflexibility restricts the ability to support new hardware and technologies efficiently \cite{anderson_2018}\cite{acmcs2015}. @@ -261,7 +292,7 @@ 32-bit and 64-bit modes, allowing it to address more memory and run more complex firmware programs. This capability enables UEFI to handle the increased demands of modern hardware and software - \cite{intel_uefi}\cite{shin2011}. Additionally, UEFI uses the GUID + \cite{intel_uefi}\cite{shin2011}. Additionally, UEFI uses the GUID Partition Table (GPT) instead of the MBR, supporting disks larger than 2 terabytes and allowing for a nearly unlimited number of partitions \cite{microsoft_uefi}\cite{russinovich2012}. @@ -271,7 +302,7 @@ thanks to its efficient hardware and software initialization processes. This improvement is particularly beneficial for systems with complex hardware configurations, where quick boot times - are essential \cite{intel_uefi}. UEFI's modular architecture + are essential \cite{intel_uefi}. UEFI's modular architecture makes it more extensible and easier to update compared to the traditional BIOS. This design allows for the addition of drivers, applications, and other components without requiring a complete @@ -294,7 +325,7 @@ computing systems, it is not without its critics. Some of the primary concerns about UEFI include its complexity, potential security vulnerabilities, and the degree of control it provides to hardware - manufacturers over the boot process. Originally known as LinuxBIOS, + manufacturers over the boot process. Originally known as LinuxBIOS, \textit{coreboot}, is a free firmware project initiated in 1999 by Ron Minnich and his team at the Los Alamos National Laboratory. The project's primary goal was to create a fast, lightweight, and @@ -310,21 +341,21 @@ as a bootloader or operating system kernel. This minimalist approach reduces the attack surface and potential for security vulnerabilities, as there is less code that could be exploited by malicious actors - \cite{rudolph2007}. Another significant benefit of \textit{coreboot} - is its libre nature. Unlike UEFI, which is controlled by a consortium + \cite{rudolph2007}. Another significant benefit of \textit{coreboot} + is its libre nature. Unlike UEFI, which is controlled by a consortium of hardware and software vendors, \textit{coreboot}'s source code is freely available and can be audited, modified, and improved by anyone. This transparency ensures that security researchers and developers can review the code for potential vulnerabilities and contribute to its improvement, fostering a community-driven approach - to firmware development\cite{coreboot}. This project also supports + to firmware development\cite{coreboot}. This project also supports a wide range of bootloaders, called payloads, allowing users to customize their boot process to suit their specific needs. Popular payloads include SeaBIOS, which provides legacy BIOS compatibility, and Tianocore, which offers UEFI functionality within the \textit{coreboot} - framework. This flexibility allows \textit{coreboot} to be used in + framework. This flexibility allows \textit{coreboot} to be used in a variety of environments, from embedded systems to high-performance - servers \cite{coreboot_payloads}. \\ + servers \cite{coreboot_payloads}. \\ \begin{figure}[H] \centering @@ -335,7 +366,7 @@ \end{figure} Despite its advantages, \textit{coreboot} is not without its - challenges. The project relies heavily on community contributions, and + challenges. The project relies heavily on community contributions, and support for new hardware often lags behind that of UEFI. Additionally, the minimalist design of \textit{coreboot} means that some advanced features provided by UEFI are not available by default. However, @@ -387,14 +418,14 @@ responsible for regulating data flow between the processor and memory modules. This includes configuring memory frequencies, voltage levels, and timing parameters to match the specifications of the installed - memory \cite{uefi_spec}\cite{BKDG}. Beyond memory management, + memory \cite{uefi_spec}\cite{BKDG}. Beyond memory management, firmware responsibilities have broadened to encompass a wide range of system-critical tasks. One key area is power management, where firmware is responsible for optimizing energy consumption across various components of the system. Efficient power management is essential not only for extending battery life in portable devices but also for reducing thermal output and ensuring system longevity - in desktop and server environments. Moreover, modern firmware takes + in desktop and server environments. Moreover, modern firmware takes on significant roles in hardware initialization and configuration, which were traditionally handled by the operating system. For example, the initialization of USB controllers, network interfaces, @@ -402,14 +433,14 @@ the early stages of the boot process. This shift ensures that the operating system can seamlessly interact with hardware from the moment it takes control, reducing boot times and improving overall - system reliability \cite{uefi_spec}. Security has also become a + system reliability \cite{uefi_spec}. Security has also become a paramount concern for modern firmware. UEFI (Unified Extensible Firmware Interface), which has largely replaced traditional BIOS in modern systems, includes features which prevents unauthorized or malicious software from loading during the boot process. This helps protect the system from rootkits and other low-level malware that could compromise the integrity of the operating system before - it even starts \cite{uefi_spec}. In the context of performance + it even starts \cite{uefi_spec}. In the context of performance tuning, firmware sometimes also plays a key role in enabling and managing overclocking, particularly for the memory subsystem. By allowing adjustments to memory frequencies, voltages, and timings, @@ -430,6 +461,9 @@ to study how modern firmware interact with hardware and also as a basis for improvements. +% ------------------------------------------------------------------------------ +% CHAPTER 2: Characteristics of ASUS KGPE-D16 mainboard +% ------------------------------------------------------------------------------ \chapter{Characteristics of ASUS KGPE-D16 mainboard} \begin{figure}[H] @@ -460,7 +494,7 @@ mainboard provides several SATA ports. Networking capabilities are enhanced by integrated dual gigabit Ethernet ports, which provide high-speed connectivity essential for data-intensive tasks and network - communication \cite{asus_kgpe_d16_manual}. Additionally, the board + communication \cite{asus_kgpe_d16_manual}. Additionally, the board is equipped with various peripheral interfaces, including USB ports, audio outputs, and other I/O ports, ensuring compatibility with a wide range of external devices. \\ @@ -504,7 +538,7 @@ handling the HyperTransport interface, a high-speed communication protocol used by AMD processors, and converting it to ALink and PCIe interfaces, which are crucial for connecting peripherals like graphics - cards \cite{SR5690BDG}. Additionally, the northbridge on the KGPE-D16 + cards \cite{SR5690BDG}. Additionally, the northbridge on the KGPE-D16 incorporates the IOMMU (Input-Output Memory Management Unit), which is crucial for ensuring secure and efficient memory access by I/O devices. The IOMMU allows for the virtualization of memory addresses, @@ -541,7 +575,7 @@ firmware \cite{winbond}. Meanwhile, the Nuvoton W83795G/ADG Hardware Monitor oversees the system’s health by monitoring temperatures, voltages, and fan speeds, ensuring that the system operates within - safe parameters \cite{nuvoton}. On the KGPE-D16, access to the Super + safe parameters \cite{nuvoton}. On the KGPE-D16, access to the Super I/O from a CPU core is done through the SR5690, then the SP5100, as that can be observed on the functional diagram of the chipset (fig. \ref{fig:d16_chipset}) \cite{SR5690BDG}. @@ -630,7 +664,7 @@ \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 + 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 @@ -643,7 +677,7 @@ 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). The BSP is responsible for starting up the system + Processor (BSP). The BSP is responsible for starting up the system by executing the initial firmware code from the reset vector, a specific memory address where the CPU begins execution after a reset \cite{amd_bsp}. Core 0 of the BSP, called the Bootstrap Core @@ -664,7 +698,7 @@ 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, + 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 @@ -672,13 +706,13 @@ main system. \\ The AST2050 features several key components that contribute to - its functionality. It includes an integrated VGA controller, + 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 + 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 @@ -702,6 +736,9 @@ related to security, logging, and network management, all within the BMC's ARM architecture framework \cite{openbmc_customization}. +% ------------------------------------------------------------------------------ +% CHAPTER 3: Key components in modern firmware +% ------------------------------------------------------------------------------ \chapter{Key components in modern firmware} \section{General structure of coreboot} @@ -1051,7 +1088,7 @@ \texttt{cache\_as\_ram\_main} and returns to \texttt{cache\_as\_ram\_setup} to finalize the process. - \texttt{coreboot} then transitions to the next stage, known as the + \textit{coreboot} then transitions to the next stage, known as the postcar stage, where it exits the cache-as-RAM mode and begins using physical RAM. @@ -1089,7 +1126,8 @@ the operating system (OS). Developed in 1996 by Intel, Microsoft, and Toshiba, ACPI replaced the older Advanced Power Management (APM) standard with more advanced and flexible power - management capabilities \cite{intel_acpi_spec}. At its core, + management capabilities \cite{intel_acpi_introduction_2023}. + At its core, ACPI is implemented through a series of data structures and executable code known as ACPI tables, which are provided by the system firmware and interpreted by the OS. These tables describe @@ -1326,38 +1364,801 @@ The ASUS KGPE-D16 mainboard does not include AMD PSP nor Intel ME. -\chapter{Memory initialization and training algorithms [WIP]} +% ------------------------------------------------------------------------------ +% CHAPTER 4: Memory initialization and training +% ------------------------------------------------------------------------------ +\chapter{Memory initialization and training} - \section{Importance of memory initialization} - \begin{itemize} - \item Steps involved in initializing the memory controller - \item Critical role in system stability and performance - \item \textbf{ASUS KGPE-D16 Example}: Memory initialization process on the KGPE-D16 mainboard - \end{itemize} + \section{Importance of DDR3 Memory Initialization} - Memory training involves several steps: - - 1. **Detection and Initialization**: The BIOS detects the installed memory - modules, determining their size, speed, and type. - - 2. **Configuration and Timing Setup**: The BIOS configures the memory - controller settings, including timings for memory access such as CAS - latency, RAS to CAS delay, and other parameters\cite{intel_uefi}. - - 3. **Training and Calibration**: The BIOS performs tests and adjustments to - calibrate the memory system, ensuring stable operation at optimal speeds by - adjusting signal voltages and testing data integrity\cite{wolf2006}. + DDR3 (Double Data Rate Type 3) is a widely used type of + SDRAM (Synchronous Dynamic Random-Access Memory) that offers + significant performance improvements over its predecessors, + DDR and DDR2. Key features of DDR3 include higher data rates, + lower power consumption, and increased memory capacity, making + it essential for high-performance computing environments + \cite{DDR3_wiki}. One of the critical aspects of DDR3 is its + internal architecture, which supports data rates ranging from + 800 to 1600 Mbps and operates at a lower voltage of 1.5V. This + enables faster data processing and more efficient power usage, + crucial for modern applications that require high-speed memory + access \cite{samsung_ddr3}. Additionally, DDR3 memory modules are + available in larger capacities, allowing systems to handle larger + datasets and more complex computing tasks \cite{altera2008}. + However, the advanced features of DDR3 come with increased + complexity in its initialization and operation. For example, + DDR3 uses a fly-by topology (fig. \ref{fig:fly-by}) for routing the + address, command, and clock signals. + In this topology, signals are routed sequentially + from the memory controller to each DRAM chip, reducing signal + reflections and improving overall signal integrity. This design + is essential for maintaining stability at the high speeds DDR3 + operates at, but it also introduces timing challenges, such as + timing skew, that must be carefully managed \cite{micron_ddr3}. \\ - These steps are crucial for modern systems, where improper memory - configuration can lead to instability, data corruption, or suboptimal - performance. + \begin{figure}[H] + \centering + \begin{minipage}[b]{0.45\textwidth} + \centering + \includegraphics[width=0.90\textwidth]{images/fly-by.png} + \end{minipage}% + \begin{minipage}[b]{0.45\textwidth} + \centering + \includegraphics[width=0.824\textwidth]{images/t.png} + \end{minipage} + \caption{DDR3 fly-by \textit{versus} T-topology + (CC BY-SA 4.0, 2021)} + \label{fig:fly-by} + \end{figure} - Memory timings, such as CAS latency, RAS to CAS delay, and others, must be - finely tuned to ensure optimal performance. The BIOS uses a combination of - predefined profiles and dynamic adjustments to achieve the best balance - between speed and stability. Advanced timing optimization involves setting - these parameters to ensure that memory operations are performed with - minimal latency and maximum throughput\cite{russinovich2012}. + + Proper memory initialization ensures that the memory controller + and the memory modules are correctly configured to work together, + allowing for efficient data transfer and reliable operation. The + initialization process involves setting various parameters, + such as memory timings, voltages, and frequencies, which are + critical for ensuring that the memory operates within its optimal + range \cite{samsung_ddr3}. Failure to initialize DDR3 memory + correctly can lead to several serious consequences, including + system instability, data corruption, and reduced performance + \cite{SridharanVilas2015MEiM}. In the worst-case scenario, improper + memory initialization can prevent the system from booting entirely, + as the memory subsystem fails to function correctly. + In the context of the ASUS KGPE-D16, a server motherboard + designed for high-performance applications, proper DDR3 memory + initialization is particularly important. The KGPE-D16 supports + up to 256GB of DDR3 memory across 16 DIMM slots, and any issues + during memory initialization, if non-fatal, could severely impact + the system's ability to handle large datasets or maintain stable + operation under heavy workloads \cite{asus_kgpe_d16_manual}. Given + the critical role that memory plays in the overall performance of + the KGPE-D16, ensuring that DDR3 memory is correctly initialized + is essential for achieving the desired balance of performance, + reliability, and stability in demanding server environments. + + \subsection{General steps for DDR3 configuration} + + DDR3 memory initialization is a detailed and essential + process that ensures both the stability and performance of the + system. The process involves several critical steps: detection + and identification of memory modules, initial configuration of the + memory controller, adjustment of timing and voltage settings, and + the execution of training and calibration procedures. \\ + + The initialization begins with the detection and identification of + the installed memory modules. During the BIST, the firmware reads + the Serial Presence Detect (SPD) data stored on + each memory module. SPD data contains crucial information about + the memory module's specifications, including size, speed, CAS + latency (CL), RAS to CAS delay (tRCD), row precharge time (tRP), + and row cycle time (tRC). This data allows to configure + the memory controller for optimal compatibility and performance. \\ + + Indeed, once the memory modules have been identified, the firmware + proceeds to the initial configuration of the memory controller. + This controller is governed by a state machine that + manages the sequence of operations required to initialize, + maintain, and control memory access. This state machine consists of + multiple states that represent various phases of memory operation, + such as reset, initialization, calibration, and data transfer. + The transitions between these states are either automatic or + command-driven, depending on the specific requirements of each + phase \cite{samsung_ddr3}\cite{micron_ddr3}. + This state machine is presented in the + fig. \ref{fig:ddr3_state_machine}. Automatic transitions, depicted + by thick arrows in the automaton, occur without external + intervention. These typically include transitions that ensure + the memory enters a stable state, such as the transition from + power-on to initialization, or from calibration to idle states. + These transitions are crucial for maintaining the integrity and + stability of the memory system, as they ensure that the controller + progresses through necessary stages like ZQ calibration and write + leveling, which are essential for proper signal timing and + impedance matching + \cite{samsung_ddr3}\cite{micron_ddr3}\cite{burnett_ddr3}. \\ + + On the other hand, command-driven transitions, represented by normal + arrows in the automaton, require specific commands issued by the + memory controller or the CPU to advance to the next state. For + instance, the transition from the idle state to the data transfer + state requires explicit read or write commands. Similarly, + transitioning from the initialization state to the calibration + state involves issuing mode register set (MRS) commands that + configure the memory’s operating parameters. These command-driven + transitions are integral to the dynamic operation of the memory + system, allowing the controller to respond to the system's + operational needs and ensuring that memory accesses are performed + efficiently and accurately \cite{samsung_ddr3}\cite{micron_ddr3}. \\ + + The memory controller configuration + involves setting up fundamental parameters such as the memory clock + (MEMCLK) frequency and the memory channel configuration. The MEMCLK + frequency is derived from the SPD data, while the memory channels + are configured to operate in single, dual, or quad-channel modes, + depending on the system architecture and the installed modules + \cite{burnett_ddr3}. Proper configuration of the memory controller + is vital to ensure synchronization with the memory modules, + establishing a stable foundation for subsequent operations. \\ + + The first critical step, during the INIT phase involves the + adjustment of timing and voltage settings. These settings are + essential for ensuring that DDR3 memory operates efficiently and + reliably. Key timing parameters include CAS Latency (CL), RAS to + CAS Delay (tRCD), Row Precharge Time (tRP), and Row Cycle Time (tRC). + These parameters are finely tuned to balance speed and stability + \cite{samsung_ddr3}. The BIOS uses the SPD data to set these + parameters and may also adjust them dynamically to achieve the + best possible performance. Voltage settings, such as DRAM voltage + (typically 1.5V for DDR3) and termination voltage (VTT), are also + configured to maintain stable operation, especially under varying + conditions such as temperature fluctuations \cite{micron_ddr3}. + Training and calibration are among the most complex and crucial + stages of DDR3 memory initialization. The fly-by topology used + for address, command, and clock signals in DDR3 modules enhances + signal integrity by reducing the number of stubs and their lengths, + but it also introduces skew between the clock (CK) and data strobe + (DQS) signals \cite{micron_ddr3}. This skew must be compensated to + ensure that data is written and read correctly. The BIOS performs + write leveling, which adjusts the timing of DQS relative to CK + for each memory module. This process ensures that the memory + controller can write data accurately across all modules, even + when they exhibit slight variations in signal timing due to the + physical layout \cite{samsung_ddr3}. \\ + + \begin{figure}[H] + \centering + \begin{tikzpicture}[scale=0.6, + transform shape, + shorten >=1pt, + node distance=5cm and 5cm, + on grid, + auto] + % States + \node[state, initial] (reset) {RESET}; + \node[draw=none,fill=none] (any) [below=2cm of reset] {ANY}; + \node[state] (init) [right=of reset] {INIT}; + \node[state] (zqcal) [below=of init] {ZQ Calibration}; + \node[state, accepting] (idle) [right=of init] {IDLE}; + \node[state] (writelevel) [above=of idle] {WRITE LEVELING}; + \node[state] (refresh) [right=of idle] {REFRESH}; + \node[state] (activation) [below=of idle] {ACTIVATION}; + \node[state] (bankactive) [below=of activation] {BANK ACTIVE}; + \node[state] (readop) [below right=of bankactive] {READ OP}; + \node[state] (writeop) [below left=of bankactive] {WRITE OP}; + \node[state] (prechrg) [below right=of readop] {PRE-CHARGING}; + % Transitions + \path[->, line width=0.2mm, >=stealth] + (reset) edge node {} (init) + (idle) edge [bend left=20] node {} (writelevel) + edge [bend left=20] node {REF} (refresh) + edge node {} (activation) + edge [bend left=10] node {ZQCL/S} (zqcal) + (activation) edge node {} (bankactive) + (bankactive) edge [bend left=30] node {PRE} (prechrg) + edge [bend left=20] node {write} (writeop) + edge [bend right=20] node {read} (readop) + (writeop) edge [loop left] node {write} (writeop) + edge [bend left=10] node {read\_a} (readop) + edge [bend right=15] node {PRE} (prechrg) + (readop) edge [loop right] node {read} (readop) + edge [bend left=10] node {write\_a} (writeop) + edge [bend right=15] node {PRE} (prechrg); + % Thick transitions + \path[->, line width=0.5mm, >=stealth] + (any) edge node {} (reset) + (init) edge node {ZQCL} (zqcal) + (zqcal) edge [bend left=10] node {} (idle) + (writelevel) edge [bend left=20] node {MRS} (idle) + (refresh) edge [bend left=20] node {} (idle) + (writeop) edge node {} (prechrg) + edge [bend left=20] node {} (bankactive) + (readop) edge [bend left=15] node {} (prechrg) + edge [bend right=20] node {} (bankactive) + (prechrg) edge [bend right=20] node {} (idle); + \end{tikzpicture} + \caption{DDR3 controller state machine} + \label{fig:ddr3_state_machine} + \end{figure} + + ZQ calibration is another vital procedure that adjusts the + output driver impedance and on-die termination (ODT) to match + the system’s characteristic impedance \cite{micron_ddr3}. This + calibration is critical for maintaining signal integrity under + different operating conditions, such as voltage and temperature + changes. During initialization, the memory controller issues a + ZQCL command, triggering the calibration sequence that optimizes + impedance settings. This ensures that the memory system can + operate with tight timing tolerances, which is crucial for + systems requiring high reliability. + Read training is also essential to ensure that data read from + the memory modules is interpreted correctly by the memory + controller. This process involves adjusting the timing of the + read data strobe (DQS) to align perfectly with the data being + received. Proper read training is necessary for reliable data + retrieval, which directly impacts system performance and stability. \\ + + In summary, the DDR3 memory initialization process in systems + like the ASUS KGPE-D16 involves a series of detailed and + interdependent steps that are critical for ensuring system + stability and performance. These include the detection and + identification of memory modules, the initial configuration of + the memory controller, precise adjustments of timing and voltage + settings, and rigorous training and calibration procedures. + + \section{Memory initialization techniques} + + \subsection{Memory training algorithms} + + Memory training algorithms are designed to fine-tune the + operational parameters of memory modules, such as timing, voltage, + and impedance. These algorithms play a crucial role in achieving + the optimal performance of DDR3 memory systems, particularly + in complex multi-core environments where synchronization + and timing are challenging. The primary algorithms used in + memory training include ZQ calibration and write leveling. + Optimizing timing and voltage settings is a critical aspect of + memory training. The memory controller adjusts parameters such as + CAS latency, RAS to CAS delay, and other timing characteristics + to ensure that data is read and written with minimal delay + and maximum accuracy. Voltage adjustments are also crucial, + as they help stabilize the operation of memory modules by + ensuring that the power supplied is within the optimal range, + compensating for any variations due to temperature or other factors + \cite{micron_ddr3}\cite{burnett_ddr3}\cite{gopikrishna2021novel}. + \\ + + ZQ calibration is a critical step in DDR3 memory initialization that + ensures the proper impedance matching of the output driver and + on-die termination (ODT) resistance. Impedance matching is crucial + for maintaining signal integrity by minimizing reflections and + ensuring reliable data transmission between the memory controller + and the DRAM modules. It is initiated by sending ZQCL (ZQ + Calibration Long) commands to the DDR3 DIMMs. Each ZQCL command + triggers a long calibration cycle within the DRAM module. The + purpose of this calibration is to adjust the output driver impedance + and the ODT resistance to match the specified target impedance. This + adjustment compensates for process variations, voltage fluctuations, + and temperature changes that can affect the impedance + characteristics of the DRAM module \cite{gopikrishna2021novel}. \\ + + A bit in the DRAM Controller + Timing register is set to 1 to send the ZQCL command, and an address + bit is also set to 1 to indicate that the ZQCL command should be + directed to the memory module. Upon receiving the ZQCL command, the + DRAM module begins the calibration process. This involves a series + of internal adjustments where the DRAM module measures its current + impedance and compares it against the target impedance. The module + then modifies its internal settings to reduce the difference between + the current and target impedance values + \cite{gopikrishna2021novel}\cite{samsung_ddr3}. This process is + iterative, meaning that it may require multiple adjustments to + converge on the optimal impedance settings. The calibration is + designed to ensure that the DRAM module's impedance remains within + a tight tolerance, which is critical for high-speed data + communication. The ZQ calibration process is time-sensitive. After + issuing the ZQCL command, the system must wait for 512 memory + clock cycles (MEMCLKs) to allow the calibration to complete. + This delay is necessary because the calibration involves both + measurement and adjustment phases, which require precise timing + to ensure accuracy \cite{gopikrishna2021novel}. If the system does + not wait the full 512 MEMCLKs, the calibration may be incomplete, + leading to suboptimal impedance matching and potential signal + integrity issues, such as reflections or noise on the data lines. \\ + + During the ZQ calibration, the DRAM module adjusts its output driver + impedance, which controls the strength of the signals it sends out. + The stronger the signal, the less susceptible it is to noise, but if + the impedance is too high or too low, it can cause signal distortion + or reflections. The ODT resistance is also calibrated to properly + terminate signals that reach the end of a data line. Proper + termination is essential to prevent signal reflections that could + interfere with the integrity of the data being transmitted. The ZQCL + command adjusts these settings by fine-tuning the resistance values + based on the module’s feedback, ensuring that the signal paths are + optimized for both transmission and termination. Once the ZQ + calibration is complete, the DCT register bit is reset to 0, + indicating that the calibration command has been processed. The + memory controller then verifies that the DRAM module has correctly + adjusted its impedance settings. This verification process may + involve additional test signals sent across the memory bus to + confirm that signal integrity meets the required standards. If the + calibration is successful, the memory subsystem is now properly + calibrated and ready for normal operation. In systems with LRDIMMs + or RDIMMs, additional steps may be necessary to ensure that all + ranks and channels are calibrated correctly, particularly in + multi-rank configurations where impedance matching can be more + complex. However, in systems with complex memory configurations, + such as those using multiple DIMMs per channel or operating at + higher memory frequencies, the ZQ calibration process becomes even + more critical. The calibration may need to be repeated at different + operating points to ensure that the memory subsystem remains stable + across all conditions. This could involve performing multiple ZQCL + calibrations at different memory frequencies, or under different + thermal conditions, to account for the dynamic nature of memory + operation in modern systems. \\ + + In seed-based algorithms, an initial "seed" value is used + as a reference point for the calibration process. The memory + controller iteratively adjusts the impedance based on feedback + from the memory module, refining the calibration with each + iteration. This method provides a more precise calibration, + particularly in systems where fine-tuned impedance matching is + critical for high-frequency operations \cite{kim2010design}. + Also, while seed-based methods can accelerate the convergence + of calibration, they require careful selection of initial seed + values to avoid suboptimal or even faulty impedance settings + \cite{gopikrishna2021novel}. \\ + + Write leveling is another critical aspect of memory training, + particularly in DDR3 systems that use a fly-by topology. It involves + using the physical layer (PHY) to detect the edge of the Data Strobe + (DQS) signal in synchronization with the clock (CK) signal on the + DIMM (Dual In-line Memory Module) during write access. The DQS + signal is a timing signal generated by the memory controller that + accompanies data (DQ) during read and write operations. For write + operations, the DQS signal must be perfectly aligned with the CK + signal to ensure that data is correctly written to memory cells. + Indeed, in systems using a fly-by topology, the DQS signal might + arrive at different times for different memory devices on the same + module due to the signal traveling through different lengths of + trace. Write leveling compensates for this skew by adjusting the + timing of the DQS signal relative to the CK signal for each lane + (a group of data lines) \cite{burnett_ddr3}. This training is + performed on a per-channel and per-DIMM basis, ensuring that each + memory module is correctly synchronized with the memory controller, + minimizing timing mismatches that could lead to data corruption. \\ + + Using seed-based algorithms, the memory controller sets an initial + delay value and then iteratively adjusts it based on the feedback + received from the memory module. This process ensures that the DQS + signal is correctly aligned with the CK signal at the memory + module's pins, minimizing the risk of data corruption and ensuring + reliable write operations + \cite{samsung_ddr3}\cite{gopikrishna2021novel}. + Seed-based write leveling offers improved precision but must be + finely tuned to account for the specific characteristics of the + memory module and the overall system architecture + \cite{gopikrishna2021novel}. \\ + + In contrast to seed-based algorithms, seedless methods + do not rely on an initial reference value. Instead, they + dynamically adjust the impedance and timing parameters during + the calibration process. Seedless ZQ calibration continuously + monitors the impedance of the memory module and makes real-time + adjustments to maintain optimal matching. This approach can be + beneficial in environments where the operating conditions are + highly variable, as it allows for more flexible and adaptive + calibration \cite{kim2010design}. Similarly, seedless write + leveling dynamically adjusts the DQS timing based on real-time + feedback from the memory module. This method is particularly + useful in systems where the memory configuration is frequently + changed or where the operating conditions vary significantly + \cite{micron_ddr3}\cite{gopikrishna2021novel}. The traditional + ZQ calibration methods, while effective, often struggle with + matching impedance perfectly across all conditions. A master + thesis by \textcite{gopikrishna2021novel} builds upon these + traditional methods by proposing enhancements that involve more + sophisticated calibration approaches, leading to better impedance + matching and overall memory performance \cite{gopikrishna2021novel}. + + \subsection{BIOS and Kernel Developer Guide (BKDG) recommendations} + + The BIOS and Kernel Developer Guide (BKDG from \textcite{BKDG}) is a + technical manual aimed at BIOS developers and operating system kernel + programmers. It provides in-depth documentation on the AMD + processor architecture, system initialization processes, and + configuration guidelines. The document is essential for + understanding the proper initialization sequences, including + those for DDR3 memory, to ensure system stability and + performance, particularly for AMD Family 15h processors. \\ + + The initialization of DDR3 memory begins with configuring the DDR + supply voltage regulator, which ensures that the memory modules + receive the correct power levels. Following this, the Northbridge + (NB) P-state is forced to \texttt{NBP0}, a state that guarantees + stable operation during the initial configuration phases. Once these + preliminary steps are completed, the initialization of the DDR + physical layer (PHY) begins, which is critical for setting up + the communication interface between the memory controller and the + DDR3 modules. PHY fence training deals with overall signal alignment + at the physical interface, while ZQ calibration focuses on impedance + matching, and write leveling addresses timing alignment during + write operations. Each process involves different methods as PHY + fence training uses iterative timing adjustments, ZQ calibration + uses impedance adjustments via the ZQ pin, and write leveling + adjusts DQS timing relative to CK during writes. These processes are + critical for configuring DDR3 DIMMs and ensuring stable and reliable + operation, especially when booting from an unpowered state such as + ACPI S4 (hibernation), S5 (soft off), or G3 (mechanical off). + + \subsubsection{DDR3 initialization procedure} + + DDR3 initialization is a multi-step process that prepares + both the memory controllers and the DIMMs for operation. This + initialization is essential to set up the memory configuration + and to ensure that the memory subsystem operates correctly + under various conditions. + + \begin{itemize} + \item \textbf{Enable DRAM initialization}: The process + begins by + enabling DRAM initialization. This is done + by setting the \texttt{EnDramInit} bit in + the \texttt{D18F2x7C\_dct} register to 1. The + \texttt{D18F2x7C\_dct} register is a specific + configuration register within the memory + controller that controls various aspects of the + DRAM initialization process. Enabling this bit + initiates the sequence of operations required to + prepare the memory for use. After setting this bit, + the system waits for 200 microseconds to allow the + initialization command to propagate and stabilize. + + \item \textbf{Deassert memory reset}: Next, the memory + reset + signal, known as \texttt{MemRstX}, is deasserted + by setting the \texttt{DeassertMemRstX} bit in the + \texttt{D18F2x7C\_dct} register to 1. Deasserting + \texttt{MemRstX} effectively takes the memory + components out of their reset state, allowing them + to begin normal operation. The system then waits + for an additional 500 microseconds to ensure that + the memory reset is fully deasserted and the memory + components are stable. + + \item \textbf{Assert clock enable (CKE)}: The next + step involves asserting the clock enable signal, known as + `CKE`, by setting the \texttt{AssertCke} bit in the + \texttt{D18F2x7C\_dct} register to 1. The \texttt{CKE} + signal is critical because it enables the clocking + of the DRAM modules, allowing them to synchronize + with the memory controller. The system must wait + for 360 nanoseconds after asserting \texttt{CKE} + to ensure that the clocking is correctly established. + + \item \textbf{Registered DIMMs and LRDIMMs initialization}: + For systems using registered DIMMs (RDIMMs) or Load + Reduced DIMMs (LRDIMMs), additional initialization + steps are necessary. RDIMMs and LRDIMMs have + buffering mechanisms that reduce electrical loading + and improve signal integrity, especially in systems + with multiple memory modules. During initialization, + the BIOS programs the \texttt{ParEn} bit in the + \texttt{D18F2x90\_dct} register based on whether + the DIMM is buffered or unbuffered. For RDIMMs, + specific Register Control (RC) commands, such as RC0 + through RC7, are sent to initialize the memory module's + control registers. Similarly, LRDIMMs require a series + of Flexible Register Control (FRC) commands, such as + F0RC and F1RC, to initialize their internal registers + according to the manufacturer’s specifications. + + \item \textbf{Mode Register Set (MRS)}: The initialization + process also involves sending Mode Register Set + (MRS) commands. These commands are used to configure + various operational parameters of the DDR3 memory + modules, such as burst length, latency timings, + and operating modes. Each MRS command targets a + specific mode register within the memory module, + and the exact sequence of commands is crucial for + setting up the DIMMs according to the system’s + requirements and the DIMM manufacturer’s guidelines. + \end{itemize} + + \subsubsection{ZQ calibration process} + + ZQ calibration is a key step in DDR3 initialization, + responsible for calibrating the output driver impedance and + on-die termination (ODT) resistance of the DDR3 modules. Proper + impedance matching is essential for maintaining signal + integrity, reducing signal reflections, and ensuring reliable + data communication between the memory controller and the + memory modules. + + \begin{itemize} + \item \textbf{Sending ZQCL commands}: The BIOS initiates + ZQ calibration by sending two ZQCL (ZQ Calibration Long) + commands to each DDR3 DIMM. ZQCL commands instruct the + memory module to perform a long calibration cycle, during + which the module adjusts its output driver impedance and + ODT resistance to match the desired target impedance. This + process compensates for variations due to manufacturing + differences, voltage fluctuations, and temperature + changes. To send a ZQCL command, the BIOS programs the + \texttt{SendZQCmd} bit in the \texttt{D18F2x7C\_dct} + register to 1 and sets the \texttt{MrsAddress[10]} bit to 1, + indicating that the ZQCL command should be sent to the + memory module. + + \item \textbf{Calibration timing}: After sending the + ZQCL command, the system must wait for 512 memory clock + cycles (MEMCLKs) to allow the calibration process to + complete. During this time, the memory module adjusts + its internal impedance to ensure it matches the specified + target impedance. This timing is critical, as inadequate + wait times could result in incomplete or inaccurate + calibration, leading to signal integrity issues and + potential data errors. + + \item \textbf{Finalization of initialization}: Once the + ZQ calibration is complete, the BIOS deactivates the DRAM + initialization process by setting the \texttt{EnDramInit} + bit in the \texttt{D18F2x7C\_dct} register to 0. For + LRDIMMs, additional configuration steps are required to + finalize the initialization process. These steps include + programming the DCT registers to monitor for errors and + ensure that the LRDIMMs are operating correctly. + \end{itemize} + + \subsubsection{Write leveling process} + + The BIOS and Kernel Developer Guide (BKDG) provides a + comprehensive approach to the write leveling process, which is + essential for ensuring correct data alignment during write + operations in DDR3 memory systems. Write leveling is + particularly crucial in systems utilizing a fly-by topology, + where timing skew between the clock and data signals can + introduce significant challenges. This kind of algorithms + were not necessary for DDR2, for example. + If the target operating + frequency is higher than the lowest supported MEMCLK frequency, + the BIOS must perform multiple passes to achieve proper write + leveling. The MEMCLK is the clock signal that synchronizes the + communication between the memory controller and the memory + modules. \\ + + During each pass, the memory subsystem is configured for a + progressively higher operating frequency: + + \begin{itemize} + \item \textbf{Pass 1:} The memory subsystem is configured + for the lowest supported MEMCLK, ensuring that initial + timing adjustments are made under the most stable + conditions. + \item \textbf{Pass 2:} The subsystem is then adjusted for + the second-lowest MEMCLK, gradually increasing the + operating frequency while fine-tuning the alignment of + the DQS and CK signals. + \item \textbf{Pass N:} This process continues until the + highest MEMCLK supported by the system is reached, + ensuring that the memory operates reliably at its + maximum speed. + \end{itemize} + + This step-wise configuration ensures that the memory system is + stable across all supported operating frequencies, minimizing + the risk of timing errors during write operations, especially + as frequencies increase and timing margins become tighter. The + configuration process varies depending on whether the DIMM is + a Registered DIMM (RDIMM) or an Unregistered DIMM (UDIMM). + RDIMMs include an additional buffer to improve signal integrity, + which is particularly important in systems with multiple DIMMs. + The steps common to both types include a preparation with the + DDR3 Mode Register Commands + (see fig. \ref{fig:ddr3_state_machine}). Mode registers in DDR3 + memory are used to configure various operational parameters such + as latency settings, burst length, and write leveling. One of + the key mode registers is \texttt{MR1\_dct}, which is specific to + DDR3 and controls certain features of the memory module, + including write leveling. \texttt{MR1\_dct} is used to enable or + disable specific functions such as write leveling and output + driver settings. The \texttt{dct} suffix refers to the Data + Control Timing that is specific to this register's function in + managing the timing and control of data operations within the + memory module. For RDIMMs, a 4-rank module is treated as two + separate DIMMs, where each rank is essentially a separate memory + module within the same DIMM. The first two ranks are the primary + target for the initial configuration. The remaining two ranks + are treated as non-target and are configured separately. \\ + + Then, these steps are followed, still common to both RDIMMs and + UDIMMs: + + \begin{itemize} + \item \textbf{Step 1A: Output Driver and ODT configuration + for target DIMM:} + \begin{itemize} + \item For the first rank (target): + \begin{itemize} + \item Set \texttt{MR1\_dct[1:0][Level] = 1} + to enable write leveling. + \item Set \texttt{MR1\_dct[1:0][Qoff] = 0} + to ensure the output drivers are active. + \end{itemize} + \item For other ranks: + \begin{itemize} + \item Set \texttt{MR1\_dct[1:0][Level] = 1} + to prepare for write leveling. + \item Set \texttt{MR1\_dct[1:0][Qoff] = 1} + to deactivate the output drivers for + ranks that are not currently being + leveled. + \end{itemize} + \item If there are two or more DIMMs per channel, + or if there is one DIMM per three channels: + \begin{itemize} + \item Program the target rank’s + \texttt{RttNom} (nominal termination + resistance value) for \texttt{RttWr} + termination, which helps in managing signal + integrity during the write process by + ensuring the correct impedance matching. + \end{itemize} + \end{itemize} + + \item \textbf{Step 1B: Configure non-target RttNom to normal + operation:} + \begin{itemize} + \item After the initial configuration, the + \texttt{RttNom} values for the non-target ranks + are set to their normal operating states. + \item A wait time of 40 MEMCLKs is observed to + ensure the configuration settings are stable + before proceeding. + \end{itemize} + + \item \textbf{Step 3: PHY configuration:} + \begin{itemize} + \item The PHY is then configured to measure and + adjust the timing delays accurately for each + data lane. The PHY layer is responsible for + converting the signals from the memory + controller into a form that can be transmitted + over the physical connections to the memory + modules. + \end{itemize} + + \item \textbf{Step 4: Perform write leveling:} + \begin{itemize} + \item The actual write leveling process is executed, + where the DQS signal timing is adjusted to + ensure it aligns perfectly with the CK signal at + the memory module’s pins, ensuring that data is + written accurately. + \end{itemize} + + \item \textbf{Step 5: Disable PHY configuration + post-measurement:} + \begin{itemize} + \item After completing the write leveling process, + the PHY configuration is disabled to stop further + timing measurements and adjustments, locking in the + calibrated settings. + \end{itemize} + + \item \textbf{Step 6: Program the DIMM to normal operation:} + \begin{itemize} + \item Finally, the DIMM is reprogrammed to its + normal operational state, resetting \texttt{Qoff} + and \texttt{Level} to \texttt{0} to conclude the + write leveling process and return to standard + operation. + \end{itemize} + \end{itemize} + + For each DIMM, the BIOS must calculate the coarse and fine + delays for each lane in the DQS Write Timing register: + + \begin{itemize} + \item \textbf{Coarse Delay Calculation:} This involves + setting a basic delay based on a seed value specific to + the platform. The seed value is determined during + initial system configuration and serves as a starting + point for further delay adjustments. + \item \textbf{Critical Delay Determination:} The minimum of + the coarse delays for each lane and DIMM is considered + the critical delay. This delay is crucial for ensuring + that all data lanes are correctly synchronized. + \item \textbf{Platform-Specific Seed:} The seed ranges + between -1.20ns and +1.20ns, providing a small + adjustment range to fine-tune the timing based on the + specific characteristics of the platform. This seed + value can differ for the first pass compared to + subsequent passes, allowing for incremental adjustments + as the system stabilizes. + \end{itemize} + + \section{Current implementation and potential improvements [WIP]} + \subsection{Current implementation in coreboot on the KGPE-D16 [WIP]} + \begin{itemize} + \item Overview of the current DDR3 initialization process in + \textit{coreboot} on the KGPE-D16 + \item Analysis of strengths and weaknesses of the current + implementation + \end{itemize} + + The process starts by calling the \texttt{fill\_mem\_ctrl} + function from + \path{src/northbridge/amd/amdfam10/raminit_sysinfo_in_ram.c}. + At this current step, only the BSC is running the firmware code. + This function iterates over all memory controllers (one per + node) and initializes their corresponding structures with the + system information needed for the RAM to function. This includes + the addresses of PCI nodes (important for DMA operations) and + SPD addresses, which are internal ROMs in each memory slot + containing crucial information for detecting and initializing + memory modules. If successful, the system posts codes + \texttt{0x3D} and then \texttt{0x40}. The + \texttt{raminit\_amdmct} function from + \path{src/northbridge/amd/amdfam10/raminit\_amdmct.c} is then + called. This function, in turn, calls \texttt{mctAutoInitMCT\_D} + from \path{src/northbridge/amd/amdmct/mct_ddr3/mct_d.c}, + which is responsible for the initial memory initialization, + predominantly written by Raptor Engineering. + + At this stage, it is assumed that memory has been pre-mapped + contiguously from address 0 to 4GB and that the previous code + has correctly mapped non-cacheable I/O areas below 4GB for the + PCI bus and Local APIC access for processor cores. + + The following prerequisites must be in place from the previous + steps: + + \begin{itemize} + \item The HyperTransport bus configured, and its speed is + correctly set. + \item The SMBus controller is configured. + \item The BSP is in unreal mode. + \item A stack is set up for all cores. + \item All cores are initialized at a frequency of 2GHz. + \item If we were using saved values, the NVRAM would have been + verified with checksums. + \end{itemize} + + The memory controller for the BSP is queried to check if it can + manage ECC memory, which is a type of memory that includes + error-correcting code to detect and correct common types of data + corruption. + + For each node available in the system, the memory controllers + are identified and initialized using a \texttt{DCTStatStruc} + structure defined in + \path{src/northbridge/amd/amdmct/mct_ddr3/mct_d.h}. This + structure contains all necessary fields for managing a memory + module. The process includes: + + \begin{itemize} + \item Retrieving the corresponding field in the sysinfo + structure for the node. + \item Clearing fields with \texttt{zero}. + \item Initializing basic fields. + \item Initializing the controller linked to the current node. + \item Verifying the presence of the node (checking if the + processor associated with this controller is present). + If yes, the SMBus is informed. + \item Pre-initializing the memory module controller for this + node using \texttt{mct\_preInitDCT}. + \end{itemize} + + The \textit{coreboot} code compensates for the delay between DQS + and DQ signals, as well as between CMD and DQ. This is handled in + the \texttt{DQSTiming\_D} function. + + Finally, if the RAM is of the ECC type, error-correcting codes + are enabled, and the function ends by activating power-saving + features if requested by the user. + + TODO (continue notes from PROJET) \begin{listing}[H] \begin{adjustwidth}{0.5cm}{0.5cm} @@ -1369,90 +2170,19 @@ We saw that in (lst. \ref{lst:c_code}). - \section{Memory training algorithms} - \begin{itemize} - \item Techniques used for training memory - \item Optimization of timings and voltage settings - \item Challenges in multi-core CPU environments - \item \textbf{ASUS KGPE-D16 Example}: Specific algorithms used for memory training in the mainboard and their performance outcomes - \end{itemize} - - To optimize memory performance, the BIOS employs various training - algorithms and calibration techniques. These methods test the memory under - different conditions and make necessary adjustments to improve stability - and efficiency. Key techniques include voltage adjustments, data integrity - testing, and signal timing calibration\cite{shin2011}. - - Voltage adjustments involve tweaking the power supplied to the memory - modules to ensure reliable operation. Data integrity testing checks that - data can be accurately read and written, while signal timing calibration - fine-tunes the delays between different memory operations to minimize - latency. - - \section{Practical examples} - \begin{itemize} - \item Real-world scenarios where firmware played a crucial role in system performance - \item Analysis of firmware updates and their impact on the KGPE-D16 mainboard - \item User experiences and testimonials highlighting the importance of firmware - \item \textbf{ASUS KGPE-D16 Example}: Specific case studies and firmware updates for the mainboard - \end{itemize} - - \subsection{RAM Initialization Preparation} - - Memory initialization is one of the most critical tasks performed by \texttt{coreboot}. Without proper memory initialization, the system memory cannot function correctly, preventing the operating system from booting. - - The process begins by setting a default voltage for the memory modules. This is a preliminary step, as the initialization process will subsequently involve searching for an optimal voltage. The function \texttt{set\_peripheral\_control\_lines} is then called to enable various peripherals, such as IEEE1394-compatible devices (e.g., integrated FireWire on the motherboard). - - Next, the system waits for all cores, except the Bootstrap Processor (BSP), to halt using \texttt{wait\_all\_other\_cores\_stopped}. If everything is in order, the system sends code \texttt{0x38}. - - \subsection{RAM Initialization} - - The process starts by calling the \texttt{fill\_mem\_ctrl} function from \texttt{src/northbridge/amd/amdfam10/raminit\_sysinfo\_in\_ram.c}. This function iterates over all memory controllers (one per node) and initializes their corresponding structures with the system information needed for the RAM to function. This includes the addresses of PCI nodes (important for DMA operations) and SPD addresses, which are internal ROMs in each memory slot containing crucial information for detecting and initializing memory modules. - - If successful, the system posts codes \texttt{0x3D} and then \texttt{0x40}. The \texttt{raminit\_amdmct} function from \texttt{src/northbridge/amd/amdfam10/raminit\_amdmct.c} is then called. This function, in turn, calls \texttt{mctAutoInitMCT\_D} from \texttt{src/northbridge/amd/amdmct/mct\_ddr3/mct\_d.c}, which is responsible for the initial memory initialization, predominantly written by Raptor Engineering. - - \subsubsection{Memory Controller Initialization} - - At this stage, it is assumed that memory has been pre-mapped contiguously from address 0 to 4GB and that the previous code has correctly mapped non-cacheable I/O areas below 4GB for the PCI bus and Local APIC access for processor cores. - - The following prerequisites must be in place from the previous steps: - - \begin{itemize} - \item The HyperTransport bus is configured, and its speed is correctly set. - \item The SMBus controller is configured. - \item The BSP is in unreal mode. - \item A stack is set up for all cores. - \item All cores are initialized at a frequency of 2GHz. - \item The NVRAM has been verified with checksums. - \end{itemize} - - The memory controller for the BSP is queried to check if it can manage ECC memory, which is a type of memory that includes error-correcting code to detect and correct common types of data corruption. - - For each node available in the system, the memory controllers are identified and initialized using a \texttt{DCTStatStruc} structure defined in \texttt{src/northbridge/amd/amdmct/mct\_ddr3/mct\_d.h}. This structure contains all necessary fields for managing a memory module. The process includes: - - \begin{itemize} - \item Retrieving the corresponding field in the sysinfo structure for the node. - \item Clearing fields with \texttt{zero}. - \item Initializing basic fields. - \item Initializing the controller linked to the current node. - \item Verifying the presence of the node (checking if the processor associated with this controller is present). If yes, the SMBus is informed. - \item Pre-initializing the memory module controller for this node using \texttt{mct\_preInitDCT}. - \end{itemize} - - \subsubsection{Memory Module Training} - - Memory modules are designed to store data. The only valid operations on memory devices are reading data stored in the device, writing (or storing) data to the device, and refreshing the data. Memory modules consist of large rectangular arrays of memory cells, including circuits used to read and write data into the arrays and refresh circuits to maintain data integrity. The memory arrays are organized into rows and columns of memory cells, known as word lines and bit lines, respectively. Each memory cell has a unique location or address defined by the intersection of a row and a column. - - A DDR3 DIMM module contains 240 contacts. The DDR3 memory interface, used by the Asus KGPE-D16, is source-synchronous. Each memory module generates a Data Strobe (DQS) pulse simultaneously with the data (DQ) it sends during a read operation. Similarly, a DQS is generated with DQ information during a write operation. The DQS differs between write and read operations. For writes, the DQS is centered in the data bit period, whereas for reads, the DQS provided by the memory is aligned with the data period's edge. - - To improve timing margins or reduce simultaneous switching noise, the DDR3 memory interface allows for adjusting various timing parameters. For systems using dual-inline memory modules (DIMMs), as in this case, the interface provides write leveling: a timing adjustment that compensates for variations in signal travel time. - - To ensure proper timing margins, the write triggering of the interface must correspond to the command signal's arrival time, which can be resolved by adjusting the DQ and DQS launch times for each device. Each module uses the DQS to sample the clock, asynchronously returning the sampled clock signal to the controller on one or more data lines. To calibrate the write leveling adjustments, the memory controller sweeps the DQS for each data group across its delay range. - - The \texttt{coreboot} code compensates for the delay between DQS and DQ signals, as well as between CMD and DQ. This is handled in the \texttt{DQSTiming\_D} function. - - Finally, if the RAM is of the ECC type, error-correcting codes are enabled, and the function ends by activating power-saving features if requested by the user. + \subsection{Potential enhancements [WIP]} + \begin{itemize} + \item Identifying areas for improvement in the current + implementation + \item Potential enhancements to memory training algorithms + and configuration settings + \item Broader applicability of these improvements to other + systems using \textit{coreboot} + \end{itemize} +% ------------------------------------------------------------------------------ +% CHAPTER 5: Virtualization of the operating system through firmware abstraction +% ------------------------------------------------------------------------------ \chapter{Virtualization of the operating system through firmware abstraction} In contemporary computing systems, the operating system (OS) no longer @@ -1481,6 +2211,64 @@ by ACPI-compliant firmware. This layer of abstraction contributes to the virtualization-like environment in which the OS operates. \\ + More importantly, the ACPI Component Architecture (ACPICA) is a critical + component integrated into the Linux kernel, serving as the foundation + for the system's ACPI implementation \cite{intel_acpi_programming_2023}. + ACPICA provides the core ACPI functionalities, such as hardware + configuration, power management, and thermal management, which are + essential for modern computing platforms. However, its integration into + the Linux kernel has brought significant complexity and code overhead, + making Linux heavily dependent on ACPICA for managing ACPI-related + tasks. + + ACPICA is a large and complex project, with its codebase encompassing + a wide range of functionalities required to implement ACPI standards. + The integration of ACPICA into the Linux kernel significantly increases + the kernel's overall code size. An example of that can easily be + reproduced with a small experiment (lst. \ref{lst:acpica_in_linux}). + + \begin{listing}[H] + \begin{adjustwidth}{0.5cm}{0.5cm} + \inputminted{sh}{listings/acpica_size.sh} + \end{adjustwidth} + \caption{\textit{How to estimate the impact of ACPICA in Linux}} + \label{lst:acpica_in_linux} + \end{listing} + + As of recent statistics, ACPICA comprises between 100,000 to 200,000 + lines of code, making it one of the larger subsystems within the Linux + kernel. This size is indicative of the extensive range of features + and capabilities ACPICA must support, including but not limited to the + ACPI interpreter, AML (ACPI Machine Language) parser, and various + hardware-specific drivers. The ACPICA codebase is not monolithic; it is + highly modular and consists of various components, each responsible for + specific ACPI functions. For instance, ACPICA includes components for + managing ACPI tables, interpreting AML bytecode, handling events, and + interacting with hardware. This modularity, while beneficial for + isolating different functionalities, also contributes to the overall + complexity of the system. The separation of ACPICA into multiple modules + necessitates careful coordination and integration with the rest of the + Linux kernel, adding to the kernel's complexity. \\ + + ACPICA's integration into the Linux kernel is designed to maintain a + clear separation between the core ACPI functionalities and the kernel's + other subsystems \cite{intel_acpi_programming_2023}. This separation is + achieved through well-defined interfaces and abstraction layers, + allowing the Linux kernel to interact with ACPICA without being tightly + coupled to its internal implementation details. For example, ACPICA + provides an API that the Linux kernel can use to interact with ACPI + tables, execute ACPI methods, and manage power states. This API + abstracts the underlying complexity of the ACPI implementation, making + it easier for kernel developers to incorporate ACPI support without + delving into the intricacies of ACPICA's internals. + Moreover, ACPICA's role in interpreting AML bytecode, which is + essentially a form of low-level programming language embedded in ACPI + tables, adds a layer of abstraction. The Linux kernel relies on ACPICA + to execute AML methods and manage hardware resources according to the + ACPI specifications. This reliance further underscores the idea that + ACPI acts as a virtualizing environment, shielding the kernel from + the complexities of directly interfacing with hardware components. + \section{SMM as a hidden execution layer} System Management Mode (SMM) is a special-purpose operating mode @@ -1511,7 +2299,102 @@ placing the OS in a position where it runs on top of another controlling layer, much like a guest OS in a VM. This persistence and the ability of UEFI to manage hardware resources independently further blur the lines - between traditional OS operation and virtualized environments. \\ + between traditional OS operation and virtualized environments. + Indeed, as we studied in a precedent chapter, UEFI is designed as a + modular and extensible firmware interface that sits between the + computer's hardware and the operating system. Unlike the monolithic + BIOS, UEFI is composed of several layers and components, each + responsible for different aspects of the system's boot and runtime + processes. The core components of UEFI include the Pre-EFI + Initialization (PEI), Driver Execution Environment (DXE), + Boot Device Selection (BDS), and Runtime Services. Each of these + components plays a critical role in initializing the hardware, + managing drivers, selecting boot devices, and providing runtime + services to the OS. \\ + + The PEI (Pre-EFI Initialization) phase is responsible for initializing + the CPU, memory, and other essential hardware components. It ensures + that the system is in a stable state before handing control to the + DXE phase. In the DXE phase, the system loads and initializes various + drivers required for the OS to interact with the hardware. The DXE phase + also constructs the UEFI Boot Services, which provide the OS with + interfaces to the hardware during the boot process. The BDS (Boot Device + Selection) phase is responsible for selecting the device from which the + OS will boot. It interacts with the UEFI Boot Manager to determine the + correct boot path and load the OS. After the OS has booted, UEFI + provides Runtime Services that remain accessible to the OS. These + services include interfaces for managing system variables, time, and + hardware. UEFI also supports the execution of standalone applications, + which can be used for system diagnostics, firmware updates, or other + tasks. These applications operate independently of the OS, highlighting + UEFI's capabilities as a minimalistic OS. \\ + + UEFI abstracts the underlying hardware from the OS, providing a + standardized interface for the OS to interact with different hardware + components. This abstraction simplifies the development of OSes and + drivers, as they do not need to be tailored for specific hardware + configurations. UEFI's hardware abstraction is one of the key features + that enable it to act as a virtualizing environment for the OS + \cite{mcclean2017uefi}. + + \subsection{Memory Management} + + UEFI provides a detailed memory map to the OS during the boot process, + which includes information about available, reserved, and used memory + regions. The OS uses this memory map to manage its own memory allocation + and paging mechanisms. The overlap in memory management functions + highlights UEFI's role in preparing the system for OS operation. + This memory map includes all the memory regions in the system, + categorized into different types, such as usable memory, reserved + memory, and memory-mapped I/O. The OS relies on this map to understand + the system's memory layout and avoid conflicts \cite{osdev_uefi_memory}. + The OS extends UEFI's memory + management by implementing its own memory allocation, paging, and + virtual memory mechanisms. However, the OS's memory management is + built on the foundation provided by UEFI, demonstrating the close + relationship between the two. + + \subsection{File System Management} + + UEFI includes its own file system management capabilities, which overlap + with those of the OS. The most notable example is the EFI System + Partition (ESP), a special partition formatted with the FAT file system + that UEFI uses to store bootloaders, drivers, and other critical files + \cite{uefi_spec}. The ESP is a mandatory partition in UEFI systems, + containing the bootloaders, firmware updates, and other files + necessary for system initialization. UEFI accesses the ESP + independently of the OS, but the OS can also access and manage files + on the ESP, creating an overlap in file system management functions + \cite{uefi_smm_security}. UEFI natively supports the FAT file + system, allowing it to read and write files on the ESP. This support + overlaps with the OS's file system management, as both UEFI and the + OS can manipulate files on the ESP. + + \subsection{Device Drivers} + + As we studied in an earlier chapter, UEFI includes its own driver + model, allowing it to load and execute drivers independently of the + OS. This capability overlaps with the OS's driver management + functions, as both UEFI and the OS manage hardware devices through + drivers. + UEFI drivers are typically used during + the boot process to initialize and control hardware devices. These + drivers provide the necessary interfaces for the OS to interact with + the hardware once it has booted \cite{uefi_smm_security}. + After the OS has booted, it loads its own drivers for hardware + devices. However, the OS often relies on the initial hardware setup + performed by UEFI drivers. + + \subsection{Power Management} + + UEFI provides power management services that overlap with the OS's + power management functions. These services allow UEFI to manage + power states and transitions independently of the OS \cite{uefi_spec}. + These services ensure that the system conserves power during periods + of inactivity and can quickly resume operation when needed + The OS extends UEFI's power management by implementing its own + power-saving mechanisms, such as CPU throttling and dynamic voltage + scaling. \section{Intel and AMD: control beyond the OS} @@ -1621,16 +2504,9 @@ \newpage -% List of figures -\addcontentsline{toc}{chapter}{List of Figures} -\listoffigures -\newpage - -% List of figures -\addcontentsline{toc}{chapter}{List of Listings} -\listoflistings -\newpage - +% ------------------------------------------------------------------------------ +% LICENSE +% ------------------------------------------------------------------------------ \chapter*{\center\rlap{GNU Free Documentation License}} \addcontentsline{toc}{chapter}{GNU Free Documentation License} @@ -1663,16 +2539,16 @@ to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of ``copyleft'', which means that derivative -works of the document must themselves be free in the same sense. It +works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the -software does. But this License is not limited to software manuals; +software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or -whether it is published as a printed book. We recommend this License +whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. @@ -1682,11 +2558,11 @@ principally for works whose purpose is instruction or reference. This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be -distributed under the terms of this License. Such a notice grants a +distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that -work under the conditions stated herein. The ``\textbf{Document}'', below, -refers to any such manual or work. Any member of the public is a -licensee, and is addressed as ``\textbf{you}''. You accept the license if you +work under the conditions stated herein. The ``\textbf{Document}'', below, +refers to any such manual or work. Any member of the public is a +licensee, and is addressed as ``\textbf{you}''. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. @@ -1698,7 +2574,7 @@ A ``\textbf{Secondary Section}'' is a named appendix or a front-matter section o the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly -within that overall subject. (Thus, if the Document is in part a +within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, @@ -1707,15 +2583,15 @@ them. The ``\textbf{Invariant Sections}'' are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice -that says that the Document is released under this License. If a +that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not -allowed to be designated as Invariant. The Document may contain zero -Invariant Sections. If the Document does not identify any Invariant +allowed to be designated as Invariant. The Document may contain zero +Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The ``\textbf{Cover Texts}'' are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that -the Document is released under this License. A Front-Cover Text may +the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A ``\textbf{Transparent}'' copy of the Document means a machine-readable copy, @@ -1725,17 +2601,17 @@ straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input -to text formatters. A copy made in an otherwise Transparent file +to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount -of text. A copy that is not ``Transparent'' is called ``\textbf{Opaque}''. +of text. A copy that is not ``Transparent'' is called ``\textbf{Opaque}''. Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple -HTML, PostScript or PDF designed for human modification. Examples of -transparent image formats include PNG, XCF and JPG. Opaque formats +HTML, PostScript or PDF designed for human modification. Examples of +transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the @@ -1744,7 +2620,7 @@ processors for output purposes only. The ``\textbf{Title Page}'' means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material -this License requires to appear in the title page. For works in +this License requires to appear in the title page. For works in formats which do not have any title page as such, ``Title Page'' means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. @@ -1754,7 +2630,7 @@ copies of the Document to the public. A section ``\textbf{Entitled XYZ}'' means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following -text that translates XYZ in another language. (Here XYZ stands for a +text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as ``\textbf{Acknowledgements}'', ``\textbf{Dedications}'', ``\textbf{Endorsements}'', or ``\textbf{History}''.) To ``\textbf{Preserve the Title}'' @@ -1762,7 +2638,7 @@ of such a section when you modify the Document means that it remains a section ``Entitled XYZ'' according to this definition. The Document may include Warranty Disclaimers next to the notice which -states that this License applies to the Document. These Warranty +states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has @@ -1777,10 +2653,10 @@ You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other -conditions whatsoever to those of this License. You may not use +conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further -copying of the copies you make or distribute. However, you may accept -compensation in exchange for copies. If you distribute a large enough +copying of the copies you make or distribute. However, you may accept +compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section~3. You may also lend copies, under the same conditions stated above, and @@ -1797,10 +2673,10 @@ printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on -the back cover. Both covers must also clearly and legibly identify -you as the publisher of these copies. The front cover must present +the back cover. Both covers must also clearly and legibly identify +you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and -visible. You may add other material on the covers in addition. +visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. @@ -1837,14 +2713,14 @@ the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy -of it. In addition, you must do these things in the Modified Version: +of it. In addition, you must do these things in the Modified Version: \begin{itemize} \item[A.] Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section - of the Document). You may use the same title as a previous version + of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. \item[B.] @@ -1880,7 +2756,7 @@ of it. In addition, you must do these things in the Modified Version: \item[I.] Preserve the section Entitled ``History'', Preserve its Title, and add to it an item stating at least the title, year, new authors, and - publisher of the Modified Version as given on the Title Page. If + publisher of the Modified Version as given on the Title Page. If there is no section Entitled ``History'' in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified @@ -1890,7 +2766,7 @@ of it. In addition, you must do these things in the Modified Version: Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions - it was based on. These may be placed in the ``History'' section. + it was based on. These may be placed in the ``History'' section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. @@ -1903,11 +2779,11 @@ of it. In addition, you must do these things in the Modified Version: \item[L.] Preserve all the Invariant Sections of the Document, - unaltered in their text and in their titles. Section numbers + unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. \item[M.] - Delete any section Entitled ``Endorsements''. Such a section + Delete any section Entitled ``Endorsements''. Such a section may not be included in the Modified Version. \item[N.] @@ -1921,7 +2797,7 @@ of it. In addition, you must do these things in the Modified Version: If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all -of these sections as invariant. To do this, add their titles to the +of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. @@ -1933,9 +2809,9 @@ standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list -of Cover Texts in the Modified Version. Only one passage of +of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or -through arrangements made by) any one entity. If the Document already +through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit @@ -1960,7 +2836,7 @@ license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single -copy. If there are multiple Invariant Sections with the same name but +copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. @@ -1970,7 +2846,7 @@ Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled ``History'' in the various original documents, forming one section Entitled ``History''; likewise combine any sections Entitled ``Acknowledgements'', -and any sections Entitled ``Dedications''. You must delete all sections +and any sections Entitled ``Dedications''. You must delete all sections Entitled ``Endorsements''. @@ -2022,11 +2898,11 @@ distribute translations of the Document under the terms of section~4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the -original versions of these Invariant Sections. You may include a +original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions -of those notices and disclaimers. In case of a disagreement between +of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. @@ -2042,7 +2918,7 @@ title. You may not copy, modify, sublicense, or distribute the Document -except as expressly provided under this License. Any attempt +except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License. @@ -2062,7 +2938,7 @@ your receipt of the notice. Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under -this License. If your rights have been terminated and not permanently +this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it. @@ -2073,9 +2949,9 @@ not give you any rights to use it. The Free Software Foundation may publish new, revised versions -of the GNU Free Documentation License from time to time. Such new +of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may -differ in detail to address new problems or concerns. See +differ in detail to address new problems or concerns. See \texttt{https://www.gnu.org/licenses/}. Each version of the License is given a distinguishing version number. @@ -2083,9 +2959,9 @@ If the Document specifies that a particular numbered version of this License ``or any later version'' applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the -Free Software Foundation. If the Document does not specify a version +Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not -as a draft) by the Free Software Foundation. If the Document +as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the @@ -2099,8 +2975,8 @@ Document. ``Massive Multiauthor Collaboration Site'' (or ``MMC Site'') means any World Wide Web server that publishes copyrightable works and also -provides prominent facilities for anybody to edit those works. A -public wiki that anybody can edit is an example of such a server. A +provides prominent facilities for anybody to edit those works. A +public wiki that anybody can edit is an example of such a server. A ``Massive Multiauthor Collaboration'' (or ``MMC'') contained in the site means any set of copyrightable works thus published on the MMC site. @@ -2165,3 +3041,5 @@ free software license, such as the GNU General Public License, to permit their use in free software. \end{document} + + diff --git a/hardware_init_review.toc b/hardware_init_review.toc index 175321f..1007249 100644 --- a/hardware_init_review.toc +++ b/hardware_init_review.toc @@ -1,43 +1,52 @@ \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}{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}{21}{subsection.3.1.2}% -\contentsline {subsection}{\numberline {3.1.3}Ramstage}{22}{subsection.3.1.3}% -\contentsline {subsubsection}{\numberline {3.1.3.1}Advanced Configuration and Power Interface}{22}{subsubsection.3.1.3.1}% -\contentsline {subsubsection}{\numberline {3.1.3.2}System Management Mode}{23}{subsubsection.3.1.3.2}% -\contentsline {subsection}{\numberline {3.1.4}Payload}{23}{subsection.3.1.4}% -\contentsline {section}{\numberline {3.2}AMD Platform Security Processor and Intel Management Engine}{24}{section.3.2}% -\contentsline {chapter}{\numberline {4}Memory initialization and training algorithms [WIP]}{26}{chapter.4}% -\contentsline {section}{\numberline {4.1}Importance of memory initialization}{26}{section.4.1}% -\contentsline {section}{\numberline {4.2}Memory training algorithms}{26}{section.4.2}% -\contentsline {section}{\numberline {4.3}Practical examples}{27}{section.4.3}% -\contentsline {subsection}{\numberline {4.3.1}RAM Initialization Preparation}{27}{subsection.4.3.1}% -\contentsline {subsection}{\numberline {4.3.2}RAM Initialization}{27}{subsection.4.3.2}% -\contentsline {subsubsection}{\numberline {4.3.2.1}Memory Controller Initialization}{27}{subsubsection.4.3.2.1}% -\contentsline {subsubsection}{\numberline {4.3.2.2}Memory Module Training}{28}{subsubsection.4.3.2.2}% -\contentsline {chapter}{\numberline {5}Virtualization of the operating system through firmware abstraction}{29}{chapter.5}% -\contentsline {section}{\numberline {5.1}ACPI and abstraction of hardware control}{29}{section.5.1}% -\contentsline {section}{\numberline {5.2}SMM as a hidden execution layer}{29}{section.5.2}% -\contentsline {section}{\numberline {5.3}UEFI and persistence}{29}{section.5.3}% -\contentsline {section}{\numberline {5.4}Intel and AMD: control beyond the OS}{30}{section.5.4}% -\contentsline {section}{\numberline {5.5}The OS as a virtualized environment}{30}{section.5.5}% -\contentsline {chapter}{Conclusion}{31}{chapter*.2}% -\contentsline {chapter}{Bibliography}{32}{chapter*.2}% -\contentsline {chapter}{List of Figures}{38}{chapter*.3}% -\contentsline {chapter}{List of Listings}{39}{chapter*.3}% -\contentsline {chapter}{GNU Free Documentation License}{40}{chapter*.5}% +\contentsline {chapter}{Acknowledgments}{3}{chapter*.1}% +\contentsline {chapter}{Abstract}{4}{chapter*.2}% +\contentsline {chapter}{List of Figures}{7}{chapter*.2}% +\contentsline {chapter}{List of Listings}{8}{chapter*.2}% +\contentsline {chapter}{\numberline {1}Introduction to firmware and BIOS evolution}{9}{chapter.1}% +\contentsline {section}{\numberline {1.1}Historical context of BIOS}{9}{section.1.1}% +\contentsline {subsection}{\numberline {1.1.1}Definition and origin}{9}{subsection.1.1.1}% +\contentsline {subsection}{\numberline {1.1.2}Functionalities and limitations}{10}{subsection.1.1.2}% +\contentsline {section}{\numberline {1.2}Modern BIOS and UEFI}{11}{section.1.2}% +\contentsline {subsection}{\numberline {1.2.1}Transition from traditional BIOS to UEFI (Unified Extensible Firmware Interface)}{11}{subsection.1.2.1}% +\contentsline {subsection}{\numberline {1.2.2}An other way with \textit {coreboot}}{11}{subsection.1.2.2}% +\contentsline {section}{\numberline {1.3}Shift in firmware responsibilities}{13}{section.1.3}% +\contentsline {chapter}{\numberline {2}Characteristics of ASUS KGPE-D16 mainboard}{14}{chapter.2}% +\contentsline {section}{\numberline {2.1}Overview of ASUS KGPE-D16 hardware}{15}{section.2.1}% +\contentsline {section}{\numberline {2.2}Chipset}{16}{section.2.2}% +\contentsline {section}{\numberline {2.3}Processors}{18}{section.2.3}% +\contentsline {section}{\numberline {2.4}Baseboard Management Controller}{19}{section.2.4}% +\contentsline {chapter}{\numberline {3}Key components in modern firmware}{21}{chapter.3}% +\contentsline {section}{\numberline {3.1}General structure of coreboot}{21}{section.3.1}% +\contentsline {subsection}{\numberline {3.1.1}Bootblock stage}{22}{subsection.3.1.1}% +\contentsline {subsection}{\numberline {3.1.2}Romstage}{24}{subsection.3.1.2}% +\contentsline {subsection}{\numberline {3.1.3}Ramstage}{25}{subsection.3.1.3}% +\contentsline {subsubsection}{\numberline {3.1.3.1}Advanced Configuration and Power Interface}{25}{subsubsection.3.1.3.1}% +\contentsline {subsubsection}{\numberline {3.1.3.2}System Management Mode}{26}{subsubsection.3.1.3.2}% +\contentsline {subsection}{\numberline {3.1.4}Payload}{26}{subsection.3.1.4}% +\contentsline {section}{\numberline {3.2}AMD Platform Security Processor and Intel Management Engine}{27}{section.3.2}% +\contentsline {chapter}{\numberline {4}Memory initialization and training}{29}{chapter.4}% +\contentsline {section}{\numberline {4.1}Importance of DDR3 Memory Initialization}{29}{section.4.1}% +\contentsline {subsection}{\numberline {4.1.1}General steps for DDR3 configuration}{30}{subsection.4.1.1}% +\contentsline {section}{\numberline {4.2}Memory initialization techniques}{32}{section.4.2}% +\contentsline {subsection}{\numberline {4.2.1}Memory training algorithms}{32}{subsection.4.2.1}% +\contentsline {subsection}{\numberline {4.2.2}BIOS and Kernel Developer Guide (BKDG) recommendations}{33}{subsection.4.2.2}% +\contentsline {subsubsection}{\numberline {4.2.2.1}DDR3 initialization procedure}{34}{subsubsection.4.2.2.1}% +\contentsline {subsubsection}{\numberline {4.2.2.2}ZQ calibration process}{34}{subsubsection.4.2.2.2}% +\contentsline {subsubsection}{\numberline {4.2.2.3}Write leveling process}{35}{subsubsection.4.2.2.3}% +\contentsline {section}{\numberline {4.3}Current implementation and potential improvements [WIP]}{36}{section.4.3}% +\contentsline {subsection}{\numberline {4.3.1}Current implementation in coreboot on the KGPE-D16 [WIP]}{36}{subsection.4.3.1}% +\contentsline {subsection}{\numberline {4.3.2}Potential enhancements [WIP]}{37}{subsection.4.3.2}% +\contentsline {chapter}{\numberline {5}Virtualization of the operating system through firmware abstraction}{38}{chapter.5}% +\contentsline {section}{\numberline {5.1}ACPI and abstraction of hardware control}{38}{section.5.1}% +\contentsline {section}{\numberline {5.2}SMM as a hidden execution layer}{39}{section.5.2}% +\contentsline {section}{\numberline {5.3}UEFI and persistence}{39}{section.5.3}% +\contentsline {subsection}{\numberline {5.3.1}Memory Management}{40}{subsection.5.3.1}% +\contentsline {subsection}{\numberline {5.3.2}File System Management}{40}{subsection.5.3.2}% +\contentsline {subsection}{\numberline {5.3.3}Device Drivers}{40}{subsection.5.3.3}% +\contentsline {subsection}{\numberline {5.3.4}Power Management}{40}{subsection.5.3.4}% +\contentsline {section}{\numberline {5.4}Intel and AMD: control beyond the OS}{40}{section.5.4}% +\contentsline {section}{\numberline {5.5}The OS as a virtualized environment}{41}{section.5.5}% +\contentsline {chapter}{Conclusion}{42}{chapter*.4}% +\contentsline {chapter}{Bibliography}{43}{chapter*.4}% +\contentsline {chapter}{GNU Free Documentation License}{50}{chapter*.6}% diff --git a/images/fly-by.png b/images/fly-by.png new file mode 100644 index 0000000..596a1ef Binary files /dev/null and b/images/fly-by.png differ diff --git a/images/t.png b/images/t.png new file mode 100644 index 0000000..e213978 Binary files /dev/null and b/images/t.png differ diff --git a/listings/acpica_size.sh b/listings/acpica_size.sh new file mode 100644 index 0000000..223f459 --- /dev/null +++ b/listings/acpica_size.sh @@ -0,0 +1,5 @@ +$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git +$ cd linux/drivers/acpi +$ find . -name "*.c" -o -name "*.h" | xargs wc -l +[...] + 168970 total \ No newline at end of file diff --git a/packages.tex b/packages.tex index 561e447..8952cdb 100644 --- a/packages.tex +++ b/packages.tex @@ -9,28 +9,27 @@ % Free Documentation License". \documentclass[french, 11pt]{report} - \usepackage[utf8]{inputenc} - \usepackage{url} - \usepackage{float} - \usepackage{fontspec} - \usepackage[hidelinks]{hyperref} - \usepackage{setspace} - \usepackage[style=numeric]{biblatex} - \usepackage{tocloft} - \usepackage{titlesec} - \usepackage[T1]{fontenc} - \usepackage[english]{babel} - \usepackage{graphicx} - \usepackage{listing} - \usepackage{minted} - \usepackage{xcolor} - \usepackage{chngcntr} - \usepackage{changepage} - \usepackage{array} - \usepackage[a4paper, portrait, margin=1.45cm]{geometry} - \title{Titre du mémoire} - \author{Nom et prénom de l'auteur} - \date{\today} + \usepackage[utf8]{inputenc} + \usepackage{url} + \usepackage{float} + \usepackage{fontspec} + \usepackage[hidelinks]{hyperref} + \usepackage{setspace} + \usepackage[style=numeric]{biblatex} + \usepackage{tocloft} + \usepackage{titlesec} + \usepackage[T1]{fontenc} + \usepackage[english]{babel} + \usepackage{graphicx} + \usepackage{listing} + \usepackage{minted} + \usepackage{xcolor} + \usepackage{chngcntr} + \usepackage{changepage} + \usepackage{array} + \usepackage{tikz} + \usetikzlibrary{automata, positioning} + \usepackage[a4paper, portrait, margin=1.45cm]{geometry} % Set parameters \setcounter{page}{0}