Re: [PATCH 4/7] gpu: nova-core: run the generic bootloader from its own type

[Alexandre Courbot]

On Thu Nov 5, 2026 at 9:50 PM JST, Eliot Courtney wrote:
> On Tue Nov 3, 2026 at 7:22 PM JST, Alexandre Courbot wrote:
>> From: John Hubbard <jhubbard@xxxxxxxxxx>
>>
>> The generic falcon bootloader needs a descriptor in DMEM to know what to
>> load, so loading it into a falcon means loading the two together by PIO
>> and starting the falcon. The FWSEC wrapper did that through its own
>> implementation of the PIO loading traits. The r000 load-and-execute
>> bootloader event will need to do the same thing.
>>
>> Give the generic bootloader a run method, which pairs it with the
>> descriptor that it receives, loads the pair by PIO, starts the falcon
>> with the given MAILBOX0 value and returns the mailboxes once the falcon
>> has halted. This will allow the FWSEC and r000 load-and-execute
>> bootloader event to share the same code.
>>
>> No functional changes.
>>
>> Assisted-by: LLM
>> Signed-off-by: John Hubbard <jhubbard@xxxxxxxxxx>
>> Co-developed-by: Alexandre Courbot <acourbot@xxxxxxxxxx>
>> Signed-off-by: Alexandre Courbot <acourbot@xxxxxxxxxx>
>> ---
>>  drivers/gpu/nova-core/firmware/fwsec/bootloader.rs | 55 ++-------------
>>  drivers/gpu/nova-core/firmware/gen_bootloader.rs   | 80 +++++++++++++++++++++-
>>  2 files changed, 84 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/firmware/fwsec/bootloader.rs b/drivers/gpu/nova-core/firmware/fwsec/bootloader.rs
>> index ad798ec5645a..c7bb877fcf20 100644
>> --- a/drivers/gpu/nova-core/firmware/fwsec/bootloader.rs
>> +++ b/drivers/gpu/nova-core/firmware/fwsec/bootloader.rs
>> @@ -16,22 +16,16 @@
>>          register::Array,
>>          Io, //
>>      },
>> -    prelude::*,
>> -    transmute::AsBytes,
>> +    prelude::*, //
>>  };
>>  
>>  use crate::{
>>      falcon::{
>>          gsp::Gsp,
>>          Falcon,
>> -        FalconBromParams,
>>          FalconDmaLoadable,
>>          FalconFbifMemType,
>> -        FalconFbifTarget,
>> -        FalconFirmware,
>> -        FalconPioDmemLoadTarget,
>> -        FalconPioImemLoadTarget,
>> -        FalconPioLoadable, //
>> +        FalconFbifTarget, //
>>      },
>>      firmware::{
>>          fwsec::FwsecFirmware,
>> @@ -50,11 +44,10 @@
>>  pub(crate) struct FwsecFirmwareWithBl<'a> {
>>      /// DMA object the bootloader will copy the firmware from.
>>      _firmware_dma: Coherent<'a, [u8]>,
>> +    /// The bootloader that copies the firmware.
>
> nit: doc change looks like it should be in a different patch
>
>>      bootloader: GenericBootloader,
>>      /// Descriptor to be loaded into DMEM for the bootloader to read.
>>      dmem_desc: BootloaderDmemDescV2,
>> -    /// BROM parameters of the loaded firmware.
>> -    brom_params: FalconBromParams,
>>  }
>>  
>>  impl<'a> FwsecFirmwareWithBl<'a> {
>> @@ -127,7 +120,6 @@ pub(crate) fn new(
>>              _firmware_dma: firmware_dma,
>>              bootloader,
>>              dmem_desc,
>> -            brom_params: firmware.brom_params(),
>>          })
>>      }
>>  
>> @@ -136,13 +128,9 @@ pub(crate) fn new(
>>      /// The bootloader will load the FWSEC firmware and then execute it. This function returns
>>      /// after FWSEC has reached completion.
>>      pub(crate) fn run(&self, dev: &Device<device::Bound>, falcon: &Falcon<'_, Gsp>) -> Result<()> {
>> -        // Reset falcon, load the firmware, and run it.
>>          falcon
>>              .reset()
>>              .inspect_err(|e| dev_err!(dev, "Failed to reset GSP falcon: {:?}\n", e))?;
>> -        falcon
>> -            .pio_load(self)
>> -            .inspect_err(|e| dev_err!(dev, "Failed to load FWSEC firmware: {:?}\n", e))?;
>>  
>>          // Configure DMA index for the bootloader to fetch the FWSEC firmware from system memory.
>>          falcon.pfalcon.update(
>
> Does it make sense for the generic bootloader to also do this step
> (falcon.pfalcon.update())? This appears to be something that's part of
> what the generic bootloader expects to be done no matter what, and it's
> doable just from `BootloaderDmemDescV2` which it already gets.

Yes, and that's a better design, notably because it removes the
documented precondition of `GenericBootloader::run` that the caller must
program the FBIF aperture, which I found a bit cumbersome.

However, the second user of the generic bootloader (the r000 load
handler) needs to specify a different `FalconFbifTarget`, so we need to
make this another parameter of `GenericBootloader::run`. Not a big deal
though.

What is a bit more of a big deal is that the r000 handler also uses a
new function taking a closure to program the aperture temporarily and
restore its original configuration afterwards, which is a better way
than what the current code is doing. So I'll bring that part from the
later patches into this series so it can use the final shape from the
get-go (with the beneficial side-effect that we will also merge more
r000 code earlier).

So thanks for this very insightful suggestion.

>
> Modulo answer to above question,
>
> Reviewed-by: Eliot Courtney <ecourtney@xxxxxxxxxx>

The patch has changed quite a bit so not taking this tag for now.