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

Compare commits

base: GNUBoot:207fa28d1a61e4ff9a0ee47a891d93f6ac0d2552
Branches Tags
GNUBoot:main
GNUBoot:1.1
GNUBoot:1.0
GNUBoot:0.2
GNUBoot:0.1
...
compare: GNUBoot:45cf64ecdb4d357ee67104b5404d065a00906968
Branches Tags
GNUBoot:main
GNUBoot:1.1
GNUBoot:1.0
GNUBoot:0.2
GNUBoot:0.1

10 Commits
207fa28d1a ... 45cf64ecdb

Author SHA1 Message Date
Adrien Bourmault 45cf64ecdb
bump to 1.1 2024-08-28 17:25:36 +02:00
Adrien Bourmault d1e389ea1a
fix: missing newline 2024-08-28 17:23:41 +02:00
Adrien Bourmault 6a892a695e
All clear 2024-08-28 17:03:16 +02:00
Adrien Bourmault a78b9177e0
Correction FSF thanks 2024-08-28 11:01:20 +02:00
Adrien Bourmault 17b00a0981
Minor fixes 2024-08-27 19:16:50 +02:00
Adrien Bourmault 26cc57786d
Add a .gitignore 2024-08-27 16:05:37 +02:00
Adrien Bourmault f9fce67871
Multiple fixes and enhancements 2024-08-27 16:03:22 +02:00
Adrien Bourmault 60cb132e76
Minor corrections 2024-08-27 14:20:57 +02:00
Adrien Bourmault b4be19c30d
Clarifications on GNU Boot 2024-08-27 14:19:02 +02:00
Adrien Bourmault 65645f7625
Minor correction 2024-08-27 14:15:12 +02:00
16 changed files with 508 additions and 394 deletions
Show Stats Expand all files Collapse all files

10
.gitignore vendored Normal file
View File

@ -0,0 +1,10 @@
_minted*/
*.aux
*.bibready
*.bcf
*.blg
*.lof
*.lol
*.log
*.out
*.xml

14
Makefile
View File

@ -7,10 +7,11 @@ DOC=hardware_init_review
all: $(DOC).pdf
clean:
rm -rf *.log *.bak *.out *.xml *.gz *.aux *.bcf *.blg
rm -rf *.log *.bak *.out *.xml *.gz *.aux *.blg *.toc
rm -rf *.lof *.lol *.bbl _minted-hardware_init_review
distclean: clean
rm -rf *.bbl *.lof *.lol *.pdf *.toc $(DOC).bibready _minted-hardware_init_review
rm -rf *.bcf *.pdf $(DOC).bibready
$(DOC).bibready:
$(XELATEX) $(DOC).tex
@ -19,11 +20,6 @@ $(DOC).bibready:
$(DOC).bbl: $(DOC).bibready bibliographie.bib
biber $(DOC)
$(DOC).aux:
$(XELATEX) $(DOC).tex
$(DOC).pdf: $(DOC).bbl $(DOC).aux *.tex listings/*
$(XELATEX) $(DOC).tex
force_update: $(DOC).toc
$(DOC).pdf: $(DOC).bbl *.tex listings/*
$(XELATEX) $(DOC).tex
$(XELATEX) $(DOC).tex

112
bibliographie.bib
View File

@ -46,14 +46,6 @@ url = "https://www.lip6.fr/",
note = "[Online; accessed 7-May-2024]"
}
@misc{lip6_annuaire,
author = "Sorbonne Université/CNRS",
title = "Annuaire LIP6",
year = "2024",
url = "https://www.lip6.fr/recherche/resultat.php?keyword=&find=Rechercher+au+LIP6",
note = "[Online; accessed 7-May-2024]"
}
@inbook{BKDG,
author = {AMD},
institution = {Advanced Micro Devices, Inc.},
@ -246,21 +238,23 @@ note = "[Online; accessed 8-May-2024]"
@misc{intel_me,
author = {{Intel Corporation}},
title = {Intel Management Engine (Intel ME)},
howpublished = {\url{https://www.intel.com/content/www/us/en/architecture-and-technology/intel-management-engine.html}},
howpublished = {\url{https://www.intel.com/content/www/us/en/support/articles/000008927/software/chipset-software.html}},
note = {Accessed: 2024-07-05}
}
@misc{amd_psp,
author = {{AMD}},
title = {AMD Platform Security Processor (PSP)},
howpublished = {\url{https://www.amd.com/en/technologies/security}},
note = {Accessed: 2024-07-05}
@misc{herrmann2017dissecting,
author = {Herrmann, Maximilian and Niemietz, Martin},
title = {Dissecting the AMD Platform Security Processor},
howpublished = {Conference presentation at the 34th Chaos Communication Congress (34C3)},
year = {2017},
url = {https://media.ccc.de/v/thms-38-dissecting-the-amd-platform-security-processor},
note = {Accessed: 2024-08-27}
}
@misc{acpi_spec,
author = {ACPI},
author = {UEFI Forum},
title = {ACPI Specification},
howpublished = {\url{https://www.acpi.info/spec.htm}},
howpublished = {\url{https://uefi.org/sites/default/files/resources/ACPI_Spec_6_5_Aug29.pdf}},
note = {Accessed: 2024-07-05}
}
@ -328,13 +322,6 @@ note = "[Online; accessed 8-May-2024]"
howpublished = {\url{https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-firmware}},
}
@misc{anderson_2018,
author = {Anderson, T.},
title = {BIOS vs. UEFI: Understanding the Modern Boot Environment},
year = {2018},
howpublished = {\url{https://www.pcworld.com/article/3171322/bios-vs-uefi-understanding-the-modern-boot-environment.html}},
}
@article{wolf2006,
author = {Wolf, K.},
title = {Modern Boot Firmware: Moving from BIOS to UEFI},
@ -394,15 +381,6 @@ note = "[Online; accessed 8-May-2024]"
note = {Accessed: 2024-07-23}
}
@inproceedings{rudolph2007,
author = {Rudolph, M.},
title = {LinuxBIOS: Open Source Boot Firmware},
booktitle = {Proceedings of the Linux Symposium},
year = {2007},
pages = {159-167},
url = {https://ols.fedoraproject.org/OLS/Reprints-2007/rudolph-Reprint.pdf}
}
@misc{coreboot_payloads,
author = {coreboot project},
title = {coreboot Payloads},
@ -455,15 +433,6 @@ note = "[Online; accessed 8-May-2024]"
isbn = {978-0974364906}
}
@inproceedings{amd_psp_overview,
author = {David Kaplan and Jeremy Powell and Tom Woller},
title = {AMD Memory Encryption},
booktitle = {Architectural Support for Programming Languages and Operating Systems},
year = {2016},
pages = {149-160},
doi = {10.1145/2851141.2851148}
}
@techreport{intel_csme,
author = {Intel Corporation},
title = {Intel Converged Security and Management Engine (CSME) Security White Paper},
@ -822,14 +791,14 @@ note = "[Online; accessed 16-August-2024]"
@misc{vikings,
author = {{Vikings GmbH}},
title = {Vikings Hardware Recommendations for KGPE-D16},
url = {https://wiki.vikings.net/KGPE-D16},
url = {https://wiki.vikings.net/hardware:kgpe-d16?s[]=kgpe&s[]=d16},
note = {Accessed: 2024-08-17}
}
@misc{amd_chipsets,
author = {{Advanced Micro Devices (AMD)}},
title = {AMD Embedded Chipsets: SR5690 and SP5100},
url = {https://www.amd.com/en/products/embedded-chipsets},
title = {AMD SR5690 Databook},
url = {https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/datasheets/43869.pdf},
note = {Accessed: 2024-08-17}
}
@ -979,10 +948,9 @@ note = "[Online; accessed 17-August-2024]"
}
@manual{coreboot_mem_management,
title = {Coreboot Memory Management and Payload Allocation},
title = {Coreboot Developer Manual},
author = {{Coreboot Project}},
year = 2024,
url = {https://doc.coreboot.org/memory-map.html},
url = {https://www.coreboot.org/Developer_Manual},
note = {Accessed: 2024-08-17}
}
@ -1020,9 +988,9 @@ note = "[Online; accessed 17-August-2024]"
@manual{tianocore_payload,
title = {TianoCore as a Coreboot Payload},
author = {{TianoCore Project}},
year = 2024,
url = {https://doc.coreboot.org/payloads/tianocore.html},
author = {TianoCore Project},
year = {2019},
url = {https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload},
note = {Accessed: 2024-08-17}
}
@ -1202,12 +1170,20 @@ note = "[Online; accessed 17-August-2024]"
@misc{osdev_uefi_memory,
author = "{OSDev Wiki contributors}",
title = "{UEFI - OSDev Wiki}",
title = "{UEFI Memory - OSDev Wiki}",
year = "2024",
url = "https://wiki.osdev.org/UEFI#Memory",
note = "[Online; accessed 25-August-2024]"
}
@misc{osdev_uefi,
author = "{OSDev Wiki contributors}",
title = "{UEFI - OSDev Wiki}",
year = "2024",
url = "https://wiki.osdev.org/UEFI",
note = "[Online; accessed 25-August-2024]"
}
@manual{intel_acpi_introduction_2023,
title = {Introduction to ACPI},
author = {Intel Corporation},
@ -1232,4 +1208,38 @@ note = "[Online; accessed 17-August-2024]"
year = {2019},
note = {Accessed: 2024-08-24},
url = {https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.11}
}
@article{Intel2018,
title={Understanding Intel's Microcode},
author={Intel Corporation},
journal={Intel Developer's Manual},
year={2018},
note={Available online: https://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html}
}
@article{Wilcox2018,
title={Understanding and Mitigating the Microcode Update Latency},
author={Wilcox, J. and others},
journal={Proceedings of the 2018 IEEE International Symposium on High-Performance Computer Architecture},
year={2018},
pages={234-245},
publisher={IEEE}
}
@inproceedings{Abraham1983,
title={A Study of Redundant Logic in Microprocessors},
author={Abraham, J.A. and Breuer, M.A.},
booktitle={Proceedings of the 10th Annual International Symposium on Computer Architecture},
year={1983},
pages={116-126},
publisher={ACM}
}
@book{Johnson1989,
title={Fault-Tolerant Microprocessor Design},
author={Johnson, B.W.},
year={1989},
publisher={Prentice-Hall},
address={Englewood Cliffs, NJ}
}

469
hardware_init_review.bbl
View File

@ -19,6 +19,38 @@
\refsection{0}
\datalist[entry]{nty/global//global/global}
\entry{Abraham1983}{inproceedings}{}
\name{author}{2}{}{%
{{hash=145a88e2c450d43e758fabba735f6b2b}{%
family={Abraham},
familyi={A\bibinitperiod},
given={J.A.},
giveni={J\bibinitperiod}}}%
{{hash=41601f087622b21f9a4a945ff2992e15}{%
family={Breuer},
familyi={B\bibinitperiod},
given={M.A.},
giveni={M\bibinitperiod}}}%
}
\list{publisher}{1}{%
{ACM}%
}
\strng{namehash}{30178f517a17fa3a49a1ee29837ca525}
\strng{fullhash}{30178f517a17fa3a49a1ee29837ca525}
\strng{bibnamehash}{30178f517a17fa3a49a1ee29837ca525}
\strng{authorbibnamehash}{30178f517a17fa3a49a1ee29837ca525}
\strng{authornamehash}{30178f517a17fa3a49a1ee29837ca525}
\strng{authorfullhash}{30178f517a17fa3a49a1ee29837ca525}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{Proceedings of the 10th Annual International Symposium on Computer Architecture}
\field{title}{A Study of Redundant Logic in Microprocessors}
\field{year}{1983}
\field{pages}{116\bibrangedash 126}
\range{pages}{11}
\endentry
\entry{acmcs2015}{article}{}
\name{author}{1}{}{%
{{hash=dd350c00debd90eb907e07a437681ea9}{%
@ -46,28 +78,7 @@
\verb 10.1145/2766462
\endverb
\endentry
\entry{acpi_spec}{misc}{}
\name{author}{1}{}{%
{{hash=970d747229841c61b3c063fb45baa9e7}{%
family={ACPI},
familyi={A\bibinitperiod}}}%
}
\strng{namehash}{970d747229841c61b3c063fb45baa9e7}
\strng{fullhash}{970d747229841c61b3c063fb45baa9e7}
\strng{bibnamehash}{970d747229841c61b3c063fb45baa9e7}
\strng{authorbibnamehash}{970d747229841c61b3c063fb45baa9e7}
\strng{authornamehash}{970d747229841c61b3c063fb45baa9e7}
\strng{authorfullhash}{970d747229841c61b3c063fb45baa9e7}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{howpublished}{\url{https://www.acpi.info/spec.htm}}
\field{note}{Accessed: 2024-07-05}
\field{title}{ACPI Specification}
\true{nocite}
\endentry
\entry{amd_chipsets}{misc}{}
\entry{amd_bsp}{manual}{}
\name{author}{1}{}{%
{{hash=ec549314e642f60d59af16514cec0835}{%
family={{Advanced Micro Devices (AMD)}},
@ -85,15 +96,16 @@
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{note}{Accessed: 2024-08-17}
\field{title}{AMD Embedded Chipsets: SR5690 and SP5100}
\field{title}{AMD Family 15h Models 30h-3Fh Processors BIOS and Kernel Developer's Guide}
\field{year}{2014}
\verb{urlraw}
\verb https://www.amd.com/en/products/embedded-chipsets
\verb https://www.amd.com/system/files/TechDocs/48751_15h_Mod_30h-3Fh_BKDG.pdf
\endverb
\verb{url}
\verb https://www.amd.com/en/products/embedded-chipsets
\verb https://www.amd.com/system/files/TechDocs/48751_15h_Mod_30h-3Fh_BKDG.pdf
\endverb
\endentry
\entry{amd_bsp}{manual}{}
\entry{amd_chipsets}{misc}{}
\name{author}{1}{}{%
{{hash=ec549314e642f60d59af16514cec0835}{%
family={{Advanced Micro Devices (AMD)}},
@ -111,13 +123,12 @@
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{note}{Accessed: 2024-08-17}
\field{title}{AMD Family 15h Models 30h-3Fh Processors BIOS and Kernel Developer's Guide}
\field{year}{2014}
\field{title}{AMD SR5690 Databook}
\verb{urlraw}
\verb https://www.amd.com/system/files/TechDocs/48751_15h_Mod_30h-3Fh_BKDG.pdf
\verb https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/datasheets/43869.pdf
\endverb
\verb{url}
\verb https://www.amd.com/system/files/TechDocs/48751_15h_Mod_30h-3Fh_BKDG.pdf
\verb https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/datasheets/43869.pdf
\endverb
\endentry
\entry{altera2008}{inproceedings}{}
@ -194,28 +205,6 @@
\verb https://developer.amd.com/
\endverb
\endentry
\entry{amd_psp}{misc}{}
\name{author}{1}{}{%
{{hash=48af4341f745163f945fa838eeabb062}{%
family={{AMD}},
familyi={A\bibinitperiod}}}%
}
\strng{namehash}{48af4341f745163f945fa838eeabb062}
\strng{fullhash}{48af4341f745163f945fa838eeabb062}
\strng{bibnamehash}{48af4341f745163f945fa838eeabb062}
\strng{authorbibnamehash}{48af4341f745163f945fa838eeabb062}
\strng{authornamehash}{48af4341f745163f945fa838eeabb062}
\strng{authorfullhash}{48af4341f745163f945fa838eeabb062}
\field{extraname}{3}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{howpublished}{\url{https://www.amd.com/en/technologies/security}}
\field{note}{Accessed: 2024-07-05}
\field{title}{AMD Platform Security Processor (PSP)}
\true{nocite}
\endentry
\entry{BKDG}{inbook}{}
\name{author}{1}{}{%
{{hash=48af4341f745163f945fa838eeabb062}{%
@ -231,7 +220,7 @@
\strng{authorbibnamehash}{48af4341f745163f945fa838eeabb062}
\strng{authornamehash}{48af4341f745163f945fa838eeabb062}
\strng{authorfullhash}{48af4341f745163f945fa838eeabb062}
\field{extraname}{4}
\field{extraname}{3}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
@ -253,7 +242,7 @@
\strng{authorbibnamehash}{48af4341f745163f945fa838eeabb062}
\strng{authornamehash}{48af4341f745163f945fa838eeabb062}
\strng{authorfullhash}{48af4341f745163f945fa838eeabb062}
\field{extraname}{5}
\field{extraname}{4}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
@ -284,7 +273,7 @@
\strng{authorbibnamehash}{48af4341f745163f945fa838eeabb062}
\strng{authornamehash}{48af4341f745163f945fa838eeabb062}
\strng{authorfullhash}{48af4341f745163f945fa838eeabb062}
\field{extraname}{6}
\field{extraname}{5}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
@ -307,7 +296,7 @@
\strng{authorbibnamehash}{48af4341f745163f945fa838eeabb062}
\strng{authornamehash}{48af4341f745163f945fa838eeabb062}
\strng{authorfullhash}{48af4341f745163f945fa838eeabb062}
\field{extraname}{7}
\field{extraname}{6}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
@ -329,7 +318,7 @@
\strng{authorbibnamehash}{48af4341f745163f945fa838eeabb062}
\strng{authornamehash}{48af4341f745163f945fa838eeabb062}
\strng{authorfullhash}{48af4341f745163f945fa838eeabb062}
\field{extraname}{8}
\field{extraname}{7}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
@ -340,28 +329,6 @@
\field{year}{2012}
\true{nocite}
\endentry
\entry{anderson_2018}{misc}{}
\name{author}{1}{}{%
{{hash=d582579a02c17863648cd49b1c91560b}{%
family={Anderson},
familyi={A\bibinitperiod},
given={T.},
giveni={T\bibinitperiod}}}%
}
\strng{namehash}{d582579a02c17863648cd49b1c91560b}
\strng{fullhash}{d582579a02c17863648cd49b1c91560b}
\strng{bibnamehash}{d582579a02c17863648cd49b1c91560b}
\strng{authorbibnamehash}{d582579a02c17863648cd49b1c91560b}
\strng{authornamehash}{d582579a02c17863648cd49b1c91560b}
\strng{authorfullhash}{d582579a02c17863648cd49b1c91560b}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{howpublished}{\url{https://www.pcworld.com/article/3171322/bios-vs-uefi-understanding-the-modern-boot-environment.html}}
\field{title}{BIOS vs. UEFI: Understanding the Modern Boot Environment}
\field{year}{2018}
\endentry
\entry{ibm_pc}{misc}{}
\name{author}{1}{}{%
{{hash=f374c5f07cf19169f9b9d346dd5dc48b}{%
@ -735,13 +702,12 @@
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{note}{Accessed: 2024-08-17}
\field{title}{Coreboot Memory Management and Payload Allocation}
\field{year}{2024}
\field{title}{Coreboot Developer Manual}
\verb{urlraw}
\verb https://doc.coreboot.org/memory-map.html
\verb https://www.coreboot.org/Developer_Manual
\endverb
\verb{url}
\verb https://doc.coreboot.org/memory-map.html
\verb https://www.coreboot.org/Developer_Manual
\endverb
\endentry
\entry{coreboot_4_11}{misc}{}
@ -921,7 +887,7 @@
\verb https://www.intel.com/content/www/us/en/developer/articles/technical/system-management-mode.html
\endverb
\endentry
\entry{intel_uefi}{misc}{}
\entry{Intel2018}{article}{}
\name{author}{1}{}{%
{{hash=42af28f239d9ce2a4d0f9a032741150e}{%
family={Corporation},
@ -940,6 +906,30 @@
\field{sortinithash}{4d103a86280481745c9c897c925753c0}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Intel Developer's Manual}
\field{note}{Available online: https://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html}
\field{title}{Understanding Intel's Microcode}
\field{year}{2018}
\endentry
\entry{intel_uefi}{misc}{}
\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}{7}
\field{sortinit}{C}
\field{sortinithash}{4d103a86280481745c9c897c925753c0}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{howpublished}{\url{https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface.html}}
\field{title}{Unified Extensible Firmware Interface (UEFI)}
\field{year}{2020}
@ -958,7 +948,7 @@
\strng{authorbibnamehash}{91da9dc9e484daf8dc9ed72055907025}
\strng{authornamehash}{91da9dc9e484daf8dc9ed72055907025}
\strng{authorfullhash}{91da9dc9e484daf8dc9ed72055907025}
\field{extraname}{7}
\field{extraname}{8}
\field{sortinit}{C}
\field{sortinithash}{4d103a86280481745c9c897c925753c0}
\field{labelnamesource}{author}
@ -1145,7 +1135,7 @@
\field{pages}{27\bibrangedash 41}
\range{pages}{15}
\endentry
\entry{uefi_spec}{misc}{}
\entry{acpi_spec}{misc}{}
\name{author}{1}{}{%
{{hash=c4a3e6668448f707c96f886df3346fc0}{%
family={Forum},
@ -1164,6 +1154,30 @@
\field{sortinithash}{2638baaa20439f1b5a8f80c6c08a13b4}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{howpublished}{\url{https://uefi.org/sites/default/files/resources/ACPI_Spec_6_5_Aug29.pdf}}
\field{note}{Accessed: 2024-07-05}
\field{title}{ACPI Specification}
\true{nocite}
\endentry
\entry{uefi_spec}{misc}{}
\name{author}{1}{}{%
{{hash=c4a3e6668448f707c96f886df3346fc0}{%
family={Forum},
familyi={F\bibinitperiod},
given={UEFI},
giveni={U\bibinitperiod}}}%
}
\strng{namehash}{c4a3e6668448f707c96f886df3346fc0}
\strng{fullhash}{c4a3e6668448f707c96f886df3346fc0}
\strng{bibnamehash}{c4a3e6668448f707c96f886df3346fc0}
\strng{authorbibnamehash}{c4a3e6668448f707c96f886df3346fc0}
\strng{authornamehash}{c4a3e6668448f707c96f886df3346fc0}
\strng{authorfullhash}{c4a3e6668448f707c96f886df3346fc0}
\field{extraname}{2}
\field{sortinit}{F}
\field{sortinithash}{2638baaa20439f1b5a8f80c6c08a13b4}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{howpublished}{\url{https://uefi.org/specifications}}
\field{title}{UEFI Specification}
\field{year}{2021}
@ -1182,7 +1196,7 @@
\strng{authorbibnamehash}{c4a3e6668448f707c96f886df3346fc0}
\strng{authornamehash}{c4a3e6668448f707c96f886df3346fc0}
\strng{authorfullhash}{c4a3e6668448f707c96f886df3346fc0}
\field{extraname}{2}
\field{extraname}{3}
\field{sortinit}{F}
\field{sortinithash}{2638baaa20439f1b5a8f80c6c08a13b4}
\field{labelnamesource}{author}
@ -1508,6 +1522,40 @@
\verb https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf
\endverb
\endentry
\entry{herrmann2017dissecting}{misc}{}
\name{author}{2}{}{%
{{hash=e18ff7cbbfcdc61f56502bf602f3d175}{%
family={Herrmann},
familyi={H\bibinitperiod},
given={Maximilian},
giveni={M\bibinitperiod}}}%
{{hash=4f9a2ad1ebed231172893123b8cfd84b}{%
family={Niemietz},
familyi={N\bibinitperiod},
given={Martin},
giveni={M\bibinitperiod}}}%
}
\strng{namehash}{325ce8bcc71d701e0ea670c133512cdb}
\strng{fullhash}{325ce8bcc71d701e0ea670c133512cdb}
\strng{bibnamehash}{325ce8bcc71d701e0ea670c133512cdb}
\strng{authorbibnamehash}{325ce8bcc71d701e0ea670c133512cdb}
\strng{authornamehash}{325ce8bcc71d701e0ea670c133512cdb}
\strng{authorfullhash}{325ce8bcc71d701e0ea670c133512cdb}
\field{sortinit}{H}
\field{sortinithash}{23a3aa7c24e56cfa16945d55545109b5}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{howpublished}{Conference presentation at the 34th Chaos Communication Congress (34C3)}
\field{note}{Accessed: 2024-08-27}
\field{title}{Dissecting the AMD Platform Security Processor}
\field{year}{2017}
\verb{urlraw}
\verb https://media.ccc.de/v/thms-38-dissecting-the-amd-platform-security-processor
\endverb
\verb{url}
\verb https://media.ccc.de/v/thms-38-dissecting-the-amd-platform-security-processor
\endverb
\endentry
\entry{hill_impact_caching}{article}{}
\name{author}{2}{}{%
{{hash=c5fd1af61abfb4398ded7625bf0ea46f}{%
@ -1612,7 +1660,7 @@
\field{sortinithash}{8d291c51ee89b6cd86bf5379f0b151d8}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{howpublished}{\url{https://www.intel.com/content/www/us/en/architecture-and-technology/intel-management-engine.html}}
\field{howpublished}{\url{https://www.intel.com/content/www/us/en/support/articles/000008927/software/chipset-software.html}}
\field{note}{Accessed: 2024-07-05}
\field{title}{Intel Management Engine (Intel ME)}
\true{nocite}
@ -1643,6 +1691,34 @@
\verb https://io.netgarage.org/me/
\endverb
\endentry
\entry{Johnson1989}{book}{}
\name{author}{1}{}{%
{{hash=4b4d002de5f92b71453190d67ffb47fe}{%
family={Johnson},
familyi={J\bibinitperiod},
given={B.W.},
giveni={B\bibinitperiod}}}%
}
\list{location}{1}{%
{Englewood Cliffs, NJ}%
}
\list{publisher}{1}{%
{Prentice-Hall}%
}
\strng{namehash}{4b4d002de5f92b71453190d67ffb47fe}
\strng{fullhash}{4b4d002de5f92b71453190d67ffb47fe}
\strng{bibnamehash}{4b4d002de5f92b71453190d67ffb47fe}
\strng{authorbibnamehash}{4b4d002de5f92b71453190d67ffb47fe}
\strng{authornamehash}{4b4d002de5f92b71453190d67ffb47fe}
\strng{authorfullhash}{4b4d002de5f92b71453190d67ffb47fe}
\field{sortinit}{J}
\field{sortinithash}{b2f54a9081ace9966a7cb9413811edb4}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{title}{Fault-Tolerant Microprocessor Design}
\field{year}{1989}
\true{nocite}
\endentry
\entry{openbmc_customization}{article}{}
\name{author}{1}{}{%
{{hash=5a25bc91f524ca6dfc2ecf9f4a13903c}{%
@ -1704,43 +1780,6 @@
\verb https://opensecuritytraining.info/IntroBIOS_files/Day1_07_Advanced%20x86%20-%20BIOS%20and%20SMM%20Internals%20-%20SMM.pdf
\endverb
\endentry
\entry{amd_psp_overview}{inproceedings}{}
\name{author}{3}{}{%
{{hash=9aa60a0635fc104c28dda319ab8cca3d}{%
family={Kaplan},
familyi={K\bibinitperiod},
given={David},
giveni={D\bibinitperiod}}}%
{{hash=50223c62dee7675ba8f24e625d026c27}{%
family={Powell},
familyi={P\bibinitperiod},
given={Jeremy},
giveni={J\bibinitperiod}}}%
{{hash=f05ca959cba94cb91d78975fcbee4787}{%
family={Woller},
familyi={W\bibinitperiod},
given={Tom},
giveni={T\bibinitperiod}}}%
}
\strng{namehash}{b5e851ee8429e8e91668d1d3551901cd}
\strng{fullhash}{b5e851ee8429e8e91668d1d3551901cd}
\strng{bibnamehash}{b5e851ee8429e8e91668d1d3551901cd}
\strng{authorbibnamehash}{b5e851ee8429e8e91668d1d3551901cd}
\strng{authornamehash}{b5e851ee8429e8e91668d1d3551901cd}
\strng{authorfullhash}{b5e851ee8429e8e91668d1d3551901cd}
\field{sortinit}{K}
\field{sortinithash}{c02bf6bff1c488450c352b40f5d853ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{Architectural Support for Programming Languages and Operating Systems}
\field{title}{AMD Memory Encryption}
\field{year}{2016}
\field{pages}{149\bibrangedash 160}
\range{pages}{12}
\verb{doi}
\verb 10.1145/2851141.2851148
\endverb
\endentry
\entry{kim2010design}{inproceedings}{}
\name{author}{3}{}{%
{{hash=8220787d0eaa6f1c680840bf616c1cf4}{%
@ -2562,6 +2601,33 @@
\verb https://wiki.osdev.org/GOP
\endverb
\endentry
\entry{osdev_uefi}{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{extraname}{1}
\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}
\verb{urlraw}
\verb https://wiki.osdev.org/UEFI
\endverb
\verb{url}
\verb https://wiki.osdev.org/UEFI
\endverb
\endentry
\entry{osdev_uefi_memory}{misc}{}
\name{author}{1}{}{%
{{hash=981adb9ea98beb2d8a06e293991365f1}{%
@ -2574,12 +2640,13 @@
\strng{authorbibnamehash}{981adb9ea98beb2d8a06e293991365f1}
\strng{authornamehash}{981adb9ea98beb2d8a06e293991365f1}
\strng{authorfullhash}{981adb9ea98beb2d8a06e293991365f1}
\field{extraname}{2}
\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{title}{{UEFI Memory - OSDev Wiki}}
\field{year}{2024}
\verb{urlraw}
\verb https://wiki.osdev.org/UEFI#Memory
@ -2624,6 +2691,7 @@
\strng{authorbibnamehash}{30947d4473970fd63cd5dcb7c90a8e4a}
\strng{authornamehash}{30947d4473970fd63cd5dcb7c90a8e4a}
\strng{authorfullhash}{30947d4473970fd63cd5dcb7c90a8e4a}
\field{extraname}{1}
\field{sortinit}{P}
\field{sortinithash}{ff3bcf24f47321b42cb156c2cc8a8422}
\field{labelnamesource}{author}
@ -2711,6 +2779,35 @@
\field{note}{Accessed: 2024-07-23}
\field{title}{coreboot: Open Source Firmware}
\endentry
\entry{tianocore_payload}{manual}{}
\name{author}{1}{}{%
{{hash=3bca4e299598e8c88e9dbc747a8b3c5c}{%
family={Project},
familyi={P\bibinitperiod},
given={TianoCore},
giveni={T\bibinitperiod}}}%
}
\strng{namehash}{3bca4e299598e8c88e9dbc747a8b3c5c}
\strng{fullhash}{3bca4e299598e8c88e9dbc747a8b3c5c}
\strng{bibnamehash}{3bca4e299598e8c88e9dbc747a8b3c5c}
\strng{authorbibnamehash}{3bca4e299598e8c88e9dbc747a8b3c5c}
\strng{authornamehash}{3bca4e299598e8c88e9dbc747a8b3c5c}
\strng{authorfullhash}{3bca4e299598e8c88e9dbc747a8b3c5c}
\field{extraname}{2}
\field{sortinit}{P}
\field{sortinithash}{ff3bcf24f47321b42cb156c2cc8a8422}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{note}{Accessed: 2024-08-17}
\field{title}{TianoCore as a Coreboot Payload}
\field{year}{2019}
\verb{urlraw}
\verb https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload
\endverb
\verb{url}
\verb https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload
\endverb
\endentry
\entry{raptor_engineering}{misc}{}
\name{author}{1}{}{%
{{hash=569ce67269d64596584ac37190233093}{%
@ -2826,36 +2923,6 @@
\field{year}{1994}
\true{nocite}
\endentry
\entry{rudolph2007}{inproceedings}{}
\name{author}{1}{}{%
{{hash=9f897e096e6193a84feb0a5b0ca95d1e}{%
family={Rudolph},
familyi={R\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
}
\strng{namehash}{9f897e096e6193a84feb0a5b0ca95d1e}
\strng{fullhash}{9f897e096e6193a84feb0a5b0ca95d1e}
\strng{bibnamehash}{9f897e096e6193a84feb0a5b0ca95d1e}
\strng{authorbibnamehash}{9f897e096e6193a84feb0a5b0ca95d1e}
\strng{authornamehash}{9f897e096e6193a84feb0a5b0ca95d1e}
\strng{authorfullhash}{9f897e096e6193a84feb0a5b0ca95d1e}
\field{sortinit}{R}
\field{sortinithash}{5e1c39a9d46ffb6bebd8f801023a9486}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{Proceedings of the Linux Symposium}
\field{title}{LinuxBIOS: Open Source Boot Firmware}
\field{year}{2007}
\field{pages}{159\bibrangedash 167}
\range{pages}{9}
\verb{urlraw}
\verb https://ols.fedoraproject.org/OLS/Reprints-2007/rudolph-Reprint.pdf
\endverb
\verb{url}
\verb https://ols.fedoraproject.org/OLS/Reprints-2007/rudolph-Reprint.pdf
\endverb
\endentry
\entry{russinovich2012}{book}{}
\name{author}{3}{}{%
{{hash=4c2da4e3b650f0a6bffc044b397680cc}{%
@ -3190,32 +3257,6 @@
\verb https://www.aspeedtech.com/products.php?fPath=20&rId=29
\endverb
\endentry
\entry{tianocore_payload}{manual}{}
\name{author}{1}{}{%
{{hash=632f06b41d4b1b901fc37d1cf32e810f}{%
family={{TianoCore Project}},
familyi={T\bibinitperiod}}}%
}
\strng{namehash}{632f06b41d4b1b901fc37d1cf32e810f}
\strng{fullhash}{632f06b41d4b1b901fc37d1cf32e810f}
\strng{bibnamehash}{632f06b41d4b1b901fc37d1cf32e810f}
\strng{authorbibnamehash}{632f06b41d4b1b901fc37d1cf32e810f}
\strng{authornamehash}{632f06b41d4b1b901fc37d1cf32e810f}
\strng{authorfullhash}{632f06b41d4b1b901fc37d1cf32e810f}
\field{sortinit}{T}
\field{sortinithash}{9af77f0292593c26bde9a56e688eaee9}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{note}{Accessed: 2024-08-17}
\field{title}{TianoCore as a Coreboot Payload}
\field{year}{2024}
\verb{urlraw}
\verb https://doc.coreboot.org/payloads/tianocore.html
\endverb
\verb{url}
\verb https://doc.coreboot.org/payloads/tianocore.html
\endverb
\endentry
\entry{uefi_what_is_uefi}{manual}{}
\name{author}{1}{}{%
{{hash=018a60b8cb2aa8763314c4672515eee5}{%
@ -3242,36 +3283,6 @@
\verb https://uefi.org/sites/default/files/resources/What%20is%20UEFI-Aug31-2023-Final.pdf
\endverb
\endentry
\entry{lip6_annuaire}{misc}{}
\name{author}{1}{}{%
{{hash=a220fc1da6562fa2e1e0bc05c201b485}{%
family={Université/CNRS},
familyi={U\bibinitperiod},
given={Sorbonne},
giveni={S\bibinitperiod}}}%
}
\strng{namehash}{a220fc1da6562fa2e1e0bc05c201b485}
\strng{fullhash}{a220fc1da6562fa2e1e0bc05c201b485}
\strng{bibnamehash}{a220fc1da6562fa2e1e0bc05c201b485}
\strng{authorbibnamehash}{a220fc1da6562fa2e1e0bc05c201b485}
\strng{authornamehash}{a220fc1da6562fa2e1e0bc05c201b485}
\strng{authorfullhash}{a220fc1da6562fa2e1e0bc05c201b485}
\field{extraname}{1}
\field{sortinit}{U}
\field{sortinithash}{6901a00e45705986ee5e7ca9fd39adca}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{note}{[Online; accessed 7-May-2024]}
\field{title}{Annuaire LIP6}
\field{year}{2024}
\true{nocite}
\verb{urlraw}
\verb https://www.lip6.fr/recherche/resultat.php?keyword=&find=Rechercher+au+LIP6
\endverb
\verb{url}
\verb https://www.lip6.fr/recherche/resultat.php?keyword=&find=Rechercher+au+LIP6
\endverb
\endentry
\entry{lip6_web}{misc}{}
\name{author}{1}{}{%
{{hash=a220fc1da6562fa2e1e0bc05c201b485}{%
@ -3286,7 +3297,6 @@
\strng{authorbibnamehash}{a220fc1da6562fa2e1e0bc05c201b485}
\strng{authornamehash}{a220fc1da6562fa2e1e0bc05c201b485}
\strng{authorfullhash}{a220fc1da6562fa2e1e0bc05c201b485}
\field{extraname}{2}
\field{sortinit}{U}
\field{sortinithash}{6901a00e45705986ee5e7ca9fd39adca}
\field{labelnamesource}{author}
@ -3380,10 +3390,10 @@
\field{note}{Accessed: 2024-08-17}
\field{title}{Vikings Hardware Recommendations for KGPE-D16}
\verb{urlraw}
\verb https://wiki.vikings.net/KGPE-D16
\verb https://wiki.vikings.net/hardware:kgpe-d16?s[]=kgpe&s[]=d16
\endverb
\verb{url}
\verb https://wiki.vikings.net/KGPE-D16
\verb https://wiki.vikings.net/hardware:kgpe-d16?s[]=kgpe&s[]=d16
\endverb
\endentry
\entry{WangDong2019AIUb}{article}{}
@ -4049,6 +4059,35 @@
\verb https://en.wikipedia.org/w/index.php?title=X86&oldid=1221800539
\endverb
\endentry
\entry{Wilcox2018}{article}{}
\true{moreauthor}
\true{morelabelname}
\name{author}{1}{}{%
{{hash=d915a447c9041e20fdda667e3b695b20}{%
family={Wilcox},
familyi={W\bibinitperiod},
given={J.},
giveni={J\bibinitperiod}}}%
}
\list{publisher}{1}{%
{IEEE}%
}
\strng{namehash}{87362f1ffa0b785aa0493de03bf223e6}
\strng{fullhash}{87362f1ffa0b785aa0493de03bf223e6}
\strng{bibnamehash}{87362f1ffa0b785aa0493de03bf223e6}
\strng{authorbibnamehash}{87362f1ffa0b785aa0493de03bf223e6}
\strng{authornamehash}{87362f1ffa0b785aa0493de03bf223e6}
\strng{authorfullhash}{87362f1ffa0b785aa0493de03bf223e6}
\field{sortinit}{W}
\field{sortinithash}{4315d78024d0cea9b57a0c6f0e35ed0d}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Proceedings of the 2018 IEEE International Symposium on High-Performance Computer Architecture}
\field{title}{Understanding and Mitigating the Microcode Update Latency}
\field{year}{2018}
\field{pages}{234\bibrangedash 245}
\range{pages}{12}
\endentry
\entry{winbond}{manual}{}
\name{author}{1}{}{%
{{hash=506790477fe03844712a0c66579f17d0}{%

BIN
hardware_init_review.pdf
View File

Binary file not shown.

260
hardware_init_review.tex
View File

@ -14,11 +14,6 @@
\author{Adrien 'neox' Bourmault}
\date{\today}
% setup things
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
%\setcounter{secnumdepth}{4}
% setup bibliography
\addbibresource{bibliographie.bib}
@ -37,7 +32,7 @@
\setcounter{page}{2}
\vspace*{\fill} % fill the page so that text is at the bottom
This is Edition 0.2. \\
This is Edition 1.1. \\
Copyright \copyright\ 2024 Adrien 'neox' Bourmault
\href{mailto:neox@gnu.org}{<neox@gnu.org>} \\
@ -78,9 +73,12 @@
reviews throughout this period. \\
I wish to express my appreciation to the Free Software Foundation for
funding the necessary equipment for this project. Special thanks go to
Zoë Kooymann and Ian Kelling for their dedication in securing this funding
and for their kindness throughout all the procedures. \\
funding the necessary equipment for this project, especially to
the board members of the foundation, including Richard M. Stallman and
Odile Bénassy, for making the funding for this project possible.
Special thanks go to Zoë Kooyman and Ian Kelling for their exceptional
support in managing the hardware order and for their kindness and assistance
throughout the entire process. \\
I am deeply grateful to Denis Carikli (GNUtoo), my fellow GNU Boot
co-maintainer, for his meticulous reviews, emotional support, and brilliant
@ -285,7 +283,7 @@
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 \cite{anderson_2018}. Early BIOS
operations \cite{osdev_uefi}. 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
@ -302,7 +300,7 @@
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}.
technologies efficiently \cite{osdev_uefi}\cite{acmcs2015}.
\section{Modern BIOS and UEFI}
@ -352,7 +350,7 @@
security features such as \textit{Secure Boot}, which ensures that
only trusted software can be executed during the boot process,
thereby protecting the system from unauthorized modifications and
malware \cite{anderson_2018}\cite{chang2013}. \\
malware \cite{osdev_uefi}\cite{chang2013}. \\
The industry-wide support and standardization of UEFI have accelerated
its adoption across various platforms and devices. Major industry
@ -381,8 +379,8 @@
required to initialize hardware and pass control to a payload, such
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}
as there is less code that could be exploited by malicious actors.
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
@ -435,10 +433,16 @@
To address these concerns, the GNU Project has developed GNU Boot,
a fully free distribution of firmware, including \textit{coreboot},
that aims to be entirely free by avoiding the use of proprietary
binary blobs. GNU Boot is committed to using only free software
binary blobs.
GNU Boot is only a distribution: it reuses existing software projects
and is not very different from fully free GNU/Linux distributions like
Trisquel or Guix, as GNU Boot is committed to use only free software
for all aspects of firmware, making it a preferred choice for users
and organizations that prioritize software freedom and transparency
\cite{gnuboot}.
and organizations that prioritize software freedom and transparency.
Its goal include to build the software and assemble it in something
that can be installed, and also to test it and to provide installation
and upgrade instructions \cite{gnuboot}.
\section{Shift in firmware responsibilities}
@ -448,7 +452,7 @@
the CPU, memory, and essential peripherals before passing control to
the operating system's bootloader. This process was relatively simple,
given the limited capabilities and straightforward architecture of
early computer systems \cite{anderson_2018}.
early computer systems \cite{osdev_uefi}.
As computer systems advanced, particularly with the advent of more
sophisticated memory technologies, the role of firmware expanded
@ -490,7 +494,7 @@
firmware provides tools for enthusiasts to push their systems beyond
default limits. At the same time, it includes safeguards to manage
the risks of instability and hardware damage, balancing performance
gains with system reliability \cite{anderson_2018}. \\
gains with system reliability \cite{osdev_uefi}. \\
In summary, the evolution of firmware from simple hardware
initialization routines to complex management systems reflects the
@ -842,7 +846,7 @@
like the IOAPIC and TPM registers have dedicated address spaces.
This structured approach helps maintain system stability and
compatibility across different platforms and allows for a reset vector
fixed at an address (\textit{0xFFFFFFF0}), regardless of the ROM size.
fixed at an address (\texttt{0xFFFFFFF0}), regardless of the ROM size.
Payloads are typically loaded into high memory, above the reserved areas
for hardware components and system resources. The exact memory location
can vary depending on the system's configuration, but generally,
@ -1354,7 +1358,7 @@
of the main CPU. These subsystems are fundamental to the security
architecture of modern computing platforms, providing functions such as
secure boot, cryptographic key management, and remote system management
\cite{amd_psp_overview}.
\cite{herrmann2017dissecting}.
The AMD PSP is based on an ARM Cortex-A5 processor and is responsible
for several security functions, including the validation of firmware
@ -1362,7 +1366,7 @@
functions, and handling cryptographic operations such as key generation
and storage. The PSP operates independently of the main x86 cores,
which allows it to execute security functions even when the main system
is powered off or compromised by malware \cite{amd_psp_overview}.
is powered off or compromised by malware \cite{herrmann2017dissecting}.
The PSP's isolated environment ensures that sensitive operations are
protected from threats that could affect the main OS. \\
@ -2243,7 +2247,7 @@
containing crucial information for detecting and initializing
memory modules. \\
\begin{listing}
\begin{listing}[H]
\begin{adjustwidth}{0.5cm}{0.5cm}
\inputminted{c}{
listings/src_northbridge_amd_amdfam10_raminit_sysinfo_in_ram.c}
@ -2261,7 +2265,7 @@
(lst. \ref{lst:mctAutoInitMCT_D_1}) from
\path{src/northbridge/amd/amdmct/mct_ddr3/mct_d.c},
which is responsible for the initial memory initialization,
predominantly written by Raptor Engineering.
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
@ -2497,7 +2501,7 @@ if (nv_DQSTrainCTL) {
* below.*/
TrainReceiverEn_D(pMCTstat, pDCTstatA, FirstPass);
mct_TrainDQSPos_D(pMCTstat, pDCTstatA);
[...]
...
TrainMaxRdLatency_En_D(pMCTstat, pDCTstatA);
} else {
mct_WriteLevelization_HW(pMCTstat, pDCTstatA, FirstPass);
@ -2611,7 +2615,7 @@ mctHookAfterAnyTraining();
(\path{global_phy_training_status}) aggregates the results of
each step, tracking any persistent issues. \\
The \path{PhyWLPass1} and \path{PhyWLPass1} function relyon
The \path{PhyWLPass1} and \path{PhyWLPass2} function relyon
\path{AgesaHwWlPhase1}, \path{AgesaHwWlPhase2} and
\path{AgesaHwWlPhase3} for this. \\
@ -2668,7 +2672,8 @@ if (Pass == FirstPass) {
The write leveling process begins by selecting the target
DIMM. This is accomplished by programming the
\path{TrDimmSel} register to ensure that the subsequent
operations apply to the correct DIMM. \\
operations apply to the correct DIMM
(lst. \ref{lst:target_dimm_selection}) \\
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -2689,7 +2694,7 @@ set_DCT_ADDR_Bits(pDCTData, dct, pDCTData->NodeId, FUN_DCT,
memory configurations, write leveling must be performed
separately for each nibble (4-bit group). The function
checks if x4 DIMMs are present and, if so, prepares to train
both nibbles. \\
both nibbles (lst. \ref{lst:x4_dimm_handling}). \\
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -2709,7 +2714,8 @@ if (pDCTstat->Dimmx4Present)
The DIMMs are prepared for write leveling by issuing Mode
Register (MR) commands. These commands configure the DIMMs
to enter a state where write leveling can be performed. \\
to enter a state where write leveling can be performed
(lst. \ref{lst:prepare_dimms}). \\
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -2730,7 +2736,8 @@ prepareDimms(pMCTstat, pDCTstat, dct, dimm, TRUE);
gross and fine delays, which are essential for the
subsequent timing adjustments. \\
\path{procConfig} generates initial seed values for gross
\path{procConfig} generates initial seed values
(lst. \ref{lst:seed_generation}) for gross
and fine delays. These seeds are calculated based on several
factors:
@ -2775,7 +2782,8 @@ Seed_Fine = Seed_Total & 0x1f;
Write leveling is initiated by enabling the
\path{WrtLvTrEn} bit. This allows the DDR PHY to begin
adjusting the DQS signals relative to the clock signals. \\
adjusting the DQS signals relative to the clock signals
(lst. \ref{lst:initiate_write_leveling}). \\
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -2792,7 +2800,8 @@ set_DCT_ADDR_Bits(pDCTData, dct, pDCTData->NodeId, FUN_DCT,
\end{listing}
If the DIMM is not x4, the function skips the nibble
training loop, as it is unnecessary. \\
training loop, as it is unnecessary
(lst. \ref{lst:exit_non_x4}). \\
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -2810,9 +2819,10 @@ if ((pDCTstat->Dimmx4Present & (1 << (dimm + dct))) == 0)
After a delay to allow the leveling process to stabilize,
the function reads the gross and fine delay values from the
relevant registers and stores them. These values represent
the initial timing adjustments necessary for correct DQS
alignment. \\
relevant registers and stores them
(lst. \ref{lst:finalize_write_leveling}). These values
represent the initial timing adjustments necessary for
correct DQS alignment. \\
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -2837,7 +2847,8 @@ for (ByteLane = 0; ByteLane < lane_count; ByteLane++) {
The function \path{TrainDQSRdWrPos_D_Fam15} orchestrates this
process by iterating over memory lanes and adjusting timing
parameters to find optimal settings. It is called by
parameters to find optimal settings
(lst. \ref{lst:dqs_train_init}). It is called by
\path{mct_TrainDQSPos_D}. \\
The function begins by initializing several variables and
@ -2879,7 +2890,8 @@ for (Receiver = receiver_start; Receiver < receiver_end; Receiver++) {
For each lane in the memory channel, the function iterates over
possible write and read delay values to find the optimal
configuration. This is done by:
configuration (lst. \ref{lst:dqs_train_iteration}).
This is done by:
\begin{enumerate}
\item Iterating over the write data delay values from the
@ -2904,8 +2916,10 @@ for (current_write_data_delay[lane] = initial_write_dqs_delay[lane];
current_read_dqs_delay[lane] < 0x20;
current_read_dqs_delay[lane]++) {
...
write_dqs_read_data_timing_registers(current_read_dqs_delay, dev, dct, dimm, index_reg);
read_dram_dqs_training_pattern_fam15(pMCTstat, pDCTstat, dct, Receiver, lane, ((check_antiphase == 0)?1:0));
write_dqs_read_data_timing_registers(
current_read_dqs_delay, dev, dct, dimm, index_reg);
read_dram_dqs_training_pattern_fam15(
pMCTstat, pDCTstat, dct, Receiver, lane, ((check_antiphase == 0)?1:0));
...
}
}
@ -2926,8 +2940,8 @@ for (current_write_data_delay[lane] = initial_write_dqs_delay[lane];
\\
After iterating over all possible delay values, the function
processes the results to determine the best DQS delay settings.
\\
processes the results to determine the best DQS delay settings
(lst. \ref{lst:dqs_train_results}). \\
This is done by:
@ -2947,7 +2961,8 @@ for (current_write_data_delay[lane] = initial_write_dqs_delay[lane];
if (best_count > 2) {
uint16_t region_center = (best_pos + (best_count / 2));
if (region_center < 16) {
printk(BIOS_WARNING, "TrainDQSRdWrPos: negative DQS recovery delay detected!");
printk(BIOS_WARNING,
"TrainDQSRdWrPos: negative DQS recovery delay detected!");
region_center = 0;
} else {
region_center -= 16;
@ -2955,7 +2970,8 @@ if (best_count > 2) {
...
current_read_dqs_delay[lane] = region_center;
passing_dqs_delay_found[lane] = 1;
write_dqs_read_data_timing_registers(current_read_dqs_delay, dev, dct, dimm, index_reg);
write_dqs_read_data_timing_registers(
current_read_dqs_delay, dev, dct, dimm, index_reg);
}
\end{minted}
\end{adjustwidth}
@ -2967,7 +2983,8 @@ if (best_count > 2) {
\end{listing}
Finally, the function checks if any lane did not find a valid
passing region. If any lanes failed to find a passing DQS delay,
passing region (lst. \ref{lst:dqs_train_finalize}).
If any lanes failed to find a passing DQS delay,
the \path{Errors} flag is set, and this error is propagated
through the \path{pDCTstat->TrainErrors} and
\path{pDCTstat->ErrStatus} variables.
@ -2996,16 +3013,6 @@ return !Errors;
\label{lst:dqs_train_finalize}
\end{listing}
The DQS position training algorithm implemented in the
\path{TrainDQSRdWrPos_D_Fam15} function systematically explores
the possible delay settings for reading and writing operations
in the memory system. By iterating over a range of values, the
function identifies the optimal delays that result in reliable
data transfer. The results are carefully processed to ensure
that the best possible settings are applied, with checks and
balances in place to handle edge cases and potential errors.
\\
\subsubsection{Details on the DQS receiver training function}
In AMD Fam15h G34 processors, the DQS receiver enable training
@ -3042,7 +3049,8 @@ return !Errors;
are specific to the memory configuration and are adjusted based
on the type of DIMM and the number of DIMMs in each channel. \\
The generated seed values are then adjusted based on the
The generated seed values are then adjusted
(lst. \ref{lst:seed_adjustment}) based on the
operating frequency of the memory (MEMCLK). The adjustment
scales the seed values to account for the difference between
the current memory frequency and the minimum supported
@ -3065,7 +3073,8 @@ initial_seed = (uint16_t) (((((uint64_t) initial_seed) *
\end{listing}
Once the seeds are generated and adjusted, they are used to set
the initial delay values for the DQS receiver enable training.
the initial delay values for the DQS receiver enable training
(lst. \ref{lst:initial_delay_values}).
The delay values are split into two components: gross delay and
fine delay. The gross delay determines the overall timing
offset, while the fine delay adjusts the timing with finer
@ -3106,7 +3115,7 @@ for (lane = 0; lane < lane_count; lane++) {
prepared for training. This includes enabling the training mode,
configuring the memory channels, and disabling certain features
such as ECC (Error-Correcting Code) to prevent interference
during training. \\
during training (lst. \ref{lst:initialization_phase}). \\
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -3115,7 +3124,7 @@ fam15EnableTrainingMode(pMCTstat, pDCTstat, ch, 1);
_DisableDramECC = mct_DisableDimmEccEn_D(pMCTstat, pDCTstat);
\end{minted}
\end{adjustwidth}
\caption{Initialization phase: Enabling training mode and disabling ECC,
\caption{Enabling training mode and disabling ECC,
extract from
\protect\path{dqsTrainRcvrEn_SW_Fam15} function in
\protect\path{src/northbridge/amd/amdmct/mct_ddr3/mctsrc.c}}
@ -3124,7 +3133,8 @@ _DisableDramECC = mct_DisableDimmEccEn_D(pMCTstat, pDCTstat);
The training phase is where the actual alignment of the DQS
signal occurs. The memory controller iterates over each DIMM and
each lane, applying the seed values and adjusting the delay
each lane (lst. \ref{lst:training_phase}),
applying the seed values and adjusting the delay
registers accordingly. For each DIMM, the training is performed
twice: once for the first nibble (lower 4 bits) and once for
the second nibble (upper 4 bits) if the DIMM is x4. \\
@ -3135,7 +3145,8 @@ _DisableDramECC = mct_DisableDimmEccEn_D(pMCTstat, pDCTstat);
for (rank = 0; rank < (_2Ranks + 1); rank++) {
for (nibble = 0; nibble < (train_both_nibbles + 1); nibble++) {
...
write_dqs_receiver_enable_control_registers(current_total_delay, dev, Channel, dimm, index_reg);
write_dqs_receiver_enable_control_registers(
current_total_delay, dev, Channel, dimm, index_reg);
...
}
}
@ -3154,7 +3165,8 @@ for (rank = 0; rank < (_2Ranks + 1); rank++) {
is correctly aligned across all lanes and ranks. \\
In the finalization phase, the memory controller exits the
training mode, and the computed delay values are written back to
training mode (lst. \ref{lst:finalization_phase}),
and the computed delay values are written back to
the appropriate registers. This ensures that the DQS signal
remains correctly aligned during normal operation. \\
@ -3194,7 +3206,7 @@ if (Pass == FirstPass) {
In the seed adjustment section for the second pass of training,
the code includes a \path{TODO} comment regarding fetching the
correct value from \path{RC2[0]} for the \path{addr_prelaunch}
variable:
variable (lst. \ref{lst:todo_rc2}).
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -3217,7 +3229,8 @@ uint8_t addr_prelaunch = 0; /* TODO: Fetch the correct value from RC2[0] */
is unclear about what RC2[0] really means. \\
The code contains another \path{TODO} comment indicating that
the support for Load Reduced DIMMs (LRDIMMs) is unimplemented:
the support for Load Reduced DIMMs (LRDIMMs) is unimplemented
(lst. \ref{lst:todo_lrdimm}).
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -3251,7 +3264,8 @@ else if ((pDCTstat->Status & (1 << SB_LoadReduced))) {
flawed or incomplete. \\
The first \path{FIXME} comment questions the usage of the
\path{SSEDIS} setting during the training process:
\path{SSEDIS} setting during the training process
(lst. \ref{lst:fixme_ssedis}).
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -3259,12 +3273,13 @@ else if ((pDCTstat->Status & (1 << SB_LoadReduced))) {
msr = HWCR_MSR;
_RDMSR(msr, &lo, &hi);
/* FIXME: Why use SSEDIS */
if (lo & (1 << 17)) { /* save the old value */
_Wrap32Dis = 1;
if (lo & (1 << 17)) { /* save the old value */
_Wrap32Dis = 1;
}
lo |= (1 << 17); /* HWCR.wrap32dis */
lo &= ~(1 << 15); /* SSEDIS */
_WRMSR(msr, lo, hi); /* Setting wrap32dis allows 64-bit memory references in real mode */
lo |= (1 << 17); /* HWCR.wrap32dis */
lo &= ~(1 << 15); /* SSEDIS */
_WRMSR(msr, lo, hi); /* Setting wrap32dis allows 64-bit memory
* references in real mode */
\end{minted}
\end{adjustwidth}
\caption{Questioning the use of
@ -3283,7 +3298,8 @@ _WRMSR(msr, lo, hi); /* Setting wrap32dis allows 64-bit memory references in rea
\\
The code also highlights a potential misprint in the BKDG
regarding the \path{WrDqDqsEarly} value:
regarding the \path{WrDqDqsEarly} value
(lst. \ref{lst:fixme_misprint}).
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -3314,10 +3330,32 @@ _WRMSR(msr, lo, hi); /* Setting wrap32dis allows 64-bit memory references in rea
The logic for adjusting the seed values based on the memory
frequency and the platform's minimum supported frequency is
complex and prone to errors, especially when combined with the
incomplete \path{TODO} features. The risk here is that incorrect
complex and prone to errors
(lst. \ref{lst:seed_adjustment_logic}),
especially when combined with the
incomplete \path{TODO} features.
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
\begin{minted}[linenos]{c}
initial_seed = (uint16_t) (((((uint64_t) initial_seed) *
fam15h_freq_tab[mem_clk] * 100) / (min_mem_clk * 100)));
\end{minted}
\end{adjustwidth}
\caption{Complex seed adjustment logic,
extract from
\protect\path{dqsTrainRcvrEn_SW_Fam15} function in
\protect\path{src/northbridge/amd/amdmct/mct_ddr3/mcrsrc.c}}
\label{lst:seed_adjustment_logic}
\end{listing}
The risk here is that incorrect
seed values could be used, leading to timing mismatches during
the training process. It seems that that seeds for used for DQS
the training process. \\
Added to that, stock seeds from the BKDG are used
(lst. \ref{lst:dqs_receiver_training_seeds}).
However, it seems that that seeds for used for DQS
training should be extensively determined for each motherboard,
and the BKDG \cite{BKDG} does not tell otherwise. Moreover,
seeds can be configured uniquely for every possible socket,
@ -3370,20 +3408,6 @@ if (pDCTstat->Status & (1 << SB_Registered)) {
\label{lst:dqs_receiver_training_seeds}
\end{listing}
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
\begin{minted}[linenos]{c}
initial_seed = (uint16_t) (((((uint64_t) initial_seed) *
fam15h_freq_tab[mem_clk] * 100) / (min_mem_clk * 100)));
\end{minted}
\end{adjustwidth}
\caption{Complex seed adjustment logic,
extract from
\protect\path{dqsTrainRcvrEn_SW_Fam15} function in
\protect\path{src/northbridge/amd/amdmct/mct_ddr3/mcrsrc.c}}
\label{lst:seed_adjustment_logic}
\end{listing}
The current implementation also has limited error handling and
reporting. While some errors are detected during training, the
code does not have robust mechanisms for recovering from or
@ -3414,7 +3438,8 @@ initial_seed = (uint16_t) (((((uint64_t) initial_seed) *
the correct or final value for this variable, once again because
of a value from RC2[0] that isn't fetched, potentially
leading to inaccuracies in the seed values used during write
leveling. This inaccuracy can result in timing mismatches, which
leveling (lst. \ref{lst:todo_seed_generation}).
This inaccuracy can result in timing mismatches, which
may cause data corruption or other stability issues. \\
\begin{listing}
@ -3434,7 +3459,8 @@ uint8_t AddrCmdPrelaunch = 0; /* TODO: Fetch the correct value from RC2[0] */
Another \path{FIXME} in the code indicates that the
\path{WrDqDqsEarly} parameter, which is critical for fine-tuning
the DQS signal’s timing during write operations, is being
ignored due to unresolved issues. This omission can result in
ignored due to unresolved issues
(lst. \ref{lst:fixme_wrdqdqs_early}). This omission can result in
less accurate timing adjustments, leading to potential marginal
instability in systems where tight timing margins are critical.
\\
@ -3454,7 +3480,8 @@ uint8_t AddrCmdPrelaunch = 0; /* TODO: Fetch the correct value from RC2[0] */
\end{listing}}
The current implementation uses generic or "stock" seed values
for certain configurations, such as Socket G34. Without
for certain configurations, such as Socket G34
(lst. \ref{lst:fixme_mainboard_specific_overrides}). Without
mainboard-specific overrides, the memory initialization process
might not be fully optimized for the particular motherboard in
use. This could result in suboptimal performance or stability
@ -3478,7 +3505,8 @@ uint8_t AddrCmdPrelaunch = 0; /* TODO: Fetch the correct value from RC2[0] */
In \path{AgesaHwWlPhase2}, there is a \path{FIXME} comment that
suggests that the Critical Gross Delay adjustment has been
temporarily disabled due to conflicts with RDIMM training.
temporarily disabled due to conflicts with RDIMM training
(lst. \ref{lst:fixme_cgd_adjustment}).
Disabling this adjustment can lead to less precise DQS alignment,
especially in complex memory configurations like those using
RDIMMs, potentially causing instability or degraded performance.
@ -3499,8 +3527,8 @@ uint8_t AddrCmdPrelaunch = 0; /* TODO: Fetch the correct value from RC2[0] */
\label{lst:fixme_cgd_adjustment}
\end{listing}
The function also bypasses certain
critical adjustments if the memory speed is being tuned (e.g.,
The function also bypasses (lst. \ref{lst:fixme_bypass_critical_adjustments})
certain critical adjustments if the memory speed is being tuned (e.g.,
during frequency stepping). This bypass is noted as a temporary
measure due to problems encountered during testing, where the
first pass values were found to cause issues with PHY training
@ -3514,7 +3542,8 @@ uint8_t AddrCmdPrelaunch = 0; /* TODO: Fetch the correct value from RC2[0] */
\begin{minted}[linenos]{c}
/* FIXME: Using the Pass 1 training values causes major phy training problems on
* all Family 15h processors I tested (Pass 1 values are randomly too high,
* and Pass 2 cannot lock). Figure out why this is and fix it, then remove the bypass code below... */
* and Pass 2 cannot lock). Figure out why this is and fix it, then remove
* the bypass code below... */
\end{minted}
\end{adjustwidth}
\caption{Bypass of critical
@ -3527,7 +3556,8 @@ uint8_t AddrCmdPrelaunch = 0; /* TODO: Fetch the correct value from RC2[0] */
The current implementation attempts to compensate for noise and
instability by overriding faulty values with seed values in
\path{AgesaHwWlPhase2}. However, this approach is somewhat blunt
\path{AgesaHwWlPhase2} (lst. \ref{lst:reactive_error_handling}).
However, this approach is somewhat blunt
and reactive, addressing the symptoms rather than the underlying
causes of instability. This method does not ensure that noise or
instability is sufficiently mitigated, potentially leading to
@ -3640,7 +3670,8 @@ if (faulty_value_detected) {
\item The warning issued when a negative DQS recovery delay
is detected suggests that the function continues despite
recognizing a potentially critical issue, which could
lead to system instability.
lead to system instability
(lst. \ref{lst:dqs_train_negative_delay}).
\item The averaging of delay values for dual-rank DIMMs does
not account for the possibility of significant
discrepancies between the ranks, which could result in
@ -3657,7 +3688,8 @@ if (faulty_value_detected) {
if (best_count > 2) {
uint16_t region_center = (best_pos + (best_count / 2));
if (region_center < 16) {
printk(BIOS_WARNING, "TrainDQSRdWrPos: negative DQS recovery delay detected!");
printk(BIOS_WARNING,
"TrainDQSRdWrPos: negative DQS recovery delay detected!");
region_center = 0;
} else {
region_center -= 16;
@ -3673,7 +3705,7 @@ if (best_count > 2) {
extract from
\protect\path{TrainDQSRdWrPos_D_Fam15} function in
\protect\path{src/northbridge/amd/amdmct/mct_ddr3/mctdqs_d.c}}
\label{lst:dqs_train_results}
\label{lst:dqs_train_negative_delay}
\end{listing}
Improving the handling of edge cases and boundary conditions,
@ -4121,6 +4153,30 @@ if (best_count > 2) {
security of VMs. The OS, in this context, operates similarly to a VM
that does not have full control over the hardware it ostensibly manages. \\
\section{Processors microcode}
Modern CPUs are incredibly complex, with their functionality relying
heavily on microcode to interpret and execute instructions. Microcode
acts as a translation layer between the high-level instructions that
software provides and the lower-level operations that the hardware
can execute. Microcode operates directly within the CPU. \\
CPU microcode is a set of low-level firmware instructions embedded
within the processor. It translates complex machine instructions into
simpler, executable sequences of operations that the CPU's hardware
can directly perform \cite{Intel2018}. This layer of abstraction allows
CPU manufacturers to update or patch the behavior of the processor
post-manufacturing, which is crucial for addressing bugs, optimizing
performance, and applying security patches \cite{Wilcox2018}.
In a sense, microcode can be seen as an argument for the CPU running
a form of low-level virtual machine. Just as a VM abstracts and manages
hardware resources for a guest OS, microcode abstracts and manages the
complexity of CPU hardware for machine-level instructions. This
virtualization enables the CPU to support a wide variety of instructions
and operational modes without needing to change the underlying hardware
\cite{Abraham1983}.
\section{The OS as a virtualized environment}
The combined effect of these firmware components (ACPI, SMM, UEFI,
@ -4138,8 +4194,9 @@ if (best_count > 2) {
OS's direct access and control. \\
The presence and operation of modern firmware components such as ACPI,
SMM, UEFI, Intel ME, and AMD PSP contribute to a significant abstraction
of hardware from the OS. This abstraction creates an environment that
SMM, UEFI, Intel ME, and AMD PSP and even CPU microcode contribute to
a significant abstraction of hardware from the OS.
This abstraction creates an environment that
parallels the operation of a virtual machine, where the OS functions
within a controlled, virtualized layer managed by these firmware
systems. The growing body of research supports this perspective,
@ -4218,7 +4275,6 @@ if (best_count > 2) {
\chapter*{Appendix: Long code listings}
\addcontentsline{toc}{chapter}{Appendix: Long code listings}
\renewcommand{\thelisting}{L.\arabic{listing}}
\setcounter{listing}{0}
\begin{listing}
\begin{adjustwidth}{0.5cm}{0.5cm}
@ -5424,5 +5480,3 @@ if (pDCTstat->Status & (1 << SB_Registered)) {
to permit their use in free software.
\end{document}

5
hardware_init_review.toc
View File

@ -40,7 +40,7 @@
\contentsline {subsubsection}{\numberline {4.4.1.1}Details on the DQS training function}{41}{subsubsection.4.4.1.1}%
\contentsline {subsubsection}{\numberline {4.4.1.2}Details on the write leveling implementation}{43}{subsubsection.4.4.1.2}%
\contentsline {subsubsection}{\numberline {4.4.1.3}Details on the DQS position training function}{45}{subsubsection.4.4.1.3}%
\contentsline {subsubsection}{\numberline {4.4.1.4}Details on the DQS receiver training function}{47}{subsubsection.4.4.1.4}%
\contentsline {subsubsection}{\numberline {4.4.1.4}Details on the DQS receiver training function}{48}{subsubsection.4.4.1.4}%
\contentsline {subsection}{\numberline {4.4.2}Potential enhancements}{50}{subsection.4.4.2}%
\contentsline {subsubsection}{\numberline {4.4.2.1}DQS receiver training}{50}{subsubsection.4.4.2.1}%
\contentsline {subsubsection}{\numberline {4.4.2.2}Write leveling}{52}{subsubsection.4.4.2.2}%
@ -56,7 +56,8 @@
\contentsline {subsection}{\numberline {5.3.3}Device Drivers}{61}{subsection.5.3.3}%
\contentsline {subsection}{\numberline {5.3.4}Power Management}{61}{subsection.5.3.4}%
\contentsline {section}{\numberline {5.4}Intel and AMD: control beyond the OS}{61}{section.5.4}%
\contentsline {section}{\numberline {5.5}The OS as a virtualized environment}{62}{section.5.5}%
\contentsline {section}{\numberline {5.5}Processors microcode}{62}{section.5.5}%
\contentsline {section}{\numberline {5.6}The OS as a virtualized environment}{62}{section.5.6}%
\contentsline {chapter}{Conclusion}{63}{chapter*.6}%
\contentsline {chapter}{Bibliography}{70}{chapter*.7}%
\contentsline {chapter}{Appendix: Long code listings}{71}{chapter*.8}%

2
listings/acpica_size.sh
View File

@ -1,5 +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

2
listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_1.c
View File

@ -45,5 +45,5 @@ void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
* 6 8.0 6 667 MHz
* 7 9.0 7 800 MHz
*/
[...]
...
}

6
listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_2.c
View File

@ -1,13 +1,13 @@
void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
struct DCTStatStruc *pDCTstatA)
{
[...]
...
restartinit:
if (!mctGet_NVbits(NV_ECC_CAP) || !mctGet_NVbits(NV_ECC))
pMCTstat->try_ecc = 0;
else
pMCTstat->try_ecc = 1;
[...]
...
for (Node = 0; Node < MAX_NODES_SUPPORTED; Node++) {
struct DCTStatStruc *pDCTstat;
pDCTstat = pDCTstatA + Node;
@ -49,5 +49,5 @@ restartinit:
node_sys_base = pDCTstat->NodeSysBase;
node_sys_base += (pDCTstat->NodeSysLimit + 2) & ~0x0F;
}
[...]
...
}

4
listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_3.c
View File

@ -1,7 +1,7 @@
void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
struct DCTStatStruc *pDCTstatA)
{
[...]
...
/* If the boot fails make sure training is attempted after reset */
nvram = 0;
set_option("allow_spd_nvram_cache_restore", &nvram);
@ -24,7 +24,7 @@ void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
}
}
}
[...]
...
}

4
listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_4.c
View File

@ -1,7 +1,7 @@
void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
struct DCTStatStruc *pDCTstatA)
{
[...]
...
for (Node = 0; Node < MAX_NODES_SUPPORTED; Node++) {
struct DCTStatStruc *pDCTstat;
pDCTstat = pDCTstatA + Node;
@ -33,7 +33,7 @@ void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
printk(BIOS_DEBUG, "mctAutoInitMCT_D: mctHookAfterCPU\n");
/* Setup external northbridge(s) */
mctHookAfterCPU();
[...]
...
return;
fatalexit:
die("mct_d: fatalexit");

4
listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_5.c
View File

@ -1,7 +1,7 @@
void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
struct DCTStatStruc *pDCTstatA)
{
[...]
...
/* FIXME
* Previous training values should only be used if the current desired
* speed is the same as the speed used in the previous boot.
@ -38,7 +38,7 @@ void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
MCTMemClr_D(pMCTstat,pDCTstatA);
}
}
[...]
...
return;
fatalexit:
die("mct_d: fatalexit");

2
listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_6.c
View File

@ -1,7 +1,7 @@
void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
struct DCTStatStruc *pDCTstatA)
{
[...]
...
printk(BIOS_DEBUG, "mctAutoInitMCT_D: CPUMemTyping_D\n");
/* Map dram into WB/UC CPU cacheability */
CPUMemTyping_D(pMCTstat, pDCTstatA);

4
listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_fixme.c
View File

@ -1,7 +1,7 @@
void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
struct DCTStatStruc *pDCTstatA)
{
[...]
...
/* If DIMM configuration has not changed since last boot restore
* training values */
allow_config_restore = 1;
@ -22,7 +22,7 @@ void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat,
* Debug and reenable this!
*/
allow_config_restore = 0;
[...]
...
}

4
packages.tex
View File

@ -81,3 +81,7 @@
numbersep=5pt,
bgcolor=bg
}
% setup things
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}