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

On Wed Nov 19, 2025 at 2:16 PM JST, Timur Tabi wrote:
> 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.
Yeah, the answer is definitely not clear for me either. :)
>
>> 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.
I'd like to see if we can get to the bottom of this, mostly because this
post/post GA102 cut is noticeable in at least 2 places:

1. The way FWSEC is loaded,
2. The way booter is loaded and started,

For 1. we have the firmware header version that tells us which method to
use; I wonder if there is some similar information we could use for 2.
in order to avoid hardcoding values.
>
>> 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.
If it comes down to "This is how things are pre and post GA102" (and
the
evidence I have seen to far suggests that unfortunately), then so be it
- we at the very least encode this as a method of `Chipset` to avoid
hardcoding chipset versions in several places.

On Wed, 2025-11-19 at 16:03 +0900, Alexandre Courbot
wrote:
> If it comes down to "This is how things are pre and post GA102"
(and the
> evidence I have seen to far suggests that unfortunately), then so be it
> - we at the very least encode this as a method of `Chipset` to avoid
> hardcoding chipset versions in several places.
I could add this method to Chipset:

    pub(crate) fn supports_dma(&self) -> bool {
	*self > Self::GA100
    }

But shouldn't this be added to the HAL instead?

There are a few things that are arbitrarily conditional:

1) whether to use PIO or DMA to transfer firmware images to Falcons
2) whether a Generic Bootloader is needed for load FWSEC
3) whether a Non-Secure IMEM section exists
4) what the name of the signature section in the GSP-RM ELF image is

If I'm reading it right, booter.rs currently has no concept of a HAL, which
is why I gated on
Chipset.  I agree that doing stuff like

                FalconLoadTarget {
                    src_start: app0.offset,
                    dst_start: if chipset > Chipset::GA100 { 0 } else {
app0.offset },
                    len: app0.len,
                },

is not ideal.  To be honest, it's hard to wrap my head around all of these
offsets.  I'm convinced
that most of the confusion is the result of RM developers trying to shoehorn
complex firmware images
into legacy file formats.  Just looking at the above:

On Turing, the secure IMEM image is copied from app0.offset in the file to ->
app0.offset (256) in
IMEM.
On Ampere, the secure IMEM image is copied from app0.offset in the file to ->
0 in IMEM.

Why? Apparently, because on Ampere we copy the Secure image to offset 0 and
ignore the Non-Secure
image.  On Turing, we copy the Non-Secure image to offset 0 and copy the Secure
image to offset 256.
It would have been much easier to copy the Secure image to 256 on Ampere also,
but that's just not
what happens.

For some reason, os_code_offset and os_code_size contain the same values on both
Turing and Ampere,
but those values are used only on Turing to hold the Non-Secure section.  So the
firmware image
headers say that there's a non-secure IMEM section on Ampere, but it's a
lie.