On Tue, Nov 04, 2025 at 10:29:16AM +0100, Kory Maincent wrote: > On Mon, 3 Nov 2025 10:19:05 -0600 > Tom Rini <[email protected]> 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 <[email protected]> wrote: > > > > > > > On Sun, 2 Nov 2025 20:54:02 +0100 > > > > Simon Glass <[email protected]> wrote: > > > > > > > > > Hi Kory, > > > > > > > > > > On Fri, 31 Oct 2025 at 17:36, Kory Maincent (TI.com) < > > > > > [email protected]> 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) <[email protected]> > > > > > > --- > > > > > > 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
signature.asc
Description: PGP signature
