diff --git a/Makefile b/Makefile index 2bc59d4..71cf27f 100644 --- a/Makefile +++ b/Makefile @@ -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 \ No newline at end of file diff --git a/bibliographie.bib b/bibliographie.bib index 55255b4..8bfe930 100644 --- a/bibliographie.bib +++ b/bibliographie.bib @@ -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} } \ No newline at end of file diff --git a/hardware_init_review.bbl b/hardware_init_review.bbl index 4efaf52..7b37753 100644 --- a/hardware_init_review.bbl +++ b/hardware_init_review.bbl @@ -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}{% diff --git a/hardware_init_review.pdf b/hardware_init_review.pdf index ec3b399..7be190b 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 2d03fd6..a5bdcd8 100644 --- a/hardware_init_review.tex +++ b/hardware_init_review.tex @@ -285,7 +285,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 +302,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 +352,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 +381,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 @@ -454,7 +454,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 @@ -496,7 +496,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 @@ -1360,7 +1360,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 @@ -1368,7 +1368,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. \\ @@ -2249,7 +2249,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} @@ -2267,7 +2267,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 @@ -2503,7 +2503,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); @@ -2617,7 +2617,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. \\ @@ -2674,7 +2674,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} @@ -2695,7 +2696,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} @@ -2715,7 +2716,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} @@ -2736,7 +2738,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: @@ -2781,7 +2784,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} @@ -2798,7 +2802,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} @@ -2816,9 +2821,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} @@ -2843,7 +2849,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 @@ -2885,7 +2892,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 @@ -2910,8 +2918,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)); ... } } @@ -2932,8 +2942,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: @@ -2953,7 +2963,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; @@ -2961,7 +2972,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} @@ -2973,7 +2985,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. @@ -3002,16 +3015,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 @@ -3048,7 +3051,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 @@ -3071,7 +3075,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 @@ -3112,7 +3117,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} @@ -3121,7 +3126,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}} @@ -3130,7 +3135,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. \\ @@ -3141,7 +3147,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); ... } } @@ -3160,7 +3167,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. \\ @@ -3200,7 +3208,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} @@ -3223,7 +3231,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} @@ -3257,7 +3266,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} @@ -3265,12 +3275,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 @@ -3289,7 +3300,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} @@ -3320,10 +3332,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, @@ -3376,20 +3410,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 @@ -3420,7 +3440,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} @@ -3440,7 +3461,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. \\ @@ -3460,7 +3482,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 @@ -3484,7 +3507,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. @@ -3505,8 +3529,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 @@ -3520,7 +3544,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 @@ -3533,7 +3558,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 @@ -3646,7 +3672,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 @@ -3663,7 +3690,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; @@ -3679,7 +3707,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, @@ -4127,6 +4155,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, @@ -4144,8 +4196,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, @@ -4224,7 +4277,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} @@ -5430,5 +5482,3 @@ if (pDCTstat->Status & (1 << SB_Registered)) { to permit their use in free software. \end{document} - - diff --git a/hardware_init_review.toc b/hardware_init_review.toc index 4d6d39d..0147631 100644 --- a/hardware_init_review.toc +++ b/hardware_init_review.toc @@ -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}% diff --git a/listings/acpica_size.sh b/listings/acpica_size.sh index 223f459..9d3fbd3 100644 --- a/listings/acpica_size.sh +++ b/listings/acpica_size.sh @@ -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 \ No newline at end of file diff --git a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_1.c b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_1.c index c0f6e62..8ba8198 100644 --- a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_1.c +++ b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_1.c @@ -45,5 +45,5 @@ void mctAutoInitMCT_D(struct MCTStatStruc *pMCTstat, * 6 8.0 6 667 MHz * 7 9.0 7 800 MHz */ - [...] + ... } diff --git a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_2.c b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_2.c index 9530031..44fdcec 100644 --- a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_2.c +++ b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_2.c @@ -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; } - [...] + ... } diff --git a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_3.c b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_3.c index 0e1871f..7273b5e 100644 --- a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_3.c +++ b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_3.c @@ -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, } } } - [...] + ... } diff --git a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_4.c b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_4.c index 70356b4..d66db60 100644 --- a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_4.c +++ b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_4.c @@ -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"); diff --git a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_5.c b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_5.c index a6b999e..039394a 100644 --- a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_5.c +++ b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_5.c @@ -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"); diff --git a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_6.c b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_6.c index 2417cc0..57f0e16 100644 --- a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_6.c +++ b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_6.c @@ -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); diff --git a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_fixme.c b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_fixme.c index 41db2f2..c12fa19 100644 --- a/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_fixme.c +++ b/listings/src_northbridge_amd_amdmct_mct_ddr3_mct_d_fixme.c @@ -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; - [...] + ... }