[PATCH v3 3/8] bootstd: Avoid depending on BLK

Fri Oct 18 19:20:40 CEST 2024

Hi Tom,

On Fri, 18 Oct 2024 at 09:11, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Oct 18, 2024 at 09:00:49AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 17 Oct 2024 at 22:39, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Oct 17, 2024 at 04:12:02PM -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>
> > > > ---
> > > >
> > > > 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(-)
> > > >
> > > > Applied to u-boot-dm, thanks!
> > >
> > > No, this is wrong, it's pulling in BOOTSTD on a ton of platforms that
> > > didn't have it before.
> >
> > This affects 103 boards and the size growth is considerable:
> >
> >    aarch64: (for 22/22 boards) all +15697.0 bss +26.2 data +710.9
> > rodata +1822.1 text +13137.8
> >        arc: (for 4/4 boards) all +15338.0 bss +4.0 data +526.0 rodata
> > +2096.0 text +12712.0
> >        arm: (for 26/26 boards) all +18882.8 data +619.2 rodata +1998.8
> > text +16264.8
> >       m68k: (for 17/17 boards) all +23859.9 bss +3.5 data +1595.8
> > rodata +1722.8 text +20537.8
> > microblaze: (for 1/1 boards) all +24713.0 bss -88.0 data +1248.0
> > rodata +2288.0 text +21265.0
> >       mips: (for 23/23 boards) all +21659.1 bss +39.5 data +746.6
> > rodata +2155.7 text +18717.4
> >      nios2: (for 2/2 boards) all +24856.0 bss +4.0 data +704.0 text +24148.0
> >    powerpc: (for 13/13 boards) all +21746.6 data +836.3 rodata +807.2
> > text +20103.2
> >
> > Added options are:
> >
> >    + all: CONFIG_BOOTDEV_ETH=1 CONFIG_BOOTMETH_EXTLINUX=1
> > CONFIG_BOOTMETH_GLOBAL=1 CONFIG_BOOTMETH_VBE=1
> > CONFIG_BOOTMETH_VBE_REQUEST=1 CONFIG_BOOTMETH_VBE_SIMPLE=1
> > CONFIG_BOOTMETH_VBE_SIMPLE_OS=1 CONFIG_BOOTSTD=1
> > CONFIG_BOOTSTD_BOOTCOMMAND=1 CONFIG_CMD_BOOTFLOW=1 CONFIG_MENU=1
> > CONFIG_PXE_UTILS=1
> >
> > Should I manually disable it on those platforms? I've reached the
> > point where bootstd needs to be available when BLK is not enabled, so
> > need some sort of solution.
>
> What is the use case for needing all of this, without BLK being set? I'm
> not sure which platforms that grew here also need bootstd?

It is just that some XPL (I can say that now) platforms don't enable
BLK but do need to read from a device, e.g. MMC.

Regards,
Simon