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? > > 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@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
