[PATCH v2 0/1] gpu: nova-core: correct FSP documentation

[PATCH v2 0/1] gpu: nova-core: correct FSP documentation

[Zhi Wang]

This patch applies on top of Alexandre Courbot's GSP-FMC
naming/framing fix [1].

Alexandre's patch corrects the code naming. This follow-up folds the
FMC expansion fix into the related documentation changes:

- Distinguish the roles of FSP, GSP BootROM, and GSP-FMC;
- Correct the FMC, NVDM, FRTS, and TLV terminology;
- Clarify the scope of the documented dGPU boot path and the meaning of
the COT response.

Changes in v2:
- Fold the FMC expansion fix into this documentation patch. (Alex)

v1: https://lore.kernel.org/cover.1787754628.git.zhiw@nvidia.com/

[1] https://patch.msgid.link/20260825-gsp-fmc-rename-v1-1-f82526f01d7d@nvidia.com

Zhi Wang (1):
  gpu: nova-core: correct FSP secure boot documentation

 Documentation/gpu/nova/core/fsp.rst | 88 ++++++++++++++++-------------
 1 file changed, 50 insertions(+), 38 deletions(-)


base-commit: d53bc149eea6213e9c4a4604df5521db7b7296ca
prerequisite-patch-id: 4bed4cad6ef80bb3ec7dedd5e32969eb50482c57
-- 
2.53.0

[PATCH v2 1/1] gpu: nova-core: correct FSP secure boot documentation

[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

Re: [PATCH v2 1/1] gpu: nova-core: correct FSP secure boot documentation

[Alexandre Courbot]

On Thu Aug 27, 2026 at 4:46 PM JST, Zhi Wang wrote:
> 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 Ampere boot model right above had a nice convention where the
processor running the firmware is explicitly mentioned in parenthesis.
Can we follow that same convention here for consistency?

>  
> -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).

FRTS is also expanded as "Firmware Runtine Services" in frts.rst, we
should fix it there as well.

Otherwise this looks good to me, thanks!