Message ID | 20220119014315.1938157-21-sjg@chromium.org |
---|---|
State | RFC |
Delegated to: | Tom Rini |
Headers | show |
Series | Initial implementation of standard boot | expand |
On Tue, Jan 18, 2022 at 06:43:15PM -0700, Simon Glass wrote: > Switch this over, for testing purposes. > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > > (no changes since v1) > > boot/Kconfig | 3 ++- > include/configs/rpi.h | 39 ++------------------------------------- > 2 files changed, 4 insertions(+), 38 deletions(-) > > diff --git a/boot/Kconfig b/boot/Kconfig > index 9cf1d013f20..eab3c0f3467 100644 > --- a/boot/Kconfig > +++ b/boot/Kconfig > @@ -1124,7 +1124,8 @@ config USE_BOOTCOMMAND > config BOOTCOMMAND > string "bootcmd value" > depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE > - default "run distro_bootcmd" if DISTRO_DEFAULTS > + default "bootflow scan -lb" if BOOTSTD > + default "run distro_bootcmd" if !BOOTSTD && DISTRO_DEFAULTS > help > This is the string of commands that will be used as bootcmd and if > AUTOBOOT is set, automatically run. > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > index d5e064fb379..ea373d0c221 100644 > --- a/include/configs/rpi.h > +++ b/include/configs/rpi.h > @@ -133,47 +133,12 @@ > "fdt_addr_r=0x02600000\0" \ > "ramdisk_addr_r=0x02700000\0" > > -#if CONFIG_IS_ENABLED(CMD_MMC) > - #define BOOT_TARGET_MMC(func) \ > - func(MMC, mmc, 0) \ > - func(MMC, mmc, 1) \ > - func(MMC, mmc, 2) > -#else > - #define BOOT_TARGET_MMC(func) > -#endif > - > -#if CONFIG_IS_ENABLED(CMD_USB) > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > -#else > - #define BOOT_TARGET_USB(func) > -#endif > - > -#if CONFIG_IS_ENABLED(CMD_PXE) > - #define BOOT_TARGET_PXE(func) func(PXE, pxe, na) > -#else > - #define BOOT_TARGET_PXE(func) > -#endif > - > -#if CONFIG_IS_ENABLED(CMD_DHCP) > - #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > -#else > - #define BOOT_TARGET_DHCP(func) > -#endif > - > -#define BOOT_TARGET_DEVICES(func) \ > - BOOT_TARGET_MMC(func) \ > - BOOT_TARGET_USB(func) \ > - BOOT_TARGET_PXE(func) \ > - BOOT_TARGET_DHCP(func) > - > -#include <config_distro_bootcmd.h> > - > #define CONFIG_EXTRA_ENV_SETTINGS \ > "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ > + "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \ We have the indirect defines to func(...) everywhere so that if a feature is disabled we still build + function, as otherwise it's a loud link error. I assume with this we just get a try and fail move to the next target at run time, yes?
Hi Tom, On Wed, 19 Jan 2022 at 07:04, Tom Rini <trini@konsulko.com> wrote: > > On Tue, Jan 18, 2022 at 06:43:15PM -0700, Simon Glass wrote: > > > Switch this over, for testing purposes. > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > --- > > > > (no changes since v1) > > > > boot/Kconfig | 3 ++- > > include/configs/rpi.h | 39 ++------------------------------------- > > 2 files changed, 4 insertions(+), 38 deletions(-) > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > index 9cf1d013f20..eab3c0f3467 100644 > > --- a/boot/Kconfig > > +++ b/boot/Kconfig > > @@ -1124,7 +1124,8 @@ config USE_BOOTCOMMAND > > config BOOTCOMMAND > > string "bootcmd value" > > depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE > > - default "run distro_bootcmd" if DISTRO_DEFAULTS > > + default "bootflow scan -lb" if BOOTSTD > > + default "run distro_bootcmd" if !BOOTSTD && DISTRO_DEFAULTS > > help > > This is the string of commands that will be used as bootcmd and if > > AUTOBOOT is set, automatically run. > > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > > index d5e064fb379..ea373d0c221 100644 > > --- a/include/configs/rpi.h > > +++ b/include/configs/rpi.h > > @@ -133,47 +133,12 @@ > > "fdt_addr_r=0x02600000\0" \ > > "ramdisk_addr_r=0x02700000\0" > > > > -#if CONFIG_IS_ENABLED(CMD_MMC) > > - #define BOOT_TARGET_MMC(func) \ > > - func(MMC, mmc, 0) \ > > - func(MMC, mmc, 1) \ > > - func(MMC, mmc, 2) > > -#else > > - #define BOOT_TARGET_MMC(func) > > -#endif > > - > > -#if CONFIG_IS_ENABLED(CMD_USB) > > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > > -#else > > - #define BOOT_TARGET_USB(func) > > -#endif > > - > > -#if CONFIG_IS_ENABLED(CMD_PXE) > > - #define BOOT_TARGET_PXE(func) func(PXE, pxe, na) > > -#else > > - #define BOOT_TARGET_PXE(func) > > -#endif > > - > > -#if CONFIG_IS_ENABLED(CMD_DHCP) > > - #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > > -#else > > - #define BOOT_TARGET_DHCP(func) > > -#endif > > - > > -#define BOOT_TARGET_DEVICES(func) \ > > - BOOT_TARGET_MMC(func) \ > > - BOOT_TARGET_USB(func) \ > > - BOOT_TARGET_PXE(func) \ > > - BOOT_TARGET_DHCP(func) > > - > > -#include <config_distro_bootcmd.h> > > - > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ > > + "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \ > > We have the indirect defines to func(...) everywhere so that if a > feature is disabled we still build + function, as otherwise it's a loud > link error. I assume with this we just get a try and fail move to the > next target at run time, yes? Yes, that's right. But I hope that boards actually set up the boot targets correctly so that only those that are actually supported are enabled. This series has the basic functionality but once we have it in I need to look at more individual cases, like all the devicetree variations. As you can imagine it is tricky to convert hundreds of boards all at one, but I plan to start with a few that I can test. Regards, Simon > > -- > Tom
On Wed, Jan 19, 2022 at 07:37:36AM -0700, Simon Glass wrote: > Hi Tom, > > On Wed, 19 Jan 2022 at 07:04, Tom Rini <trini@konsulko.com> wrote: > > > > On Tue, Jan 18, 2022 at 06:43:15PM -0700, Simon Glass wrote: > > > > > Switch this over, for testing purposes. > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > --- > > > > > > (no changes since v1) > > > > > > boot/Kconfig | 3 ++- > > > include/configs/rpi.h | 39 ++------------------------------------- > > > 2 files changed, 4 insertions(+), 38 deletions(-) > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > index 9cf1d013f20..eab3c0f3467 100644 > > > --- a/boot/Kconfig > > > +++ b/boot/Kconfig > > > @@ -1124,7 +1124,8 @@ config USE_BOOTCOMMAND > > > config BOOTCOMMAND > > > string "bootcmd value" > > > depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE > > > - default "run distro_bootcmd" if DISTRO_DEFAULTS > > > + default "bootflow scan -lb" if BOOTSTD > > > + default "run distro_bootcmd" if !BOOTSTD && DISTRO_DEFAULTS > > > help > > > This is the string of commands that will be used as bootcmd and if > > > AUTOBOOT is set, automatically run. > > > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > > > index d5e064fb379..ea373d0c221 100644 > > > --- a/include/configs/rpi.h > > > +++ b/include/configs/rpi.h > > > @@ -133,47 +133,12 @@ > > > "fdt_addr_r=0x02600000\0" \ > > > "ramdisk_addr_r=0x02700000\0" > > > > > > -#if CONFIG_IS_ENABLED(CMD_MMC) > > > - #define BOOT_TARGET_MMC(func) \ > > > - func(MMC, mmc, 0) \ > > > - func(MMC, mmc, 1) \ > > > - func(MMC, mmc, 2) > > > -#else > > > - #define BOOT_TARGET_MMC(func) > > > -#endif > > > - > > > -#if CONFIG_IS_ENABLED(CMD_USB) > > > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > > > -#else > > > - #define BOOT_TARGET_USB(func) > > > -#endif > > > - > > > -#if CONFIG_IS_ENABLED(CMD_PXE) > > > - #define BOOT_TARGET_PXE(func) func(PXE, pxe, na) > > > -#else > > > - #define BOOT_TARGET_PXE(func) > > > -#endif > > > - > > > -#if CONFIG_IS_ENABLED(CMD_DHCP) > > > - #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > > > -#else > > > - #define BOOT_TARGET_DHCP(func) > > > -#endif > > > - > > > -#define BOOT_TARGET_DEVICES(func) \ > > > - BOOT_TARGET_MMC(func) \ > > > - BOOT_TARGET_USB(func) \ > > > - BOOT_TARGET_PXE(func) \ > > > - BOOT_TARGET_DHCP(func) > > > - > > > -#include <config_distro_bootcmd.h> > > > - > > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > > "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ > > > + "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \ > > > > We have the indirect defines to func(...) everywhere so that if a > > feature is disabled we still build + function, as otherwise it's a loud > > link error. I assume with this we just get a try and fail move to the > > next target at run time, yes? > > Yes, that's right. But I hope that boards actually set up the boot > targets correctly so that only those that are actually supported are > enabled. What do you mean? They always do that, even today, which is why we have those #ifdef's in the distro boot board code. If the user ends up disabling something, it should still build and work. And honestly, given that dependencies are now in Kconfig, the distro_boot.h stuff could get away with dropping all of the "Enabled_foo_without_CONFIG_CMD_foo" stuff I bet. > This series has the basic functionality but once we have it in I need > to look at more individual cases, like all the devicetree variations. > As you can imagine it is tricky to convert hundreds of boards all at > one, but I plan to start with a few that I can test. Right, I'm just trying to make sure we have as much apples-to-apples understanding of both ways.
Hi Tom, On Wed, 19 Jan 2022 at 08:01, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Jan 19, 2022 at 07:37:36AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 19 Jan 2022 at 07:04, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Tue, Jan 18, 2022 at 06:43:15PM -0700, Simon Glass wrote: > > > > > > > Switch this over, for testing purposes. > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > --- > > > > > > > > (no changes since v1) > > > > > > > > boot/Kconfig | 3 ++- > > > > include/configs/rpi.h | 39 ++------------------------------------- > > > > 2 files changed, 4 insertions(+), 38 deletions(-) > > > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > > index 9cf1d013f20..eab3c0f3467 100644 > > > > --- a/boot/Kconfig > > > > +++ b/boot/Kconfig > > > > @@ -1124,7 +1124,8 @@ config USE_BOOTCOMMAND > > > > config BOOTCOMMAND > > > > string "bootcmd value" > > > > depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE > > > > - default "run distro_bootcmd" if DISTRO_DEFAULTS > > > > + default "bootflow scan -lb" if BOOTSTD > > > > + default "run distro_bootcmd" if !BOOTSTD && DISTRO_DEFAULTS > > > > help > > > > This is the string of commands that will be used as bootcmd and if > > > > AUTOBOOT is set, automatically run. > > > > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > > > > index d5e064fb379..ea373d0c221 100644 > > > > --- a/include/configs/rpi.h > > > > +++ b/include/configs/rpi.h > > > > @@ -133,47 +133,12 @@ > > > > "fdt_addr_r=0x02600000\0" \ > > > > "ramdisk_addr_r=0x02700000\0" > > > > > > > > -#if CONFIG_IS_ENABLED(CMD_MMC) > > > > - #define BOOT_TARGET_MMC(func) \ > > > > - func(MMC, mmc, 0) \ > > > > - func(MMC, mmc, 1) \ > > > > - func(MMC, mmc, 2) > > > > -#else > > > > - #define BOOT_TARGET_MMC(func) > > > > -#endif > > > > - > > > > -#if CONFIG_IS_ENABLED(CMD_USB) > > > > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > > > > -#else > > > > - #define BOOT_TARGET_USB(func) > > > > -#endif > > > > - > > > > -#if CONFIG_IS_ENABLED(CMD_PXE) > > > > - #define BOOT_TARGET_PXE(func) func(PXE, pxe, na) > > > > -#else > > > > - #define BOOT_TARGET_PXE(func) > > > > -#endif > > > > - > > > > -#if CONFIG_IS_ENABLED(CMD_DHCP) > > > > - #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > > > > -#else > > > > - #define BOOT_TARGET_DHCP(func) > > > > -#endif > > > > - > > > > -#define BOOT_TARGET_DEVICES(func) \ > > > > - BOOT_TARGET_MMC(func) \ > > > > - BOOT_TARGET_USB(func) \ > > > > - BOOT_TARGET_PXE(func) \ > > > > - BOOT_TARGET_DHCP(func) > > > > - > > > > -#include <config_distro_bootcmd.h> > > > > - > > > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > > > "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ > > > > + "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \ > > > > > > We have the indirect defines to func(...) everywhere so that if a > > > feature is disabled we still build + function, as otherwise it's a loud > > > link error. I assume with this we just get a try and fail move to the > > > next target at run time, yes? > > > > Yes, that's right. But I hope that boards actually set up the boot > > targets correctly so that only those that are actually supported are > > enabled. > > What do you mean? They always do that, even today, which is why we have > those #ifdef's in the distro boot board code. If the user ends up > disabling something, it should still build and work. And honestly, > given that dependencies are now in Kconfig, the distro_boot.h stuff > could get away with dropping all of the > "Enabled_foo_without_CONFIG_CMD_foo" stuff I bet. Then I don't think I understand your original question. With bootstd if USB is disabled (for example) then the USB bootdev won't exist so it won't look at USB. It is not so much a link error, just that the device is not there. > > > This series has the basic functionality but once we have it in I need > > to look at more individual cases, like all the devicetree variations. > > As you can imagine it is tricky to convert hundreds of boards all at > > one, but I plan to start with a few that I can test. > > Right, I'm just trying to make sure we have as much apples-to-apples > understanding of both ways. OK. Regards, Simon
On Wed, Jan 19, 2022 at 09:09:51AM -0700, Simon Glass wrote: > Hi Tom, > > On Wed, 19 Jan 2022 at 08:01, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Jan 19, 2022 at 07:37:36AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 19 Jan 2022 at 07:04, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Tue, Jan 18, 2022 at 06:43:15PM -0700, Simon Glass wrote: > > > > > > > > > Switch this over, for testing purposes. > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > --- > > > > > > > > > > (no changes since v1) > > > > > > > > > > boot/Kconfig | 3 ++- > > > > > include/configs/rpi.h | 39 ++------------------------------------- > > > > > 2 files changed, 4 insertions(+), 38 deletions(-) > > > > > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > > > index 9cf1d013f20..eab3c0f3467 100644 > > > > > --- a/boot/Kconfig > > > > > +++ b/boot/Kconfig > > > > > @@ -1124,7 +1124,8 @@ config USE_BOOTCOMMAND > > > > > config BOOTCOMMAND > > > > > string "bootcmd value" > > > > > depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE > > > > > - default "run distro_bootcmd" if DISTRO_DEFAULTS > > > > > + default "bootflow scan -lb" if BOOTSTD > > > > > + default "run distro_bootcmd" if !BOOTSTD && DISTRO_DEFAULTS > > > > > help > > > > > This is the string of commands that will be used as bootcmd and if > > > > > AUTOBOOT is set, automatically run. > > > > > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > > > > > index d5e064fb379..ea373d0c221 100644 > > > > > --- a/include/configs/rpi.h > > > > > +++ b/include/configs/rpi.h > > > > > @@ -133,47 +133,12 @@ > > > > > "fdt_addr_r=0x02600000\0" \ > > > > > "ramdisk_addr_r=0x02700000\0" > > > > > > > > > > -#if CONFIG_IS_ENABLED(CMD_MMC) > > > > > - #define BOOT_TARGET_MMC(func) \ > > > > > - func(MMC, mmc, 0) \ > > > > > - func(MMC, mmc, 1) \ > > > > > - func(MMC, mmc, 2) > > > > > -#else > > > > > - #define BOOT_TARGET_MMC(func) > > > > > -#endif > > > > > - > > > > > -#if CONFIG_IS_ENABLED(CMD_USB) > > > > > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > > > > > -#else > > > > > - #define BOOT_TARGET_USB(func) > > > > > -#endif > > > > > - > > > > > -#if CONFIG_IS_ENABLED(CMD_PXE) > > > > > - #define BOOT_TARGET_PXE(func) func(PXE, pxe, na) > > > > > -#else > > > > > - #define BOOT_TARGET_PXE(func) > > > > > -#endif > > > > > - > > > > > -#if CONFIG_IS_ENABLED(CMD_DHCP) > > > > > - #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > > > > > -#else > > > > > - #define BOOT_TARGET_DHCP(func) > > > > > -#endif > > > > > - > > > > > -#define BOOT_TARGET_DEVICES(func) \ > > > > > - BOOT_TARGET_MMC(func) \ > > > > > - BOOT_TARGET_USB(func) \ > > > > > - BOOT_TARGET_PXE(func) \ > > > > > - BOOT_TARGET_DHCP(func) > > > > > - > > > > > -#include <config_distro_bootcmd.h> > > > > > - > > > > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > > > > "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ > > > > > + "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \ > > > > > > > > We have the indirect defines to func(...) everywhere so that if a > > > > feature is disabled we still build + function, as otherwise it's a loud > > > > link error. I assume with this we just get a try and fail move to the > > > > next target at run time, yes? > > > > > > Yes, that's right. But I hope that boards actually set up the boot > > > targets correctly so that only those that are actually supported are > > > enabled. > > > > What do you mean? They always do that, even today, which is why we have > > those #ifdef's in the distro boot board code. If the user ends up > > disabling something, it should still build and work. And honestly, > > given that dependencies are now in Kconfig, the distro_boot.h stuff > > could get away with dropping all of the > > "Enabled_foo_without_CONFIG_CMD_foo" stuff I bet. > > Then I don't think I understand your original question. With bootstd > if USB is disabled (for example) then the USB bootdev won't exist so > it won't look at USB. It is not so much a link error, just that the > device is not there. I mean, with "boot_targets=mmc0 mmc1 usb0 pxe dhcp0" but CONFIG_MMC disabled, bootstd will gracefully fail, gracefully fail, boot from USB.
> Date: Wed, 19 Jan 2022 11:21:17 -0500 > From: Tom Rini <trini@konsulko.com> > > On Wed, Jan 19, 2022 at 09:09:51AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 19 Jan 2022 at 08:01, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Jan 19, 2022 at 07:37:36AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Wed, 19 Jan 2022 at 07:04, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Tue, Jan 18, 2022 at 06:43:15PM -0700, Simon Glass wrote: > > > > > > > > > > > Switch this over, for testing purposes. > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > --- > > > > > > > > > > > > (no changes since v1) > > > > > > > > > > > > boot/Kconfig | 3 ++- > > > > > > include/configs/rpi.h | 39 ++------------------------------------- > > > > > > 2 files changed, 4 insertions(+), 38 deletions(-) > > > > > > > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > > > > index 9cf1d013f20..eab3c0f3467 100644 > > > > > > --- a/boot/Kconfig > > > > > > +++ b/boot/Kconfig > > > > > > @@ -1124,7 +1124,8 @@ config USE_BOOTCOMMAND > > > > > > config BOOTCOMMAND > > > > > > string "bootcmd value" > > > > > > depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE > > > > > > - default "run distro_bootcmd" if DISTRO_DEFAULTS > > > > > > + default "bootflow scan -lb" if BOOTSTD > > > > > > + default "run distro_bootcmd" if !BOOTSTD && DISTRO_DEFAULTS > > > > > > help > > > > > > This is the string of commands that will be used as bootcmd and if > > > > > > AUTOBOOT is set, automatically run. > > > > > > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > > > > > > index d5e064fb379..ea373d0c221 100644 > > > > > > --- a/include/configs/rpi.h > > > > > > +++ b/include/configs/rpi.h > > > > > > @@ -133,47 +133,12 @@ > > > > > > "fdt_addr_r=0x02600000\0" \ > > > > > > "ramdisk_addr_r=0x02700000\0" > > > > > > > > > > > > -#if CONFIG_IS_ENABLED(CMD_MMC) > > > > > > - #define BOOT_TARGET_MMC(func) \ > > > > > > - func(MMC, mmc, 0) \ > > > > > > - func(MMC, mmc, 1) \ > > > > > > - func(MMC, mmc, 2) > > > > > > -#else > > > > > > - #define BOOT_TARGET_MMC(func) > > > > > > -#endif > > > > > > - > > > > > > -#if CONFIG_IS_ENABLED(CMD_USB) > > > > > > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > > > > > > -#else > > > > > > - #define BOOT_TARGET_USB(func) > > > > > > -#endif > > > > > > - > > > > > > -#if CONFIG_IS_ENABLED(CMD_PXE) > > > > > > - #define BOOT_TARGET_PXE(func) func(PXE, pxe, na) > > > > > > -#else > > > > > > - #define BOOT_TARGET_PXE(func) > > > > > > -#endif > > > > > > - > > > > > > -#if CONFIG_IS_ENABLED(CMD_DHCP) > > > > > > - #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > > > > > > -#else > > > > > > - #define BOOT_TARGET_DHCP(func) > > > > > > -#endif > > > > > > - > > > > > > -#define BOOT_TARGET_DEVICES(func) \ > > > > > > - BOOT_TARGET_MMC(func) \ > > > > > > - BOOT_TARGET_USB(func) \ > > > > > > - BOOT_TARGET_PXE(func) \ > > > > > > - BOOT_TARGET_DHCP(func) > > > > > > - > > > > > > -#include <config_distro_bootcmd.h> > > > > > > - > > > > > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > > > > > "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ > > > > > > + "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \ > > > > > > > > > > We have the indirect defines to func(...) everywhere so that if a > > > > > feature is disabled we still build + function, as otherwise it's a loud > > > > > link error. I assume with this we just get a try and fail move to the > > > > > next target at run time, yes? > > > > > > > > Yes, that's right. But I hope that boards actually set up the boot > > > > targets correctly so that only those that are actually supported are > > > > enabled. > > > > > > What do you mean? They always do that, even today, which is why we have > > > those #ifdef's in the distro boot board code. If the user ends up > > > disabling something, it should still build and work. And honestly, > > > given that dependencies are now in Kconfig, the distro_boot.h stuff > > > could get away with dropping all of the > > > "Enabled_foo_without_CONFIG_CMD_foo" stuff I bet. > > > > Then I don't think I understand your original question. With bootstd > > if USB is disabled (for example) then the USB bootdev won't exist so > > it won't look at USB. It is not so much a link error, just that the > > device is not there. > > I mean, with "boot_targets=mmc0 mmc1 usb0 pxe dhcp0" but CONFIG_MMC > disabled, bootstd will gracefully fail, gracefully fail, boot from USB. Even if it gracefully fails, wouldn't it be better if the boot_targets environment variable would correctly reflect the devices that are actually avialable to boot from. We already have the logic to construct that list. So why are we throwing that logic away?
Hi Tom, On Wed, 19 Jan 2022 at 09:21, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Jan 19, 2022 at 09:09:51AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 19 Jan 2022 at 08:01, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Jan 19, 2022 at 07:37:36AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Wed, 19 Jan 2022 at 07:04, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Tue, Jan 18, 2022 at 06:43:15PM -0700, Simon Glass wrote: > > > > > > > > > > > Switch this over, for testing purposes. > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > --- > > > > > > > > > > > > (no changes since v1) > > > > > > > > > > > > boot/Kconfig | 3 ++- > > > > > > include/configs/rpi.h | 39 ++------------------------------------- > > > > > > 2 files changed, 4 insertions(+), 38 deletions(-) > > > > > > > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > > > > index 9cf1d013f20..eab3c0f3467 100644 > > > > > > --- a/boot/Kconfig > > > > > > +++ b/boot/Kconfig > > > > > > @@ -1124,7 +1124,8 @@ config USE_BOOTCOMMAND > > > > > > config BOOTCOMMAND > > > > > > string "bootcmd value" > > > > > > depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE > > > > > > - default "run distro_bootcmd" if DISTRO_DEFAULTS > > > > > > + default "bootflow scan -lb" if BOOTSTD > > > > > > + default "run distro_bootcmd" if !BOOTSTD && DISTRO_DEFAULTS > > > > > > help > > > > > > This is the string of commands that will be used as bootcmd and if > > > > > > AUTOBOOT is set, automatically run. > > > > > > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > > > > > > index d5e064fb379..ea373d0c221 100644 > > > > > > --- a/include/configs/rpi.h > > > > > > +++ b/include/configs/rpi.h > > > > > > @@ -133,47 +133,12 @@ > > > > > > "fdt_addr_r=0x02600000\0" \ > > > > > > "ramdisk_addr_r=0x02700000\0" > > > > > > > > > > > > -#if CONFIG_IS_ENABLED(CMD_MMC) > > > > > > - #define BOOT_TARGET_MMC(func) \ > > > > > > - func(MMC, mmc, 0) \ > > > > > > - func(MMC, mmc, 1) \ > > > > > > - func(MMC, mmc, 2) > > > > > > -#else > > > > > > - #define BOOT_TARGET_MMC(func) > > > > > > -#endif > > > > > > - > > > > > > -#if CONFIG_IS_ENABLED(CMD_USB) > > > > > > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > > > > > > -#else > > > > > > - #define BOOT_TARGET_USB(func) > > > > > > -#endif > > > > > > - > > > > > > -#if CONFIG_IS_ENABLED(CMD_PXE) > > > > > > - #define BOOT_TARGET_PXE(func) func(PXE, pxe, na) > > > > > > -#else > > > > > > - #define BOOT_TARGET_PXE(func) > > > > > > -#endif > > > > > > - > > > > > > -#if CONFIG_IS_ENABLED(CMD_DHCP) > > > > > > - #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > > > > > > -#else > > > > > > - #define BOOT_TARGET_DHCP(func) > > > > > > -#endif > > > > > > - > > > > > > -#define BOOT_TARGET_DEVICES(func) \ > > > > > > - BOOT_TARGET_MMC(func) \ > > > > > > - BOOT_TARGET_USB(func) \ > > > > > > - BOOT_TARGET_PXE(func) \ > > > > > > - BOOT_TARGET_DHCP(func) > > > > > > - > > > > > > -#include <config_distro_bootcmd.h> > > > > > > - > > > > > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > > > > > "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ > > > > > > + "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \ > > > > > > > > > > We have the indirect defines to func(...) everywhere so that if a > > > > > feature is disabled we still build + function, as otherwise it's a loud > > > > > link error. I assume with this we just get a try and fail move to the > > > > > next target at run time, yes? > > > > > > > > Yes, that's right. But I hope that boards actually set up the boot > > > > targets correctly so that only those that are actually supported are > > > > enabled. > > > > > > What do you mean? They always do that, even today, which is why we have > > > those #ifdef's in the distro boot board code. If the user ends up > > > disabling something, it should still build and work. And honestly, > > > given that dependencies are now in Kconfig, the distro_boot.h stuff > > > could get away with dropping all of the > > > "Enabled_foo_without_CONFIG_CMD_foo" stuff I bet. > > > > Then I don't think I understand your original question. With bootstd > > if USB is disabled (for example) then the USB bootdev won't exist so > > it won't look at USB. It is not so much a link error, just that the > > device is not there. > > I mean, with "boot_targets=mmc0 mmc1 usb0 pxe dhcp0" but CONFIG_MMC > disabled, bootstd will gracefully fail, gracefully fail, boot from USB. It should do (you get a warning like 'Unknown uclass 'mmc' in label'). I'll add a test case for it. Regards, Simon
()Hi Mark, On Wed, 19 Jan 2022 at 09:38, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > Date: Wed, 19 Jan 2022 11:21:17 -0500 > > From: Tom Rini <trini@konsulko.com> > > > > On Wed, Jan 19, 2022 at 09:09:51AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 19 Jan 2022 at 08:01, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Wed, Jan 19, 2022 at 07:37:36AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Wed, 19 Jan 2022 at 07:04, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Tue, Jan 18, 2022 at 06:43:15PM -0700, Simon Glass wrote: > > > > > > > > > > > > > Switch this over, for testing purposes. > > > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > > --- > > > > > > > > > > > > > > (no changes since v1) > > > > > > > > > > > > > > boot/Kconfig | 3 ++- > > > > > > > include/configs/rpi.h | 39 ++------------------------------------- > > > > > > > 2 files changed, 4 insertions(+), 38 deletions(-) > > > > > > > > > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > > > > > index 9cf1d013f20..eab3c0f3467 100644 > > > > > > > --- a/boot/Kconfig > > > > > > > +++ b/boot/Kconfig > > > > > > > @@ -1124,7 +1124,8 @@ config USE_BOOTCOMMAND > > > > > > > config BOOTCOMMAND > > > > > > > string "bootcmd value" > > > > > > > depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE > > > > > > > - default "run distro_bootcmd" if DISTRO_DEFAULTS > > > > > > > + default "bootflow scan -lb" if BOOTSTD > > > > > > > + default "run distro_bootcmd" if !BOOTSTD && DISTRO_DEFAULTS > > > > > > > help > > > > > > > This is the string of commands that will be used as bootcmd and if > > > > > > > AUTOBOOT is set, automatically run. > > > > > > > diff --git a/include/configs/rpi.h b/include/configs/rpi.h > > > > > > > index d5e064fb379..ea373d0c221 100644 > > > > > > > --- a/include/configs/rpi.h > > > > > > > +++ b/include/configs/rpi.h > > > > > > > @@ -133,47 +133,12 @@ > > > > > > > "fdt_addr_r=0x02600000\0" \ > > > > > > > "ramdisk_addr_r=0x02700000\0" > > > > > > > > > > > > > > -#if CONFIG_IS_ENABLED(CMD_MMC) > > > > > > > - #define BOOT_TARGET_MMC(func) \ > > > > > > > - func(MMC, mmc, 0) \ > > > > > > > - func(MMC, mmc, 1) \ > > > > > > > - func(MMC, mmc, 2) > > > > > > > -#else > > > > > > > - #define BOOT_TARGET_MMC(func) > > > > > > > -#endif > > > > > > > - > > > > > > > -#if CONFIG_IS_ENABLED(CMD_USB) > > > > > > > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > > > > > > > -#else > > > > > > > - #define BOOT_TARGET_USB(func) > > > > > > > -#endif > > > > > > > - > > > > > > > -#if CONFIG_IS_ENABLED(CMD_PXE) > > > > > > > - #define BOOT_TARGET_PXE(func) func(PXE, pxe, na) > > > > > > > -#else > > > > > > > - #define BOOT_TARGET_PXE(func) > > > > > > > -#endif > > > > > > > - > > > > > > > -#if CONFIG_IS_ENABLED(CMD_DHCP) > > > > > > > - #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > > > > > > > -#else > > > > > > > - #define BOOT_TARGET_DHCP(func) > > > > > > > -#endif > > > > > > > - > > > > > > > -#define BOOT_TARGET_DEVICES(func) \ > > > > > > > - BOOT_TARGET_MMC(func) \ > > > > > > > - BOOT_TARGET_USB(func) \ > > > > > > > - BOOT_TARGET_PXE(func) \ > > > > > > > - BOOT_TARGET_DHCP(func) > > > > > > > - > > > > > > > -#include <config_distro_bootcmd.h> > > > > > > > - > > > > > > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > > > > > > "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ > > > > > > > + "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \ > > > > > > > > > > > > We have the indirect defines to func(...) everywhere so that if a > > > > > > feature is disabled we still build + function, as otherwise it's a loud > > > > > > link error. I assume with this we just get a try and fail move to the > > > > > > next target at run time, yes? > > > > > > > > > > Yes, that's right. But I hope that boards actually set up the boot > > > > > targets correctly so that only those that are actually supported are > > > > > enabled. > > > > > > > > What do you mean? They always do that, even today, which is why we have > > > > those #ifdef's in the distro boot board code. If the user ends up > > > > disabling something, it should still build and work. And honestly, > > > > given that dependencies are now in Kconfig, the distro_boot.h stuff > > > > could get away with dropping all of the > > > > "Enabled_foo_without_CONFIG_CMD_foo" stuff I bet. > > > > > > Then I don't think I understand your original question. With bootstd > > > if USB is disabled (for example) then the USB bootdev won't exist so > > > it won't look at USB. It is not so much a link error, just that the > > > device is not there. > > > > I mean, with "boot_targets=mmc0 mmc1 usb0 pxe dhcp0" but CONFIG_MMC > > disabled, bootstd will gracefully fail, gracefully fail, boot from USB. > > Even if it gracefully fails, wouldn't it be better if the boot_targets > environment variable would correctly reflect the devices that are > actually avialable to boot from. We already have the logic to > construct that list. So why are we throwing that logic away? Well, the availability of bootdevs provides the same information. You can see that by looking at the definition of BOOT_TARGET_DEVICES above. The bootdevs have a natural priority, based on the assumed speed of the device, so the board would only need to intervene (with an env var or a devicetree property) when that is wrong. Regards, Simon
> The bootdevs have a natural priority, based on the assumed speed of > the device, so the board would only need to intervene (with an env var > or a devicetree property) when that is wrong. Does this make sense in general? The default boot order for a board should depend on what is available on board (or on the carrier board) and what is pluggable. I doubt there can be a sane default, so almost all boards will have to define its own boot order anyway. So it doesn't really matter how the general list is sorted, but sorting by the speed of the interface sounds.. strange. -michael
> From: Michael Walle <michael@walle.cc> > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > The bootdevs have a natural priority, based on the assumed speed of > > the device, so the board would only need to intervene (with an env var > > or a devicetree property) when that is wrong. > > Does this make sense in general? The default boot order for a > board should depend on what is available on board (or on the > carrier board) and what is pluggable. I doubt there can be a sane > default, so almost all boards will have to define its own > boot order anyway. > > So it doesn't really matter how the general list is sorted, but > sorting by the speed of the interface sounds.. strange. From a security standpoint "removable" vs. "non-removable" is what really matters. You don't really want someone to plug a usb key or SD card into your device and accidentally boot from it. Also, changing the default boot order for an already supported device is probably going to cause problems. Something to keep in mind when devices get converted to the new mechanism.
Hi Mark, On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Michael Walle <michael@walle.cc> > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > the device, so the board would only need to intervene (with an env var > > > or a devicetree property) when that is wrong. > > > > Does this make sense in general? The default boot order for a > > board should depend on what is available on board (or on the > > carrier board) and what is pluggable. I doubt there can be a sane > > default, so almost all boards will have to define its own > > boot order anyway. Please can you be more specific about what you the problem is here? If the board does not have a device then it will not exist in driver model (or will not probe) and it won't have a bootdev (or it won't probe). That seems to be equivalent to me. > > > > So it doesn't really matter how the general list is sorted, but > > sorting by the speed of the interface sounds.. strange. > > From a security standpoint "removable" vs. "non-removable" is what > really matters. You don't really want someone to plug a usb key or > SD card into your device and accidentally boot from it. Yes, this should be easy enough to set up. From what I've seen so far, people tend to put the MMC devices next to each other in priority, with USB and network later. But I still think having a sane default makes sense rather than making every board do this explicitly. > > Also, changing the default boot order for an already supported device > is probably going to cause problems. Something to keep in mind when > devices get converted to the new mechanism. Well conversion is a different thing. We should be able to make sure the order is the same as before, perhaps with a runtime check, e.g. adding an env variable which provides the expected order. Regards, Simon
On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > Hi Mark, > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > From: Michael Walle <michael@walle.cc> > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > the device, so the board would only need to intervene (with an env var > > > > or a devicetree property) when that is wrong. > > > > > > Does this make sense in general? The default boot order for a > > > board should depend on what is available on board (or on the > > > carrier board) and what is pluggable. I doubt there can be a sane > > > default, so almost all boards will have to define its own > > > boot order anyway. > > Please can you be more specific about what you the problem is here? If > the board does not have a device then it will not exist in driver > model (or will not probe) and it won't have a bootdev (or it won't > probe). That seems to be equivalent to me. So, I'm not sure how much of a problem it is, since the board can still define the default probe order via environment. But pick any random SoC with more than 1 SD/MMC set of lines on the chip. Youboard may put the first as SD slot and second as eMMC and Myboard may do the opposite and both are going to probe in the same order since it's the same chip. That's what I think Mark is getting at with it not really making sense to just rely on probe order as what to try.
> Date: Thu, 20 Jan 2022 13:30:47 -0500 > From: Tom Rini <trini@konsulko.com> > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > Hi Mark, > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > From: Michael Walle <michael@walle.cc> > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > the device, so the board would only need to intervene (with an env var > > > > > or a devicetree property) when that is wrong. > > > > > > > > Does this make sense in general? The default boot order for a > > > > board should depend on what is available on board (or on the > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > default, so almost all boards will have to define its own > > > > boot order anyway. > > > > Please can you be more specific about what you the problem is here? If > > the board does not have a device then it will not exist in driver > > model (or will not probe) and it won't have a bootdev (or it won't > > probe). That seems to be equivalent to me. > > So, I'm not sure how much of a problem it is, since the board can still > define the default probe order via environment. But pick any random SoC > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > first as SD slot and second as eMMC and Myboard may do the opposite and > both are going to probe in the same order since it's the same chip. > > That's what I think Mark is getting at with it not really making sense > to just rely on probe order as what to try. Something like that. I remember a lot of issues when boards were switched over to DM_MMC and the boot order changed. I believe this ended up beging solved by having aliases in the device tree.
Hi Mark, On Thu, 20 Jan 2022 at 11:56, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > Date: Thu, 20 Jan 2022 13:30:47 -0500 > > From: Tom Rini <trini@konsulko.com> > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > Hi Mark, > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > board should depend on what is available on board (or on the > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > default, so almost all boards will have to define its own > > > > > boot order anyway. > > > > > > Please can you be more specific about what you the problem is here? If > > > the board does not have a device then it will not exist in driver > > > model (or will not probe) and it won't have a bootdev (or it won't > > > probe). That seems to be equivalent to me. > > > > So, I'm not sure how much of a problem it is, since the board can still > > define the default probe order via environment. But pick any random SoC > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > first as SD slot and second as eMMC and Myboard may do the opposite and > > both are going to probe in the same order since it's the same chip. > > > > That's what I think Mark is getting at with it not really making sense > > to just rely on probe order as what to try. > > Something like that. I remember a lot of issues when boards were > switched over to DM_MMC and the boot order changed. I believe this > ended up beging solved by having aliases in the device tree. The bootdevs use the same aliases so the ordering should remain the same in that sense. Regards, Simon
Hi Tom, On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > Hi Mark, > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > From: Michael Walle <michael@walle.cc> > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > the device, so the board would only need to intervene (with an env var > > > > > or a devicetree property) when that is wrong. > > > > > > > > Does this make sense in general? The default boot order for a > > > > board should depend on what is available on board (or on the > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > default, so almost all boards will have to define its own > > > > boot order anyway. > > > > Please can you be more specific about what you the problem is here? If > > the board does not have a device then it will not exist in driver > > model (or will not probe) and it won't have a bootdev (or it won't > > probe). That seems to be equivalent to me. > > So, I'm not sure how much of a problem it is, since the board can still > define the default probe order via environment. But pick any random SoC > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > first as SD slot and second as eMMC and Myboard may do the opposite and > both are going to probe in the same order since it's the same chip. > > That's what I think Mark is getting at with it not really making sense > to just rely on probe order as what to try. Doesn't the 'non-removable' flag describe this feature of the hardware? If you don't want to rely on the normal ordering, you can set the boot_targets variable. I'd just like to avoid that being required for 'normal' boards and situations. Regards, Simon
On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > Hi Mark, > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > board should depend on what is available on board (or on the > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > default, so almost all boards will have to define its own > > > > > boot order anyway. > > > > > > Please can you be more specific about what you the problem is here? If > > > the board does not have a device then it will not exist in driver > > > model (or will not probe) and it won't have a bootdev (or it won't > > > probe). That seems to be equivalent to me. > > > > So, I'm not sure how much of a problem it is, since the board can still > > define the default probe order via environment. But pick any random SoC > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > first as SD slot and second as eMMC and Myboard may do the opposite and > > both are going to probe in the same order since it's the same chip. > > > > That's what I think Mark is getting at with it not really making sense > > to just rely on probe order as what to try. > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > If you don't want to rely on the normal ordering, you can set the > boot_targets variable. I'd just like to avoid that being required for > 'normal' boards and situations. I think setting things via the environment to have correct defaults is a must. I mean, yes, OK, if there's some device tree binding that we can use that describes this, sure, that's choice A. But choice B would probably be environment strings. Probe and hope is choice C, or more like last resort, imho.
Hi Tom, On Thu, 20 Jan 2022 at 13:08, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > Hi Mark, > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > > board should depend on what is available on board (or on the > > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > > default, so almost all boards will have to define its own > > > > > > boot order anyway. > > > > > > > > Please can you be more specific about what you the problem is here? If > > > > the board does not have a device then it will not exist in driver > > > > model (or will not probe) and it won't have a bootdev (or it won't > > > > probe). That seems to be equivalent to me. > > > > > > So, I'm not sure how much of a problem it is, since the board can still > > > define the default probe order via environment. But pick any random SoC > > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > > first as SD slot and second as eMMC and Myboard may do the opposite and > > > both are going to probe in the same order since it's the same chip. > > > > > > That's what I think Mark is getting at with it not really making sense > > > to just rely on probe order as what to try. > > > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > > > If you don't want to rely on the normal ordering, you can set the > > boot_targets variable. I'd just like to avoid that being required for > > 'normal' boards and situations. > > I think setting things via the environment to have correct defaults is a > must. I mean, yes, OK, if there's some device tree binding that we can > use that describes this, sure, that's choice A. But choice B would > probably be environment strings. Probe and hope is choice C, or more > like last resort, imho. Well the boot_targets var is implemented in this series. The question is whether we force platforms to define it, or have a way to handle things gracefully by default. Regards, Simon
On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 20 Jan 2022 at 13:08, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > > Hi Mark, > > > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > > > board should depend on what is available on board (or on the > > > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > > > default, so almost all boards will have to define its own > > > > > > > boot order anyway. > > > > > > > > > > Please can you be more specific about what you the problem is here? If > > > > > the board does not have a device then it will not exist in driver > > > > > model (or will not probe) and it won't have a bootdev (or it won't > > > > > probe). That seems to be equivalent to me. > > > > > > > > So, I'm not sure how much of a problem it is, since the board can still > > > > define the default probe order via environment. But pick any random SoC > > > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > > > first as SD slot and second as eMMC and Myboard may do the opposite and > > > > both are going to probe in the same order since it's the same chip. > > > > > > > > That's what I think Mark is getting at with it not really making sense > > > > to just rely on probe order as what to try. > > > > > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > > > > > If you don't want to rely on the normal ordering, you can set the > > > boot_targets variable. I'd just like to avoid that being required for > > > 'normal' boards and situations. > > > > I think setting things via the environment to have correct defaults is a > > must. I mean, yes, OK, if there's some device tree binding that we can > > use that describes this, sure, that's choice A. But choice B would > > probably be environment strings. Probe and hope is choice C, or more > > like last resort, imho. > > Well the boot_targets var is implemented in this series. > > The question is whether we force platforms to define it, or have a way > to handle things gracefully by default. I think we need to force it to be defined until / unless there's some agreed on standard to provide that information at run time.
Hi Tom, On Thu, 20 Jan 2022 at 16:23, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 20 Jan 2022 at 13:08, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > > > Hi Mark, > > > > > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > > > > board should depend on what is available on board (or on the > > > > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > > > > default, so almost all boards will have to define its own > > > > > > > > boot order anyway. > > > > > > > > > > > > Please can you be more specific about what you the problem is here? If > > > > > > the board does not have a device then it will not exist in driver > > > > > > model (or will not probe) and it won't have a bootdev (or it won't > > > > > > probe). That seems to be equivalent to me. > > > > > > > > > > So, I'm not sure how much of a problem it is, since the board can still > > > > > define the default probe order via environment. But pick any random SoC > > > > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > > > > first as SD slot and second as eMMC and Myboard may do the opposite and > > > > > both are going to probe in the same order since it's the same chip. > > > > > > > > > > That's what I think Mark is getting at with it not really making sense > > > > > to just rely on probe order as what to try. > > > > > > > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > > > > > > > If you don't want to rely on the normal ordering, you can set the > > > > boot_targets variable. I'd just like to avoid that being required for > > > > 'normal' boards and situations. > > > > > > I think setting things via the environment to have correct defaults is a > > > must. I mean, yes, OK, if there's some device tree binding that we can > > > use that describes this, sure, that's choice A. But choice B would > > > probably be environment strings. Probe and hope is choice C, or more > > > like last resort, imho. > > > > Well the boot_targets var is implemented in this series. > > > > The question is whether we force platforms to define it, or have a way > > to handle things gracefully by default. > > I think we need to force it to be defined until / unless there's some > agreed on standard to provide that information at run time. Well we can do that with a cut-down distro header with some macros, I suppose? Regards, Simon
On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 20 Jan 2022 at 16:23, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 20 Jan 2022 at 13:08, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > > > > Hi Mark, > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > > > > > board should depend on what is available on board (or on the > > > > > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > > > > > default, so almost all boards will have to define its own > > > > > > > > > boot order anyway. > > > > > > > > > > > > > > Please can you be more specific about what you the problem is here? If > > > > > > > the board does not have a device then it will not exist in driver > > > > > > > model (or will not probe) and it won't have a bootdev (or it won't > > > > > > > probe). That seems to be equivalent to me. > > > > > > > > > > > > So, I'm not sure how much of a problem it is, since the board can still > > > > > > define the default probe order via environment. But pick any random SoC > > > > > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > > > > > first as SD slot and second as eMMC and Myboard may do the opposite and > > > > > > both are going to probe in the same order since it's the same chip. > > > > > > > > > > > > That's what I think Mark is getting at with it not really making sense > > > > > > to just rely on probe order as what to try. > > > > > > > > > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > > > > > > > > > If you don't want to rely on the normal ordering, you can set the > > > > > boot_targets variable. I'd just like to avoid that being required for > > > > > 'normal' boards and situations. > > > > > > > > I think setting things via the environment to have correct defaults is a > > > > must. I mean, yes, OK, if there's some device tree binding that we can > > > > use that describes this, sure, that's choice A. But choice B would > > > > probably be environment strings. Probe and hope is choice C, or more > > > > like last resort, imho. > > > > > > Well the boot_targets var is implemented in this series. > > > > > > The question is whether we force platforms to define it, or have a way > > > to handle things gracefully by default. > > > > I think we need to force it to be defined until / unless there's some > > agreed on standard to provide that information at run time. > > Well we can do that with a cut-down distro header with some macros, I suppose? Sorry? I mean, when I said standard above, and since you had mentioned from the device tree before (I thought..) I mean get some property defined and accepted and use that for first best path. Then keep using boot_targets and make sure it's documented (and in help, etc) that boards should define that in their default environment for a preferred fallback default boot order. The final fall back of "probe and guess" might need an off switch for securing systems, I'm not sure.
Hi Tom, On Thu, 20 Jan 2022 at 18:08, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 20 Jan 2022 at 16:23, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 20 Jan 2022 at 13:08, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > > > > > > board should depend on what is available on board (or on the > > > > > > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > > > > > > default, so almost all boards will have to define its own > > > > > > > > > > boot order anyway. > > > > > > > > > > > > > > > > Please can you be more specific about what you the problem is here? If > > > > > > > > the board does not have a device then it will not exist in driver > > > > > > > > model (or will not probe) and it won't have a bootdev (or it won't > > > > > > > > probe). That seems to be equivalent to me. > > > > > > > > > > > > > > So, I'm not sure how much of a problem it is, since the board can still > > > > > > > define the default probe order via environment. But pick any random SoC > > > > > > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > > > > > > first as SD slot and second as eMMC and Myboard may do the opposite and > > > > > > > both are going to probe in the same order since it's the same chip. > > > > > > > > > > > > > > That's what I think Mark is getting at with it not really making sense > > > > > > > to just rely on probe order as what to try. > > > > > > > > > > > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > > > > > > > > > > > If you don't want to rely on the normal ordering, you can set the > > > > > > boot_targets variable. I'd just like to avoid that being required for > > > > > > 'normal' boards and situations. > > > > > > > > > > I think setting things via the environment to have correct defaults is a > > > > > must. I mean, yes, OK, if there's some device tree binding that we can > > > > > use that describes this, sure, that's choice A. But choice B would > > > > > probably be environment strings. Probe and hope is choice C, or more > > > > > like last resort, imho. > > > > > > > > Well the boot_targets var is implemented in this series. > > > > > > > > The question is whether we force platforms to define it, or have a way > > > > to handle things gracefully by default. > > > > > > I think we need to force it to be defined until / unless there's some > > > agreed on standard to provide that information at run time. > > > > Well we can do that with a cut-down distro header with some macros, I suppose? > > Sorry? I mean, when I said standard above, and since you had mentioned > from the device tree before (I thought..) I mean get some property > defined and accepted and use that for first best path. Then keep using I think this discussion is a bit beyond the scope of this series. You are talking about the policy for the bootdev selection. So far, implemented in this series, we have, in order of preference: - boot_targets env var - bootdev-order device tree property (which you are referring to here) - priority order (as announced by each bootdev, i.e. it can depend on removable flags, etc.) - alias order (using device tree) - simple sequence order (position in device tree, or order in which devices were bound) I think that is enough to be getting on with. My point above was that if we want to define the boot_targets env var in a header file as now, we could. > boot_targets and make sure it's documented (and in help, etc) that > boards should define that in their default environment for a preferred > fallback default boot order. The final fall back of "probe and guess" > might need an off switch for securing systems, I'm not sure. Yes we need to be careful about that. But for now my intent is to make it possible to migrate from the scripts. Once we have the basics in place we can expand it and I suspect people will find it a lot easier to work with. Also see BOOTFLOWF_FIXED for example, which isn't implemented, but is intended to allow devices to be filtered based on whether they are internal to the device or not. Regards, Simon
> From: Simon Glass <sjg@chromium.org> > Date: Thu, 20 Jan 2022 20:12:41 -0700 > > Hi Tom, > > On Thu, 20 Jan 2022 at 18:08, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 20 Jan 2022 at 16:23, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 20 Jan 2022 at 13:08, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > > > > > > > board should depend on what is available on board (or on the > > > > > > > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > > > > > > > default, so almost all boards will have to define its own > > > > > > > > > > > boot order anyway. > > > > > > > > > > > > > > > > > > Please can you be more specific about what you the problem is here? If > > > > > > > > > the board does not have a device then it will not exist in driver > > > > > > > > > model (or will not probe) and it won't have a bootdev (or it won't > > > > > > > > > probe). That seems to be equivalent to me. > > > > > > > > > > > > > > > > So, I'm not sure how much of a problem it is, since the board can still > > > > > > > > define the default probe order via environment. But pick any random SoC > > > > > > > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > > > > > > > first as SD slot and second as eMMC and Myboard may do the opposite and > > > > > > > > both are going to probe in the same order since it's the same chip. > > > > > > > > > > > > > > > > That's what I think Mark is getting at with it not really making sense > > > > > > > > to just rely on probe order as what to try. > > > > > > > > > > > > > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > > > > > > > > > > > > > If you don't want to rely on the normal ordering, you can set the > > > > > > > boot_targets variable. I'd just like to avoid that being required for > > > > > > > 'normal' boards and situations. > > > > > > > > > > > > I think setting things via the environment to have correct defaults is a > > > > > > must. I mean, yes, OK, if there's some device tree binding that we can > > > > > > use that describes this, sure, that's choice A. But choice B would > > > > > > probably be environment strings. Probe and hope is choice C, or more > > > > > > like last resort, imho. > > > > > > > > > > Well the boot_targets var is implemented in this series. > > > > > > > > > > The question is whether we force platforms to define it, or have a way > > > > > to handle things gracefully by default. > > > > > > > > I think we need to force it to be defined until / unless there's some > > > > agreed on standard to provide that information at run time. > > > > > > Well we can do that with a cut-down distro header with some macros, I suppose? > > > > Sorry? I mean, when I said standard above, and since you had mentioned > > from the device tree before (I thought..) I mean get some property > > defined and accepted and use that for first best path. Then keep using > > I think this discussion is a bit beyond the scope of this series. You > are talking about the policy for the bootdev selection. So far, > implemented in this series, we have, in order of preference: > > - boot_targets env var > - bootdev-order device tree property (which you are referring to here) > - priority order (as announced by each bootdev, i.e. it can depend on > removable flags, etc.) > - alias order (using device tree) > - simple sequence order (position in device tree, or order in which > devices were bound) > > I think that is enough to be getting on with. My point above was that > if we want to define the boot_targets env var in a header file as now, > we could. > > > boot_targets and make sure it's documented (and in help, etc) that > > boards should define that in their default environment for a preferred > > fallback default boot order. The final fall back of "probe and guess" > > might need an off switch for securing systems, I'm not sure. > > Yes we need to be careful about that. But for now my intent is to make > it possible to migrate from the scripts. Once we have the basics in > place we can expand it and I suspect people will find it a lot easier > to work with. > > Also see BOOTFLOWF_FIXED for example, which isn't implemented, but is > intended to allow devices to be filtered based on whether they are > internal to the device or not. I think what is important here is that when a board gets converted to the new mechanism, the order remains the same as before. With the approach taken by Simon that will take some effort. That's why I thought that keeping the existing macros but redefining them to just produce the boot_targets environment variable instead of the complicated script we have now would be a good idea. Regarding encoding the boot order in the device tree, I must say that the proposed bindings look a bit strange to me with the use of compatible strings for things that are essentially user-settable options. I also don't entirely see why boot device selection should be u-boot-specific. There actually is a precedent here set by Open Firmware. In Open Firmware you select the boot order by setting the "boot-device" variable that appears as a property of the /options node in the device tree. This variable is a list of boot devices very similar to the boot_targets variable that U-Boot has. The items in this list are separated by spaces (like boot_targets) and the are in principle full device tree paths specifying devices. But aliases (as defined in the /aliases node) can be used as well.
On Thu, Jan 20, 2022 at 08:12:41PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 20 Jan 2022 at 18:08, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 20 Jan 2022 at 16:23, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 20 Jan 2022 at 13:08, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > > > > > > > board should depend on what is available on board (or on the > > > > > > > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > > > > > > > default, so almost all boards will have to define its own > > > > > > > > > > > boot order anyway. > > > > > > > > > > > > > > > > > > Please can you be more specific about what you the problem is here? If > > > > > > > > > the board does not have a device then it will not exist in driver > > > > > > > > > model (or will not probe) and it won't have a bootdev (or it won't > > > > > > > > > probe). That seems to be equivalent to me. > > > > > > > > > > > > > > > > So, I'm not sure how much of a problem it is, since the board can still > > > > > > > > define the default probe order via environment. But pick any random SoC > > > > > > > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > > > > > > > first as SD slot and second as eMMC and Myboard may do the opposite and > > > > > > > > both are going to probe in the same order since it's the same chip. > > > > > > > > > > > > > > > > That's what I think Mark is getting at with it not really making sense > > > > > > > > to just rely on probe order as what to try. > > > > > > > > > > > > > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > > > > > > > > > > > > > If you don't want to rely on the normal ordering, you can set the > > > > > > > boot_targets variable. I'd just like to avoid that being required for > > > > > > > 'normal' boards and situations. > > > > > > > > > > > > I think setting things via the environment to have correct defaults is a > > > > > > must. I mean, yes, OK, if there's some device tree binding that we can > > > > > > use that describes this, sure, that's choice A. But choice B would > > > > > > probably be environment strings. Probe and hope is choice C, or more > > > > > > like last resort, imho. > > > > > > > > > > Well the boot_targets var is implemented in this series. > > > > > > > > > > The question is whether we force platforms to define it, or have a way > > > > > to handle things gracefully by default. > > > > > > > > I think we need to force it to be defined until / unless there's some > > > > agreed on standard to provide that information at run time. > > > > > > Well we can do that with a cut-down distro header with some macros, I suppose? > > > > Sorry? I mean, when I said standard above, and since you had mentioned > > from the device tree before (I thought..) I mean get some property > > defined and accepted and use that for first best path. Then keep using > > I think this discussion is a bit beyond the scope of this series. You > are talking about the policy for the bootdev selection. So far, > implemented in this series, we have, in order of preference: I still owe comments on the concept, but I want to make sure we don't end up in another case where we ad-hoc something for device tree and keep building off of it without it being made official.
Hi Tom, On Fri, 21 Jan 2022 at 08:05, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Jan 20, 2022 at 08:12:41PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 20 Jan 2022 at 18:08, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 20 Jan 2022 at 16:23, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 20 Jan 2022 at 13:08, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > > > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > > > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > > > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > > > > > > > > board should depend on what is available on board (or on the > > > > > > > > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > > > > > > > > default, so almost all boards will have to define its own > > > > > > > > > > > > boot order anyway. > > > > > > > > > > > > > > > > > > > > Please can you be more specific about what you the problem is here? If > > > > > > > > > > the board does not have a device then it will not exist in driver > > > > > > > > > > model (or will not probe) and it won't have a bootdev (or it won't > > > > > > > > > > probe). That seems to be equivalent to me. > > > > > > > > > > > > > > > > > > So, I'm not sure how much of a problem it is, since the board can still > > > > > > > > > define the default probe order via environment. But pick any random SoC > > > > > > > > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > > > > > > > > first as SD slot and second as eMMC and Myboard may do the opposite and > > > > > > > > > both are going to probe in the same order since it's the same chip. > > > > > > > > > > > > > > > > > > That's what I think Mark is getting at with it not really making sense > > > > > > > > > to just rely on probe order as what to try. > > > > > > > > > > > > > > > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > > > > > > > > > > > > > > > If you don't want to rely on the normal ordering, you can set the > > > > > > > > boot_targets variable. I'd just like to avoid that being required for > > > > > > > > 'normal' boards and situations. > > > > > > > > > > > > > > I think setting things via the environment to have correct defaults is a > > > > > > > must. I mean, yes, OK, if there's some device tree binding that we can > > > > > > > use that describes this, sure, that's choice A. But choice B would > > > > > > > probably be environment strings. Probe and hope is choice C, or more > > > > > > > like last resort, imho. > > > > > > > > > > > > Well the boot_targets var is implemented in this series. > > > > > > > > > > > > The question is whether we force platforms to define it, or have a way > > > > > > to handle things gracefully by default. > > > > > > > > > > I think we need to force it to be defined until / unless there's some > > > > > agreed on standard to provide that information at run time. > > > > > > > > Well we can do that with a cut-down distro header with some macros, I suppose? > > > > > > Sorry? I mean, when I said standard above, and since you had mentioned > > > from the device tree before (I thought..) I mean get some property > > > defined and accepted and use that for first best path. Then keep using > > > > I think this discussion is a bit beyond the scope of this series. You > > are talking about the policy for the bootdev selection. So far, > > implemented in this series, we have, in order of preference: > > I still owe comments on the concept, but I want to make sure we don't > end up in another case where we ad-hoc something for device tree and > keep building off of it without it being made official. Yes, the bootstd node itself is currently ad-hoc, as are the bootdev devices and bootmeth. Of course all of these are optional and don't appear in .dts files for now, but we should still add bindings for them. Regards, Simon
Hi Mark, On Fri, 21 Jan 2022 at 02:36, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Simon Glass <sjg@chromium.org> > > Date: Thu, 20 Jan 2022 20:12:41 -0700 > > > > Hi Tom, > > > > On Thu, 20 Jan 2022 at 18:08, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 20 Jan 2022 at 16:23, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 20 Jan 2022 at 13:08, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > > > > > > > > > > > > > > > > > > From: Michael Walle <michael@walle.cc> > > > > > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > > > > > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > > > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > > > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > > > > > > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > > > > > > > > board should depend on what is available on board (or on the > > > > > > > > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > > > > > > > > default, so almost all boards will have to define its own > > > > > > > > > > > > boot order anyway. > > > > > > > > > > > > > > > > > > > > Please can you be more specific about what you the problem is here? If > > > > > > > > > > the board does not have a device then it will not exist in driver > > > > > > > > > > model (or will not probe) and it won't have a bootdev (or it won't > > > > > > > > > > probe). That seems to be equivalent to me. > > > > > > > > > > > > > > > > > > So, I'm not sure how much of a problem it is, since the board can still > > > > > > > > > define the default probe order via environment. But pick any random SoC > > > > > > > > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > > > > > > > > first as SD slot and second as eMMC and Myboard may do the opposite and > > > > > > > > > both are going to probe in the same order since it's the same chip. > > > > > > > > > > > > > > > > > > That's what I think Mark is getting at with it not really making sense > > > > > > > > > to just rely on probe order as what to try. > > > > > > > > > > > > > > > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > > > > > > > > > > > > > > > If you don't want to rely on the normal ordering, you can set the > > > > > > > > boot_targets variable. I'd just like to avoid that being required for > > > > > > > > 'normal' boards and situations. > > > > > > > > > > > > > > I think setting things via the environment to have correct defaults is a > > > > > > > must. I mean, yes, OK, if there's some device tree binding that we can > > > > > > > use that describes this, sure, that's choice A. But choice B would > > > > > > > probably be environment strings. Probe and hope is choice C, or more > > > > > > > like last resort, imho. > > > > > > > > > > > > Well the boot_targets var is implemented in this series. > > > > > > > > > > > > The question is whether we force platforms to define it, or have a way > > > > > > to handle things gracefully by default. > > > > > > > > > > I think we need to force it to be defined until / unless there's some > > > > > agreed on standard to provide that information at run time. > > > > > > > > Well we can do that with a cut-down distro header with some macros, I suppose? > > > > > > Sorry? I mean, when I said standard above, and since you had mentioned > > > from the device tree before (I thought..) I mean get some property > > > defined and accepted and use that for first best path. Then keep using > > > > I think this discussion is a bit beyond the scope of this series. You > > are talking about the policy for the bootdev selection. So far, > > implemented in this series, we have, in order of preference: > > > > - boot_targets env var > > - bootdev-order device tree property (which you are referring to here) > > - priority order (as announced by each bootdev, i.e. it can depend on > > removable flags, etc.) > > - alias order (using device tree) > > - simple sequence order (position in device tree, or order in which > > devices were bound) > > > > I think that is enough to be getting on with. My point above was that > > if we want to define the boot_targets env var in a header file as now, > > we could. > > > > > boot_targets and make sure it's documented (and in help, etc) that > > > boards should define that in their default environment for a preferred > > > fallback default boot order. The final fall back of "probe and guess" > > > might need an off switch for securing systems, I'm not sure. > > > > Yes we need to be careful about that. But for now my intent is to make > > it possible to migrate from the scripts. Once we have the basics in > > place we can expand it and I suspect people will find it a lot easier > > to work with. > > > > Also see BOOTFLOWF_FIXED for example, which isn't implemented, but is > > intended to allow devices to be filtered based on whether they are > > internal to the device or not. > > I think what is important here is that when a board gets converted to > the new mechanism, the order remains the same as before. With the > approach taken by Simon that will take some effort. That's why I > thought that keeping the existing macros but redefining them to just > produce the boot_targets environment variable instead of the > complicated script we have now would be a good idea. Your comment above is why I suggested keeping some macros but just produced that one env var from them. > > Regarding encoding the boot order in the device tree, I must say that > the proposed bindings look a bit strange to me with the use of > compatible strings for things that are essentially user-settable > options. I also don't entirely see why boot device selection should > be u-boot-specific. There actually is a precedent here set by Open > Firmware. In Open Firmware you select the boot order by setting the > "boot-device" variable that appears as a property of the /options node > in the device tree. This variable is a list of boot devices very > similar to the boot_targets variable that U-Boot has. The items in > this list are separated by spaces (like boot_targets) and the are in" > principle full device tree paths specifying devices. But aliases (as > defined in the /aliases node) can be used as well. Which compatible strings are you referring to? There is a "bootdev-order" property which sounds like "boot-device", except that it is a string list, not a space-separated string. Regards, Simon
diff --git a/boot/Kconfig b/boot/Kconfig index 9cf1d013f20..eab3c0f3467 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -1124,7 +1124,8 @@ config USE_BOOTCOMMAND config BOOTCOMMAND string "bootcmd value" depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE - default "run distro_bootcmd" if DISTRO_DEFAULTS + default "bootflow scan -lb" if BOOTSTD + default "run distro_bootcmd" if !BOOTSTD && DISTRO_DEFAULTS help This is the string of commands that will be used as bootcmd and if AUTOBOOT is set, automatically run. diff --git a/include/configs/rpi.h b/include/configs/rpi.h index d5e064fb379..ea373d0c221 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -133,47 +133,12 @@ "fdt_addr_r=0x02600000\0" \ "ramdisk_addr_r=0x02700000\0" -#if CONFIG_IS_ENABLED(CMD_MMC) - #define BOOT_TARGET_MMC(func) \ - func(MMC, mmc, 0) \ - func(MMC, mmc, 1) \ - func(MMC, mmc, 2) -#else - #define BOOT_TARGET_MMC(func) -#endif - -#if CONFIG_IS_ENABLED(CMD_USB) - #define BOOT_TARGET_USB(func) func(USB, usb, 0) -#else - #define BOOT_TARGET_USB(func) -#endif - -#if CONFIG_IS_ENABLED(CMD_PXE) - #define BOOT_TARGET_PXE(func) func(PXE, pxe, na) -#else - #define BOOT_TARGET_PXE(func) -#endif - -#if CONFIG_IS_ENABLED(CMD_DHCP) - #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) -#else - #define BOOT_TARGET_DHCP(func) -#endif - -#define BOOT_TARGET_DEVICES(func) \ - BOOT_TARGET_MMC(func) \ - BOOT_TARGET_USB(func) \ - BOOT_TARGET_PXE(func) \ - BOOT_TARGET_DHCP(func) - -#include <config_distro_bootcmd.h> - #define CONFIG_EXTRA_ENV_SETTINGS \ "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ + "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \ ENV_DEVICE_SETTINGS \ ENV_DFU_SETTINGS \ - ENV_MEM_LAYOUT_SETTINGS \ - BOOTENV + ENV_MEM_LAYOUT_SETTINGS #endif
Switch this over, for testing purposes. Signed-off-by: Simon Glass <sjg@chromium.org> --- (no changes since v1) boot/Kconfig | 3 ++- include/configs/rpi.h | 39 ++------------------------------------- 2 files changed, 4 insertions(+), 38 deletions(-)