On Wed, Nov 13, 2024 at 08:53:31PM -0700, Simon Glass wrote:
Hi Tom,
On Wed, 13 Nov 2024 at 10:47, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 13, 2024 at 08:09:31AM -0700, Simon Glass wrote:
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 suchThis ends up being a massive size bloat on all of the boards which did not use BOOTSTD before, and still can't (because there's no appropriate methods). You need to not just disable it on the one board that fails but on everything not currently enabling it, which now does enable it.
Looking through the list it is hard to know which boards can't use bootstd, nor what the missing methods are. See [1]. I could perhaps disable bootstd for all of the boards?
Well, since you cannot have a block device without BLK at this point, none of them can use bootstd since there's no methods for whatever flash they use?
Or you need to better explain what's going on here, exactly and why depending on BLK here is wrong, for what you're doing.
I tried that already. We had quite a long thread about it.
Yes, can you remind me please? I still don't see why this is required for sunxi support. And I think this is another good example of where your commit message explains your solution, but not the underlying problem you're solving. None of the platforms in [1] are ARCH_SUNXI.