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

gpu: nova-core: firmware: factor out an elf_str() function

2026-03-30T05:01:53+00:00

Factor out a chunk of complexity into a new subroutine. This is an incremental step in adding ELF32 support to the existing ELF64 section support, for handling GPU firmware. Signed-off-by: John Hubbard Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260326013902.588242-9-jhubbard@nvidia.com [acourbot: use fuller prefix in commit message.] Signed-off-by: Alexandre Courbot

gpu: nova-core: firmware: move firmware image parsing code to firmware.rs

2026-03-30T05:01:40+00:00

Up until now, only the GSP required parsing of its firmware headers. However, upcoming support for Hopper/Blackwell+ adds another firmware image (FMC), along with another format (ELF32). Therefore, the current ELF64 section parsing support needs to be moved up a level, so that both of the above can use it. There are no functional changes. This is pure code movement. Reviewed-by: Gary Guo Signed-off-by: John Hubbard Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260326013902.588242-8-jhubbard@nvidia.com [acourbot: use fuller prefix in commit message.] Signed-off-by: Alexandre Courbot

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

2026-03-09T05:29:21+00:00

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

gpu: nova-core: firmware: add comments to justify v3 header values

2026-03-09T05:15:13+00:00

There is no member in `FalconUCodeDescV3` to describe the start offsets of the IMEM and DMEM section in the firmware object. Add comments to justify how they are computed. Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260306-turing_prep-v11-8-8f0042c5d026@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: add gen_bootloader firmware to ModInfoBuilder

2026-03-09T01:39:10+00:00

Turing GPUs need an additional firmware file (the FWSEC generic bootloader) in order to initialize. Add it to `ModInfoBuilder`. Reviewed-by: Eliot Courtney Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260306-turing_prep-v11-11-8f0042c5d026@nvidia.com Signed-off-by: Alexandre Courbot

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

2026-03-09T01:35:40+00:00

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

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

2026-03-09T01:35:37+00:00

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

gpu: nova-core: use core library's CStr instead of kernel one

2026-02-24T23:17:04+00:00

The kernel's own CStr type has been replaced by the one in the core library, and is now an alias to the latter. Change our imports to directly reference the actual type. Reviewed-by: Lyude Paul Reviewed-by: Gary Guo Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260217-nova-misc-v3-7-b4e2d45eafbc@nvidia.com [acourbot@nvidia.com: remove unneeded imports reorganization in firmware/gsp.rs] Signed-off-by: Alexandre Courbot

gpu: nova-core: use checked arithmetic in BinFirmware::data

2026-02-24T23:16:55+00:00

Use checked_add() when computing the firmware data end offset in the BinFirmware::data() method. The data_offset and data_size fields come from the BinHdr structure parsed from the firmware file header. Reviewed-by: Zhi Wang Signed-off-by: Joel Fernandes Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260126202305.2526618-5-joelagnelf@nvidia.com Signed-off-by: Alexandre Courbot

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