[PATCH v5 1/8] bootstd: Avoid depending on BLK

[Simon Glass]

Hi Tom,

On Thu, 14 Nov 2024 at 07:22, Tom Rini <trini at konsulko.com> wrote:
>
> 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 at 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 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.
> >
> > 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?

We have SPI flash and FEL, for example. Also, sandbox's hostfs doesn't
use BLK. Plus the network bootmeths are available without 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.
> >
> > 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.

Yes it is at [2]. If you look at BLK it says:

config BLK
   bool # "Support block devices"
   depends on DM
   def_bool y if MMC || USB || SCSI || NVME || IDE || AHCI || SATA
   def_bool y if EFI_MEDIA || VIRTIO_BLK || PVBLOCK

We also have, in the commit message:

symbol BLK is selected by EFI_LOADER

Having a 'select X' and 'depends on X' is known to cause problems. We
really shouldn't do it. So I am removing 'depends on BLK'.

Regards,
Simon

[2] https://patchwork.ozlabs.org/project/uboot/patch/20240901222734.462334-4-sjg@chromium.org/