[PATCH 0/2] Add support for customizable find_distro_rootpart

[PATCH 0/2] Add support for customizable find_distro_rootpart

[Kory Maincent (TI.com)]

Add a customizable find_distro_rootpart command to allow each board to
define its own logic for locating the rootfs partition inside the
config_distro_bootcmd logic.

Convert am335x_evm board to this new find_distro_rootpart customizable
environment variable to locate the rootfs partition dynamically, instead
of finduuid which hardcodes the rootfs partition location (mmc 0:2).

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
---
Kory Maincent (TI.com) (2):
      distro_bootcmd: Add support for customizable find_distro_rootpart
      include: configs: am335x_evm: Replace findduid with find_distro_rootpart

 configs/am335x_evm_defconfig         |  3 +--
 configs/am335x_evm_spiboot_defconfig |  3 +--
 configs/am335x_hs_evm_defconfig      |  2 +-
 configs/am335x_hs_evm_spi_defconfig  |  1 -
 configs/am335x_hs_evm_uart_defconfig |  3 +--
 doc/develop/distro.rst               | 11 +++++++++++
 include/config_distro_bootcmd.h      | 10 +++++++---
 include/configs/am335x_evm.h         |  4 +++-
 8 files changed, 25 insertions(+), 12 deletions(-)
---
base-commit: 4e4a9de31de2a5f395ee25c59e4026422fbcb27e
change-id: 20251031-feature_distro_rootpart-58887b655c1f

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

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

[Kory Maincent (TI.com)]

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@bootlin.com>
---
 doc/develop/distro.rst          | 11 +++++++++++
 include/config_distro_bootcmd.h | 10 +++++++---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/doc/develop/distro.rst b/doc/develop/distro.rst
index 01efce40a29..4468cf7c95a 100644
--- a/doc/develop/distro.rst
+++ b/doc/develop/distro.rst
@@ -312,6 +312,17 @@ scriptaddr:
 
   A size of 1MB for extlinux.conf is more than adequate.
 
+find_distro_rootpart:
+  Optional. Sets the rootfs partition by applying distro boot enumeration logic,
+  allowing the boot partition environment variables (distro_bootpart, devtype,
+  devnum, etc.) to be reused for rootfs detection.
+
+  For example::
+
+    "find_distro_rootpart=" \
+        "setexpr distro_rootpart ${distro_bootpart} + 1 ;" \
+        "part uuid ${devtype} ${devnum}:${distro_rootpart} rootpart_uuid ;\0"
+
 For suggestions on memory locations for ARM systems, you must follow the
 guidelines specified in Documentation/arm/Booting in the Linux kernel tree.
 
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 7b6ac6eed9d..d0e125af6f8 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -549,9 +549,13 @@
 			"if fstype ${devtype} "                           \
 					"${devnum}:${distro_bootpart} "   \
 					"bootfstype; then "               \
-				"part uuid ${devtype} "                   \
-					"${devnum}:${distro_bootpart} "   \
-					"distro_bootpart_uuid ; "         \
+				"if test -n ${find_distro_rootpart}; then " \
+					"run find_distro_rootpart; "      \
+				"else "                                   \
+					"part uuid ${devtype} "           \
+						"${devnum}:${distro_bootpart} " \
+						"distro_bootpart_uuid ; " \
+				"fi; "                                    \
 				"run scan_dev_for_boot; "                 \
 			"fi; "                                            \
 		"done; "                                                  \

-- 
2.43.0

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

[Simon Glass]

Hi Kory,

On Fri, 31 Oct 2025 at 17:36, Kory Maincent (TI.com) <
kory.maincent@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@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?

Regards,
Simon

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

[Kory Maincent]

On Sun, 2 Nov 2025 20:54:02 +0100
Simon Glass <sjg@chromium.org> wrote:

> Hi Kory,
> 
> On Fri, 31 Oct 2025 at 17:36, Kory Maincent (TI.com) <
> kory.maincent@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@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.

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

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

[Kory Maincent]

On Mon, 3 Nov 2025 11:52:25 +0100
Kory Maincent <kory.maincent@bootlin.com> wrote:

