kernel/linux.git/drivers/gpu/nova-core/firmware.rs, branch linux-7.0.y

gpu: nova-core: firmware: fix and explain v2 header offsets computations

2026-05-23T11:08:44+00:00

[ Upstream commit 17d7c97f73c7a0bd90bd22cd7441269a6f8a1d72 ] There are no offsets in `FalconUCodeDescV2` to give the non-secure and secure IMEM sections start offsets relative to the beginning of the firmware object. The start offsets for both sections were set to `0`, but that is obviously incorrect since two different sections cannot start at the same offset. Since these offsets were not used by the bootloader, this doesn't prevent proper function but is incorrect nonetheless. Fix this by computing the start of the secure IMEM section relatively to the start of the firmware object and setting it properly. Also add and improve comments to explain how the values are obtained. Fixes: dbfb5aa41f16 ("gpu: nova-core: add FalconUCodeDescV2 support") Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260306-turing_prep-v11-9-8f0042c5d026@nvidia.com Signed-off-by: Alexandre Courbot Signed-off-by: Sasha Levin

gpu: nova-core: falcon: rename load parameters to reflect DMA dependency

2026-05-23T11:08:44+00:00

[ Upstream commit 8a623869b8269dbf52d52711cd7b9355044b6b53 ] The current `FalconLoadParams` and `FalconLoadTarget` types are fit for DMA loading, but not so much for PIO loading which will require its own types. Start by renaming them to something that indicates that they are indeed DMA-related. Reviewed-by: Eliot Courtney Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260306-turing_prep-v11-3-8f0042c5d026@nvidia.com [acourbot@nvidia.com: fixup order of import items.] Signed-off-by: Alexandre Courbot Stable-dep-of: 17d7c97f73c7 ("gpu: nova-core: firmware: fix and explain v2 header offsets computations") Signed-off-by: Sasha Levin

gpu: nova-core: create falcon firmware DMA objects lazily

2026-05-23T11:08:44+00:00

[ Upstream commit bc9de9e1af2f05461460e1b215a6d209ee62d65a ] When DMA was the only loading option for falcon firmwares, we decided to store them in DMA objects as soon as they were loaded from disk and patch them in-place to avoid having to do an extra copy. This decision complicates the PIO loading patch considerably, and actually does not even stand on its own when put into perspective with the fact that it requires 8 unsafe statements in the code that wouldn't exist if we stored the firmware into a `KVVec` and copied it into a DMA object at the last minute. The cost of the copy is, as can be expected, imperceptible at runtime. Thus, switch to a lazy DMA object creation model and simplify our code a bit. This will also have the nice side-effect of being more fit for PIO loading. Reviewed-by: Eliot Courtney Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260306-turing_prep-v11-1-8f0042c5d026@nvidia.com [acourbot@nvidia.com: add TODO item to switch back to a coherent allocation when it becomes convenient to do so.] Signed-off-by: Alexandre Courbot Stable-dep-of: 17d7c97f73c7 ("gpu: nova-core: firmware: fix and explain v2 header offsets computations") Signed-off-by: Sasha Levin

gpu: nova-core: add FalconUCodeDescV2 support

2026-01-24T01:48:59+00:00

The FRTS firmware in Turing and GA100 VBIOS has an older header format (v2 instead of v3). To support both v2 and v3 at runtime, add the FalconUCodeDescV2 struct, and update code that references the FalconUCodeDescV3 directly with a FalconUCodeDesc enum that encapsulates both. Signed-off-by: Timur Tabi Reviewed-by: Joel Fernandes Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260122222848.2555890-11-ttabi@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: replace use of `as` with functions from `num`

2025-11-07T23:22:45+00:00

Use the newly-introduced `num` module to replace the use of `as` wherever it is safe to do. This ensures that a given conversion cannot lose data if its source or destination type ever changes. Acked-by: Danilo Krummrich [acourbot@nvidia.com: fix merge conflicts after rebase.] Signed-off-by: Alexandre Courbot Message-ID: <20251029-nova-as-v3-5-6a30c7333ad9@nvidia.com>

gpu: nova-core: apply the one "use" item per line policy

2025-11-07T14:10:44+00:00

As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for the entire nova-core driver. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Acked-by: Danilo Krummrich Signed-off-by: John Hubbard [acourbot@nvidia.com: remove imports already in prelude as pointed out by Danilo.] [acourbot@nvidia.com: remove a few unneeded trailing `//`.] Signed-off-by: Alexandre Courbot Message-ID: <20251107021006.434109-1-jhubbard@nvidia.com>

gpu: nova-core: firmware: use 570.144 firmware

2025-09-13T14:17:45+00:00

570.144 is the latest available into linux-firmware as of this commit, and the one we will use to start development of nova-core. It should eventually be dropped for a newer version before the driver becomes able to do anything useful. The newer firmware is expected to iron out some of the inelegances of 570.144, notably related to packaging. Reviewed-by: John Hubbard Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-9-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: firmware: process the GSP bootloader

2025-09-13T14:17:42+00:00

The GSP bootloader is a small RISC-V firmware that is loaded by Booter onto the GSP core and is in charge of loading, validating, and starting the actual GSP firmware. It is a regular binary firmware file containing a specific header. Create a type holding the DMA-mapped firmware as well as useful information extracted from the header, and hook it into our firmware structure for later use. The GSP bootloader is stored into the `GspFirmware` structure, since it is part of the GSP firmware package. This makes the `Firmware` structure empty, so remove it. Reviewed-by: John Hubbard Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-8-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: firmware: process and prepare the GSP firmware

2025-09-13T14:17:38+00:00

The GSP firmware is a binary blob that is verified, loaded, and run by the GSP bootloader. Its presentation is a bit peculiar as the GSP bootloader expects to be given a DMA address to a 3-levels page table mapping the GSP firmware at address 0 of its own address space. Prepare such a structure containing the DMA-mapped firmware as well as the DMA-mapped page tables, and a way to obtain the DMA handle of the level 0 page table. Then, move the GSP firmware instance from the `Firmware` struct to the `start_gsp` method since it doesn't need to be kept after the GSP is booted. As we are performing the required ELF section parsing and radix3 page table building, remove these items from the TODO file. Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-7-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: firmware: process Booter and patch its signature

2025-09-13T14:17:34+00:00

The Booter signed firmware is an essential part of bringing up the GSP on Turing and Ampere. It is loaded on the sec2 falcon core and is responsible for loading and running the RISC-V GSP bootloader into the GSP core. Add support for parsing the Booter firmware loaded from userspace, patch its signatures, and store it into a form that is ready to be loaded and executed on the sec2 falcon. Then, move the Booter instance from the `Firmware` struct to the `start_gsp` method since it doesn't need to be kept after the GSP is booted. We do not run Booter yet, as its own payload (the GSP bootloader and firmware image) still need to be prepared. Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-6-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot