[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250913-nova_firmware-v6-0-9007079548b0@nvidia.com>
Date: Sat, 13 Sep 2025 23:12:13 +0900
From: Alexandre Courbot <acourbot@...dia.com>
To: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>, David Airlie <airlied@...il.com>,
Simona Vetter <simona@...ll.ch>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>
Cc: John Hubbard <jhubbard@...dia.com>,
Alistair Popple <apopple@...dia.com>,
Joel Fernandes <joelagnelf@...dia.com>, Timur Tabi <ttabi@...dia.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
nouveau@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
Alexandre Courbot <acourbot@...dia.com>
Subject: [PATCH v6 00/11] gpu: nova-core: process and prepare more
firmwares to boot GSP
Sending a final revision to have the `Link:` tags that dim requires, and
for the record.
This series makes more progress on the GSP boot process for Ampere GPUs.
At the end of the previous series [1], we were left with a WPR memory
region created by the FRTS firmware, but still far from the GSP running.
This series brings us closer to that goal by preparing 2 new firmware
packages:
* The Booter firmware, which the driver loads and runs on the SEC2
falcon;
* The GSP bootloader and firmware, with the bootloader loaded by Booter
onto the GSP RISC-V core to verify and load the actual GSP firmware.
There firmwares are involved in a rather complex dance that is made
necessary by limitations related to the level of privilege required to
load code onto the GSP (doing so requires a Heavy Secured signed
firmware, which is the role fulfilled by Booter).
The first 5 patches perform some cleanup and preparatory work for the
remainder of the series. Notably, the GSP boot is moved to a new method
of `Gpu` to get ready for the additional steps that will be added to it,
and the `Gpu` object is now fully built in-place. We also simplify
chipset name generation a bit and move the code requesting a firmware
file into a dedicated function in prevision of the removal of the
`Firmware` structure.
Patch 6 parses the Booter firmware file, queries the hardware for the
right signature to use, and patch it into the firmware blob. This makes
Booter ready to load and run.
Patches 7 and 8 prepare the GSP firmware and its bootloader, and keep
them into a single structure as they are closely related.
Patches 9 and 10 switch to the 570.144 firmware and introduce the
layout for its bindings. The raw bindings are stored in a private
module, and abstracted by the parent module as needed. This allows
consumer modules to access a safer/nicer form of the bindings than the
raw one, and also makes it easier to switch to a different (and
potentially incompatible) firmware version in the future.
570.144 has been picked because it is the latest firmware currently in
linux-firmware, but as development progresses the plan is to switch to a
newer one that is designed with the constraint of upstream in mind. So
support for 570.144 will be dropped in the future. Support for multiple
firmware versions is not considered at the moment: there is no immediate
need for it as the driver is still unstable, and we can think about this
point once we approach stability (and have better visibility about the
shape of the firmware at that point).
The last patch introduces the first bindings and uses them to compute
more framebuffer layout information needed for booting the GSP. A
separate patch series will pick up from there to use this information
and finally run these firmware blobs.
The base of this series is today's drm-rust-next, with the Alignment [2]
series required for the last patch.
A tree with all these dependencies and the patches of this series is
available at [3].
[1] https://lore.kernel.org/rust-for-linux/20250619-nova-frts-v6-0-ecf41ef99252@nvidia.com/
[2] https://lore.kernel.org/rust-for-linux/20250908-num-v5-0-c0f2f681ea96@nvidia.com/
[3] https://github.com/Gnurou/linux/tree/b4/nova_firmware
Signed-off-by: Alexandre Courbot <acourbot@...dia.com>
---
Changes in v6:
- Rename `request_nv_firmware` to `nv_firmware`.
- Move GSP boot code to the `gsp/boot` module.
- Declare and use an empty `Gsp` type and proactively pin it into the
`Gpu` object, in prevision of the future addition of mutexes.
- Link to v5: https://lore.kernel.org/r/20250911-nova_firmware-v5-0-5a8a33bddca1@nvidia.com
Changes in v5:
- Perform construction of `Gpu` object in-place.
- Link to v4: https://lore.kernel.org/r/20250909-nova_firmware-v4-0-4dcb433d5fee@nvidia.com
Changes in v4:
- Rebase on top of latest Alignment series.
- Make use of pin-init references to initialized fields.
- Remove all uses of `unsafe` except for `FromBytes` and `AsBytes`
implementations.
- Keep the GSP placeholder inside the `Gpu` struct.
- Move GSP firmware bindings under the `gsp` module.
- Get the firmware-specific information from the bindings instead of a
HAL.
- Link to v3: https://lore.kernel.org/r/20250902-nova_firmware-v3-0-56854d9c5398@nvidia.com
Changes in v3:
- Move the GSP boot process out of the Gpu constructor.
- Get rid of the `Firmware` struct and discard loaded firmware blobs
after the GSP is booted.
- Consolidate the GSP firmware, bootloader and signatures into a single
type.
- Make firmware bindings completely opaque to the driver.
- Improve firmware abstractions related to framebuffer carveout.
- Improve comments and naming throughout the series. (thanks John!)
- Use alias for bindings module in `nvfw` to avoid repeated version
numbers everywhere. (thanks John!)
- Fix inconsistency in naming of members of Booter header. (thanks
Timur!)
- Link to v2: https://lore.kernel.org/r/20250826-nova_firmware-v2-0-93566252fe3a@nvidia.com
Changes in v2:
- Add some GSP bindings and use them to compute more FB layout info
needed to boot GSP,
- Use PinInit in GspFirmware to avoid several heap allocations,
- Rename `bootloader` to `gsp_bootloader` in `Firmware` to avoid
confusion with the future Turing falcon bootloader,
- Link to v1: https://lore.kernel.org/r/20250822-nova_firmware-v1-0-ff5633679460@nvidia.com
---
Alexandre Courbot (10):
gpu: nova-core: require `Send` on `FalconEngine` and `FalconHal`
gpu: nova-core: move GSP boot code to its own module
gpu: nova-core: add Chipset::name() method
gpu: nova-core: firmware: move firmware request code into a function
gpu: nova-core: firmware: add support for common firmware header
gpu: nova-core: firmware: process Booter and patch its signature
gpu: nova-core: firmware: process and prepare the GSP firmware
gpu: nova-core: firmware: process the GSP bootloader
gpu: nova-core: firmware: use 570.144 firmware
gpu: nova-core: compute layout of more framebuffer regions required for GSP
Alistair Popple (1):
gpu: nova-core: Add base files for r570.144 firmware bindings
Documentation/gpu/nova/core/todo.rst | 17 -
drivers/gpu/nova-core/driver.rs | 9 +-
drivers/gpu/nova-core/falcon.rs | 6 +-
drivers/gpu/nova-core/falcon/hal.rs | 2 +-
drivers/gpu/nova-core/fb.rs | 65 +++-
drivers/gpu/nova-core/firmware.rs | 107 ++++--
drivers/gpu/nova-core/firmware/booter.rs | 375 ++++++++++++++++++++++
drivers/gpu/nova-core/firmware/gsp.rs | 243 ++++++++++++++
drivers/gpu/nova-core/firmware/riscv.rs | 91 ++++++
drivers/gpu/nova-core/gpu.rs | 186 ++++-------
drivers/gpu/nova-core/gsp.rs | 27 ++
drivers/gpu/nova-core/gsp/boot.rs | 137 ++++++++
drivers/gpu/nova-core/gsp/fw.rs | 101 ++++++
drivers/gpu/nova-core/gsp/fw/r570_144.rs | 28 ++
drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs | 126 ++++++++
drivers/gpu/nova-core/nova_core.rs | 1 +
drivers/gpu/nova-core/util.rs | 20 --
17 files changed, 1337 insertions(+), 204 deletions(-)
---
base-commit: e2580413a83680f679904ad2f2c1aa6969876469
change-id: 20250822-nova_firmware-e0ffb492ba35
Best regards,
--
Alexandre Courbot <acourbot@...dia.com>
Powered by blists - more mailing lists