Beginning with Family 17h products (a.k.a. “Zen” cores), AMD changed their paradigm for initializing the system and this requires major modifications to the execution flow of coreboot. This file discusses the new boot flow, and challenges, and the tradeoffs of the initial port into coreboot.
Family 17h products are x86-based designs. This documentation assumes 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 specification1. coreboot relies on util/amdfwtool to build the structures and add various other firmware to the final image. 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 (AGESATM). AGESA contains the technology for enabling DRAM, configuring proprietary core logic, assistance with generating ACPI tables, and other features.
AGESA for products earlier than Family 17h is known as v5 or Arch20082. Also note that coreboot currently contains both open source AGESA and closed source implementations (binaryPI) compiled from AGESA.
The first AMD Family 17h device ported to coreboot is codenamed “Picasso”3, and will be added to soc/amd/picasso.
AMD has ported early AGESA features to the PSP, which now discovers, enables and trains DRAM. Unlike any other x86 device in coreboot, a Picasso system has DRAM online prior to the first instruction fetch.
Cache-as-RAM (CAR) is no longer a supportable feature in AMD hardware. Early code expecting CAR behavior must account for writes escaping the L2 cache and going to DRAM.
Without any practical need for CAR, or DRAM initialization, coreboot should arguably skip bootblock and romstage, and possibly use ramstage as the BIOS image. This approach presents a number of challenges:
AGESA supporting Picasso is now at v9. Unlike Arch2008, which defines granular entry points for easy inclusion to a legacy BIOS, v9 is rewritten for compilation into a UEFI. The source follows UEFI standards, i.e. assumes the presence of UEFI phases, implements dependency expressions, much functionality is rewritten as libraries, etc. It would, in no way, fit into the v5 model used in coreboot.
The following steps occur prior to x86 processor operation.
As mentioned above, prior to releasing the x86 main core from reset, the PSP decompresses a BIOS image into DRAM. The PSP uses a specific BIOS Directory Table entry type to determine the source address (in flash), the destination address (in DRAM), and the destination size. The decompressed image is at the top of the destination region. The PSP then
Calculates the x86 reset vector as
reset_vector = dest_addr + dest_size - 0x10
Sets x86 CS descriptor shadow register to
base = dest_addr + dest_size - 0x10000 limit = 0xffff
Like all x86 devices, the main core is allowed to begin executing instructions with
CS:IP = 0xf000:0xfff0
For example, assume the BIOS Directory Table indicates
destination = 0x9b00000 size = 0x300000
… then the BIOS image is placed at the topmost position the region 0x9b00000-0x9dfffff and
reset_vector = 0x9dffff0 CS_shdw_base = 0x9df0000 CS:IP = 0xf000:0xfff0
Although the x86 behaves as though it began executing at 0xfffffff0 i.e. 0xf000:0xfff0, the initial GDT load must use the physical address of the table and not the typical CS-centric address. And, the first 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 destination.
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.
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.
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.
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.
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.
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.
Given the UEFI nature of modern AGESA, and the existing open source work from Intel, Picasso shall support AGESA via an FSP-like prebuilt image. The Intel Firmware Support Package4 combines 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.