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
