Re: [PATCH 2/3] arm: mediatek: enable U-Boot fastboot DAs on Genio 510 and 700

[Carlo Caione <ccaione@baylibre.com>]

On Tue, Sep 22, 2026 at 11:27:35 +0100, David Lechner wrote:
> On 9/14/26 8:35 AM, Carlo Caione wrote:
> > Some provisioning flows need U-Boot's command support in addition to
> > fastboot. Provide a U-Boot-based download agent for Genio 510 and 700 so
> > these flows can run without relying on firmware already stored on the
> > board.
> 
> So this is providing the same utility as in the previous patch, but also
> uses U-Boot proper? Why do we need both?

I'll explain that better in the next respin but basically U-Boot proper
is preferred when the complete agent fits BootROM's SRAM download area
before DRAM initialization (it is preferred because well, you have the
full U-Boot at your disposal).

The SPL alternative is useful for tighter payload budgets, because it
avoids the space required by BL31 and U-Boot proper (an external DDR
loader is still required).
 
So it is just matter of space really: if you have enough SRAM usable as
download area it is better to go with proper U-Boot, if space is tight
SPL is your only option.

> > diff --git a/arch/arm/mach-mediatek/spl.c b/arch/arm/mach-mediatek/spl.c
> > index 6f1ec052b95..75b51f4986e 100644
> > --- a/arch/arm/mach-mediatek/spl.c
> > +++ b/arch/arm/mach-mediatek/spl.c
> > @@ -33,6 +33,9 @@ void board_init_f(ulong dummy)
> >  
> >  u32 spl_boot_device(void)
> >  {
> > +	if (CONFIG_IS_ENABLED(RAM_DEVICE))
> > +		return BOOT_DEVICE_RAM;
> > +
> 
> It seems like this could unintentionally affect other MediaTek targets since
> they all share this code. Should we also check one of the FASTBOOT config
> options here?

Uh, good eye. Thanks for spotting this.

> >  #if defined(CONFIG_SPL_SPI)
> >  	return BOOT_DEVICE_SPI;
> >  #elif defined(CONFIG_SPL_MMC)
> Should we have a precursor patch to clean up the existing entries to also
> use CONFIG_IS_ENABLED() to keep this consistent?

I'll clean it up in this set, no need to have a precursor patch.

> (And I assume in the config from the first patch, this would fall though to
> BOOT_DEVICE_NONE since there is no u-boot proper in that case?)

mmh no, spl_boot_device() returns BOOT_DEVICE_MMC1, not
BOOT_DEVICE_NONE. The point is that there is no U-Boot proper inside the
SPL DA, but SPL can load it from eMMC.

Thank you for the review,

--
Carlo Caione