aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/gpu/nova-core/firmware (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-13gpu: nova-core: firmware: process the GSP bootloaderAlexandre Courbot2-0/+98
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 <jhubbard@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-8-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: firmware: process and prepare the GSP firmwareAlexandre Courbot1-0/+236
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 <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-7-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: firmware: process Booter and patch its signatureAlexandre Courbot1-0/+375
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 <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-6-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-01gpu: nova-core: vbios: store reference to Device where relevantAlexandre Courbot1-4/+4
Now that the vbios code uses a non-bound `Device` instance, store an `ARef` to it at construction time so we can use it for logging without having to carry an extra argument on every method for that sole purpose. Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250808-vbios_device-v1-2-834bbbab6471@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-22gpu: nova-core: falcon: align DMA transfers to 256 bytesAlexandre Courbot1-8/+1
Falcon DMA transfers are done in 256 bytes increments, and the method responsible for initiating the transfer checked that the required length was indeed a multiple of 256. While correct, this also requires callers to specifically account for this limitation of DMA transfers, and we had for instance the fwsec code performing a seemingly arbitrary (and potentially overflowing) upwards alignment of the DMEM load size to match this requirement. Let's move that alignment into the loading code itself instead: since it is working in terms of number of transfers, we can turn this upwards alignment into a non-overflowing operation, and check that the requested transfer remains into the limits of the DMA object. This also allows us to remove a DMA-specific constant in the fwsec code. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250821-falcondma_256b-v2-1-83e8647a24b5@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-25gpu: nova-core: consider `clippy::cast_lossless`Danilo Krummrich1-1/+1
Fix all warnings caused by `clippy::cast_lossless`, which is going to be enabled by [1]. Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250615-ptr-as-ptr-v12-5-f43b024581e8@gmail.com [1] Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250624132337.2242-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: update and annotate TODO listAlexandre Courbot1-3/+3
A few new dependencies are required to remove some of the TODO items: - A way to safely convert from byte slices to types implementing `FromBytes`, - A way to obtain slices and write into a `CoherentAllocation`, - Several improvements to the `register!()` macro, - Alignment operations to powers of two, and an equivalent to the C `fls`, - Support for `xa_alloc` in the XAlloc bindings. Some items have also become obsolete: - The auxiliary bus abstractions have been implemented and are in use, - The ELF utilities are not considered for being part of the core kernel bindings anymore. - VBIOS, falcon and GPU timer have been completed. We now have quite a few TODO entries in the code, so annotate them with a 4 letter code representing the corresponding task in `todo.rst`. This allows to easily find which part of the code corresponds to a given entry (and conversely). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-24-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: load and run FWSEC-FRTSAlexandre Courbot1-0/+25
With all the required pieces in place, load FWSEC-FRTS onto the GSP falcon, run it, and check that it successfully carved out the WPR2 region out of framebuffer memory. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-23-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTSAlexandre Courbot1-0/+398
The FWSEC firmware needs to be extracted from the VBIOS and patched with the desired command, as well as the right signature. Do this so we are ready to load and run this firmware into the GSP falcon and create the FRTS region. [joelagnelf@nvidia.com: give better names to FalconAppifHdrV1's fields] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-22-ecf41ef99252@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>