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

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 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 <[email protected]>
---
 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 cc2e3bbb9b53..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 (First Mutable Code, 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