In principle bootstd can work without block devices, even if it does require driver model to be enabled in that case.
The use of a 'depends on BLK' for BOOTSTD conflicts with the way 'BLK' is now defined, producing recursive errors through multiple different paths, one of which is this (with Linksprite_pcDuino3 and BOOTSTD_DEFAULTS enabled):
arch/arm/Kconfig:7:error: recursive dependency detected! arch/arm/Kconfig:7: symbol ARM64 is selected by ARCH_UNIPHIER_V8_MULTI arch/arm/mach-uniphier/Kconfig:17: symbol ARCH_UNIPHIER_V8_MULTI is part of choice <choice> arch/arm/mach-uniphier/Kconfig:6: choice <choice> contains symbol ARCH_UNIPHIER_V8_MULTI arch/arm/mach-uniphier/Kconfig:17: symbol ARCH_UNIPHIER_V8_MULTI is part of choice SPL arch/arm/mach-stm32mp/Kconfig:3: symbol SPL depends on SUPPORT_SPL common/spl/Kconfig:1: symbol SUPPORT_SPL is selected by ASPEED_AST2600 arch/arm/mach-aspeed/Kconfig:26: symbol ASPEED_AST2600 is part of choice <choice> arch/arm/mach-aspeed/Kconfig:12: choice <choice> contains symbol ASPEED_AST2500 arch/arm/mach-aspeed/Kconfig:17: symbol ASPEED_AST2500 is part of choice DM_RESET arch/arm/mach-renesas/Kconfig.rcar3:197: symbol DM_RESET is selected by CLK_RCAR_GEN3 drivers/clk/renesas/Kconfig:53: symbol CLK_RCAR_GEN3 depends on CLK_RENESAS drivers/clk/renesas/Kconfig:1: symbol CLK_RENESAS depends on CLK drivers/clk/Kconfig:3: symbol CLK is selected by IMX8M_POWER_DOMAIN drivers/power/domain/Kconfig:35: symbol IMX8M_POWER_DOMAIN depends on POWER_DOMAIN drivers/power/domain/Kconfig:3: symbol POWER_DOMAIN is selected by BCM6318_USBH_PHY drivers/phy/Kconfig:83: symbol BCM6318_USBH_PHY depends on PHY drivers/phy/Kconfig:4: symbol PHY is selected by USB_EHCI_MX7 drivers/usb/host/Kconfig:211: symbol USB_EHCI_MX7 depends on USB drivers/usb/Kconfig:1: symbol USB is selected by BOOTSTD_DEFAULTS boot/Kconfig:455: symbol BOOTSTD_DEFAULTS depends on BOOTSTD boot/Kconfig:398: symbol BOOTSTD depends on BLK drivers/block/Kconfig:1: symbol BLK is selected by PVBLOCK drivers/xen/Kconfig:1: symbol PVBLOCK depends on XEN Kconfig:176: symbol XEN depends on ARM64
We don't want to revert the change to BLK, which has been in place for a year now. We don't want to select BLK in BOOTSTD since it should support booting without block devices. The only realistic option is to remove BOOTSTD's dependency on BLK.
Disable standard boot on the one board which fails.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v3)
Changes in v3: - Drop wip (work-in-progress) comment in commit
Changes in v2: - Add new patch to resolve BOOTSTD->BLK recursion with Kconfig
boot/Kconfig | 2 +- configs/gardena-smart-gateway-mt7688_defconfig | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/boot/Kconfig b/boot/Kconfig index 7dd30a030e3..b5433e88f10 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -393,7 +393,7 @@ config BOOT_DEFAULTS menuconfig BOOTSTD bool "Standard boot" default y - depends on DM && OF_CONTROL && BLK + depends on DM && OF_CONTROL help U-Boot supports a standard way of locating something to boot, typically an Operating System such as Linux, provided by a distro such diff --git a/configs/gardena-smart-gateway-mt7688_defconfig b/configs/gardena-smart-gateway-mt7688_defconfig index b7f4a76ce68..85f42a3ab6d 100644 --- a/configs/gardena-smart-gateway-mt7688_defconfig +++ b/configs/gardena-smart-gateway-mt7688_defconfig @@ -30,6 +30,7 @@ CONFIG_HAS_BOARD_SIZE_LIMIT=y CONFIG_BOARD_SIZE_LIMIT=655360 CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +# CONFIG_BOOTSTD is not set CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_AUTOBOOT_KEYED=y CONFIG_AUTOBOOT_STOP_STR="x"