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