[PATCH v5 1/8] bootstd: Avoid depending on BLK
Tom Rini
trini at konsulko.com
Wed Nov 13 18:47:07 CET 2024
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 at 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.
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241113/cfd524b9/attachment.sig>
More information about the U-Boot
mailing list