Change in coreboot[master]: Documentation/soc/amd/family17: Update to match current design
Marshall Dawson has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/38713 )
Change subject: Documentation/soc/amd/family17: Update to match current design ......................................................................
Documentation/soc/amd/family17: Update to match current design
The Picasso no longer intends to implement a hybrid romstage, opting instead for a more traditional bootblock/romstage/ramstage. Update the documentation to reflect this. Clarify additional details that have come to light since the last revision.
Signed-off-by: Marshall Dawson marshalldawson3rd@gmail.com Change-Id: I6c98c007ddb8a4a05810f19e4215bde719de7bb8 --- M Documentation/soc/amd/family17h.md 1 file changed, 58 insertions(+), 32 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/13/38713/1
diff --git a/Documentation/soc/amd/family17h.md b/Documentation/soc/amd/family17h.md index 9608b57..71ce8f0 100755 --- a/Documentation/soc/amd/family17h.md +++ b/Documentation/soc/amd/family17h.md @@ -51,8 +51,13 @@ * Embedded Firmware Structure - Signature and pointers used by the PSP to locate the PSP Directory Table and BIOS Directory Table; these items are generated during coreboot build and are located in the SPI ROM -* Verstage - The code to verify the firmware contained in the -writable section of the SPI ROM +* vboot - The generic technology name for verifying/choosing a RW A/B +or fallback RO path. +* verstage - The code (vboot) to verify the firmware contained in the +writable section of the SPI ROM, traditionally run on the AP processor, +and in some cases a separate stage added to coreboot +* vboot app - A portion of vboot technology designed and compiled +to run on the PSP * APCB - AMD PSP Customization Block - A binary containing PSP and system configuration preferences (analogous to v5 BUILDOPT_ options), and generated by APCBTool to be added to coreboot/utils later @@ -102,15 +107,15 @@ the SPI ROM * PSP verifies and executes the PSP off-chip bootloader * ChromeOS systems: - * Off-chip bootloader attempts to locate verstage via the RO BIOS + * Off-chip bootloader attempts to locate vboot app via the RO BIOS Directory Table - * If verstage is not found, booting continues with ABLs below - * Verstage initializes, setting up GPIOs, UART if needed, + * If vboot app is not found, booting continues with ABLs below + * vboot app initializes, setting up GPIOs, UART if needed, communication path to the EC, and the SPI controller for direct access to the flash device. - * Verstage verifies the RW sections (as is typically performed by + * vboot app verifies the RW sections (as is typically performed by the main processor) - * Verstage locates the Embedded Firmware Directory within the + * vboot app locates the Embedded Firmware Directory within the verified FMAP section and passes a pointer to the PSP bootloader. If the verification fails, it passes a pointer to the RO header to the bootloader. @@ -166,37 +171,55 @@ code that is position-dependent must be linked to run at the final destination.
-## Initial coreboot Implementation +## Implementation for coreboot
-Supporting Picasso doesn’t fit well with many of the coreboot -assumptions. Initial porting shall attempt to fit within existing -coreboot paradigms and make minimal changes to common code. +Supporting Picasso doesn’t fit perfectly with many of the coreboot +assumptions about x86 processors. Changes are introduced primarily +into arch/x86 to accommodate a processor starting in DRAM and at a +nontraditional reset vector.
-### CAR and bootblock +### CAR and early stages
-The coreboot bootblock contains features Picasso doesn’t require or -can’t use, and is assumed to execute in an unusable location. -Picasso’s requirement for bootblock in coreboot will be eliminated. +The traditional coreboot bootblock and romstage rely on cache-as-RAM +and a linker script that positions temporary storage accordingly. A +substitute for the DCACHE variables, called EARLYRAM, is introduced. +Like DCACHE, this allows for a consistent mapping of early regions +required across multiple stages prior to cbmem coming online. +Examples are the _preram_cbmem_console and _timestamp.
-### Hybrid romstage +Due to Picasso's unique nature of starting with DRAM enabled, no +early stages run as execute-in-place (XIP). All post-bootblock +stages are copied from the BIOS flash into DRAM for faster +performance, and these regions are marked reserved later in POST.
-Picasso’s x86 reset state doesn’t meet the coreboot expectations -for jumping directly to ramstage. The primary feature of romstage is -also not needed, however there are other important features that are -typically in romstage that Picasso does need. +Unlike CAR-based systems, and because Picasso does not run early +stages as XIP, its early stages are not constrained in their use +of .bss or .data sections. All stages' .bss is zeroed, and all +.data sections are fully R/W at load time.
-The romstage architecture is designed around the presence of CAR. -Several features implement ROMSTAGE_CBMEM_INIT_HOOK, expecting to move -data from CAR to cbmem. The hybrid romstage consumes DRAM for the -purpose of implementing the expected CAR storage. This region as well -as the DRAM where romstage is decompressed must be reserved and -unavailable to the OS. +### bootblock
-The initial Picasso port implements a hybrid romstage that contains the -first instruction fetched at the reset vector. It minimally configures -flat protected mode, initializes cbmem, then loads the next stage. -Future work will consider breaking the dependencies mentioned above -and/or potentially loading ramstage directly from the PSP. +Picasso uses a bootblock that mirrors a traditional bootblock as much +as possible. Because the image is loaded by the PSP, the bootblock is +not restricted to the top of the BIOS flash device. The compressed +image is added into the PSP's amdfw.rom build. + +### vboot app and verstage + +Development is currently underway for the vboot app, and potentially +an x86-based verstage companion. This document shall be updated once +the design is finalized and functioning. Support for the PSP honoring +the presence of the vboot app is available only in certain SKUs. + +### romstage and postcar + +A traditional romstage is maintained for Picasso. The primary reason for +this choice is to remain compatible with coreboot conventions and +to support the FSP 2.0 driver. Picasso's romstage uses an +fsp_memory_init() call to glean the memory map from AGESA. (See below.) +fsp_memory_init() brings cbmem online before returning to the caller. + +No postcar stage is required or supported.
## AGESA v9 on Picasso
@@ -211,6 +234,9 @@ reference code with EDK II source to create a modular image with discoverable entry points. coreboot source already contains knowledge of FSP, how to parse it, integrate it, and how to communicate with it. +Picasso's FSP is compatible with rev. 2.0 of the External Architecture +Specification. Deviations, e.g., no FSP-T support, shall be published +in an Integration Guide.
## Footnotes
@@ -221,4 +247,4 @@ 2. [PSP Integration](psp_integration.md) 3. [https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf%5D(https://www....) 4. [https://en.wikichip.org/wiki/amd/cores/picasso%5D(https://en.wikichip.org/wi...) -5. [https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-s...) +5. [https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-s...) \ No newline at end of file
Paul Menzel has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38713 )
Change subject: Documentation/soc/amd/family17: Update to match current design ......................................................................
Patch Set 1:
(2 comments)
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... File Documentation/soc/amd/family17h.md:
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 205: amdfw.rom Mark up with ``?
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 205: image is added into the PSP's amdfw.rom build. Remove trailing spaces.
Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38713 )
Change subject: Documentation/soc/amd/family17: Update to match current design ......................................................................
Patch Set 1:
(6 comments)
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... File Documentation/soc/amd/family17h.md:
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 18: (a.k.a. PSP) in system initialization is addressed here. AMD has https://www.amd.com/en/technologies/security
AMD Secure Processor (formerly “Platform Security Processor” or “PSP”)
I quess Fam17 and before may have used PSP term only.
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 19: historically required an NDA for access to the PSP .. AMD continues to require an NDA ..
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 97: * For the foreseeable future, AGESA source will distributed only Can you add your expectations or intentions for AMD to give out permissions to distribute custom and/or debugging builds?
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 193: performance, and these regions are marked reserved later in POST. Can you elaborate about "later in POST"? Reserved only from the OS or excluded from being used in coreboot proper already?
Whether you really need to reserve those depends of how S3 resume path will look like. From what I understand any pre-ramstage rmodule will not be relocatable, and used regions have to be asserted at build-time already with the used linker scripts.
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 229: the existing v5 interface impractical. I believe I know what you mean, but maybe the phrase needs some commas.
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 239: in an Integration Guide. Did you evaluate FSP rev 2.1 to be less compatible choice? I would have thought that to have FSP_USES_CB_STACK enabled would be preferable, but don't really have a clue of some of the design details behind this.
Felix Held has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38713 )
Change subject: Documentation/soc/amd/family17: Update to match current design ......................................................................
Patch Set 1:
(3 comments)
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... File Documentation/soc/amd/family17h.md:
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 57: AP AP and not BSP? I mostly know that acronym from SMP system, where the first processor is the BootStrap Processor and the other ones the Application Processor. If the PSP is considered the bootstrap processor in the system, it should probably be mentioned that the acronyms have a slightly differently meaning here
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 190: enabled "already available" instead of "enabled"?
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 250: 5. [https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-s...) please keep the newline at the end
Hello Felix Held, Arthur Heymans, Patrick Rudolph, build bot (Jenkins),
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/38713
to look at the new patch set (#2).
Change subject: Documentation/soc/amd/family17: Update to match current design ......................................................................
Documentation/soc/amd/family17: Update to match current design
The Picasso no longer intends to implement a hybrid romstage, opting instead for a more traditional bootblock/romstage/ramstage. Update the documentation to reflect this. Clarify additional details that have come to light since the last revision.
Signed-off-by: Marshall Dawson marshalldawson3rd@gmail.com Change-Id: I6c98c007ddb8a4a05810f19e4215bde719de7bb8 --- M Documentation/soc/amd/family17h.md 1 file changed, 71 insertions(+), 46 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/13/38713/2
Marshall Dawson has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38713 )
Change subject: Documentation/soc/amd/family17: Update to match current design ......................................................................
Patch Set 2:
(11 comments)
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... File Documentation/soc/amd/family17h.md:
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 18: (a.k.a. PSP) in system initialization is addressed here. AMD has
*sigh*, I dislike name changes. Actually this is the first time I've heard "AMD Secure Processor" and everyone still uses "PSP". Haven't found much documentation using the new name either.
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 19: historically required an NDA for access to the PSP
.. AMD continues to require an NDA ..
I don't like the way it sounds, so will make it more direct. I'm still hopeful it'll be open in the future.
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 57: AP
AP and not BSP? I mostly know that acronym from SMP system, where the first processor is the BootStr […]
No, you're right. That mistake comes from working on Chromebooks where Google refers to the EC and the AP. When used in that context, the AP is the entire x86.
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 97: * For the foreseeable future, AGESA source will distributed only
Can you add your expectations or intentions for AMD to give out permissions to distribute custom and […]
I'll add a clarification about debug builds being released, although it's not a favorable position. AFAIK creating and distributing custom, i.e. derivative works, is already permitted through the existing license agreement. (BTW I'm still working to get 3rd parties access to additional NDA source code, including the older binaryPI.)
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 190: enabled
"already available" instead of "enabled"?
Done
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 193: performance, and these regions are marked reserved later in POST.
Can you elaborate about "later in POST"? Reserved only from the OS or excluded from being used in coreboot proper already?
A couple of examples I have in mind: https://review.coreboot.org/c/coreboot/+/38729/1/src/arch/x86/nonxip_rsvd.c or https://review.coreboot.org/c/coreboot/+/38702/1/src/soc/amd/picasso/northbr...
Whether you really need to reserve those depends of how S3 resume path will look like. From what I understand any pre-ramstage rmodule will not be relocatable,...
I was planning on the resume path looking very similar (i.e. if you treat AGESA almost like a black box) to older devices. Load and execute the stages in order... However, it hadn't occurred to me that romstage and FSP could also be cached away for performance.
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 205: amdfw.rom
Mark up with ``?
Done
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 205: image is added into the PSP's amdfw.rom build.
Remove trailing spaces.
Done
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 229: the existing v5 interface impractical.
I believe I know what you mean, but maybe the phrase needs some commas.
Done
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 239: in an Integration Guide.
Did you evaluate FSP rev 2. […]
IIRC the 2.1 spec came out just after we'd started down the 2.0 path. I don't remember precise details now, but I'd experimented with FSP_USES_CB_STACK and it seemed the tianocore IntelFsp2Pkg we were using wasn't yet 2.1-compliant. Internally we recognized the desire to us that but it wasn't a high enough priority to add the necessary code. As it was, we discovered other things missing which needed to be added to make a functioning FSP2.0 implementation.
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 250: 5. [https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-s...)
please keep the newline at the end
Done
Felix Held has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38713 )
Change subject: Documentation/soc/amd/family17: Update to match current design ......................................................................
Patch Set 2: Code-Review+2
(1 comment)
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... File Documentation/soc/amd/family17h.md:
https://review.coreboot.org/c/coreboot/+/38713/1/Documentation/soc/amd/famil... PS1, Line 57: AP
No, you're right. […]
Done
Patrick Georgi has submitted this change. ( https://review.coreboot.org/c/coreboot/+/38713 )
Change subject: Documentation/soc/amd/family17: Update to match current design ......................................................................
Documentation/soc/amd/family17: Update to match current design
The Picasso no longer intends to implement a hybrid romstage, opting instead for a more traditional bootblock/romstage/ramstage. Update the documentation to reflect this. Clarify additional details that have come to light since the last revision.
Signed-off-by: Marshall Dawson marshalldawson3rd@gmail.com Change-Id: I6c98c007ddb8a4a05810f19e4215bde719de7bb8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/38713 Tested-by: build bot (Jenkins) no-reply@coreboot.org Reviewed-by: Felix Held felix-coreboot@felixheld.de --- M Documentation/soc/amd/family17h.md 1 file changed, 71 insertions(+), 46 deletions(-)
Approvals: build bot (Jenkins): Verified Felix Held: Looks good to me, approved
diff --git a/Documentation/soc/amd/family17h.md b/Documentation/soc/amd/family17h.md index 9608b57..b917c94 100755 --- a/Documentation/soc/amd/family17h.md +++ b/Documentation/soc/amd/family17h.md @@ -14,13 +14,12 @@ familiarity with x86, its reset state and its early initialization requirements.
-To the extent necessary, the role of the Platform Security Processor -(a.k.a. PSP) in system initialization is addressed here. AMD has -historically required an NDA for access to the PSP -specification<sup>1</sup>. coreboot relies on util/amdfwtool to build -the structures and add various other firmware to the final image<sup>2</sup>. -The Family 17h PSP design guide adds a new BIOS Directory Table, similar to -the PSP Directory Table. +To the extent necessary, the role of the AMD Secure Processor (a.k.a. +Platform Security Processor or PSP) in system initialization is addressed +here. The PSP specification<sup>1</sup> is available only with an NDA. +coreboot relies on util/amdfwtool to build the structures and add various +other firmware to the final image<sup>2</sup>. The Family 17h PSP design +guide adds a new BIOS Directory Table, similar to the PSP Directory Table.
Support in coreboot for modern AMD products is based on AMD’s reference code: AMD Generic Encapsulated Software Architecture @@ -51,8 +50,13 @@ * Embedded Firmware Structure - Signature and pointers used by the PSP to locate the PSP Directory Table and BIOS Directory Table; these items are generated during coreboot build and are located in the SPI ROM -* Verstage - The code to verify the firmware contained in the -writable section of the SPI ROM +* vboot - The generic technology name for verifying/choosing a RW A/B +or fallback RO path. +* verstage - The code (vboot) to verify the firmware contained in the +writable section of the SPI ROM, traditionally run on the x86 processor, +and in some cases a separate stage added to coreboot +* vboot app - A portion of vboot technology designed and compiled +to run on the PSP * APCB - AMD PSP Customization Block - A binary containing PSP and system configuration preferences (analogous to v5 BUILDOPT_ options), and generated by APCBTool to be added to coreboot/utils later @@ -90,7 +94,8 @@ etc. It would, in no way, fit into the v5 model used in coreboot.
* For the foreseeable future, AGESA source will distributed only -under NDA. +under NDA. Furthermore, because AGESA's integrated debug services divulge +NDA information, no debug builds will be released to the general public.
## Basic Pre-x86 Boot Flow
@@ -102,15 +107,15 @@ the SPI ROM * PSP verifies and executes the PSP off-chip bootloader * ChromeOS systems: - * Off-chip bootloader attempts to locate verstage via the RO BIOS + * Off-chip bootloader attempts to locate vboot app via the RO BIOS Directory Table - * If verstage is not found, booting continues with ABLs below - * Verstage initializes, setting up GPIOs, UART if needed, + * If vboot app is not found, booting continues with ABLs below + * vboot app initializes, setting up GPIOs, UART if needed, communication path to the EC, and the SPI controller for direct access to the flash device. - * Verstage verifies the RW sections (as is typically performed by + * vboot app verifies the RW sections (as is typically performed by the main processor) - * Verstage locates the Embedded Firmware Directory within the + * vboot app locates the Embedded Firmware Directory within the verified FMAP section and passes a pointer to the PSP bootloader. If the verification fails, it passes a pointer to the RO header to the bootloader. @@ -166,44 +171,61 @@ code that is position-dependent must be linked to run at the final destination.
-## Initial coreboot Implementation +## Implementation for coreboot
-Supporting Picasso doesn’t fit well with many of the coreboot -assumptions. Initial porting shall attempt to fit within existing -coreboot paradigms and make minimal changes to common code. +Supporting Picasso doesn’t fit perfectly with many of the coreboot +assumptions about x86 processors. Changes are introduced primarily +into arch/x86 to accommodate a processor starting in DRAM and at a +nontraditional reset vector.
-### CAR and bootblock +### CAR and early stages
-The coreboot bootblock contains features Picasso doesn’t require or -can’t use, and is assumed to execute in an unusable location. -Picasso’s requirement for bootblock in coreboot will be eliminated. +The traditional coreboot bootblock and romstage rely on cache-as-RAM +and a linker script that positions temporary storage accordingly. A +substitute for the DCACHE variables, called EARLYRAM, is introduced. +Like DCACHE, this allows for a consistent mapping of early regions +required across multiple stages prior to cbmem coming online. +Examples are the _preram_cbmem_console and _timestamp.
-### Hybrid romstage +Due to Picasso's unique nature of starting with DRAM already available, +no early stages run as execute-in-place (XIP). All post-bootblock +stages are copied from the BIOS flash into DRAM for faster +performance, and these regions are marked reserved later in POST.
-Picasso’s x86 reset state doesn’t meet the coreboot expectations -for jumping directly to ramstage. The primary feature of romstage is -also not needed, however there are other important features that are -typically in romstage that Picasso does need. +Unlike CAR-based systems, and because Picasso does not run early +stages as XIP, its early stages are not constrained in their use +of .bss or .data sections. All stages' .bss is zeroed, and all +.data sections are fully R/W at load time.
-The romstage architecture is designed around the presence of CAR. -Several features implement ROMSTAGE_CBMEM_INIT_HOOK, expecting to move -data from CAR to cbmem. The hybrid romstage consumes DRAM for the -purpose of implementing the expected CAR storage. This region as well -as the DRAM where romstage is decompressed must be reserved and -unavailable to the OS. +### bootblock
-The initial Picasso port implements a hybrid romstage that contains the -first instruction fetched at the reset vector. It minimally configures -flat protected mode, initializes cbmem, then loads the next stage. -Future work will consider breaking the dependencies mentioned above -and/or potentially loading ramstage directly from the PSP. +Picasso uses a bootblock that mirrors a traditional bootblock as much +as possible. Because the image is loaded by the PSP, the bootblock is +not restricted to the top of the BIOS flash device. The compressed +image is added into the PSP's `amdfw.rom` build. + +### vboot app and verstage + +Development is currently underway for the vboot app, and potentially +an x86-based verstage companion. This document shall be updated once +the design is finalized and functioning. Support for the PSP honoring +the presence of the vboot app is available only in certain SKUs. + +### romstage and postcar + +A traditional romstage is maintained for Picasso. The primary reason for +this choice is to remain compatible with coreboot conventions and +to support the FSP 2.0 driver. Picasso's romstage uses an +fsp_memory_init() call to glean the memory map from AGESA. (See below.) +fsp_memory_init() brings cbmem online before returning to the caller. + +No postcar stage is required or supported.
## AGESA v9 on Picasso
-Due to the current inability to publish AGESA source, a pre-built -binary solution remains a requirement. The rewrite from v5 to v9 for -direct inclusion into UEFI source makes modifying it for conforming to -the existing v5 interface impractical. +Due to the current restriction on publishing AGESA source, a pre-built +binary solution remains a requirement. Modifying v9 to conform to the +existing v5 binaryPI interface was considered impractical.
Given the UEFI nature of modern AGESA, and the existing open source work from Intel, Picasso shall support AGESA via an FSP-like prebuilt @@ -211,12 +233,15 @@ reference code with EDK II source to create a modular image with discoverable entry points. coreboot source already contains knowledge of FSP, how to parse it, integrate it, and how to communicate with it. +Picasso's FSP is compatible with rev. 2.0 of the External Architecture +Specification. Deviations, e.g., no FSP-T support, shall be published +in an Integration Guide.
## Footnotes
-1. “AMD Platform Security Processor BIOS Architecture Design Guide -for AMD Family 17h Processors” (PID #55758) and “AMD Platform -Security Processor BIOS Architecture Design Guide” (PID #54267) for +1. *AMD Platform Security Processor BIOS Architecture Design Guide +for AMD Family 17h Processors* (PID #55758) and *AMD Platform +Security Processor BIOS Architecture Design Guide* (PID #54267) for earlier products 2. [PSP Integration](psp_integration.md) 3. [https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf%5D(https://www....)
-
Felix Held (Code Review) -
Kyösti Mälkki (Code Review)
-
Marshall Dawson (Code Review)
-
Patrick Georgi (Code Review)
-
Paul Menzel (Code Review)