[PATCH v5 1/8] bootstd: Avoid depending on BLK
Simon Glass
sjg at chromium.org
Thu Nov 14 04:53:31 CET 2024
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?
>
> 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.
Regards,
Simon
[1]
10m50
3c120
CMPC885
CMPCPRO
M5208EVBE
M5235EVB_Flash32
M5235EVB
M5249EVB
M5272C3
M5275EVB
M5282EVB
M53017EVB
M5329AFEE
M5329BFEE
M5373EVB
MCR3000
MPC8548CDS_36BIT
MPC8548CDS
MPC8548CDS_legacy
SBx81LIFKW
SBx81LIFXCAT
amcore
amd_versal2_mini
amd_versal2_mini_ospi
amd_versal2_mini_qspi
ap121
ap143
ap152
astro_mcf5373l
axm
bcm968380gerg_ram
bcmns
boston32r2
boston32r2el
boston32r6
boston32r6el
boston64r2
boston64r2el
boston64r6
boston64r6el
cobra5272
cortina_presidio-asic-base
cortina_presidio-asic-pnand
crs305-1g-4s-bit
crs305-1g-4s
crs326-24g-2s-bit
crs326-24g-2s
crs328-4c-20s-4s-bit
crs328-4c-20s-4s
eb_cpu5282
eb_cpu5282_internal
efi-x86_app32
efi-x86_app64
evb-ast2500
gardena-smart-gateway-at91sam
gardena-smart-gateway-mt7688
gxp
ibex-ast2700
imgtec_xilfpga
integratorap_cm720t
integratorap_cm920t
integratorap_cm926ejs
integratorap_cm946es
integratorcp_cm1136
integratorcp_cm920t
integratorcp_cm926ejs
integratorcp_cm946es
inteno_xg6846_ram
kmcoge5ne
kmeter1
kmopti2
kmsupx5
kmtepr2
lschlv2
lsxhl
maxbcm
meesc_dataflash
meesc
microblaze-generic
mscc_jr2
mscc_luton
mscc_ocelot
mscc_serval
mscc_servalt
mt7620_mt7530_rfb
mt7628_rfb
mt7981_rfb
mt7986_rfb
mx6memcal
netgear_cg3100d_ram
nsim_700
nsim_700be
nsim_hs38be
pg_wcom_expu1
pg_wcom_expu1_update
pg_wcom_seli8
pg_wcom_seli8_update
r8a77970_eagle
rcar3_salvator-x
sagem_f at st1704_ram
sama5d29_curiosity_mmc1
sama5d29_curiosity_mmc
sama5d29_curiosity_qspiflash
sama7g54_curiosity_mmc
sama7g54_curiosity_nandflash
sama7g54_curiosity_qspiflash
smdkc100
smegw01
socfpga_is1
stm32f429-discovery
stm32mp25
stmark2
tb100
tbs2910
th1520_lpi4a
thunderx_88xx
tuge1
tuxx1
usb_a9263_dataflash
work_92105
xilinx_versal_mini
xilinx_versal_mini_ospi
xilinx_versal_mini_qspi
xilinx_versal_net_mini
xilinx_versal_net_mini_ospi
xilinx_versal_net_mini_qspi
xilinx_zynqmp_mini
xilinx_zynqmp_mini_nand
xilinx_zynqmp_mini_nand_single
xilinx_zynqmp_mini_qspi
xtfpga
zynq_cse_nand
zynq_cse_nor
zynq_cse_qspi
More information about the U-Boot
mailing list