[PATCH 0/6] gpu: nova-core: Hopper/Blackwell prerequisites

[PATCH 0/6] gpu: nova-core: Hopper/Blackwell prerequisites

[John Hubbard]

I've based these Hopper/Blackwell prerequisites on top of Joel's and
Alex's changes, and also on top of my recent boot0/boot42 changes.

This makes it easier for both Timur Tabi to post his Turing support
(which he's about ready to do), and for me to post the actual
Hopper/Blackwell support, without generating conflicts.

Testing: This works as expected on Ampere and Blackwell (bare metal),
on my local test machine.

Here's a working branch, with my patches, if you would like to apply
locally:

    https://github.com/johnhubbard/linux/tree/nova-core-blackwell-prereqs-v0

John Hubbard (6):
  gpu: nova-core: print FB sizes, along with ranges
  gpu: nova-core: Hopper: basic GPU identification
  gpu: nova-core: Blackwell: basic GPU identification
  gpu: nova-core: factor .fwsignature* selection into a new
    get_gsp_sigs_section()
  gpu: nova-core: regs.rs: clean up chipset(), architecture()
  gpu: nova-core: use gpu::Architecture instead of long lists of GPUs

 drivers/gpu/nova-core/falcon/hal.rs   | 14 ++++++++----
 drivers/gpu/nova-core/fb.rs           | 33 ++++++++++++++++++++++++++-
 drivers/gpu/nova-core/fb/hal.rs       | 19 +++++++++------
 drivers/gpu/nova-core/firmware/gsp.rs | 30 ++++++++++++++++++++----
 drivers/gpu/nova-core/gpu.rs          | 22 ++++++++++++++++++
 drivers/gpu/nova-core/gsp/boot.rs     |  2 +-
 drivers/gpu/nova-core/regs.rs         | 29 +++++++++++------------
 7 files changed, 115 insertions(+), 34 deletions(-)


base-commit: 7f6c212713e07e714bdf29d1158e21c3965917f2
-- 
2.51.2

[PATCH 1/6] gpu: nova-core: print FB sizes, along with ranges

[John Hubbard]

For convenience of the reader: now you can directly see the sizes of
each range. It is suprising just how much this helps.

Sample output:

NovaCore 0000:e1:00.0: FbLayout {
    fb: 0x0..0x3ff800000 (16376 MB),
    vga_workspace: 0x3ff700000..0x3ff800000 (1 MB),
    frts: 0x3ff600000..0x3ff700000 (1 MB),
    boot: 0x3ff5fa000..0x3ff600000 (0 MB),
    elf: 0x3fb960000..0x3ff5f9000 (60 MB),
    wpr2_heap: 0x3f3900000..0x3fb900000 (128 MB),
    wpr2: 0x3f3800000..0x3ff700000 (191 MB),
    heap: 0x3f3700000..0x3f3800000 (1 MB),
    vf_partition_count: 0x0,
    rsvd_size: 0x1a00000,
}

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 drivers/gpu/nova-core/fb.rs       | 33 ++++++++++++++++++++++++++++++-
 drivers/gpu/nova-core/gsp/boot.rs |  2 +-
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
index 10406b6f2e16..004238689f26 100644
--- a/drivers/gpu/nova-core/fb.rs
+++ b/drivers/gpu/nova-core/fb.rs
@@ -87,7 +87,6 @@ pub(crate) fn unregister(&self, bar: &Bar0) {
 /// Layout of the GPU framebuffer memory.
 ///
 /// Contains ranges of GPU memory reserved for a given purpose during the GSP boot process.
-#[derive(Debug)]
 pub(crate) struct FbLayout {
     /// Range of the framebuffer. Starts at `0`.
     pub(crate) fb: Range<u64>,
@@ -107,6 +106,38 @@ pub(crate) struct FbLayout {
     pub(crate) vf_partition_count: u8,
 }
 
+struct RangeWithSize<'a>(&'a Range<u64>);
+
+impl core::fmt::Debug for RangeWithSize<'_> {
+    fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result {
+        if self.0.start == 0 && self.0.end == 0 {
+            write!(f, "0x0..0x0")
+        } else {
+            let size_mb = (self.0.end - self.0.start) >> 20;
+            write!(f, "{:#x}..{:#x} ({} MB)", self.0.start, self.0.end, size_mb)
+        }
+    }
+}
+
+impl core::fmt::Debug for FbLayout {
+    fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result {
+        f.debug_struct("FbLayout")
+            .field("fb", &RangeWithSize(&self.fb))
+            .field("vga_workspace", &RangeWithSize(&self.vga_workspace))
+            .field("frts", &RangeWithSize(&self.frts))
+            .field("boot", &RangeWithSize(&self.boot))
+            .field("elf", &RangeWithSize(&self.elf))
+            .field("wpr2_heap", &RangeWithSize(&self.wpr2_heap))
+            .field("wpr2", &RangeWithSize(&self.wpr2))
+            .field("heap", &RangeWithSize(&self.heap))
+            .field(
+                "vf_partition_count",
+                &fmt!("{:#x}", self.vf_partition_count),
+            )
+            .finish()
+    }
+}
+
 impl FbLayout {
     /// Computes the FB layout for `chipset`, for running the `bl` GSP bootloader and `gsp` GSP
     /// firmware.
diff --git a/drivers/gpu/nova-core/gsp/boot.rs b/drivers/gpu/nova-core/gsp/boot.rs
index bd3be366526e..c27a90aa782c 100644
--- a/drivers/gpu/nova-core/gsp/boot.rs
+++ b/drivers/gpu/nova-core/gsp/boot.rs
@@ -141,7 +141,7 @@ pub(crate) fn boot(
         )?;
 
         let fb_layout = FbLayout::new(chipset, bar, &gsp_fw)?;
-        dev_dbg!(dev, "{:#x?}\n", fb_layout);
+        dev_dbg!(dev, "{:#?}\n", fb_layout);
 
         Self::run_fwsec_frts(dev, gsp_falcon, bar, &bios, &fb_layout)?;
 
-- 
2.51.2

Re: [PATCH 1/6] gpu: nova-core: print FB sizes, along with ranges

[Alexandre Courbot]

On Thu Nov 6, 2025 at 12:54 PM JST, John Hubbard wrote:
> For convenience of the reader: now you can directly see the sizes of
> each range. It is suprising just how much this helps.
>
> Sample output:
>
> NovaCore 0000:e1:00.0: FbLayout {
>     fb: 0x0..0x3ff800000 (16376 MB),
>     vga_workspace: 0x3ff700000..0x3ff800000 (1 MB),
>     frts: 0x3ff600000..0x3ff700000 (1 MB),
>     boot: 0x3ff5fa000..0x3ff600000 (0 MB),
>     elf: 0x3fb960000..0x3ff5f9000 (60 MB),
>     wpr2_heap: 0x3f3900000..0x3fb900000 (128 MB),
>     wpr2: 0x3f3800000..0x3ff700000 (191 MB),
>     heap: 0x3f3700000..0x3f3800000 (1 MB),
>     vf_partition_count: 0x0,
>     rsvd_size: 0x1a00000,
> }
>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
>  drivers/gpu/nova-core/fb.rs       | 33 ++++++++++++++++++++++++++++++-
>  drivers/gpu/nova-core/gsp/boot.rs |  2 +-
>  2 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
> index 10406b6f2e16..004238689f26 100644
> --- a/drivers/gpu/nova-core/fb.rs
> +++ b/drivers/gpu/nova-core/fb.rs
> @@ -87,7 +87,6 @@ pub(crate) fn unregister(&self, bar: &Bar0) {
>  /// Layout of the GPU framebuffer memory.
>  ///
>  /// Contains ranges of GPU memory reserved for a given purpose during the GSP boot process.
> -#[derive(Debug)]
>  pub(crate) struct FbLayout {
>      /// Range of the framebuffer. Starts at `0`.
>      pub(crate) fb: Range<u64>,
> @@ -107,6 +106,38 @@ pub(crate) struct FbLayout {
>      pub(crate) vf_partition_count: u8,
>  }
>  
> +struct RangeWithSize<'a>(&'a Range<u64>);
> +
> +impl core::fmt::Debug for RangeWithSize<'_> {
> +    fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result {
> +        if self.0.start == 0 && self.0.end == 0 {
> +            write!(f, "0x0..0x0")
> +        } else {
> +            let size_mb = (self.0.end - self.0.start) >> 20;
> +            write!(f, "{:#x}..{:#x} ({} MB)", self.0.start, self.0.end, size_mb)
> +        }
> +    }
> +}
> +
> +impl core::fmt::Debug for FbLayout {
> +    fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result {
> +        f.debug_struct("FbLayout")
> +            .field("fb", &RangeWithSize(&self.fb))
> +            .field("vga_workspace", &RangeWithSize(&self.vga_workspace))
> +            .field("frts", &RangeWithSize(&self.frts))
> +            .field("boot", &RangeWithSize(&self.boot))
> +            .field("elf", &RangeWithSize(&self.elf))
> +            .field("wpr2_heap", &RangeWithSize(&self.wpr2_heap))
> +            .field("wpr2", &RangeWithSize(&self.wpr2))
> +            .field("heap", &RangeWithSize(&self.heap))
> +            .field(
> +                "vf_partition_count",
> +                &fmt!("{:#x}", self.vf_partition_count),
> +            )
> +            .finish()
> +    }
> +}

The only concern I have is that if we add fields to `FbLayout` we will
need (and probably forget) to update its `Debug` implementation.

How about we just use this more intrusively:

    pub(crate) struct FbRange(Range<u64>);

    // Convert easily from a regular `Range`.
    impl From<Range<u64>> for FbRange {
        fn from(range: Range<u64>) -> Self {
            Self(range)
        }
    }

    // Provide transparent access to the members of `Range`.
    impl Deref for FbRange {
        type Target = Range<u64>;

        fn deref(&self) -> &Self::Target {
            &self.0
        }
    }

    impl Debug for FbRange {
        ...
    }

Then we can change the members of `FbLayout` to `FbRange`, and keep its
derived `Debug` implementation.

The initialization code would only need to marginally change, e.g:

    let fb: FbRange = {
        let fb_size = hal.vidmem_size(bar);

        (0..fb_size).into()
    };

And with this new type, we can also address one another shortcoming that
was bugging me! In e.g. `boot.rs` we have this ugly bit:

        frts_size: fb_layout.frts.end - fb_layout.frts.start,

What we want is a `len` method, but since our range uses u64, and `len`
returns a `usize`, standard Rust doesn't provide one for us. But thanks
to this dedicated type we can now implement our own! :)

Not saying this has to be done in this patch though, but it's a nice
side-effect.

Re: [PATCH 1/6] gpu: nova-core: print FB sizes, along with ranges

[John Hubbard]

On 11/18/25 11:33 PM, Alexandre Courbot wrote:
> On Thu Nov 6, 2025 at 12:54 PM JST, John Hubbard wrote:
...
> And with this new type, we can also address one another shortcoming that
> was bugging me! In e.g. `boot.rs` we have this ugly bit:
> 
>          frts_size: fb_layout.frts.end - fb_layout.frts.start,
> 
> What we want is a `len` method, but since our range uses u64, and `len`
> returns a `usize`, standard Rust doesn't provide one for us. But thanks
> to this dedicated type we can now implement our own! :)
> 
> Not saying this has to be done in this patch though, but it's a nice
> side-effect.

This all sounds good, I'll do it, thanks for the ideas and most of
the implementation too. :)

thanks,
-- 
John Hubbard

[PATCH 2/6] gpu: nova-core: Hopper: basic GPU identification

[John Hubbard]

GH100 identification, including the ELF .fwsignature_gh10x.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 drivers/gpu/nova-core/falcon/hal.rs   | 2 +-
 drivers/gpu/nova-core/fb/hal.rs       | 2 +-
 drivers/gpu/nova-core/firmware/gsp.rs | 1 +
 drivers/gpu/nova-core/gpu.rs          | 5 +++++
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/nova-core/falcon/hal.rs b/drivers/gpu/nova-core/falcon/hal.rs
index c6c71db1bb70..2e1fcd7ac813 100644
--- a/drivers/gpu/nova-core/falcon/hal.rs
+++ b/drivers/gpu/nova-core/falcon/hal.rs
@@ -44,7 +44,7 @@ pub(super) fn falcon_hal<E: FalconEngine + 'static>(
     use Chipset::*;
 
     let hal = match chipset {
-        GA102 | GA103 | GA104 | GA106 | GA107 | AD102 | AD103 | AD104 | AD106 | AD107 => {
+        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107 => {
             KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>>
         }
         _ => return Err(ENOTSUPP),
diff --git a/drivers/gpu/nova-core/fb/hal.rs b/drivers/gpu/nova-core/fb/hal.rs
index 2f914948bb9a..c8e86193317d 100644
--- a/drivers/gpu/nova-core/fb/hal.rs
+++ b/drivers/gpu/nova-core/fb/hal.rs
@@ -32,7 +32,7 @@ pub(super) fn fb_hal(chipset: Chipset) -> &'static dyn FbHal {
     match chipset {
         TU102 | TU104 | TU106 | TU117 | TU116 => tu102::TU102_HAL,
         GA100 => ga100::GA100_HAL,
-        GA102 | GA103 | GA104 | GA106 | GA107 | AD102 | AD103 | AD104 | AD106 | AD107 => {
+        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107 => {
             ga102::GA102_HAL
         }
     }
diff --git a/drivers/gpu/nova-core/firmware/gsp.rs b/drivers/gpu/nova-core/firmware/gsp.rs
index e3d76a300851..f824863ad551 100644
--- a/drivers/gpu/nova-core/firmware/gsp.rs
+++ b/drivers/gpu/nova-core/firmware/gsp.rs
@@ -151,6 +151,7 @@ pub(crate) fn new<'a, 'b>(
 
         let sigs_section = match chipset.arch() {
             Architecture::Ampere => ".fwsignature_ga10x",
+            Architecture::Hopper => ".fwsignature_gh10x",
             Architecture::Ada => ".fwsignature_ad10x",
             _ => return Err(ENOTSUPP),
         };
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 9025bab1726b..678577cd8c9c 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -70,6 +70,8 @@ fn try_from(value: u32) -> Result<Self, Self::Error> {
     GA104 = 0x174,
     GA106 = 0x176,
     GA107 = 0x177,
+    // Hopper
+    GH100 = 0x180,
     // Ada
     AD102 = 0x192,
     AD103 = 0x193,
@@ -87,6 +89,7 @@ pub(crate) fn arch(&self) -> Architecture {
             Self::GA100 | Self::GA102 | Self::GA103 | Self::GA104 | Self::GA106 | Self::GA107 => {
                 Architecture::Ampere
             }
+            Self::GH100 => Architecture::Hopper,
             Self::AD102 | Self::AD103 | Self::AD104 | Self::AD106 | Self::AD107 => {
                 Architecture::Ada
             }
@@ -115,6 +118,7 @@ pub(crate) enum Architecture {
     #[default]
     Turing = 0x16,
     Ampere = 0x17,
+    Hopper = 0x18,
     Ada = 0x19,
 }
 
@@ -125,6 +129,7 @@ fn try_from(value: u8) -> Result<Self> {
         match value {
             0x16 => Ok(Self::Turing),
             0x17 => Ok(Self::Ampere),
+            0x18 => Ok(Self::Hopper),
             0x19 => Ok(Self::Ada),
             _ => Err(ENODEV),
         }
-- 
2.51.2

[PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification

[John Hubbard]

Blackwell GPU identification, including ELF .fwsignature_* items.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 drivers/gpu/nova-core/falcon/hal.rs   |  3 ++-
 drivers/gpu/nova-core/fb/hal.rs       |  5 ++---
 drivers/gpu/nova-core/firmware/gsp.rs | 16 ++++++++++++++++
 drivers/gpu/nova-core/gpu.rs          | 17 +++++++++++++++++
 4 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/nova-core/falcon/hal.rs b/drivers/gpu/nova-core/falcon/hal.rs
index 2e1fcd7ac813..7ba8ba856c72 100644
--- a/drivers/gpu/nova-core/falcon/hal.rs
+++ b/drivers/gpu/nova-core/falcon/hal.rs
@@ -44,7 +44,8 @@ pub(super) fn falcon_hal<E: FalconEngine + 'static>(
     use Chipset::*;
 
     let hal = match chipset {
-        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107 => {
+        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
+        | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => {
             KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>>
         }
         _ => return Err(ENOTSUPP),
diff --git a/drivers/gpu/nova-core/fb/hal.rs b/drivers/gpu/nova-core/fb/hal.rs
index c8e86193317d..30fde2487d8b 100644
--- a/drivers/gpu/nova-core/fb/hal.rs
+++ b/drivers/gpu/nova-core/fb/hal.rs
@@ -32,8 +32,7 @@ pub(super) fn fb_hal(chipset: Chipset) -> &'static dyn FbHal {
     match chipset {
         TU102 | TU104 | TU106 | TU117 | TU116 => tu102::TU102_HAL,
         GA100 => ga100::GA100_HAL,
-        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107 => {
-            ga102::GA102_HAL
-        }
+        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
+        | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => ga102::GA102_HAL,
     }
 }
diff --git a/drivers/gpu/nova-core/firmware/gsp.rs b/drivers/gpu/nova-core/firmware/gsp.rs
index f824863ad551..ed2dea2cd144 100644
--- a/drivers/gpu/nova-core/firmware/gsp.rs
+++ b/drivers/gpu/nova-core/firmware/gsp.rs
@@ -153,6 +153,22 @@ pub(crate) fn new<'a, 'b>(
             Architecture::Ampere => ".fwsignature_ga10x",
             Architecture::Hopper => ".fwsignature_gh10x",
             Architecture::Ada => ".fwsignature_ad10x",
+            Architecture::Blackwell => {
+                // Distinguish between GB10x and GB20x series
+                match chipset {
+                    // GB10x series: GB100, GB102
+                    Chipset::GB100 | Chipset::GB102 => ".fwsignature_gb10x",
+                    // GB20x series: GB202, GB203, GB205, GB206, GB207
+                    Chipset::GB202
+                    | Chipset::GB203
+                    | Chipset::GB205
+                    | Chipset::GB206
+                    | Chipset::GB207 => ".fwsignature_gb20x",
+                    // Unsupported Blackwell chips
+                    _ => return Err(ENOTSUPP),
+                }
+            }
+
             _ => return Err(ENOTSUPP),
         };
         let signatures = elf::elf64_section(fw.data(), sigs_section)
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 678577cd8c9c..024bd4d6e092 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -78,6 +78,14 @@ fn try_from(value: u32) -> Result<Self, Self::Error> {
     AD104 = 0x194,
     AD106 = 0x196,
     AD107 = 0x197,
+    // Blackwell
+    GB100 = 0x1a0,
+    GB102 = 0x1a2,
+    GB202 = 0x1b2,
+    GB203 = 0x1b3,
+    GB205 = 0x1b5,
+    GB206 = 0x1b6,
+    GB207 = 0x1b7,
 });
 
 impl Chipset {
@@ -93,6 +101,13 @@ pub(crate) fn arch(&self) -> Architecture {
             Self::AD102 | Self::AD103 | Self::AD104 | Self::AD106 | Self::AD107 => {
                 Architecture::Ada
             }
+            Self::GB100
+            | Self::GB102
+            | Self::GB202
+            | Self::GB203
+            | Self::GB205
+            | Self::GB206
+            | Self::GB207 => Architecture::Blackwell,
         }
     }
 }
@@ -120,6 +135,7 @@ pub(crate) enum Architecture {
     Ampere = 0x17,
     Hopper = 0x18,
     Ada = 0x19,
+    Blackwell = 0x1b,
 }
 
 impl TryFrom<u8> for Architecture {
@@ -131,6 +147,7 @@ fn try_from(value: u8) -> Result<Self> {
             0x17 => Ok(Self::Ampere),
             0x18 => Ok(Self::Hopper),
             0x19 => Ok(Self::Ada),
+            0x1b => Ok(Self::Blackwell),
             _ => Err(ENODEV),
         }
     }
-- 
2.51.2

Re: [PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification

[Timur Tabi]

On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>      let hal = match chipset {
> -        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
> => {
> +        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
> +        | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => {
>              KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>>
>          }

Maybe combine patches 2 and 3?  Also, maybe this should be a range check, instead of listing
every since version?  It seems like everything past GA100 uses the GA102 HAL.

Re: [PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification

[John Hubbard]

On 11/6/25 6:44 AM, Timur Tabi wrote:
> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>>       let hal = match chipset {
>> -        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
>> => {
>> +        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
>> +        | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => {
>>               KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>>
>>           }
> 
> Maybe combine patches 2 and 3?  Also, maybe this should be a range check, instead of listing
> every since version?  It seems like everything past GA100 uses the GA102 HAL.
> 

Sure, I can combine the patches.

I'm not sure why I've been wary of using ranges for these arch's.
I'll try it out.


thanks,
John Hubbard

Re: [PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification

[John Hubbard]

On 11/6/25 2:24 PM, John Hubbard wrote:
> On 11/6/25 6:44 AM, Timur Tabi wrote:
>> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>>>       let hal = match chipset {
>>> -        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
>>> => {
>>> +        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
>>> +        | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => {
>>>               KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>>
>>>           }
>>
>> Maybe combine patches 2 and 3?  Also, maybe this should be a range check, instead of listing
>> every since version?  It seems like everything past GA100 uses the GA102 HAL.
>>
> 
> Sure, I can combine the patches.
> 
> I'm not sure why I've been wary of using ranges for these arch's.
> I'll try it out.

Now I know. :)  Unlike C, Rust does *not* like it when we try to
treat enums as integers. Casting or other (messier) approaches are
required, and in no case is the end result a more readable on-screen
experience. At least not so far.

It is possible to mix in Architecture (Turing, Ampere, etc) checks,
but I'm not sure that is worth the additional clutter.

Maybe let's just do the long lists of chipsets for now...?

thanks,
-- 
John Hubbard

Re: [PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification

[Alexandre Courbot]

On Wed Nov 19, 2025 at 10:46 AM JST, John Hubbard wrote:
> On 11/6/25 2:24 PM, John Hubbard wrote:
>> On 11/6/25 6:44 AM, Timur Tabi wrote:
>>> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>>>>       let hal = match chipset {
>>>> -        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
>>>> => {
>>>> +        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
>>>> +        | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => {
>>>>               KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>>
>>>>           }
>>>
>>> Maybe combine patches 2 and 3?  Also, maybe this should be a range check, instead of listing
>>> every since version?  It seems like everything past GA100 uses the GA102 HAL.
>>>
>> 
>> Sure, I can combine the patches.
>> 
>> I'm not sure why I've been wary of using ranges for these arch's.
>> I'll try it out.
>
> Now I know. :)  Unlike C, Rust does *not* like it when we try to
> treat enums as integers. Casting or other (messier) approaches are
> required, and in no case is the end result a more readable on-screen
> experience. At least not so far.
>
> It is possible to mix in Architecture (Turing, Ampere, etc) checks,
> but I'm not sure that is worth the additional clutter.
>
> Maybe let's just do the long lists of chipsets for now...?

Yeah, I've hit this issue as well. The compiler might remove that
limitation in the future, or maybe we can craft a `chipset_range!()`
macro that hides the messy casting, but this exhaustive listing also has
the benefit of forcing us to consider every critical site whenever we
support a new chipset so I'm actually not too bothered by it.

Re: [PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification

[Dave Airlie]

On Wed, 19 Nov 2025 at 12:46, Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> On Wed Nov 19, 2025 at 10:46 AM JST, John Hubbard wrote:
> > On 11/6/25 2:24 PM, John Hubbard wrote:
> >> On 11/6/25 6:44 AM, Timur Tabi wrote:
> >>> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
> >>>>       let hal = match chipset {
> >>>> -        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
> >>>> => {
> >>>> +        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
> >>>> +        | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => {
> >>>>               KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>>
> >>>>           }
> >>>
> >>> Maybe combine patches 2 and 3?  Also, maybe this should be a range check, instead of listing
> >>> every since version?  It seems like everything past GA100 uses the GA102 HAL.
> >>>
> >>
> >> Sure, I can combine the patches.
> >>
> >> I'm not sure why I've been wary of using ranges for these arch's.
> >> I'll try it out.
> >
> > Now I know. :)  Unlike C, Rust does *not* like it when we try to
> > treat enums as integers. Casting or other (messier) approaches are
> > required, and in no case is the end result a more readable on-screen
> > experience. At least not so far.
> >
> > It is possible to mix in Architecture (Turing, Ampere, etc) checks,
> > but I'm not sure that is worth the additional clutter.
> >
> > Maybe let's just do the long lists of chipsets for now...?
>
> Yeah, I've hit this issue as well. The compiler might remove that
> limitation in the future, or maybe we can craft a `chipset_range!()`
> macro that hides the messy casting, but this exhaustive listing also has
> the benefit of forcing us to consider every critical site whenever we
> support a new chipset so I'm actually not too bothered by it.

I wrote some macros in my nova-core-experiments, had
chipset_before/after/range I think

Dave.

Re: [PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification

[John Hubbard]

On 11/18/25 7:15 PM, Dave Airlie wrote:
> On Wed, 19 Nov 2025 at 12:46, Alexandre Courbot <acourbot@nvidia.com> wrote:
...
>>> Maybe let's just do the long lists of chipsets for now...?
>>
>> Yeah, I've hit this issue as well. The compiler might remove that
>> limitation in the future, or maybe we can craft a `chipset_range!()`
>> macro that hides the messy casting, but this exhaustive listing also has
>> the benefit of forcing us to consider every critical site whenever we
>> support a new chipset so I'm actually not too bothered by it.
> 
> I wrote some macros in my nova-core-experiments, had
> chipset_before/after/range I think
> 

aha, I was afraid someone was going to say "macros" out loud, at some
point. And now you've gone and done it. :)

Well, I think we probably want:

a) The ability to clearly specify a chipset range, and

b) For extra credit, maybe: also be able to specify entire GPU
architectures, and architecture ranges.

...again, without too much extraneous noise at the call sites: the goal is
to read it easily:

     GA102..=GA104 | Architecture::Blackwell


for example. Macros are going to require that to be less clean, but
let me poke around and see.

thanks,
-- 
John Hubbard

Re: [PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification

[Dave Airlie]

On Wed, 19 Nov 2025 at 17:08, John Hubbard <jhubbard@nvidia.com> wrote:
>
> On 11/18/25 7:15 PM, Dave Airlie wrote:
> > On Wed, 19 Nov 2025 at 12:46, Alexandre Courbot <acourbot@nvidia.com> wrote:
> ...
> >>> Maybe let's just do the long lists of chipsets for now...?
> >>
> >> Yeah, I've hit this issue as well. The compiler might remove that
> >> limitation in the future, or maybe we can craft a `chipset_range!()`
> >> macro that hides the messy casting, but this exhaustive listing also has
> >> the benefit of forcing us to consider every critical site whenever we
> >> support a new chipset so I'm actually not too bothered by it.
> >
> > I wrote some macros in my nova-core-experiments, had
> > chipset_before/after/range I think
> >
>
> aha, I was afraid someone was going to say "macros" out loud, at some
> point. And now you've gone and done it. :)
>
> Well, I think we probably want:
>
> a) The ability to clearly specify a chipset range, and
>
> b) For extra credit, maybe: also be able to specify entire GPU
> architectures, and architecture ranges.
>
> ...again, without too much extraneous noise at the call sites: the goal is
> to read it easily:
>
>      GA102..=GA104 | Architecture::Blackwell
>
>
> for example. Macros are going to require that to be less clean, but
> let me poke around and see.

https://gitlab.freedesktop.org/nouvelles/kernel/-/blob/nova-core-experiments-fsp-boot/drivers/gpu/nova-core/gpu.rs?ref_type=heads#L96

is what I did, but yeah probably not going to get nice ranges like that.

Dave.

Re: [PATCH 3/6] gpu: nova-core: Blackwell: basic GPU identification

[John Hubbard]

On 11/18/25 11:15 PM, Dave Airlie wrote:
> On Wed, 19 Nov 2025 at 17:08, John Hubbard <jhubbard@nvidia.com> wrote:
>>
>> On 11/18/25 7:15 PM, Dave Airlie wrote:
>>> On Wed, 19 Nov 2025 at 12:46, Alexandre Courbot <acourbot@nvidia.com> wrote:
>> ...
>>       GA102..=GA104 | Architecture::Blackwell
>>
>>
>> for example. Macros are going to require that to be less clean, but
>> let me poke around and see.
> 
> https://gitlab.freedesktop.org/nouvelles/kernel/-/blob/nova-core-experiments-fsp-boot/drivers/gpu/nova-core/gpu.rs?ref_type=heads#L96
> 
> is what I did, but yeah probably not going to get nice ranges like that.
> 

Thanks for the pointer, I was wondering where that was (I didn't see
it in https://github.com/airlied/linux.git, and forgot about the
freedesktop.org repo).

Yes, I see we can really only go so far here.

thanks,
-- 
John Hubbard

[PATCH 4/6] gpu: nova-core: factor .fwsignature* selection into a new get_gsp_sigs_section()

[John Hubbard]

This cleans up GspFirmware::new(), which is helpful on its own. In
addition, future work in this area will build upon this.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 drivers/gpu/nova-core/firmware/gsp.rs | 41 ++++++++++++++-------------
 1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/nova-core/firmware/gsp.rs b/drivers/gpu/nova-core/firmware/gsp.rs
index ed2dea2cd144..3a85f34bdbea 100644
--- a/drivers/gpu/nova-core/firmware/gsp.rs
+++ b/drivers/gpu/nova-core/firmware/gsp.rs
@@ -138,39 +138,42 @@ pub(crate) struct GspFirmware {
 }
 
 impl GspFirmware {
-    /// Loads the GSP firmware binaries, map them into `dev`'s address-space, and creates the page
-    /// tables expected by the GSP bootloader to load it.
-    pub(crate) fn new<'a, 'b>(
-        dev: &'a device::Device<device::Bound>,
-        chipset: Chipset,
-        ver: &'b str,
-    ) -> Result<impl PinInit<Self, Error> + 'a> {
-        let fw = super::request_firmware(dev, chipset, "gsp", ver)?;
-
-        let fw_section = elf::elf64_section(fw.data(), ".fwimage").ok_or(EINVAL)?;
-
-        let sigs_section = match chipset.arch() {
-            Architecture::Ampere => ".fwsignature_ga10x",
-            Architecture::Hopper => ".fwsignature_gh10x",
-            Architecture::Ada => ".fwsignature_ad10x",
+    fn get_gsp_sigs_section(chipset: Chipset) -> Result<&'static str> {
+        match chipset.arch() {
+            Architecture::Ampere => Ok(".fwsignature_ga10x"),
+            Architecture::Hopper => Ok(".fwsignature_gh10x"),
+            Architecture::Ada => Ok(".fwsignature_ad10x"),
             Architecture::Blackwell => {
                 // Distinguish between GB10x and GB20x series
                 match chipset {
                     // GB10x series: GB100, GB102
-                    Chipset::GB100 | Chipset::GB102 => ".fwsignature_gb10x",
+                    Chipset::GB100 | Chipset::GB102 => Ok(".fwsignature_gb10x"),
                     // GB20x series: GB202, GB203, GB205, GB206, GB207
                     Chipset::GB202
                     | Chipset::GB203
                     | Chipset::GB205
                     | Chipset::GB206
-                    | Chipset::GB207 => ".fwsignature_gb20x",
+                    | Chipset::GB207 => Ok(".fwsignature_gb20x"),
                     // Unsupported Blackwell chips
                     _ => return Err(ENOTSUPP),
                 }
             }
-
             _ => return Err(ENOTSUPP),
-        };
+        }
+    }
+
+    /// Loads the GSP firmware binaries, map them into `dev`'s address-space, and creates the page
+    /// tables expected by the GSP bootloader to load it.
+    pub(crate) fn new<'a, 'b>(
+        dev: &'a device::Device<device::Bound>,
+        chipset: Chipset,
+        ver: &'b str,
+    ) -> Result<impl PinInit<Self, Error> + 'a> {
+        let fw = super::request_firmware(dev, chipset, "gsp", ver)?;
+
+        let fw_section = elf::elf64_section(fw.data(), ".fwimage").ok_or(EINVAL)?;
+
+        let sigs_section = Self::get_gsp_sigs_section(chipset)?;
         let signatures = elf::elf64_section(fw.data(), sigs_section)
             .ok_or(EINVAL)
             .and_then(|data| DmaObject::from_data(dev, data))?;
-- 
2.51.2

[PATCH 5/6] gpu: nova-core: regs.rs: clean up chipset(), architecture()

[John Hubbard]

In preparation for an upcoming commit that uses the GPU's reported
architecture, rather than deducing it from chipset().

This means that the architecture() method is no longer used, so
delete it.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 drivers/gpu/nova-core/regs.rs | 24 +++++++++---------------
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
index 15145426f8a1..fcb319806391 100644
--- a/drivers/gpu/nova-core/regs.rs
+++ b/drivers/gpu/nova-core/regs.rs
@@ -33,21 +33,16 @@ pub(crate) fn use_boot42_instead(self) -> bool {
         self.architecture_0() == 0 && self.architecture_1() == 1
     }
 
-    /// Combines `architecture_0` and `architecture_1` to obtain the architecture of the chip.
-    pub(crate) fn architecture(self) -> Result<Architecture> {
-        Architecture::try_from(
-            self.architecture_0() | (self.architecture_1() << Self::ARCHITECTURE_0_RANGE.len()),
-        )
-    }
-
-    /// Combines `architecture` and `implementation` to obtain a code unique to the chipset.
+    /// "chipset" is a unique identifier for the GPU. Examples: GA100, GA102, GA103, GA104, GB202.
     pub(crate) fn chipset(self) -> Result<Chipset> {
-        self.architecture()
-            .map(|arch| {
-                ((arch as u32) << Self::IMPLEMENTATION_RANGE.len())
-                    | u32::from(self.implementation())
-            })
-            .and_then(Chipset::try_from)
+        let arch_bits =
+            self.architecture_0() | (self.architecture_1() << Self::ARCHITECTURE_0_RANGE.len());
+
+        // Combine with implementation to form chipset value
+        let chipset_value =
+            (arch_bits as u32) << Self::IMPLEMENTATION_RANGE.len() | self.implementation() as u32;
+
+        Chipset::try_from(chipset_value)
     }
 
     /// Returns the revision information of the chip.
@@ -58,7 +53,6 @@ pub(crate) fn revision(self) -> crate::gpu::Revision {
         }
     }
 }
-
 register!(NV_PMC_BOOT_42 @ 0x00000108, "Extended architecture information" {
     7:0     implementation as u8, "Implementation version of the architecture";
     15:8    architecture as u8 ?=> Architecture, "Architecture value";
-- 
2.51.2

Re: [PATCH 5/6] gpu: nova-core: regs.rs: clean up chipset(), architecture()

[Timur Tabi]

On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>  }
> -
>  register!(NV_PMC_BOOT_42 @ 0x00000108, "Extended architecture information" {

Did you intend to delete this blank line?

Re: [PATCH 5/6] gpu: nova-core: regs.rs: clean up chipset(), architecture()

[John Hubbard]

On 11/6/25 6:39 AM, Timur Tabi wrote:
> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>>   }
>> -
>>   register!(NV_PMC_BOOT_42 @ 0x00000108, "Extended architecture information" {
> 
> Did you intend to delete this blank line?

Nope. :)


thanks,
John Hubbard

[PATCH 6/6] gpu: nova-core: use gpu::Architecture instead of long lists of GPUs

[John Hubbard]

Use Architecture::Ampere, for example, instead of checking for
membership inside an exhaustive list of GPUs of that architecture.

Also, apply the new "use" multi-line format.

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
 drivers/gpu/nova-core/falcon/hal.rs | 15 ++++++++++-----
 drivers/gpu/nova-core/fb/hal.rs     | 20 +++++++++++++-------
 drivers/gpu/nova-core/regs.rs       |  5 ++++-
 3 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/nova-core/falcon/hal.rs b/drivers/gpu/nova-core/falcon/hal.rs
index 7ba8ba856c72..08b97f593a8f 100644
--- a/drivers/gpu/nova-core/falcon/hal.rs
+++ b/drivers/gpu/nova-core/falcon/hal.rs
@@ -41,14 +41,19 @@ fn signature_reg_fuse_version(
 pub(super) fn falcon_hal<E: FalconEngine + 'static>(
     chipset: Chipset,
 ) -> Result<KBox<dyn FalconHal<E>>> {
-    use Chipset::*;
+    use crate::gpu::Architecture;
 
-    let hal = match chipset {
-        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
-        | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => {
+    let hal = match chipset.arch() {
+        Architecture::Ampere
+        | Architecture::Hopper
+        | Architecture::Ada
+        | Architecture::Blackwell => {
             KBox::new(ga102::Ga102::<E>::new(), GFP_KERNEL)? as KBox<dyn FalconHal<E>>
         }
-        _ => return Err(ENOTSUPP),
+        Architecture::Turing => {
+            // TODO: Add Turing falcon HAL support
+            return Err(ENOTSUPP);
+        }
     };
 
     Ok(hal)
diff --git a/drivers/gpu/nova-core/fb/hal.rs b/drivers/gpu/nova-core/fb/hal.rs
index 30fde2487d8b..dfa896dc8acf 100644
--- a/drivers/gpu/nova-core/fb/hal.rs
+++ b/drivers/gpu/nova-core/fb/hal.rs
@@ -27,12 +27,18 @@ pub(crate) trait FbHal {
 
 /// Returns the HAL corresponding to `chipset`.
 pub(super) fn fb_hal(chipset: Chipset) -> &'static dyn FbHal {
-    use Chipset::*;
-
-    match chipset {
-        TU102 | TU104 | TU106 | TU117 | TU116 => tu102::TU102_HAL,
-        GA100 => ga100::GA100_HAL,
-        GA102 | GA103 | GA104 | GA106 | GA107 | GH100 | AD102 | AD103 | AD104 | AD106 | AD107
-        | GB100 | GB102 | GB202 | GB203 | GB205 | GB206 | GB207 => ga102::GA102_HAL,
+    use crate::gpu::Architecture;
+
+    match chipset.arch() {
+        Architecture::Turing => tu102::TU102_HAL,
+        Architecture::Ampere => {
+            // GA100 has its own HAL, all other Ampere chips use GA102 HAL
+            if chipset == Chipset::GA100 {
+                ga100::GA100_HAL
+            } else {
+                ga102::GA102_HAL
+            }
+        }
+        Architecture::Hopper | Architecture::Ada | Architecture::Blackwell => ga102::GA102_HAL,
     }
 }
diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
index fcb319806391..deb9219ea126 100644
--- a/drivers/gpu/nova-core/regs.rs
+++ b/drivers/gpu/nova-core/regs.rs
@@ -11,7 +11,10 @@
     DmaTrfCmdSize, FalconCoreRev, FalconCoreRevSubversion, FalconFbifMemType, FalconFbifTarget,
     FalconModSelAlgo, FalconSecurityModel, PFalcon2Base, PFalconBase, PeregrineCoreSelect,
 };
-use crate::gpu::{Architecture, Chipset};
+use crate::gpu::{
+    Architecture,
+    Chipset, //
+};
 use crate::num::FromSafeCast;
 use kernel::prelude::*;
 
-- 
2.51.2

Re: [PATCH 6/6] gpu: nova-core: use gpu::Architecture instead of long lists of GPUs

[Timur Tabi]

On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
> -use crate::gpu::{Architecture, Chipset};
> +use crate::gpu::{
> +    Architecture,
> +    Chipset, //
> +};

I don't think this change should be part of this patch.  

Re: [PATCH 6/6] gpu: nova-core: use gpu::Architecture instead of long lists of GPUs

[Danilo Krummrich]

On 11/6/25 3:41 PM, Timur Tabi wrote:
> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>> -use crate::gpu::{Architecture, Chipset};
>> +use crate::gpu::{
>> +    Architecture,
>> +    Chipset, //
>> +};
> 
> I don't think this change should be part of this patch.  

I think it would be good to send a patch converting nova-core (and nova-drm) to
kernel vertical import style at once and then rebase other patches on top of that.

Re: [PATCH 6/6] gpu: nova-core: use gpu::Architecture instead of long lists of GPUs

[John Hubbard]

On 11/6/25 1:42 PM, Danilo Krummrich wrote:
> On 11/6/25 3:41 PM, Timur Tabi wrote:
>> On Wed, 2025-11-05 at 19:54 -0800, John Hubbard wrote:
>>> -use crate::gpu::{Architecture, Chipset};
>>> +use crate::gpu::{
>>> +    Architecture,
>>> +    Chipset, //
>>> +};
>>
>> I don't think this change should be part of this patch.
> 
> I think it would be good to send a patch converting nova-core (and nova-drm) to
> kernel vertical import style at once and then rebase other patches on top of that.

Yes...thinking out loud, our fiercest merge/rebase conflicts lately
are not due to "use" statements, but other, more difficult items.

I'm thinking we can either do it, before or after the big pending
set of patches that have been posted so far, probably.

thanks,
John Hubbard

Re: [PATCH 6/6] gpu: nova-core: use gpu::Architecture instead of long lists of GPUs

[Danilo Krummrich]

On 11/6/25 11:18 PM, John Hubbard wrote:
> I'm thinking we can either do it, before or after the big pending
> set of patches that have been posted so far, probably.

I'd prefer doing it before, it ensures we have consistent style throughout the
driver and gives the chance to cleanup unnecessary imports that are covered by
prelude.

Re: [PATCH 6/6] gpu: nova-core: use gpu::Architecture instead of long lists of GPUs

[John Hubbard]

On 11/6/25 3:30 PM, Danilo Krummrich wrote:
> On 11/6/25 11:18 PM, John Hubbard wrote:
>> I'm thinking we can either do it, before or after the big pending
>> set of patches that have been posted so far, probably.
> 
> I'd prefer doing it before, it ensures we have consistent style throughout the
> driver and gives the chance to cleanup unnecessary imports that are covered by
> prelude.

OK. I'll post something ASAP.

thanks,
-- 
John Hubbard