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@xxxxxxxxxx>
> ---
>  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!