> On Sun, 2 Nov 2025 20:54:02 +0100
> Simon Glass <sjg@chromium.org> wrote:
> 
> > Hi Kory,
> > 
> > On Fri, 31 Oct 2025 at 17:36, Kory Maincent (TI.com) <  
> > kory.maincent@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@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

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

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]

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@bootlin.com> wrote:
> 
> > On Sun, 2 Nov 2025 20:54:02 +0100
> > Simon Glass <sjg@chromium.org> wrote:
> > 
> > > Hi Kory,
> > > 
> > > On Fri, 31 Oct 2025 at 17:36, Kory Maincent (TI.com) <  
> > > kory.maincent@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@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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [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@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@bootlin.com> wrote:
> >   
> > > On Sun, 2 Nov 2025 20:54:02 +0100
> > > Simon Glass <sjg@chromium.org> wrote:
> > >   
> > > > Hi Kory,
> > > > 
> > > > On Fri, 31 Oct 2025 at 17:36, Kory Maincent (TI.com) <    
> > > > kory.maincent@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@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

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

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@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@bootlin.com> wrote:
> > >   
> > > > On Sun, 2 Nov 2025 20:54:02 +0100
> > > > Simon Glass <sjg@chromium.org> wrote:
> > > >   
> > > > > Hi Kory,
> > > > > 
> > > > > On Fri, 31 Oct 2025 at 17:36, Kory Maincent (TI.com) <    
> > > > > kory.maincent@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@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Kory Maincent]

On Tue, 4 Nov 2025 10:38:16 -0600
Tom Rini <trini@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@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@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.

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

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

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3865 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Kory Maincent]

On Thu, 6 Nov 2025 12:23:29 -0600
Tom Rini <trini@konsulko.com> wrote:

> 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@konsulko.com> wrote:
> > 
> > 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.

Sorry if I was not clear.
For the am335x_evm most of the environment is only in the main u-boot image
(i.e. not an xPL image).
https://elixir.bootlin.com/u-boot/v2025.10/source/include/configs/am335x_evm.h#L78

I would like to do the same but with the new text environment format. Is it
possible? Something like: board/ti/am335x/am335x.env for main image
and board/ti/am335x/spl_am335x.env for SPL image.
If that is not the case could you point me where the change need to
happen to help me on that. I didn't find yet where the text environment is
pulled into the images.

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

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

[Simon Glass]

Hi Kory,

On Fri, 7 Nov 2025 at 10:05, Kory Maincent <kory.maincent@bootlin.com> wrote:
>
> On Thu, 6 Nov 2025 12:23:29 -0600
> Tom Rini <trini@konsulko.com> wrote:
>
> > 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@konsulko.com> wrote:
> > >
> > > 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.
>
> Sorry if I was not clear.
> For the am335x_evm most of the environment is only in the main u-boot image
> (i.e. not an xPL image).
> https://elixir.bootlin.com/u-boot/v2025.10/source/include/configs/am335x_evm.h#L78
>
> I would like to do the same but with the new text environment format. Is it
> possible? Something like: board/ti/am335x/am335x.env for main image
> and board/ti/am335x/spl_am335x.env for SPL image.
> If that is not the case could you point me where the change need to
> happen to help me on that. I didn't find yet where the text environment is
> pulled into the images.

Some developer info at
https://docs.u-boot.org/en/latest/develop/environment.html would be
useful, if you have time.

In Makefile:

ENV_FILE is the filename of the .env file. This is run through the C
preprocessor with all Kconfig options and also DEFAULT_DEVICE_TREE set
to CONFIG_DEFAULT_DEVICE_TREE which produces env.in

env.in then goes through scripts/env2string.awk to convert it into a C
header file containing the full environment (#define
CONFIG_EXTRA_ENV_TEXT "..."), in include/generated/environment.h

generated/environment.h is then included by include/env_default.h

Regards,
Simon

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

On Fri, Nov 07, 2025 at 10:05:17AM +0100, Kory Maincent wrote:
> On Thu, 6 Nov 2025 12:23:29 -0600
> Tom Rini <trini@konsulko.com> wrote:
> 
> > 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@konsulko.com> wrote:
> > > 
> > > 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.
> 
> Sorry if I was not clear.
> For the am335x_evm most of the environment is only in the main u-boot image
> (i.e. not an xPL image).
> https://elixir.bootlin.com/u-boot/v2025.10/source/include/configs/am335x_evm.h#L78
> 
> I would like to do the same but with the new text environment format. Is it
> possible? Something like: board/ti/am335x/am335x.env for main image
> and board/ti/am335x/spl_am335x.env for SPL image.
> If that is not the case could you point me where the change need to
> happen to help me on that. I didn't find yet where the text environment is
> pulled into the images.

