FSP/coreboot Firmware for AMD Processors Open Source Firmware Conference September, 2019 Kerry L. Brown 1 Topics ● Background ● What’s new with AMD Processors (Family 17h, Zen/Zen2) ● Our approach ● Where are we now 2 Background: AMD coreboot ● AMD has actively supported coreboot firmware (on and off) since the Geode LX Processor (2003) ● Recent implementations were based on AMD Generic Encapsulated Software Architecture, AGESATM, version 5 or Architecture 2008 (Arch2008) ○ There have been have been both open-source and prebuilt binary versions of AGESA based on v5 3 New: AMD Processors Zen core processors, like Family 17h Picasso SOC processors ● New AGESA version 9 ○ Designed and optimized for UEFI build and execution ○ Leverages (and depends upon) Tianocore infrastructure ○ Eliminated legacy (including coreboot) support mechanisms ● Our approach: Leverage Intel® FSP framework ○ Existing drivers and methods in both coreboot and Tianocore ○ Standard approach to inclusion of UEFI drivers in coreboot 4 FSP coreboot Bootflow 5 New: AMD Processors Zen core processors, like Family 17h Picasso SOC processors ● Breaks assumptions about x86 boot flow ○ PSP trains memory, not x86 core ○ DRAM available BEFORE x86 released from reset ○ Does not use cache-as-ram (CAR) (aka tempRAM init) ○ PSP loads firmware image into DRAM before x86 released from reset 6 FSP coreboot Bootflow 7 New: AMD Processors Zen core processors, like Family 17h Picasso SOC processors ● Breaks assumptions about x86 boot flow ○ PSP trains memory, not x86 core ○ DRAM available BEFORE x86 released from reset ○ Does not use cache-as-ram (CAR) (aka tempRAM init) ○ PSP loads firmware image into DRAM before x86 released from reset ● FSP implications ○ FSP-T not needed, FSP-M repurposed but present, FSP-S mostly unchanged ● coreboot implications ○ Bootblock & romstage would be after DRAM, but still rely on some of that code ○ Need to handle assumptions about CAR cbmem initialization, etc. ■ CAR contains information which must be copied to cbmem for later use 8 Our Approach ● Maximize use of existing FSP / coreboot solution ○ Maintaining entry points for clarity and order ○ Based on Intel FSP 2.0 specification ● Minimize change to coreboot common code ○ Created “hybrid romstage” combining necessary features of bootblock and romstage ■ PSP uncompresses hybrid romstage to DRAM prior to x86 release from reset ○ Sacrificing some reserved DRAM as a mock CAR to leverage romstage code dependent 9 Status ● Preliminary version running on AMD reference design ● Expect production worthy version in 2020 ○ Complete ACPI support ○ Implement S3 and Si0x support ● Based on coreboot community feedback ○ Update to FSP 2.1 ○ Create a new pspstage to replace hybrid romstage ■ Will be specific to AMD Fam 17h and beyond ■ Eliminate dependency on the virtual CAR structure ■ Functionality could vary based on subsequent stages ● Very lean for ramstage which does everything ● A little more complex for LinuxBoot to take over with a kernel 10.