Re: [PATCH v4 6/8] gpu: nova-core: gsp: shuffle boot code a bit to keep chipset-specific parts close

["Alexandre Courbot" <acourbot@nvidia.com>]

On Tue Apr 28, 2026 at 4:13 PM JST, Dave Airlie wrote:
> On Mon, 27 Apr 2026 at 16:57, Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> Some parts of the GSP boot process are chip-specific actions, whereas
>> others (like sending the initial post-boot messages) deal directly with
>> the working GSP.
>>
>> Reorganize the boot code a bit so the chipset-specific parts are clumped
>> together, which will make their extraction into a HAL easier.
>>
>> This has no effect on the GSP boot process.
>
> So this is something that has changed in open-gpu over firmwares.
>
> Older firmwares pre-595 always queued up the async messages before
> hitting the boot sequence,
>
> on 595 and later you send the async message later in the boot process
> once GSP is booted.
>
> I can't read enough context in this patch to know if that matters, but
> I just thought I'd point it out.

Indeed. I started this after being a bit confused that the code for the
Blackwell series had a conditional to queue the messages *after* the GSP
was booted on chips using the FSP path, but *before* for chips using
SEC2. Looking at OpenRM it indeed seems to be linked to the firmware
version rather than the architecture, meaning that John probably used a
more recent OpenRM for reference when writing the Blackwell code.

In practice, unless GSP-RM does something really funny, it shouldn't
matter whether there already are messages on its message queue when it
boots or whether they arrive a bit later. I tested both options on both
SEC2 and FSP hardware, and they both booted successfully for both cases.

So I opted for the latter since this is what OpenRM currently does, and
the first firmware we will actually support long-term will be post-595.