Ah. It sounds like we need to add missing logic to generate the text
environment in each phase rather than once and use it in all phases?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Simon Glass]

On Fri, 7 Nov 2025 at 16:51, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Nov 07, 2025 at 10:05:17AM +0100, Kory Maincent wrote:
> > On Thu, 6 Nov 2025 12:23:29 -0600
> > Tom Rini <trini@konsulko.com> wrote:
> >
> > > 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@konsulko.com> wrote:
> > > >
> > > > 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.
> >
> > Sorry if I was not clear.
> > For the am335x_evm most of the environment is only in the main u-boot image
> > (i.e. not an xPL image).
> > https://elixir.bootlin.com/u-boot/v2025.10/source/include/configs/am335x_evm.h#L78
> >
> > I would like to do the same but with the new text environment format. Is it
> > possible? Something like: board/ti/am335x/am335x.env for main image
> > and board/ti/am335x/spl_am335x.env for SPL image.
> > If that is not the case could you point me where the change need to
> > happen to help me on that. I didn't find yet where the text environment is
> > pulled into the images.
>
> Ah. It sounds like we need to add missing logic to generate the text
> environment in each phase rather than once and use it in all phases?

That's quite possible, I'm not sure.

- Simon

[PATCH 2/2] include: configs: am335x_evm: Replace findduid with find_distro_rootpart

[Kory Maincent (TI.com)]

The default config does not allow booting from different storage devices
when using the uuid environment variable to describe the rootfs partition.

Use the newly introduced find_distro_rootpart customizable environment
variable to locate the rootfs partition dynamically, instead of finduuid
which hardcodes the rootfs partition location (mmc 0:2). This allows the
board to boot from different storage devices while still using UUID-based
root partition identification.

Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
---
 configs/am335x_evm_defconfig         | 3 +--
 configs/am335x_evm_spiboot_defconfig | 3 +--
 configs/am335x_hs_evm_defconfig      | 2 +-
 configs/am335x_hs_evm_spi_defconfig  | 1 -
 configs/am335x_hs_evm_uart_defconfig | 3 +--
 include/configs/am335x_evm.h         | 4 +++-
 6 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 2b68902edef..a85e76ef3a1 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -17,7 +17,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run init_console; run finduuid; run distro_bootcmd"
+CONFIG_BOOTCOMMAND="run findfdt; run init_console; run distro_bootcmd"
 CONFIG_LOGLEVEL=3
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_SPL_SYS_MALLOC=y
@@ -44,7 +44,6 @@ CONFIG_CMD_SPL=y
 CONFIG_CMD_SPL_NAND_OFS=0x00080000
 CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
 CONFIG_CMD_NAND=y
-# CONFIG_CMD_SETEXPR is not set
 CONFIG_BOOTP_DNS2=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
diff --git a/configs/am335x_evm_spiboot_defconfig b/configs/am335x_evm_spiboot_defconfig
index f81149e9435..014dba4e8b3 100644
--- a/configs/am335x_evm_spiboot_defconfig
+++ b/configs/am335x_evm_spiboot_defconfig
@@ -19,7 +19,7 @@ CONFIG_TIMESTAMP=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run init_console; run finduuid; run distro_bootcmd"
+CONFIG_BOOTCOMMAND="run findfdt; run init_console; run distro_bootcmd"
 CONFIG_LOGLEVEL=3
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_SPL_SYS_MALLOC=y
@@ -34,7 +34,6 @@ CONFIG_SYS_SPI_U_BOOT_OFFS=0x20000
 CONFIG_CMD_SPL=y
 CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
 CONFIG_CMD_NAND=y
-# CONFIG_CMD_SETEXPR is not set
 CONFIG_BOOTP_DNS2=y
 CONFIG_CMD_MTDPARTS=y
 # CONFIG_SPL_EFI_PARTITION is not set
diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
index 6673038cb4c..bdf2e303eb9 100644
--- a/configs/am335x_hs_evm_defconfig
+++ b/configs/am335x_hs_evm_defconfig
@@ -15,7 +15,7 @@ CONFIG_TIMESTAMP=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run init_console; run finduuid; run distro_bootcmd"
+CONFIG_BOOTCOMMAND="run findfdt; run init_console; run distro_bootcmd"
 CONFIG_LOGLEVEL=3
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_SPL_MAX_SIZE=0xb0b0
diff --git a/configs/am335x_hs_evm_spi_defconfig b/configs/am335x_hs_evm_spi_defconfig
index df009844def..f6cf589275c 100644
--- a/configs/am335x_hs_evm_spi_defconfig
+++ b/configs/am335x_hs_evm_spi_defconfig
@@ -17,7 +17,6 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_DFU=y
 CONFIG_CMD_GPIO=y
-# CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_EXT4_WRITE=y
 
 CONFIG_BLK=n
diff --git a/configs/am335x_hs_evm_uart_defconfig b/configs/am335x_hs_evm_uart_defconfig
index 00fe12f8f67..e93a45fd6a4 100644
--- a/configs/am335x_hs_evm_uart_defconfig
+++ b/configs/am335x_hs_evm_uart_defconfig
@@ -18,7 +18,7 @@ CONFIG_TIMESTAMP=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run init_console; run finduuid; run distro_bootcmd"
+CONFIG_BOOTCOMMAND="run findfdt; run init_console; run distro_bootcmd"
 CONFIG_LOGLEVEL=3
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_SPL_MAX_SIZE=0x9ab0
@@ -33,7 +33,6 @@ CONFIG_SPL_NAND_DRIVERS=y
 CONFIG_SPL_NAND_ECC=y
 CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
 CONFIG_CMD_NAND=y
-# CONFIG_CMD_SETEXPR is not set
 CONFIG_BOOTP_DNS2=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index d2164b41d6d..46dc7e2db4e 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -81,7 +81,9 @@
 #define CFG_EXTRA_ENV_SETTINGS \
 	DEFAULT_LINUX_BOOT_ENV \
 	"fdtfile=undefined\0" \
-	"finduuid=part uuid mmc 0:2 uuid\0" \
+	"find_distro_rootpart=" \
+		"setexpr distro_rootpart ${distro_bootpart} + 1 ;" \
+		"part uuid ${devtype} ${devnum}:${distro_rootpart} uuid ;\0" \
 	"console=ttyO0,115200n8\0" \
 	"partitions=" \
 		"uuid_disk=${uuid_gpt_disk};" \

-- 
2.43.0

Re: [PATCH 0/2] Add support for customizable find_distro_rootpart

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On Fri, Oct 31, 2025 at 05:36:02PM +0100, Kory Maincent (TI.com) wrote:

> Add a customizable find_distro_rootpart command to allow each board to
> define its own logic for locating the rootfs partition inside the
> config_distro_bootcmd logic.
> 
> Convert am335x_evm board to this new find_distro_rootpart customizable
> environment variable to locate the rootfs partition dynamically, instead
> of finduuid which hardcodes the rootfs partition location (mmc 0:2).
> 
> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
> ---
> Kory Maincent (TI.com) (2):
>       distro_bootcmd: Add support for customizable find_distro_rootpart
>       include: configs: am335x_evm: Replace findduid with find_distro_rootpart

The first question here is, can we migrate these to standard boot
instead, or is that kind of functionality also missing there?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 0/2] Add support for customizable find_distro_rootpart

[Kory Maincent]

On Fri, 31 Oct 2025 11:47:33 -0600
Tom Rini <trini@konsulko.com> wrote:

> On Fri, Oct 31, 2025 at 05:36:02PM +0100, Kory Maincent (TI.com) wrote:
> 
> > Add a customizable find_distro_rootpart command to allow each board to
> > define its own logic for locating the rootfs partition inside the
> > config_distro_bootcmd logic.
> > 
> > Convert am335x_evm board to this new find_distro_rootpart customizable
> > environment variable to locate the rootfs partition dynamically, instead
> > of finduuid which hardcodes the rootfs partition location (mmc 0:2).
> > 
> > Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
> > ---
> > Kory Maincent (TI.com) (2):
> >       distro_bootcmd: Add support for customizable find_distro_rootpart
> >       include: configs: am335x_evm: Replace findduid with
> > find_distro_rootpart  
> 
> The first question here is, can we migrate these to standard boot
> instead, or is that kind of functionality also missing there?

I will let Simon confirm but I don't see anything related to the rootfs
partition or parameters that could be used by the "root=" Linux cmdline option.

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