U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Jagan Teki <jagan@amarulasolutions.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Quentin Schulz <quentin.schulz@cherry.de>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Marek Vasut <marek.vasut+renesas@mailbox.org>,
	Mattijs Korpershoek <mkorpershoek@baylibre.com>,
	Stefan Roese <sr@denx.de>
Subject: Re: [PATCH v5 1/8] bootstd: Avoid depending on BLK
Date: Wed, 13 Nov 2024 11:47:07 -0600	[thread overview]
Message-ID: <20241113174707.GR3600562@bill-the-cat> (raw)
In-Reply-To: <20241113150938.1534931-2-sjg@chromium.org>

[-- Attachment #1: Type: text/plain, Size: 4038 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2024-11-13 17:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-13 15:09 [PATCH v5 0/8] bootstd: sunxi: Migrate to standard boot Simon Glass
2024-11-13 15:09 ` [PATCH v5 1/8] bootstd: Avoid depending on BLK Simon Glass
2024-11-13 17:47   ` Tom Rini [this message]
2024-11-14  3:53     ` Simon Glass
2024-11-14 14:22       ` Tom Rini
2024-11-15 14:27         ` Simon Glass
2024-11-15 14:37           ` Tom Rini
2024-11-13 15:09 ` [PATCH v5 2/8] sunxi: Add a bootmeth for FEL Simon Glass
2024-11-13 15:09 ` [PATCH v5 3/8] efi_loader: bootstd: Drop bootmgr for sunxi Simon Glass
2024-11-13 17:50   ` Tom Rini
2024-11-15 14:21     ` Simon Glass
2024-11-23  2:08       ` Andre Przywara
2024-11-23  4:06         ` Heinrich Schuchardt
2024-11-23 13:07           ` Andre Przywara
2024-11-23 16:56             ` Ilias Apalodimas
2024-11-16  7:37   ` Heinrich Schuchardt
2024-11-13 15:09 ` [PATCH v5 4/8] RFC: Revert "bootstd: Make efi_mgr bootmeth work for non-sandbox setups" Simon Glass
2024-11-13 17:52   ` Tom Rini
2025-01-05  2:50   ` Heinrich Schuchardt
2025-01-09 15:01     ` Simon Glass
2025-01-09 15:04       ` Tom Rini
2025-01-09 15:11         ` Simon Glass
2025-01-09 15:22           ` Tom Rini
2025-01-10 13:41             ` Simon Glass
2025-01-10 17:05               ` Tom Rini
2025-01-15 13:22                 ` Simon Glass
2025-01-15 14:33                   ` Tom Rini
2024-11-13 15:09 ` [PATCH v5 5/8] sunxi: Move to bootstd Simon Glass
2024-11-13 15:09 ` [PATCH v5 6/8] sunxi: Drop old distro boot variables Simon Glass
2024-11-13 15:09 ` [PATCH v5 7/8] env: Provide a work-around for unquoting fdtfile Simon Glass
2024-11-13 17:53   ` Tom Rini
2025-03-10 22:26   ` Tom Rini
2024-11-13 15:09 ` [PATCH v5 8/8] sunxi: Move to text environment Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241113174707.GR3600562@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=andre.przywara@arm.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jagan@amarulasolutions.com \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=mkorpershoek@baylibre.com \
    --cc=quentin.schulz@cherry.de \
    --cc=sjg@chromium.org \
    --cc=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox