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

[Tom Rini]

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:
> > >   
> > > > 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?

Hard to say. We got stuck on trying to find the right balance between
features and size growth.

> 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.

-- 
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/20251104/59f857d6/attachment.sig>