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 <tr...@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 <s...@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 > > > > This 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. -- Tom
signature.asc
Description: PGP signature
