GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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>
This commit is contained in:
Marshall Dawson 2020-02-04 17:16:27 -07:00 committed by Patrick Georgi
parent 5a1ba1bc29
commit 5b43484db3
1 changed files with 71 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

117
Documentation/soc/amd/family17h.md
View File

@ -14,13 +14,12 @@ Family 17h products are x86-based designs. This documentation assumes
familiarity with x86, its reset state and its early initialization familiarity with x86, its reset state and its early initialization
requirements. requirements.
To the extent necessary, the role of the Platform Security Processor To the extent necessary, the role of the AMD Secure Processor (a.k.a.
(a.k.a. PSP) in system initialization is addressed here. AMD has Platform Security Processor or PSP) in system initialization is addressed
historically required an NDA for access to the PSP here. The PSP specification<sup>1</sup> is available only with an NDA.
specification<sup>1</sup>. coreboot relies on util/amdfwtool to build coreboot relies on util/amdfwtool to build the structures and add various
the structures and add various other firmware to the final image<sup>2</sup>. other firmware to the final image<sup>2</sup>. The Family 17h PSP design
The Family 17h PSP design guide adds a new BIOS Directory Table, similar to guide adds a new BIOS Directory Table, similar to the PSP Directory Table.
the PSP Directory Table.
Support in coreboot for modern AMD products is based on AMD’s Support in coreboot for modern AMD products is based on AMD’s
reference code: AMD Generic Encapsulated Software Architecture reference code: AMD Generic Encapsulated Software Architecture
@ -51,8 +50,13 @@ related firmware images
* Embedded Firmware Structure - Signature and pointers used by the * Embedded Firmware Structure - Signature and pointers used by the
PSP to locate the PSP Directory Table and BIOS Directory Table; these 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 items are generated during coreboot build and are located in the SPI ROM
* Verstage - The code to verify the firmware contained in the * vboot - The generic technology name for verifying/choosing a RW A/B
writable section of the SPI ROM 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 * APCB - AMD PSP Customization Block - A binary containing PSP and
system configuration preferences (analogous to v5 BUILDOPT_ options), system configuration preferences (analogous to v5 BUILDOPT_ options),
and generated by APCBTool to be added to coreboot/utils later and generated by APCBTool to be added to coreboot/utils later
@ -90,7 +94,8 @@ dependency expressions, much functionality is rewritten as libraries,
etc. It would, in no way, fit into the v5 model used in coreboot. etc. It would, in no way, fit into the v5 model used in coreboot.
* For the foreseeable future, AGESA source will distributed only * 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 ## Basic Pre-x86 Boot Flow
@ -102,15 +107,15 @@ The following steps occur prior to x86 processor operation.
the SPI ROM the SPI ROM
* PSP verifies and executes the PSP off-chip bootloader * PSP verifies and executes the PSP off-chip bootloader
* ChromeOS systems: * 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 Directory Table
* If verstage is not found, booting continues with ABLs below * If vboot app is not found, booting continues with ABLs below
* Verstage initializes, setting up GPIOs, UART if needed, * vboot app initializes, setting up GPIOs, UART if needed,
communication path to the EC, and the SPI controller for direct access communication path to the EC, and the SPI controller for direct access
to the flash device. 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) 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 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 the verification fails, it passes a pointer to the RO header to the
bootloader. bootloader.
@ -166,44 +171,61 @@ jump to protected mode must jump to the physical address in DRAM. Any
code that is position-dependent must be linked to run at the final code that is position-dependent must be linked to run at the final
destination. destination.
## Initial coreboot Implementation ## Implementation for coreboot
Supporting Picasso doesn’t fit well with many of the coreboot Supporting Picasso doesn’t fit perfectly with many of the coreboot
assumptions. Initial porting shall attempt to fit within existing assumptions about x86 processors. Changes are introduced primarily
coreboot paradigms and make minimal changes to common code. 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 The traditional coreboot bootblock and romstage rely on cache-as-RAM
can’t use, and is assumed to execute in an unusable location. and a linker script that positions temporary storage accordingly. A
Picasso’s requirement for bootblock in coreboot will be eliminated. 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 Unlike CAR-based systems, and because Picasso does not run early
for jumping directly to ramstage. The primary feature of romstage is stages as XIP, its early stages are not constrained in their use
also not needed, however there are other important features that are of .bss or .data sections. All stages' .bss is zeroed, and all
typically in romstage that Picasso does need. .data sections are fully R/W at load time.
The romstage architecture is designed around the presence of CAR. ### bootblock
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.
The initial Picasso port implements a hybrid romstage that contains the Picasso uses a bootblock that mirrors a traditional bootblock as much
first instruction fetched at the reset vector. It minimally configures as possible. Because the image is loaded by the PSP, the bootblock is
flat protected mode, initializes cbmem, then loads the next stage. not restricted to the top of the BIOS flash device. The compressed
Future work will consider breaking the dependencies mentioned above image is added into the PSP's `amdfw.rom` build.
and/or potentially loading ramstage directly from the PSP.
### 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 ## AGESA v9 on Picasso
Due to the current inability to publish AGESA source, a pre-built Due to the current restriction on publishing AGESA source, a pre-built
binary solution remains a requirement. The rewrite from v5 to v9 for binary solution remains a requirement. Modifying v9 to conform to the
direct inclusion into UEFI source makes modifying it for conforming to existing v5 binaryPI interface was considered impractical.
the existing v5 interface impractical.
Given the UEFI nature of modern AGESA, and the existing open source Given the UEFI nature of modern AGESA, and the existing open source
work from Intel, Picasso shall support AGESA via an FSP-like prebuilt work from Intel, Picasso shall support AGESA via an FSP-like prebuilt
@ -211,12 +233,15 @@ image. The Intel Firmware Support Package<sup>5</sup> combines
reference code with EDK II source to create a modular image with reference code with EDK II source to create a modular image with
discoverable entry points. coreboot source already contains knowledge discoverable entry points. coreboot source already contains knowledge
of FSP, how to parse it, integrate it, and how to communicate with it. 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 ## Footnotes
1. “AMD Platform Security Processor BIOS Architecture Design Guide 1. *AMD Platform Security Processor BIOS Architecture Design Guide
for AMD Family 17h Processors” (PID #55758) and “AMD Platform for AMD Family 17h Processors* (PID #55758) and *AMD Platform
Security Processor BIOS Architecture Design Guide” (PID #54267) for Security Processor BIOS Architecture Design Guide* (PID #54267) for
earlier products earlier products
2. [PSP Integration](psp_integration.md) 2. [PSP Integration](psp_integration.md)
3. [https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf](https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf) 3. [https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf](https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf)