Nouveau - Nov 2025 - [PATCH 03/11] gpu: nova-core: support header parsing on Turing/GA100

On Sat Nov 15, 2025 at 8:30 AM JST, Timur Tabi wrote:
> The Turing/GA100 version of Booter is slightly different from the
> GA102+ version.  The headers are the same, but different fields of
> the headers are used to identify the IMEM section.  In addition,
> there is an NMEM section on Turing/GA100.
>
> Signed-off-by: Timur Tabi <ttabi at nvidia.com>
> ---
>  drivers/gpu/nova-core/firmware/booter.rs | 40 +++++++++++++++++++-----
>  1 file changed, 33 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/firmware/booter.rs
b/drivers/gpu/nova-core/firmware/booter.rs
> index 1b98bb47424c..6ac9593504db 100644
> --- a/drivers/gpu/nova-core/firmware/booter.rs
> +++ b/drivers/gpu/nova-core/firmware/booter.rs
> @@ -356,14 +356,34 @@ pub(crate) fn new(
>              }
>          };
>  
> +        // There are two versions of Booter, one for Turing/GA100, and
another for
> +        // GA102+.  The extraction of the IMEM sections differs between
the two
> +        // versions.  Unfortunately, the file names are the same, and the
headers
> +        // don't indicate the versions.  The only way to differentiate
is by the Chipset.
> +
>          Ok(Self {
> -            imem_sec_load_target: FalconLoadTarget {
> -                src_start: app0.offset,
> -                dst_start: 0,
> -                len: app0.len,
> +            imem_sec_load_target: if chipset > Chipset::GA100 {
> +                FalconLoadTarget {
> +                    src_start: app0.offset,
> +                    dst_start: 0,
> +                    len: app0.len,
> +                }
> +            } else {
> +                FalconLoadTarget {
> +                    src_start: load_hdr.os_code_size,
> +                    dst_start: app0.offset,
> +                    len: app0.len,
> +                }
> +            },
> +            imem_ns_load_target: if chipset > Chipset::GA100 {
> +                None
> +            } else {
> +                Some(FalconLoadTarget {
> +                    src_start: 0,
> +                    dst_start: load_hdr.os_code_offset,
> +                    len: load_hdr.os_code_size,
> +                })
I'd prefer if we could reason in terms of functionality instead of
specific chipset versions.

IIUC the relevant factor is that Turing/GA100 have some non-secure
bootloader code as the entry point of booter, which GA102+ doesn't
feature as it is capable of starting in secure mode directly (please
correct me as my understanding is probably incomplete if not outright
wrong).

What is the HW or SW fact that requires this on Turing? Is it linked
to the fact we need to use PIO for it? What I would like to achieve is
removing or at least reducing these chipset checks into one single
point, which in the worst case could be a method of `Chipset` telling us
which loading method to use. But if we can find a distinguishing factor
in the parsed by this method, that would be even better.

On Wed, 2025-11-19 at 11:51 +0900, Alexandre Courbot
wrote:
> I'd prefer if we could reason in terms of functionality instead of
> specific chipset versions.
If you can figure it out, I'd be happy to change the code.  I wasn't
being lazy when I made this
comment:

  // There are two versions of Booter, one for Turing/GA100, and another for
  // GA102+.  The extraction of the IMEM sections differs between the two
  // versions.  Unfortunately, the file names are the same, and the headers
  // don't indicate the versions.  The only way to differentiate is by the
Chipset.
> IIUC the relevant factor is that Turing/GA100 have some non-secure
> bootloader code as the entry point of booter, which GA102+ doesn't
> feature as it is capable of starting in secure mode directly (please
> correct me as my understanding is probably incomplete if not outright
> wrong).
That sounds about right.  There are secure and non-secure sections in the
firmware image.
> What is the HW or SW fact that requires this on Turing??
I don't know how to answer that question.  That's just how it's done
on Turing/GA100.  I would
need to start an internal Slack thread to get a better answer, and I don't
really see what it
would gain us.
> Is it linked
> to the fact we need to use PIO for it? What I would like to achieve is
> removing or at least reducing these chipset checks into one single
> point, which in the worst case could be a method of `Chipset` telling us
> which loading method to use. But if we can find a distinguishing factor
> in the parsed by this method, that would be even better.
Both OpenRM and Nouveau use the chipset to gate on how to parse the headers.