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

[Kory Maincent]

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:
> >   
> > > On Sun, 2 Nov 2025 20:54:02 +0100
> > > Simon Glass <sjg at chromium.org> wrote:
> > >   
> > > > Hi Kory,
> > > > 
> > > > On Fri, 31 Oct 2025 at 17:36, Kory Maincent (TI.com) <    
> > > > kory.maincent at bootlin.com> wrote:
> > > > >
> > > > > Commit d0ba0ca45a49 ("distro_bootcmd: Set distro_bootpart_uuid for
> > > > > block devices") added support for the distro_boot_part_uuid
> > > > > environment variable to allow using PARTUUID in the kernel command
> > > > > line.
> > > > >
> > > > > However, the way it was written only supports the case where the boot
> > > > >      
> > > > files    
> > > > > and the rootfs are located in the same partition. There are many cases
> > > > > where the boot partition and rootfs partition are separate.
> > > > >
> > > > > Add a customizable find_distro_rootpart command to allow each board to
> > > > > define its own logic for locating the rootfs partition. This provides
> > > > > flexibility for boards with custom partition layouts while maintaining
> > > > > backward compatibility for the default case where boot and rootfs
> > > > > share the same partition.
> > > > >
> > > > > Signed-off-by: Kory Maincent (TI.com) <kory.maincent at bootlin.com>
> > > > > ---
> > > > >  doc/develop/distro.rst          | 11 +++++++++++
> > > > >  include/config_distro_bootcmd.h | 10 +++++++---
> > > > >  2 files changed, 18 insertions(+), 3 deletions(-)
> > > > >      
> > > > 
> > > > 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?
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?

Regards
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com