[PATCH 1/2] distro_bootcmd: Add support for customizable find_distro_rootpart

[Tom Rini]

On Thu, Nov 06, 2025 at 07:00:01PM +0100, Kory Maincent wrote:
> On Tue, 4 Nov 2025 10:38:16 -0600
> Tom Rini <trini at konsulko.com> wrote:
> 
> > On Tue, Nov 04, 2025 at 10:29:16AM +0100, Kory Maincent wrote:
> > > On Mon, 3 Nov 2025 10:19:05 -0600
> > > Tom Rini <trini at konsulko.com> wrote:
> > >   
> > > > On Mon, Nov 03, 2025 at 05:16:30PM +0100, Kory Maincent wrote:  
> > > > > On Mon, 3 Nov 2025 11:52:25 +0100
> > > > > Kory Maincent <kory.maincent at bootlin.com> wrote:
> > > > > > > >        
> > > > > > > 
> > > > > > > How about moving to standard boot and look at this there?      
> > > > > > 
> > > > > > Ok, I will take a look at it.    
> > > > > 
> > > > > There is a custom nand boot target [1], and I have not any am335x board
> > > > > with nand memory to test it. I am afraid to break it during the update
> > > > > to bootstd. Not sure we can accept that. What do you think?
> > > > > 
> > > > > [1]https://elixir.bootlin.com/u-boot/v2025.10/source/include/configs/am335x_evm.h#L27
> > > > >    
> > > > 
> > > > I think we can risk it. I'd even be OK with not migrating that portion
> > > > and letting anyone still using those platforms, with NAND only, to just
> > > > use a custom boot command instead as I have strong doubts there's anyone
> > > > doing anything other than that currently.  
> > > 
> > > Ok.
> > > 
> > > Small questions related to standard boot:
> > > Why do we have a lot of bootmeth selected by default like
> > > BOOTMETH_EFILOADER, BOOTMETH_EFI_BOOTMGR, BOOTMETH_VBE ..., but
> > > BOOTSTD_DEFAULTS not selected by default? Shouldn't it be the contrary?  
> > 
> > Hard to say. We got stuck on trying to find the right balance between
> > features and size growth.
> 
> I still think we should disable these as default, moreover they are run first
> in the bootstd process as they are global bootmeth.

We changed that just now, but also running efi bootmgr is important for
the common use case of generic OS support (which is growing more for
64bit ARM than 32bit ARM).

> > > Moreover it is explicitly described that global bootmeth can be slow:
> > > https://elixir.bootlin.com/u-boot/v2025.10/source/doc/develop/bootstd/overview.rst#L103
> > > 
> > > The bootmeths environment variable is never read.
> > > Changing this environment in the prompt allows to change the bootmeth order
> > > thanks to this callback:
> > > https://elixir.bootlin.com/u-boot/v2025.10/source/boot/bootmeth-uclass.c#L459
> > > But if we set bootmeths in the board environment it doesn't work at all.
> > > Is it intended?  
> > 
> > Standard boot is still in development. We're still in the process of
> > getting more SoCs migrated and in turn finding and fixing the rough
> > spots. Global boot meths have changed a bit since v2025.10 as part of
> > hopefully addressing the feedback Andre P. had as part of migrating
> > sunxi, but I think there's still the ordering half of his concerns to be
> > figured out.
> 
> Ok thanks for your replies.
> 
> Other question: Is it possible to not add the environment to SPL image using
> the new text environment format. I have tried to update am335_evm board to it
> but I got a SPL too big error.
> I have tried to add "#if !defined(XPL_BUILD)" but it is not working.
> It seems the same generated environment file is used for all images.
> I still haven't found were it is included in the build of the SPL image. 

It shouldn't change the environment size, but also environment is likely
being pulled in to SPL for network boot support which does require
environment. What do you mean by "same generated environment file is
used for all images" ? And are you building in separate object
directories for a given board or is it not being re-generated on config
changes? Or did I misunderstand? Thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251106/82b52a7d/attachment.sig>