From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>, "Gary Guo" <gary@garyguo.net>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>
Cc: <nova-gpu@lists.linux.dev>, <dri-devel@lists.freedesktop.org>,
<linux-kernel@vger.kernel.org>, <rust-for-linux@vger.kernel.org>,
"dri-devel" <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH v4 09/13] gpu: nova-core: introduce GspBootMethod
Date: Thu, 02 Jul 2026 11:28:51 +0900 [thread overview]
Message-ID: <DJNQC1A84TF0.17HUBQBCRGFZ4@nvidia.com> (raw)
In-Reply-To: <20260629-nova-bootcontext-v4-9-5539d8469590@nvidia.com>
On Mon Jun 29, 2026 at 11:09 PM JST, Alexandre Courbot wrote:
> The GSP boot method is currently determined by two ad-hoc methods of
> `Chipset`: `uses_fsp` (a boolean telling whether to use the FSP boot
> path or the Sec2 Booter one) and `needs_fwsec_bootloader` (another
> boolean valid only for the Sec2 Booter method that tells whether the
> FWSEC bootloader must be used).
>
> This is neither extensible nor sound: the combination `uses_fsp &&
> needs_fwsec_bootloader` is invalid, but can still be expressed.
>
> Thus, unify these two predicates into a single `gsp_boot_method` method
> that returns an enum type unambiguously describing the boot method to
> use. This ensures that no invalid combination can be expressed, which
> makes matching sounder.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
Ideally we would not need to expose bootloader details (needs fwsec
bootloader, mapping of architecture to GspBootMethod) outside of the
HAL, and also not have to duplicate the logic for determining
`needs_fwsec_bootloader` in both the HAL and Chipset. One thing
preventing keeping all this in the HALs is that we need to know the set
of firmware files in a const context, which can't go through the &dyn
for HALs. I also find it a bit odd to go Chipset->GspBootMethod->HAL
which relies on the GSP HAL being entirely determined by the boot method
which doesn't feel generally correct to me.
What if we added a const fn n gsp/hal.rs called like boot_firmware_files
( or whatever) which returns the extra firmware files needed to boot the
GSP based on the architecture. Then we don't need to expose details like
`needs_fwsec_bootloader` or `GspBootMethod` outside of the HALs. We
still need another set of matches but it's unavoidable AFAICT without
being able to know the HAL type in a const context, at least it's
consolidated and in the HAL this way. In the future we might consider
type parameterising `Gpu` with the chipset and types that it uses with
the minimal set of strategies that it needs (e.g. sec2 vs fsp boot) then
we could even make the HALs not use dyn and push a bunch of stuff into
associated types.
That looks like this (on top of patch 8):
WDYT?
diff --git a/drivers/gpu/nova-core/firmware.rs b/drivers/gpu/nova-core/firmware.rs
index 80e948bf7511..1c02d80de7bc 100644
--- a/drivers/gpu/nova-core/firmware.rs
+++ b/drivers/gpu/nova-core/firmware.rs
@@ -423,24 +423,19 @@ const fn make_entry_file(self, chipset: &str, fw: &str) -> Self {
const fn make_entry_chipset(self, chipset: gpu::Chipset) -> Self {
let name = chipset.name();
- let this = self
+ let mut this = self
.make_entry_file(name, "bootloader")
.make_entry_file(name, "gsp");
- // FSP-based chipsets (Hopper, Blackwell and later) boot the GSP via the FMC image loaded by
- // FSP. Older chipsets use the SEC2 booter instead.
- let this = if chipset.uses_fsp() {
- this.make_entry_file(name, "fmc")
- } else {
- this.make_entry_file(name, "booter_load")
- .make_entry_file(name, "booter_unload")
- };
-
- if chipset.needs_fwsec_bootloader() {
- this.make_entry_file(name, "gen_bootloader")
- } else {
- this
+ // Add the firmware files specific to the GSP boot method of `chipset`.
+ let boot_files = crate::gsp::boot_firmware_files(chipset);
+ let mut i = 0;
+ while i < boot_files.len() {
+ this = this.make_entry_file(name, boot_files[i]);
+ i += 1;
}
+
+ this
}
pub(crate) const fn create(
diff --git a/drivers/gpu/nova-core/firmware/fwsec.rs b/drivers/gpu/nova-core/firmware/fwsec.rs
index 95e0dd77746b..7a931f22f629 100644
--- a/drivers/gpu/nova-core/firmware/fwsec.rs
+++ b/drivers/gpu/nova-core/firmware/fwsec.rs
@@ -385,9 +385,8 @@ pub(crate) fn new(
/// Loads the FWSEC firmware into `falcon` and execute it.
///
- /// This must only be called on chipsets that do not need the FWSEC bootloader (i.e., where
- /// [`Chipset::needs_fwsec_bootloader()`](crate::gpu::Chipset::needs_fwsec_bootloader) returns
- /// `false`). On chipsets that do, use [`bootloader::FwsecFirmwareWithBl`] instead.
+ /// This must only be called on chipsets that do not need the FWSEC bootloader. On chipsets
+ /// where the bootloader is required, use [`bootloader::FwsecFirmwareWithBl`] instead.
pub(crate) fn run(&self, dev: &Device<device::Bound>, falcon: &Falcon<'_, Gsp>) -> Result<()> {
// Reset falcon, load the firmware, and run it.
falcon
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 32bfa0be2357..c04706b60ba8 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -133,22 +133,6 @@ pub(crate) const fn arch(self) -> Architecture {
}
}
- /// Returns `true` if this chipset requires the PIO-loaded bootloader in order to boot FWSEC.
- ///
- /// This includes all chipsets < GA102.
- pub(crate) const fn needs_fwsec_bootloader(self) -> bool {
- matches!(self.arch(), Architecture::Turing) || matches!(self, Self::GA100)
- }
-
- /// Returns `true` if this chipset boots via FSP (Hopper and later), which requires the FMC
- /// firmware image.
- pub(crate) const fn uses_fsp(self) -> bool {
- matches!(
- self.arch(),
- Architecture::Hopper | Architecture::BlackwellGB10x | Architecture::BlackwellGB20x
- )
- }
-
/// Returns the address range of the PCI config mirror space.
pub(crate) fn pci_config_mirror_range(self) -> Range<u32> {
hal::gpu_hal(self).pci_config_mirror_range()
diff --git a/drivers/gpu/nova-core/gsp.rs b/drivers/gpu/nova-core/gsp.rs
index b4ac4156056e..d5cca3c8350a 100644
--- a/drivers/gpu/nova-core/gsp.rs
+++ b/drivers/gpu/nova-core/gsp.rs
@@ -30,6 +30,7 @@
GspFwWprMeta,
LibosParams, //
};
+pub(crate) use hal::boot_firmware_files;
use crate::{
driver::Bar0,
diff --git a/drivers/gpu/nova-core/gsp/hal.rs b/drivers/gpu/nova-core/gsp/hal.rs
index eddb4e8bf510..9da078dd1059 100644
--- a/drivers/gpu/nova-core/gsp/hal.rs
+++ b/drivers/gpu/nova-core/gsp/hal.rs
@@ -57,6 +57,25 @@ fn post_boot(&self, _gsp: &Gsp, _ctx: &GspBootContext<'_>, _gsp_fw: &GspFirmware
}
}
+/// Returns the names of the firmware files required to boot the GSP of `chipset`, in addition to
+/// the "bootloader" and "gsp" images required by all chipsets.
+pub(crate) const fn boot_firmware_files(chipset: Chipset) -> &'static [&'static str] {
+ match chipset.arch() {
+ // Turing chipsets boot the GSP via the SEC2 Booter, and require the FWSEC bootloader.
+ Architecture::Turing => &["booter_load", "booter_unload", "gen_bootloader"],
+ // GA100 also requires the FWSEC bootloader.
+ Architecture::Ampere if matches!(chipset, Chipset::GA100) => {
+ &["booter_load", "booter_unload", "gen_bootloader"]
+ }
+ // Other Ampere chipsets, as well as Ada chipsets, run FWSEC directly.
+ Architecture::Ampere | Architecture::Ada => &["booter_load", "booter_unload"],
+ // Hopper and later chipsets boot the GSP via the FMC image loaded by FSP.
+ Architecture::Hopper | Architecture::BlackwellGB10x | Architecture::BlackwellGB20x => {
+ &["fmc"]
+ }
+ }
+}
+
/// Returns the GSP HAL to be used for `chipset`.
pub(super) fn gsp_hal(chipset: Chipset) -> &'static dyn GspHal {
match chipset.arch() {
next prev parent reply other threads:[~2026-07-02 2:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 14:09 [PATCH v4 00/13] gpu: nova-core: consolidate and streamline GSP boot process Alexandre Courbot
2026-06-29 14:09 ` [PATCH v4 01/13] gpu: nova-core: gsp: sequencer: use GspBootContext Alexandre Courbot
2026-06-29 14:09 ` [PATCH v4 02/13] gpu: nova-core: gsp: sequencer: do not store sequence into GspSequencer Alexandre Courbot
2026-06-29 14:09 ` [PATCH v4 03/13] gpu: nova-core: gsp: replace BootUnloadGuard with local handlers Alexandre Courbot
2026-07-01 2:54 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 04/13] gpu: nova-core: gsp: pass GspBootContext to unload methods Alexandre Courbot
2026-07-01 3:57 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 05/13] gpu: nova-core: gsp: centralize missing unload bundle warnings Alexandre Courbot
2026-07-01 4:06 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 06/13] gpu: nova-core: gsp: fold TU102 unload bundle construction into HAL method Alexandre Courbot
2026-07-01 4:15 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 07/13] gpu: nova-core: gsp: turn FWSEC execution " Alexandre Courbot
2026-07-01 4:16 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 08/13] gpu: nova-core: gsp: make use of FWSEC bootloader a property of the TU102 HAL Alexandre Courbot
2026-06-29 14:09 ` [PATCH v4 09/13] gpu: nova-core: introduce GspBootMethod Alexandre Courbot
2026-07-02 2:28 ` Eliot Courtney [this message]
2026-06-29 14:09 ` [PATCH v4 10/13] gpu: nova-core: avoid repeated calls to pci::Device::as_ref Alexandre Courbot
2026-07-01 6:38 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 11/13] gpu: nova-core: gsp: pass GspBootContext mutably Alexandre Courbot
2026-07-01 6:40 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 12/13] gpu: nova-core: gsp: separate context and GPU lifetimes in GspBootContext Alexandre Courbot
2026-07-01 6:52 ` Eliot Courtney
2026-06-29 14:09 ` [PATCH v4 13/13] gpu: nova-core: store Fsp instance in Gpu Alexandre Courbot
2026-07-01 6:46 ` Eliot Courtney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DJNQC1A84TF0.17HUBQBCRGFZ4@nvidia.com \
--to=ecourtney@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel-bounces@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=ttabi@nvidia.com \
--cc=zhiw@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox