* [PATCH v2 1/1] gpu: nova-core: correct FSP secure boot documentation
2026-08-27 7:45 [PATCH v2 0/1] gpu: nova-core: correct FSP documentation Zhi Wang
@ 2026-08-27 7:46 ` Zhi Wang
0 siblings, 0 replies; 2+ messages in thread
From: Zhi Wang @ 2026-08-27 7:46 UTC (permalink / raw)
To: dakr, acourbot
Cc: airlied, simona, ojeda, alex.gaynor, boqun.feng, gary, bjorn3_gh,
lossin, a.hindborg, aliceryhl, tmgross, jhubbard, ecourtney,
apopple, cjia, smitra, kjaju, alkumar, ankita, aniketa,
kwankhede, targupta, nova-gpu, linux-kernel, zhiwang, Zhi Wang
The FSP documentation still blurs the roles of FSP, GSP BootROM,
and GSP-FMC in the common Hopper/Blackwell dGPU boot path. It also
uses incorrect expansions for FMC, NVDM, and FRTS, and describes
GSP-FMC as an ELF image, while nova-core loads it from a TLV firmware
file.
Correct those terms and show the FSP-to-GSP handoff in the existing
message-flow diagram. Clarify that the COT response reports command
status only, and scope the SEC2 and PRC descriptions to the dGPU
platforms covered by nova-core.
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
---
Documentation/gpu/nova/core/fsp.rst | 88 ++++++++++++++++-------------
1 file changed, 50 insertions(+), 38 deletions(-)
diff --git a/Documentation/gpu/nova/core/fsp.rst b/Documentation/gpu/nova/core/fsp.rst
index 52d618d22bb8..bebe3c8ede2a 100644
--- a/Documentation/gpu/nova/core/fsp.rst
+++ b/Documentation/gpu/nova/core/fsp.rst
@@ -3,8 +3,8 @@
===================================================
FSP (Foundation Security Processor) and Secure Boot
===================================================
-This document describes the role of the FSP in the GPU boot sequence on
-Hopper and Blackwell GPUs, and how it differs from the earlier Ampere boot
+This document describes the role of the FSP in the common boot path for
+Hopper and Blackwell dGPUs, and how it differs from the earlier Ampere boot
flow. It also provides a brief overview of the PRC (Product Reconfiguration
Control) protocol used to query device configuration through FSP. As with
other documents in this directory, the information is subject to change and
@@ -42,18 +42,20 @@ On **Hopper/Blackwell** GPUs, FSP replaces this multi-stage process with a
single message-driven interface::
FSP (hardware root of trust, boots from ROM)
- -> FMC (Falcon Microcontroller, verified by FSP)
- -> GSP-RM (verified and loaded by FMC)
+ -> GSP BootROM
+ -> GSP-FMC (First Mutable Code, running on GSP)
+ -> GSP-RM (verified and loaded by GSP-FMC)
-The driver only needs to:
+At a high level, the driver:
1. Wait for FSP to complete its own secure boot (polling a scratch register).
-2. Send a Chain of Trust (COT) message to FSP with the FMC firmware location,
- cryptographic signatures, and GSP boot parameters.
-3. FSP authenticates the FMC firmware and boots it, FMC in turn loads GSP-RM.
+2. Send a Chain of Trust (COT) message to FSP with the GSP-FMC firmware
+ location, cryptographic signatures, and GSP boot parameters.
+3. Wait for the FSP command response, then for later GSP-side boot milestones.
-There is no SEC2 involvement, no Booter ucode, and no FWSEC-FRTS stage. The
-entire secure boot is driven by a single FSP message exchange.
+In the dGPU path described here, SEC2 and Booter ucode are not used to bring
+up GSP-RM, and FWSEC-FRTS is not run as a separate stage. The driver initiates
+secure boot through a single FSP message exchange.
Chain of Trust (COT) protocol
=============================
@@ -62,39 +64,49 @@ ensuring the GPU reaches a known, trusted state.
The driver communicates with FSP using a message queue (Falcon MSGQ
interface). Each message consists of an MCTP (Management Component Transport
-Protocol) transport header and an NVDM (NVIDIA Vendor Defined Message) header,
+Protocol) transport header and an NVDM (NVIDIA Data Model) header,
followed by a protocol-specific payload.
For Chain of Trust, the payload includes:
-- The system memory address of the FMC firmware image.
-- Cryptographic material: a SHA-384 hash, RSA-3K public key, and RSA-3K
- signature extracted from the FMC ELF firmware.
-- FRTS (Firmware Runtime Services) region information (vidmem offset and size).
+- The system memory address of the GSP-FMC firmware image.
+- Cryptographic material extracted from the GSP-FMC TLV firmware: a SHA-384
+ hash, RSA-3K public key, and RSA-3K signature.
+- FRTS (Firmware Runtime Security) region information (vidmem offset and size).
- The system memory address of the GSP boot arguments structure.
-FSP verifies the signature against the provided public key and hash, and if
-verification succeeds, boots the FMC. The FMC then authenticates and launches
-GSP-RM.
+FSP validates the COT payload and authenticates the GSP-FMC image using the
+supplied cryptographic material. It then stages the image in GSP memory and
+triggers GSP BootROM. GSP BootROM authenticates and starts GSP-FMC, which then
+authenticates and launches GSP-RM.
The message flow is::
- nova-core FSP
- | |
- | 1. Poll scratch register |
- | (wait for FSP boot complete) |
- | |
- | 2. COT message ------------> |
- | (FMC addr, signatures, |
- | boot params) |
- | |
- | |--- Verify FMC signature
- | |--- Boot FMC
- | |--- FMC loads GSP-RM
- | |
- | 3. COT response <------------ |
- | (success/error) |
- | |
+ nova-core FSP GSP
+ | | |
+ | 1. Poll scratch register | |
+ | (wait for FSP boot complete) | |
+ | | |
+ | 2. COT message ------------> | |
+ | (GSP-FMC addr, | |
+ | signatures, boot params) | |
+ | | |
+ | | Verify GSP-FMC |
+ | | signature |
+ | | |
+ | | Load GSP-FMC image |
+ | | -------------------->|
+ | | |
+ | | Trigger GSP BootROM |
+ | | -------------------->| GSP BootROM
+ | | | starts GSP-FMC
+ | 3. COT response <----------- | | GSP-FMC
+ | (command status) | | verifies and
+ | | | starts GSP-RM
+ | | |
+
+The COT response reports only the FSP command status; it does not indicate
+that GSP-RM is ready.
FSP message format
==================
@@ -107,7 +119,7 @@ All FSP messages share a common header format consisting of two 32-bit words:
- Bits 29:28: Packet sequence number
- Bits 23:16: Source Endpoint ID
-**NVDM header** (NVIDIA Vendor Defined Message):
+**NVDM header** (NVIDIA Data Model):
- Bits 6:0: MCTP message type (0x7e = vendor-defined PCI)
- Bits 23:8: PCI vendor ID (0x10de = NVIDIA)
@@ -127,9 +139,9 @@ Each knob has two values:
- **Active**: the currently effective value for this boot cycle.
- **Persistent**: the value stored in InfoROM, applied on subsequent boots.
-The nova-core driver uses PRC to read the vGPU mode knob (object ID 0x29)
-during early boot, before firmware loading, to determine whether the GPU
-should operate in vGPU mode.
+On Blackwell and later dGPUs, nova-core uses PRC to read the vGPU mode knob
+(object ID 0x29) during early boot, before firmware loading, to determine
+whether the GPU should operate in vGPU mode.
The PRC message format follows the same MCTP/NVDM header structure as COT,
with NVDM type 0x13. The payload contains:
--
2.53.0
^ permalink raw reply [flat|nested] 2+ messages in thread