[PATCH v5 0/8] bootstd: sunxi: Migrate to standard boot
This series attempts to migrate all sunxi boards to use standard boot, along with a text environment.
Unfortunately a late-breaking problem has come up with bootmgr. There are two ways to fix this, both included in this series:
- Drop bootmgr for sunxi - Change efi_mgr bootmeth back to sandbox-only
Based on the mailing-list discussion I have selected the first one and marked the second as RFC.
Changes in v5: - Add new patch to drop bootmgr for sunxi
Changes in v4: - Reword Kconfig - Add a name for the bootflow - Drop UUID_GPT_SYSTEM and UUID_GPT_ESP definitions - Drop special case for ARM64's devicetree subdir - Drop unwanted quotations and indentation in KERNEL_COMPAT path
Changes in v3: - Drop wip (work-in-progress) comment in commit - Fix 'supressed' typo - Use backquotes to highlight DEFAULT_DEVICE_TREE
Changes in v2: - Add new patch to resolve BOOTSTD->BLK recursion with Kconfig - Put the FEL bootmeth before all other global bootmeths - Convert the other DISTRO_DEFAULTS in the Kconfig too - Keep BOOTCMD_SUNXI_COMPAT - Keep bootcmd_sunxi_compat if OLD_SUNXI_KERNEL_COMPAT is enabled
Simon Glass (8): bootstd: Avoid depending on BLK sunxi: Add a bootmeth for FEL efi_loader: bootstd: Drop bootmgr for sunxi RFC: Revert "bootstd: Make efi_mgr bootmeth work for non-sandbox setups" sunxi: Move to bootstd sunxi: Drop old distro boot variables env: Provide a work-around for unquoting fdtfile sunxi: Move to text environment
Makefile | 1 + arch/arm/Kconfig | 10 +- board/sunxi/sunxi.env | 140 +++++++++++ boot/Kconfig | 18 +- boot/Makefile | 1 + boot/bootmeth_efi_mgr.c | 18 +- boot/bootmeth_fel.c | 84 +++++++ .../gardena-smart-gateway-mt7688_defconfig | 1 + doc/usage/environment.rst | 12 + include/configs/sunxi-common.h | 238 ------------------ 10 files changed, 261 insertions(+), 262 deletions(-) create mode 100644 board/sunxi/sunxi.env create mode 100644 boot/bootmeth_fel.c
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 diff --git a/configs/gardena-smart-gateway-mt7688_defconfig b/configs/gardena-smart-gateway-mt7688_defconfig index b7f4a76ce68..85f42a3ab6d 100644 --- a/configs/gardena-smart-gateway-mt7688_defconfig +++ b/configs/gardena-smart-gateway-mt7688_defconfig @@ -30,6 +30,7 @@ CONFIG_HAS_BOARD_SIZE_LIMIT=y CONFIG_BOARD_SIZE_LIMIT=655360 CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +# CONFIG_BOOTSTD is not set CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_AUTOBOOT_KEYED=y CONFIG_AUTOBOOT_STOP_STR="x"
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.
Hi Tom,
On Wed, 13 Nov 2024 at 10:47, Tom Rini trini@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@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 suchThis 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
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@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@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 suchThis 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?
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.
Hi Tom,
On Thu, 14 Nov 2024 at 07:22, Tom Rini trini@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@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@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 suchThis 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...
On Fri, Nov 15, 2024 at 07:27:19AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 14 Nov 2024 at 07:22, Tom Rini trini@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@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@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 suchThis 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'.
The challenge here is that when working with "default y" symbols, you need to exercise a lot more care. I'm sending out later today a series that also addresses the problems this patch exposed.
Add support for booting from a script loaded over FEL. This mirrors the bootcmd_fel provided by distro boot.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com ---
(no changes since v4)
Changes in v4: - Reword Kconfig - Add a name for the bootflow
Changes in v2: - Put the FEL bootmeth before all other global bootmeths
boot/Kconfig | 14 ++++++++ boot/Makefile | 1 + boot/bootmeth_fel.c | 84 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 99 insertions(+) create mode 100644 boot/bootmeth_fel.c
diff --git a/boot/Kconfig b/boot/Kconfig index b5433e88f10..b612360ca55 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -589,6 +589,20 @@ config BOOTMETH_EFI_BOOTMGR the EFI binary to be launched is determined. To set the EFI variables use the eficonfig command.
+config BOOTMETH_FEL + bool "Bootdev support for Sunxi FEL" + depends on ARCH_SUNXI + default y + help + Enables support for executing an explicit boot script uploaded before + via the USB FEL protocol. The 'fel_scriptaddr' environment variable + holds the address of this script, taken from the SPL header. + + This method is only available if booting from FEL, i.e. the + 'fel_booted' environment variable is set. + + See https://linux-sunxi.org/FEL/Protocol for more information. + config BOOTMETH_QFW bool "Boot method using QEMU parameters" depends on QFW diff --git a/boot/Makefile b/boot/Makefile index 43def7c33d7..b03d628187b 100644 --- a/boot/Makefile +++ b/boot/Makefile @@ -31,6 +31,7 @@ obj-$(CONFIG_$(PHASE_)BOOTMETH_EXTLINUX) += bootmeth_extlinux.o obj-$(CONFIG_$(PHASE_)BOOTMETH_EXTLINUX_PXE) += bootmeth_pxe.o obj-$(CONFIG_$(PHASE_)BOOTMETH_EFILOADER) += bootmeth_efi.o obj-$(CONFIG_$(PHASE_)BOOTMETH_CROS) += bootm.o bootm_os.o bootmeth_cros.o +obj-$(CONFIG_$(PHASE_)BOOTMETH_FEL) += bootmeth_fel.o obj-$(CONFIG_$(PHASE_)BOOTMETH_QFW) += bootmeth_qfw.o obj-$(CONFIG_$(PHASE_)BOOTMETH_SANDBOX) += bootmeth_sandbox.o obj-$(CONFIG_$(PHASE_)BOOTMETH_SCRIPT) += bootmeth_script.o diff --git a/boot/bootmeth_fel.c b/boot/bootmeth_fel.c new file mode 100644 index 00000000000..61332d5a3b4 --- /dev/null +++ b/boot/bootmeth_fel.c @@ -0,0 +1,84 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Bootmethod for sunxi FEL loading + * + * Copyright 2024 Google LLC + * Written by Simon Glass sjg@chromium.org + */ + +#define LOG_CATEGORY UCLASS_BOOTSTD + +#include <bootdev.h> +#include <bootflow.h> +#include <bootmeth.h> +#include <command.h> +#include <dm.h> +#include <env.h> + +static int fel_check(struct udevice *dev, struct bootflow_iter *iter) +{ + return 0; +} + +static int fel_read_bootflow(struct udevice *dev, struct bootflow *bflow) +{ + if (!env_get("fel_booted") || !env_get("fel_scriptaddr")) + return -ENOENT; + + bflow->name = strdup("fel-script"); + if (!bflow->name) + return log_msg_ret("fel", -ENOMEM); + bflow->state = BOOTFLOWST_READY; + + return 0; +} + +static int fel_read_file(struct udevice *dev, struct bootflow *bflow, + const char *file_path, ulong addr, ulong *sizep) +{ + return -ENOSYS; +} + +static int fel_boot(struct udevice *dev, struct bootflow *bflow) +{ + ulong addr; + int ret; + + addr = env_get_hex("fel_scriptaddr", 0); + ret = cmd_source_script(addr, NULL, NULL); + if (ret) + return log_msg_ret("boot", ret); + + return 0; +} + +static int fel_bootmeth_bind(struct udevice *dev) +{ + struct bootmeth_uc_plat *plat = dev_get_uclass_plat(dev); + + plat->desc = IS_ENABLED(CONFIG_BOOTSTD_FULL) ? + "Sunxi FEL boot over USB" : "FEL"; + plat->flags = BOOTMETHF_GLOBAL; + + return 0; +} + +static struct bootmeth_ops fel_bootmeth_ops = { + .check = fel_check, + .read_bootflow = fel_read_bootflow, + .read_file = fel_read_file, + .boot = fel_boot, +}; + +static const struct udevice_id fel_bootmeth_ids[] = { + { .compatible = "u-boot,fel-bootmeth" }, + { } +}; + +U_BOOT_DRIVER(bootmeth_2fel) = { + .name = "bootmeth_fel", + .id = UCLASS_BOOTMETH, + .of_match = fel_bootmeth_ids, + .ops = &fel_bootmeth_ops, + .bind = fel_bootmeth_bind, +};
This causes problems with the boot order, so drop it until we can figure out a better way to know when bootmgr should be used.
Link: https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.a...
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v5: - Add new patch to drop bootmgr for sunxi
boot/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/Kconfig b/boot/Kconfig index b612360ca55..42c5ed288c5 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -583,7 +583,7 @@ config BOOTMETH_EFI_BOOTMGR bool "Bootdev support for EFI boot manager" depends on EFI_BOOTMGR select BOOTMETH_GLOBAL - default y + default y if !ARCH_SUNXI # Temporary work-around for sunxi help Enable booting via the UEFI boot manager. Based on the EFI variables the EFI binary to be launched is determined. To set the EFI variables
On Wed, Nov 13, 2024 at 08:09:33AM -0700, Simon Glass wrote:
This causes problems with the boot order, so drop it until we can figure out a better way to know when bootmgr should be used.
Link: https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.a...
Signed-off-by: Simon Glass sjg@chromium.org
I would really prefer a short summary of the contents of the link in the commit message. I'm not NAK'ing the patch as-is, but it would be helpful when revisiting this if there was a short explanation of the problem to solve here and not just "problems with the boot order". Thanks.
Hi Tom,
On Wed, 13 Nov 2024 at 10:50, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 13, 2024 at 08:09:33AM -0700, Simon Glass wrote:
This causes problems with the boot order, so drop it until we can figure out a better way to know when bootmgr should be used.
Link: https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.a...
Signed-off-by: Simon Glass sjg@chromium.org
I would really prefer a short summary of the contents of the link in the commit message. I'm not NAK'ing the patch as-is, but it would be helpful when revisiting this if there was a short explanation of the problem to solve here and not just "problems with the boot order". Thanks.
The summary is that sunxi supports FEL (USB boot) but bootmgr is not aware of it, so boots the OS instead.
Regards, Simon
On Fri, 15 Nov 2024 07:21:53 -0700 Simon Glass sjg@chromium.org wrote:
Hi Simon, Tom, Heinrich,
sorry for the delay, I was away.
On Wed, 13 Nov 2024 at 10:50, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 13, 2024 at 08:09:33AM -0700, Simon Glass wrote:
This causes problems with the boot order, so drop it until we can figure out a better way to know when bootmgr should be used.
Link: https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.a...
Signed-off-by: Simon Glass sjg@chromium.org
I would really prefer a short summary of the contents of the link in the commit message. I'm not NAK'ing the patch as-is, but it would be helpful when revisiting this if there was a short explanation of the problem to solve here and not just "problems with the boot order". Thanks.
The summary is that sunxi supports FEL (USB boot) but bootmgr is not aware of it, so boots the OS instead.
So that's not the problem: FEL is working fine, since it's marked as global, same as efi_bootmgr, but with a lower order number. The problem is that the higher priority non-global methods (scripts) are "ignored".
So this is the list without this patch: Order Seq Name Description ----- --- ------------------ ------------------ 0 0 extlinux extlinux glob 1 fel FEL 2 2 script script glob 3 efi_mgr EFI bootmgr flow 4 4 efi EFI 5 5 pxe PXE glob 6 vbe_simple vbe-simple ----- --- ------------------ ------------------
The sequence looks roughly alright, only that it's not the actual order, since "glob" takes precedence. So the actual order is: fel -> efi_mgr -> vbe_simple -> extlinux -> script -> efi -> pxe And that puts efi_mgr before extlinux and script, which is not what we want, because efi_mgr finds bootaa64.efi *somewhere* (eMMC or SD card or USB stick) and uses that, even when there is a tailored boot.scr or extlinux.conf on the *boot media* which should be higher priority. "fel" being first is fine, since it's *only* triggered if someone deliberately uploaded a boot script via USB: in this case they surely want to execute exactly that.
So I think the underlying problem is the "glob" tag for efi_mgr PLUS the fact that it scans all media for bootaa64.efi files. I think it would be fine if efi_mgr would just consider EFI boot order variables, and would ignore any "removable media" default files (bootaa64.efi). The "efi" bootmeth does the scanning as well, and it's fine there, since it's lower priority, so we can still boot EFI systems.
I guess it would make sense if an installer on an USB stick should boot even if there is something on the eMMC, for instance. But we want to control that, and we can't, because the order is ignored due to the "glob" flag.
So while I agree that disabling efi_bootmgr sounds like a hack, it solves the problem quite elegantly: We keep the (current) boot order, which prioritises scripts over EFI, but still retain EFI. If people want EFI first, they can change the order in the environment (I think?).
Without that patch there is quite a regression for users, because suddenly any bootaa64.efi files *somewhere* would be booted first, and there is no way to turn that off.
This has bitten me actually: for development I put a custom boot.scr on an SD card which loads a kernel+DTB via TFTP from my box. And I want that to be first, despite there being a proper EFI setup on the eMMC or USB drive.
So I hope that clears that up. I am not a big fan of that patch, but I would like sunxi to be converted, and Simon seemed to be eager to do this as well, so in the interest of not blocking this, I am fine with that.
Cheers, Andre
Am 23. November 2024 03:08:02 MEZ schrieb Andre Przywara andre.przywara@arm.com:
On Fri, 15 Nov 2024 07:21:53 -0700 Simon Glass sjg@chromium.org wrote:
Hi Simon, Tom, Heinrich,
sorry for the delay, I was away.
On Wed, 13 Nov 2024 at 10:50, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 13, 2024 at 08:09:33AM -0700, Simon Glass wrote:
This causes problems with the boot order, so drop it until we can figure out a better way to know when bootmgr should be used.
Link: https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.a...
Signed-off-by: Simon Glass sjg@chromium.org
I would really prefer a short summary of the contents of the link in the commit message. I'm not NAK'ing the patch as-is, but it would be helpful when revisiting this if there was a short explanation of the problem to solve here and not just "problems with the boot order". Thanks.
The summary is that sunxi supports FEL (USB boot) but bootmgr is not aware of it, so boots the OS instead.
So that's not the problem: FEL is working fine, since it's marked as global, same as efi_bootmgr, but with a lower order number. The problem is that the higher priority non-global methods (scripts) are "ignored".
So this is the list without this patch: Order Seq Name Description
0 0 extlinux extlinux glob 1 fel FEL 2 2 script script glob 3 efi_mgr EFI bootmgr flow 4 4 efi EFI 5 5 pxe PXE glob 6 vbe_simple vbe-simple
The sequence looks roughly alright, only that it's not the actual order, since "glob" takes precedence. So the actual order is: fel -> efi_mgr -> vbe_simple -> extlinux -> script -> efi -> pxe And that puts efi_mgr before extlinux and script, which is not what we want, because efi_mgr finds bootaa64.efi *somewhere* (eMMC or SD card or USB stick) and uses that, even when there is a tailored boot.scr or extlinux.conf on the *boot media* which should be higher priority. "fel" being first is fine, since it's *only* triggered if someone deliberately uploaded a boot script via USB: in this case they surely want to execute exactly that.
So I think the underlying problem is the "glob" tag for efi_mgr PLUS the fact that it scans all media for bootaa64.efi files. I think it would be fine if efi_mgr would just consider EFI boot order variables, and would ignore any "removable media" default files (bootaa64.efi). The "efi" bootmeth does the scanning as well, and it's fine there, since it's lower priority, so we can still boot EFI systems.
I guess it would make sense if an installer on an USB stick should boot even if there is something on the eMMC, for instance. But we want to control that, and we can't, because the order is ignored due to the "glob" flag.
So while I agree that disabling efi_bootmgr sounds like a hack, it solves the problem quite elegantly: We keep the (current) boot order, which prioritises scripts over EFI, but still retain EFI. If people want EFI first, they can change the order in the environment (I think?).
Without that patch there is quite a regression for users, because suddenly any bootaa64.efi files *somewhere* would be booted first, and there is no way to turn that off.
This has bitten me actually: for development I put a custom boot.scr on an SD card which loads a kernel+DTB via TFTP from my box. And I want that to be first, despite there being a proper EFI setup on the eMMC or USB drive.
So I hope that clears that up. I am not a big fan of that patch, but I would like sunxi to be converted, and Simon seemed to be eager to do this as well, so in the interest of not blocking this, I am fine with that.
Disabling EFI will break booting for users that rely on it (like me).
Cheers, Andre
Yes, the introduction of boot standard changed the boot order and specifically deprioritizing scripts is unexpected.
The priority sequence used to be
scripts extlinux efi pxe
bootmeth_efimgr always running before scripts be fixed. bootmeth_efi should be removed from the code base as redundant.
Best regards
Heinrich
On Sat, 23 Nov 2024 05:06:49 +0100 Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Hi,
Am 23. November 2024 03:08:02 MEZ schrieb Andre Przywara andre.przywara@arm.com:
On Fri, 15 Nov 2024 07:21:53 -0700 Simon Glass sjg@chromium.org wrote:
Hi Simon, Tom, Heinrich,
sorry for the delay, I was away.
On Wed, 13 Nov 2024 at 10:50, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 13, 2024 at 08:09:33AM -0700, Simon Glass wrote:
This causes problems with the boot order, so drop it until we can figure out a better way to know when bootmgr should be used.
Link: https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.a...
Signed-off-by: Simon Glass sjg@chromium.org
I would really prefer a short summary of the contents of the link in the commit message. I'm not NAK'ing the patch as-is, but it would be helpful when revisiting this if there was a short explanation of the problem to solve here and not just "problems with the boot order". Thanks.
The summary is that sunxi supports FEL (USB boot) but bootmgr is not aware of it, so boots the OS instead.
So that's not the problem: FEL is working fine, since it's marked as global, same as efi_bootmgr, but with a lower order number. The problem is that the higher priority non-global methods (scripts) are "ignored".
So this is the list without this patch: Order Seq Name Description
0 0 extlinux extlinux glob 1 fel FEL 2 2 script script glob 3 efi_mgr EFI bootmgr flow 4 4 efi EFI 5 5 pxe PXE glob 6 vbe_simple vbe-simple
The sequence looks roughly alright, only that it's not the actual order, since "glob" takes precedence. So the actual order is: fel -> efi_mgr -> vbe_simple -> extlinux -> script -> efi -> pxe And that puts efi_mgr before extlinux and script, which is not what we want, because efi_mgr finds bootaa64.efi *somewhere* (eMMC or SD card or USB stick) and uses that, even when there is a tailored boot.scr or extlinux.conf on the *boot media* which should be higher priority. "fel" being first is fine, since it's *only* triggered if someone deliberately uploaded a boot script via USB: in this case they surely want to execute exactly that.
So I think the underlying problem is the "glob" tag for efi_mgr PLUS the fact that it scans all media for bootaa64.efi files. I think it would be fine if efi_mgr would just consider EFI boot order variables, and would ignore any "removable media" default files (bootaa64.efi). The "efi" bootmeth does the scanning as well, and it's fine there, since it's lower priority, so we can still boot EFI systems.
I guess it would make sense if an installer on an USB stick should boot even if there is something on the eMMC, for instance. But we want to control that, and we can't, because the order is ignored due to the "glob" flag.
So while I agree that disabling efi_bootmgr sounds like a hack, it solves the problem quite elegantly: We keep the (current) boot order, which prioritises scripts over EFI, but still retain EFI. If people want EFI first, they can change the order in the environment (I think?).
Without that patch there is quite a regression for users, because suddenly any bootaa64.efi files *somewhere* would be booted first, and there is no way to turn that off.
This has bitten me actually: for development I put a custom boot.scr on an SD card which loads a kernel+DTB via TFTP from my box. And I want that to be first, despite there being a proper EFI setup on the eMMC or USB drive.
So I hope that clears that up. I am not a big fan of that patch, but I would like sunxi to be converted, and Simon seemed to be eager to do this as well, so in the interest of not blocking this, I am fine with that.
Disabling EFI will break booting for users that rely on it (like me).
So are you using the UEFI BootOrder variables? How do you set them? Manually on the U-Boot shell, or via some Linux tool manipulating the U-Boot environment file? IIUC those are the only two methods that work for sunxi, since the UEFI variable runtime services are not implemented.
In reality I am using UEFI booting as well, but entirely rely on bootaa64.efi, hence bootmeth_efi is totally sufficient for me.
Yes, the introduction of boot standard changed the boot order and specifically deprioritizing scripts is unexpected.
The priority sequence used to be
scripts extlinux efi pxe
bootmeth_efimgr always running before scripts be fixed.
I agree, but with bootmeth_efimgr marked as global this is not gonna work easily, at least that's my understanding.
bootmeth_efi should be removed from the code base as redundant.
I wonder if a solution is to split this up: bootmeth_efimgr is only looking at variables - then "glob" would be correct. Then people can place bootmeth_efi at the position they want, either before the scripts (allowing USB boot) or after. I think this would also solve the case where bootaa64.efi is both on an eMMC and an SD card, as it would pick the boot media first.
A lot of sunxi use cases are embedded, and people mostly don't want to boot from USB on for instance their TV box, just because the stick with the movies and some bootaa64.efi was still in the slot when they turned the box on. Even more so for truly embedded devices. And that's also the default setting for PCs, I think, where USB booting would need to be explicitly enabled in the BIOS.
Cheers, Andre
Hi Andre,
[...]
So while I agree that disabling efi_bootmgr sounds like a hack, it solves the problem quite elegantly: We keep the (current) boot order, which prioritises scripts over EFI, but still retain EFI. If people want EFI first, they can change the order in the environment (I think?).
Without that patch there is quite a regression for users, because suddenly any bootaa64.efi files *somewhere* would be booted first, and there is no way to turn that off.
This has bitten me actually: for development I put a custom boot.scr on an SD card which loads a kernel+DTB via TFTP from my box. And I want that to be first, despite there being a proper EFI setup on the eMMC or USB drive.
So I hope that clears that up. I am not a big fan of that patch, but I would like sunxi to be converted, and Simon seemed to be eager to do this as well, so in the interest of not blocking this, I am fine with that.
Disabling EFI will break booting for users that rely on it (like me).
So are you using the UEFI BootOrder variables? How do you set them? Manually on the U-Boot shell, or via some Linux tool manipulating the U-Boot environment file? IIUC those are the only two methods that work for sunxi, since the UEFI variable runtime services are not implemented.
I haven't followed the rest of the thread but EFI runtime does work since commit 00da8d65a3ba. Yes for now you have to manually dd the file on updates, but this is supposed to be solved by [0]
In reality I am using UEFI booting as well, but entirely rely on bootaa64.efi, hence bootmeth_efi is totally sufficient for me.
Yes, the introduction of boot standard changed the boot order and specifically deprioritizing scripts is unexpected.
The priority sequence used to be
scripts extlinux efi pxe
bootmeth_efimgr always running before scripts be fixed.
I agree, but with bootmeth_efimgr marked as global this is not gonna work easily, at least that's my understanding.
bootmeth_efi should be removed from the code base as redundant.
I wonder if a solution is to split this up: bootmeth_efimgr is only looking at variables - then "glob" would be correct. Then people can place bootmeth_efi at the position they want, either before the scripts (allowing USB boot) or after. I think this would also solve the case where bootaa64.efi is both on an eMMC and an SD card, as it would pick the boot media first.
A lot of sunxi use cases are embedded, and people mostly don't want to boot from USB on for instance their TV box, just because the stick with the movies and some bootaa64.efi was still in the slot when they turned the box on. Even more so for truly embedded devices. And that's also the default setting for PCs, I think, where USB booting would need to be explicitly enabled in the BIOS.
Cheers, Andre
[0] https://github.com/rhboot/efivar/pull/267
Cheers /Ilias
Am 13. November 2024 16:09:33 MEZ schrieb Simon Glass sjg@chromium.org:
This causes problems with the boot order, so drop it until we can figure out a better way to know when bootmgr should be used.
It dhould be used by default.
Please, describe your observations in sufficient detail.
I don't think that we should break EFI booting on sunxi boards. Please, mark the series as RFC, if it is not working properly.
Best regards
Heinrich
Link: https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.a...
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v5:
- Add new patch to drop bootmgr for sunxi
boot/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/Kconfig b/boot/Kconfig index b612360ca55..42c5ed288c5 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -583,7 +583,7 @@ config BOOTMETH_EFI_BOOTMGR bool "Bootdev support for EFI boot manager" depends on EFI_BOOTMGR select BOOTMETH_GLOBAL
- default y
- default y if !ARCH_SUNXI # Temporary work-around for sunxi help Enable booting via the UEFI boot manager. Based on the EFI variables the EFI binary to be launched is determined. To set the EFI variables
This is another option to fix sunxi booting with bootstd, which may be better since it will work for all boards. We can then figure out how to automatically and deterministicaly decide when bootmgr should be used.
This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7.
Signed-off-by: Simon Glass sjg@chromium.org --- If this patch is applied, we don't need to drop bootmgr for sunxi
(no changes since v1)
boot/bootmeth_efi_mgr.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c index 23ae1e610ac..095fa74fc60 100644 --- a/boot/bootmeth_efi_mgr.c +++ b/boot/bootmeth_efi_mgr.c @@ -14,8 +14,6 @@ #include <command.h> #include <dm.h> #include <efi_loader.h> -#include <efi_variable.h> -#include <malloc.h>
/** * struct efi_mgr_priv - private info for the efi-mgr driver @@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct efi_mgr_priv *priv = dev_get_priv(dev); - efi_status_t ret; - efi_uintn_t size; - u16 *bootorder;
if (priv->fake_dev) { bflow->state = BOOTFLOWST_READY; return 0; }
- ret = efi_init_obj_list(); - if (ret) - return log_msg_ret("init", ret); - - /* Enable this method if the "BootOrder" UEFI exists. */ - bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid, - &size); - if (bootorder) { - free(bootorder); - bflow->state = BOOTFLOWST_READY; - return 0; - } + /* To be implemented */
return -EINVAL; }
On Wed, Nov 13, 2024 at 08:09:34AM -0700, Simon Glass wrote:
This is another option to fix sunxi booting with bootstd, which may be better since it will work for all boards. We can then figure out how to automatically and deterministicaly decide when bootmgr should be used.
This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7.
Signed-off-by: Simon Glass sjg@chromium.org
If this patch is applied, we don't need to drop bootmgr for sunxi
(no changes since v1)
boot/bootmeth_efi_mgr.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-)
This seems like the wrong direction to go since one of the common cases should be "Do we just want to fire off the EFI boot manager? Yes" since lots of "off the shelf" operating systems want to treat ARM just like x86 and not have to special-case things.
On 11/13/24 16:09, Simon Glass wrote:
This is another option to fix sunxi booting with bootstd, which may be better since it will work for all boards. We can then figure out how to automatically and deterministicaly decide when bootmgr should be used.
This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7.
Signed-off-by: Simon Glass sjg@chromium.org
If this patch is applied, we don't need to drop bootmgr for sunxi
(no changes since v1)
boot/bootmeth_efi_mgr.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c index 23ae1e610ac..095fa74fc60 100644 --- a/boot/bootmeth_efi_mgr.c +++ b/boot/bootmeth_efi_mgr.c @@ -14,8 +14,6 @@ #include <command.h> #include <dm.h> #include <efi_loader.h> -#include <efi_variable.h> -#include <malloc.h>
/**
- struct efi_mgr_priv - private info for the efi-mgr driver
@@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct efi_mgr_priv *priv = dev_get_priv(dev);
efi_status_t ret;
efi_uintn_t size;
u16 *bootorder;
if (priv->fake_dev) { bflow->state = BOOTFLOWST_READY; return 0; }
ret = efi_init_obj_list();
if (ret)
return log_msg_ret("init", ret);/* Enable this method if the "BootOrder" UEFI exists. */
bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid,
&size);if (bootorder) {
free(bootorder);bflow->state = BOOTFLOWST_READY;return 0;}
- /* To be implemented */
The EFI boot manager can boot based on:
* variable BootOrder * variable BootNext * an existing file EFI/BOOT/BOOT<arch>.EFI
It obsoletes bootsmeth_efi.
return -EINVAL;
We must always run the EFI boot manager if it is enabled. So -EINVAL is wrong here.
Best regards
Heinrich
Hi Heinrich,
On Sat, 4 Jan 2025 at 19:50, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/13/24 16:09, Simon Glass wrote:
This is another option to fix sunxi booting with bootstd, which may be better since it will work for all boards. We can then figure out how to automatically and deterministicaly decide when bootmgr should be used.
This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7.
Signed-off-by: Simon Glass sjg@chromium.org
If this patch is applied, we don't need to drop bootmgr for sunxi
(no changes since v1)
boot/bootmeth_efi_mgr.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-)avilable
diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c index 23ae1e610ac..095fa74fc60 100644 --- a/boot/bootmeth_efi_mgr.c +++ b/boot/bootmeth_efi_mgr.c @@ -14,8 +14,6 @@ #include <command.h> #include <dm.h> #include <efi_loader.h> -#include <efi_variable.h> -#include <malloc.h>
/**
- struct efi_mgr_priv - private info for the efi-mgr driver
@@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct efi_mgr_priv *priv = dev_get_priv(dev);
efi_status_t ret;efi_uintn_t size;u16 *bootorder; if (priv->fake_dev) { bflow->state = BOOTFLOWST_READY; return 0; }ret = efi_init_obj_list();if (ret)return log_msg_ret("init", ret);/* Enable this method if the "BootOrder" UEFI exists. */bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid,&size);if (bootorder) {free(bootorder);bflow->state = BOOTFLOWST_READY;return 0;}
/* To be implemented */The EFI boot manager can boot based on:
- variable BootOrder
- variable BootNext
- an existing file EFI/BOOT/BOOT<arch>.EFI
It obsoletes bootsmeth_efi.
return -EINVAL;We must always run the EFI boot manager if it is enabled. So -EINVAL is wrong here.
Well, I don't believe you have a solution, then.
You did suggest putting bootmgr later, as we discussed on irc.
For now, I think we should apply this patch (and series), while we sort out how to make bootmgr more incremental. It should not be scanning every available device before it starts, since that can be very slow.
Regards, Simon
On Thu, Jan 09, 2025 at 08:01:13AM -0700, Simon Glass wrote:
Hi Heinrich,
On Sat, 4 Jan 2025 at 19:50, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/13/24 16:09, Simon Glass wrote:
This is another option to fix sunxi booting with bootstd, which may be better since it will work for all boards. We can then figure out how to automatically and deterministicaly decide when bootmgr should be used.
This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7.
Signed-off-by: Simon Glass sjg@chromium.org
If this patch is applied, we don't need to drop bootmgr for sunxi
(no changes since v1)
boot/bootmeth_efi_mgr.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-)avilable
diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c index 23ae1e610ac..095fa74fc60 100644 --- a/boot/bootmeth_efi_mgr.c +++ b/boot/bootmeth_efi_mgr.c @@ -14,8 +14,6 @@ #include <command.h> #include <dm.h> #include <efi_loader.h> -#include <efi_variable.h> -#include <malloc.h>
/**
- struct efi_mgr_priv - private info for the efi-mgr driver
@@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct efi_mgr_priv *priv = dev_get_priv(dev);
efi_status_t ret;efi_uintn_t size;u16 *bootorder; if (priv->fake_dev) { bflow->state = BOOTFLOWST_READY; return 0; }ret = efi_init_obj_list();if (ret)return log_msg_ret("init", ret);/* Enable this method if the "BootOrder" UEFI exists. */bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid,&size);if (bootorder) {free(bootorder);bflow->state = BOOTFLOWST_READY;return 0;}
/* To be implemented */The EFI boot manager can boot based on:
- variable BootOrder
- variable BootNext
- an existing file EFI/BOOT/BOOT<arch>.EFI
It obsoletes bootsmeth_efi.
return -EINVAL;We must always run the EFI boot manager if it is enabled. So -EINVAL is wrong here.
Well, I don't believe you have a solution, then.
You did suggest putting bootmgr later, as we discussed on irc.
For now, I think we should apply this patch (and series), while we sort out how to make bootmgr more incremental. It should not be scanning every available device before it starts, since that can be very slow.
Heinrich and I talked the other day, and we think the right path is the "later" path, where we don't try and use efi bootmanager until everything has been probed, and also drop the single "efi" option. This should mean that by the time we would be trying efi bootmanager most if not everything that needs to be probed has been probed. It doesn't make any sense to have "efi bootmanger" be more incremental as conceptually it's point is to show the user all the options.
Hi Tom,
On Thu, 9 Jan 2025 at 08:05, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:01:13AM -0700, Simon Glass wrote:
Hi Heinrich,
On Sat, 4 Jan 2025 at 19:50, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/13/24 16:09, Simon Glass wrote:
This is another option to fix sunxi booting with bootstd, which may be better since it will work for all boards. We can then figure out how to automatically and deterministicaly decide when bootmgr should be used.
This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7.
Signed-off-by: Simon Glass sjg@chromium.org
If this patch is applied, we don't need to drop bootmgr for sunxi
(no changes since v1)
boot/bootmeth_efi_mgr.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-)avilable
diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c index 23ae1e610ac..095fa74fc60 100644 --- a/boot/bootmeth_efi_mgr.c +++ b/boot/bootmeth_efi_mgr.c @@ -14,8 +14,6 @@ #include <command.h> #include <dm.h> #include <efi_loader.h> -#include <efi_variable.h> -#include <malloc.h>
/**
- struct efi_mgr_priv - private info for the efi-mgr driver
@@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct efi_mgr_priv *priv = dev_get_priv(dev);
efi_status_t ret;efi_uintn_t size;u16 *bootorder; if (priv->fake_dev) { bflow->state = BOOTFLOWST_READY; return 0; }ret = efi_init_obj_list();if (ret)return log_msg_ret("init", ret);/* Enable this method if the "BootOrder" UEFI exists. */bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid,&size);if (bootorder) {free(bootorder);bflow->state = BOOTFLOWST_READY;return 0;}
/* To be implemented */The EFI boot manager can boot based on:
- variable BootOrder
- variable BootNext
- an existing file EFI/BOOT/BOOT<arch>.EFI
It obsoletes bootsmeth_efi.
return -EINVAL;We must always run the EFI boot manager if it is enabled. So -EINVAL is wrong here.
Well, I don't believe you have a solution, then.
You did suggest putting bootmgr later, as we discussed on irc.
For now, I think we should apply this patch (and series), while we sort out how to make bootmgr more incremental. It should not be scanning every available device before it starts, since that can be very slow.
Heinrich and I talked the other day, and we think the right path is the "later" path, where we don't try and use efi bootmanager until everything has been probed, and also drop the single "efi" option. This should mean that by the time we would be trying efi bootmanager most if not everything that needs to be probed has been probed. It doesn't make any sense to have "efi bootmanger" be more incremental as conceptually it's point is to show the user all the options.
What is the single 'efi' option? I hope you don't mean the EFI bootmeth.
Putting bootmanager at the very end is OK with me, if we really cannot figure out a way to know whether the system is using it or now. It is 'putting it in the middle' that I don't like.
How to handle the case where bootorder only specifies a subset of options? Ideally we would just probe devices related to that subset. That is what I was getting at.
Regards, Simon
On Thu, Jan 09, 2025 at 08:11:58AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 9 Jan 2025 at 08:05, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:01:13AM -0700, Simon Glass wrote:
Hi Heinrich,
On Sat, 4 Jan 2025 at 19:50, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/13/24 16:09, Simon Glass wrote:
This is another option to fix sunxi booting with bootstd, which may be better since it will work for all boards. We can then figure out how to automatically and deterministicaly decide when bootmgr should be used.
This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7.
Signed-off-by: Simon Glass sjg@chromium.org
If this patch is applied, we don't need to drop bootmgr for sunxi
(no changes since v1)
boot/bootmeth_efi_mgr.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-)avilable
diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c index 23ae1e610ac..095fa74fc60 100644 --- a/boot/bootmeth_efi_mgr.c +++ b/boot/bootmeth_efi_mgr.c @@ -14,8 +14,6 @@ #include <command.h> #include <dm.h> #include <efi_loader.h> -#include <efi_variable.h> -#include <malloc.h>
/**
- struct efi_mgr_priv - private info for the efi-mgr driver
@@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct efi_mgr_priv *priv = dev_get_priv(dev);
efi_status_t ret;efi_uintn_t size;u16 *bootorder; if (priv->fake_dev) { bflow->state = BOOTFLOWST_READY; return 0; }ret = efi_init_obj_list();if (ret)return log_msg_ret("init", ret);/* Enable this method if the "BootOrder" UEFI exists. */bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid,&size);if (bootorder) {free(bootorder);bflow->state = BOOTFLOWST_READY;return 0;}
/* To be implemented */The EFI boot manager can boot based on:
- variable BootOrder
- variable BootNext
- an existing file EFI/BOOT/BOOT<arch>.EFI
It obsoletes bootsmeth_efi.
return -EINVAL;We must always run the EFI boot manager if it is enabled. So -EINVAL is wrong here.
Well, I don't believe you have a solution, then.
You did suggest putting bootmgr later, as we discussed on irc.
For now, I think we should apply this patch (and series), while we sort out how to make bootmgr more incremental. It should not be scanning every available device before it starts, since that can be very slow.
Heinrich and I talked the other day, and we think the right path is the "later" path, where we don't try and use efi bootmanager until everything has been probed, and also drop the single "efi" option. This should mean that by the time we would be trying efi bootmanager most if not everything that needs to be probed has been probed. It doesn't make any sense to have "efi bootmanger" be more incremental as conceptually it's point is to show the user all the options.
What is the single 'efi' option? I hope you don't mean the EFI bootmeth.
Yes, the single EFI bootmeth. Because part of the issue with that is to be compliant a bunch of things need to be probed. And rather than have an option to be only semi-compliant, the preference is to be compliant and just tried later in the boot sequence.
Putting bootmanager at the very end is OK with me, if we really cannot figure out a way to know whether the system is using it or now. It is 'putting it in the middle' that I don't like.
In the case of no specified boot order, after block (and after very special things like FEL) and before network is what makes the most sense. We don't need to try and DHCP/etc for it, just need to know if the interface exists (and so the user can say / have configured, to try and boot it).
How to handle the case where bootorder only specifies a subset of options? Ideally we would just probe devices related to that subset. That is what I was getting at.
Yes, that should work just fine, especially if we're in the middle?
The big challenge here is that conceptually, "bootstd" and "efi bootmanager" are duplicate functionality. They are both "figure out what on the system we should boot". The compromise is to try "bootstd" on block devices first (the common case).
Hi Tom,
On Thu, 9 Jan 2025 at 08:22, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:11:58AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 9 Jan 2025 at 08:05, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:01:13AM -0700, Simon Glass wrote:
Hi Heinrich,
On Sat, 4 Jan 2025 at 19:50, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/13/24 16:09, Simon Glass wrote:
This is another option to fix sunxi booting with bootstd, which may be better since it will work for all boards. We can then figure out how to automatically and deterministicaly decide when bootmgr should be used.
This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7.
Signed-off-by: Simon Glass sjg@chromium.org
If this patch is applied, we don't need to drop bootmgr for sunxi
(no changes since v1)
boot/bootmeth_efi_mgr.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-)avilable
diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c index 23ae1e610ac..095fa74fc60 100644 --- a/boot/bootmeth_efi_mgr.c +++ b/boot/bootmeth_efi_mgr.c @@ -14,8 +14,6 @@ #include <command.h> #include <dm.h> #include <efi_loader.h> -#include <efi_variable.h> -#include <malloc.h>
/**
- struct efi_mgr_priv - private info for the efi-mgr driver
@@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct efi_mgr_priv *priv = dev_get_priv(dev);
efi_status_t ret;efi_uintn_t size;u16 *bootorder; if (priv->fake_dev) { bflow->state = BOOTFLOWST_READY; return 0; }ret = efi_init_obj_list();if (ret)return log_msg_ret("init", ret);/* Enable this method if the "BootOrder" UEFI exists. */bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid,&size);if (bootorder) {free(bootorder);bflow->state = BOOTFLOWST_READY;return 0;}
/* To be implemented */The EFI boot manager can boot based on:
- variable BootOrder
- variable BootNext
- an existing file EFI/BOOT/BOOT<arch>.EFI
It obsoletes bootsmeth_efi.
return -EINVAL;We must always run the EFI boot manager if it is enabled. So -EINVAL is wrong here.
Well, I don't believe you have a solution, then.
You did suggest putting bootmgr later, as we discussed on irc.
For now, I think we should apply this patch (and series), while we sort out how to make bootmgr more incremental. It should not be scanning every available device before it starts, since that can be very slow.
Heinrich and I talked the other day, and we think the right path is the "later" path, where we don't try and use efi bootmanager until everything has been probed, and also drop the single "efi" option. This should mean that by the time we would be trying efi bootmanager most if not everything that needs to be probed has been probed. It doesn't make any sense to have "efi bootmanger" be more incremental as conceptually it's point is to show the user all the options.
What is the single 'efi' option? I hope you don't mean the EFI bootmeth.
Yes, the single EFI bootmeth. Because part of the issue with that is to be compliant a bunch of things need to be probed. And rather than have an option to be only semi-compliant, the preference is to be compliant and just tried later in the boot sequence.
Well then you need a way to disable the single EFI bootmeth?
Putting bootmanager at the very end is OK with me, if we really cannot figure out a way to know whether the system is using it or now. It is 'putting it in the middle' that I don't like.
In the case of no specified boot order, after block (and after very special things like FEL) and before network is what makes the most sense. We don't need to try and DHCP/etc for it, just need to know if the interface exists (and so the user can say / have configured, to try and boot it).
Apart from FEL, we also have ChromeOS, Android, QFW.
How to handle the case where bootorder only specifies a subset of options? Ideally we would just probe devices related to that subset. That is what I was getting at.
Yes, that should work just fine, especially if we're in the middle?
The big challenge here is that conceptually, "bootstd" and "efi bootmanager" are duplicate functionality. They are both "figure out what on the system we should boot". The compromise is to try "bootstd" on block devices first (the common case).
Are we trying to make boot slower?
A better way to design this would be to integrate the EFI stuff with bootstd, rather than duplicating things. For example, a way to convert a BOOTxxxx device into a bootdev would permit faster booting, since we can just work through the boot order and request each device in turn.
Once we give up on that and ask the user, we need to probe all devices.
The monolithic init of EFI_LOADER is creating quite a few problems. Am I the only one that sees it?
Regards, Simon
On Fri, Jan 10, 2025 at 06:41:00AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 9 Jan 2025 at 08:22, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:11:58AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 9 Jan 2025 at 08:05, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:01:13AM -0700, Simon Glass wrote:
Hi Heinrich,
On Sat, 4 Jan 2025 at 19:50, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/13/24 16:09, Simon Glass wrote: > This is another option to fix sunxi booting with bootstd, which may be > better since it will work for all boards. We can then figure out how to > automatically and deterministicaly decide when bootmgr should be used. > > This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7. > > Signed-off-by: Simon Glass sjg@chromium.org > --- > If this patch is applied, we don't need to drop bootmgr for sunxi > > (no changes since v1) > > boot/bootmeth_efi_mgr.c | 18 +----------------- > 1 file changed, 1 insertion(+), 17 deletions(-)avilable > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c > index 23ae1e610ac..095fa74fc60 100644 > --- a/boot/bootmeth_efi_mgr.c > +++ b/boot/bootmeth_efi_mgr.c > @@ -14,8 +14,6 @@ > #include <command.h> > #include <dm.h> > #include <efi_loader.h> > -#include <efi_variable.h> > -#include <malloc.h> > > /** > * struct efi_mgr_priv - private info for the efi-mgr driver > @@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) > static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) > { > struct efi_mgr_priv *priv = dev_get_priv(dev); > - efi_status_t ret; > - efi_uintn_t size; > - u16 *bootorder; > > if (priv->fake_dev) { > bflow->state = BOOTFLOWST_READY; > return 0; > } > > - ret = efi_init_obj_list(); > - if (ret) > - return log_msg_ret("init", ret); > - > - /* Enable this method if the "BootOrder" UEFI exists. */ > - bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid, > - &size); > - if (bootorder) { > - free(bootorder); > - bflow->state = BOOTFLOWST_READY; > - return 0; > - } > + /* To be implemented */
The EFI boot manager can boot based on:
- variable BootOrder
- variable BootNext
- an existing file EFI/BOOT/BOOT<arch>.EFI
It obsoletes bootsmeth_efi.
> > return -EINVAL;
We must always run the EFI boot manager if it is enabled. So -EINVAL is wrong here.
Well, I don't believe you have a solution, then.
You did suggest putting bootmgr later, as we discussed on irc.
For now, I think we should apply this patch (and series), while we sort out how to make bootmgr more incremental. It should not be scanning every available device before it starts, since that can be very slow.
Heinrich and I talked the other day, and we think the right path is the "later" path, where we don't try and use efi bootmanager until everything has been probed, and also drop the single "efi" option. This should mean that by the time we would be trying efi bootmanager most if not everything that needs to be probed has been probed. It doesn't make any sense to have "efi bootmanger" be more incremental as conceptually it's point is to show the user all the options.
What is the single 'efi' option? I hope you don't mean the EFI bootmeth.
Yes, the single EFI bootmeth. Because part of the issue with that is to be compliant a bunch of things need to be probed. And rather than have an option to be only semi-compliant, the preference is to be compliant and just tried later in the boot sequence.
Well then you need a way to disable the single EFI bootmeth?
We have BOOTMETH_EFILOADER already.
Putting bootmanager at the very end is OK with me, if we really cannot figure out a way to know whether the system is using it or now. It is 'putting it in the middle' that I don't like.
In the case of no specified boot order, after block (and after very special things like FEL) and before network is what makes the most sense. We don't need to try and DHCP/etc for it, just need to know if the interface exists (and so the user can say / have configured, to try and boot it).
Apart from FEL, we also have ChromeOS, Android, QFW.
OK? Yes, bootstd needs to handle "we're in a special update things state". I'm not sure if QFW counts as a faux-block device or not. And ChromeOS I would have thought is "try and boot like $this from $device". I don't know if by "Android" you mean booting the OS, or the AVB state machine. The former would be like ChromeOS and the latter the special state machine case.
How to handle the case where bootorder only specifies a subset of options? Ideally we would just probe devices related to that subset. That is what I was getting at.
Yes, that should work just fine, especially if we're in the middle?
The big challenge here is that conceptually, "bootstd" and "efi bootmanager" are duplicate functionality. They are both "figure out what on the system we should boot". The compromise is to try "bootstd" on block devices first (the common case).
Are we trying to make boot slower?
We're already in the slow path, because we're making guesses. But no, we aren't trying to make anything slower. This should potentially faster in the non-EFI case since we won't be trying to EFI boot every block device until we have exhausted the non-EFI methods.
A better way to design this would be to integrate the EFI stuff with bootstd, rather than duplicating things. For example, a way to convert a BOOTxxxx device into a bootdev would permit faster booting, since we can just work through the boot order and request each device in turn.
Once we give up on that and ask the user, we need to probe all devices.
No, we're trying to untangle "EFI", "EFI bootmanager" and "bootstd".
The monolithic init of EFI_LOADER is creating quite a few problems. Am I the only one that sees it?
Yes, because your "monolithic init is a problem" is the subsystem maintainers "monolithic init makes us spec compliant".
And when we're in some sort of "probe the device and see what can be booted" the subsystem maintainers would rather be spec compliant.
And for the role I played in this confusion by suggesting how to integrate things privately and has now gone off the rails, I am sorry for the confusion and wasted efforts. I don't know if I was unclear or misspoke.
Hi Tom,
On Fri, 10 Jan 2025 at 10:05, Tom Rini trini@konsulko.com wrote:
On Fri, Jan 10, 2025 at 06:41:00AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 9 Jan 2025 at 08:22, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:11:58AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 9 Jan 2025 at 08:05, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:01:13AM -0700, Simon Glass wrote:
Hi Heinrich,
On Sat, 4 Jan 2025 at 19:50, Heinrich Schuchardt xypron.glpk@gmx.de wrote: > > On 11/13/24 16:09, Simon Glass wrote: > > This is another option to fix sunxi booting with bootstd, which may be > > better since it will work for all boards. We can then figure out how to > > automatically and deterministicaly decide when bootmgr should be used. > > > > This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7. > > > > Signed-off-by: Simon Glass sjg@chromium.org > > --- > > If this patch is applied, we don't need to drop bootmgr for sunxi > > > > (no changes since v1) > > > > boot/bootmeth_efi_mgr.c | 18 +----------------- > > 1 file changed, 1 insertion(+), 17 deletions(-)avilable > > > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c > > index 23ae1e610ac..095fa74fc60 100644 > > --- a/boot/bootmeth_efi_mgr.c > > +++ b/boot/bootmeth_efi_mgr.c > > @@ -14,8 +14,6 @@ > > #include <command.h> > > #include <dm.h> > > #include <efi_loader.h> > > -#include <efi_variable.h> > > -#include <malloc.h> > > > > /** > > * struct efi_mgr_priv - private info for the efi-mgr driver > > @@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) > > static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) > > { > > struct efi_mgr_priv *priv = dev_get_priv(dev); > > - efi_status_t ret; > > - efi_uintn_t size; > > - u16 *bootorder; > > > > if (priv->fake_dev) { > > bflow->state = BOOTFLOWST_READY; > > return 0; > > } > > > > - ret = efi_init_obj_list(); > > - if (ret) > > - return log_msg_ret("init", ret); > > - > > - /* Enable this method if the "BootOrder" UEFI exists. */ > > - bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid, > > - &size); > > - if (bootorder) { > > - free(bootorder); > > - bflow->state = BOOTFLOWST_READY; > > - return 0; > > - } > > + /* To be implemented */ > > The EFI boot manager can boot based on: > > * variable BootOrder > * variable BootNext > * an existing file EFI/BOOT/BOOT<arch>.EFI > > It obsoletes bootsmeth_efi. > > > > > return -EINVAL; > > We must always run the EFI boot manager if it is enabled. So -EINVAL is > wrong here.
Well, I don't believe you have a solution, then.
You did suggest putting bootmgr later, as we discussed on irc.
For now, I think we should apply this patch (and series), while we sort out how to make bootmgr more incremental. It should not be scanning every available device before it starts, since that can be very slow.
Heinrich and I talked the other day, and we think the right path is the "later" path, where we don't try and use efi bootmanager until everything has been probed, and also drop the single "efi" option. This should mean that by the time we would be trying efi bootmanager most if not everything that needs to be probed has been probed. It doesn't make any sense to have "efi bootmanger" be more incremental as conceptually it's point is to show the user all the options.
What is the single 'efi' option? I hope you don't mean the EFI bootmeth.
Yes, the single EFI bootmeth. Because part of the issue with that is to be compliant a bunch of things need to be probed. And rather than have an option to be only semi-compliant, the preference is to be compliant and just tried later in the boot sequence.
Well then you need a way to disable the single EFI bootmeth?
We have BOOTMETH_EFILOADER already.
Putting bootmanager at the very end is OK with me, if we really cannot figure out a way to know whether the system is using it or now. It is 'putting it in the middle' that I don't like.
In the case of no specified boot order, after block (and after very special things like FEL) and before network is what makes the most sense. We don't need to try and DHCP/etc for it, just need to know if the interface exists (and so the user can say / have configured, to try and boot it).
Apart from FEL, we also have ChromeOS, Android, QFW.
OK? Yes, bootstd needs to handle "we're in a special update things state". I'm not sure if QFW counts as a faux-block device or not. And ChromeOS I would have thought is "try and boot like $this from $device". I don't know if by "Android" you mean booting the OS, or the AVB state machine. The former would be like ChromeOS and the latter the special state machine case.
Standard boot is designed as a generalisation of the boot process and is able to cope with most use cases. Everything uses the same algorithm, at a high level.
How to handle the case where bootorder only specifies a subset of options? Ideally we would just probe devices related to that subset. That is what I was getting at.
Yes, that should work just fine, especially if we're in the middle?
The big challenge here is that conceptually, "bootstd" and "efi bootmanager" are duplicate functionality. They are both "figure out what on the system we should boot". The compromise is to try "bootstd" on block devices first (the common case).
Are we trying to make boot slower?
We're already in the slow path, because we're making guesses. But no, we aren't trying to make anything slower. This should potentially faster in the non-EFI case since we won't be trying to EFI boot every block device until we have exhausted the non-EFI methods.
A better way to design this would be to integrate the EFI stuff with bootstd, rather than duplicating things. For example, a way to convert a BOOTxxxx device into a bootdev would permit faster booting, since we can just work through the boot order and request each device in turn.
Once we give up on that and ask the user, we need to probe all devices.
No, we're trying to untangle "EFI", "EFI bootmanager" and "bootstd".
By neutering bootstd? It would be better to update EFI to make use of bootdev, for example. Heinrich did a patch to use the 'hunt' feature of bootdev.
The monolithic init of EFI_LOADER is creating quite a few problems. Am I the only one that sees it?
Yes, because your "monolithic init is a problem" is the subsystem maintainers "monolithic init makes us spec compliant".
And when we're in some sort of "probe the device and see what can be booted" the subsystem maintainers would rather be spec compliant.
We don't need to be noncompliant with spec. But some thoughtful design would help us a lot.
And for the role I played in this confusion by suggesting how to integrate things privately and has now gone off the rails, I am sorry for the confusion and wasted efforts. I don't know if I was unclear or misspoke.
I'm not sure what that relates to?
Regards, Simon
On Wed, Jan 15, 2025 at 06:22:40AM -0700, Simon Glass wrote:
Hi Tom,
On Fri, 10 Jan 2025 at 10:05, Tom Rini trini@konsulko.com wrote:
On Fri, Jan 10, 2025 at 06:41:00AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 9 Jan 2025 at 08:22, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:11:58AM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 9 Jan 2025 at 08:05, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 09, 2025 at 08:01:13AM -0700, Simon Glass wrote: > Hi Heinrich, > > On Sat, 4 Jan 2025 at 19:50, Heinrich Schuchardt xypron.glpk@gmx.de wrote: > > > > On 11/13/24 16:09, Simon Glass wrote: > > > This is another option to fix sunxi booting with bootstd, which may be > > > better since it will work for all boards. We can then figure out how to > > > automatically and deterministicaly decide when bootmgr should be used. > > > > > > This reverts commit f2bfa0cb17948aa4a0fa20fdf9014296b9c4d9c7. > > > > > > Signed-off-by: Simon Glass sjg@chromium.org > > > --- > > > If this patch is applied, we don't need to drop bootmgr for sunxi > > > > > > (no changes since v1) > > > > > > boot/bootmeth_efi_mgr.c | 18 +----------------- > > > 1 file changed, 1 insertion(+), 17 deletions(-)avilable > > > > > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c > > > index 23ae1e610ac..095fa74fc60 100644 > > > --- a/boot/bootmeth_efi_mgr.c > > > +++ b/boot/bootmeth_efi_mgr.c > > > @@ -14,8 +14,6 @@ > > > #include <command.h> > > > #include <dm.h> > > > #include <efi_loader.h> > > > -#include <efi_variable.h> > > > -#include <malloc.h> > > > > > > /** > > > * struct efi_mgr_priv - private info for the efi-mgr driver > > > @@ -48,27 +46,13 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) > > > static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) > > > { > > > struct efi_mgr_priv *priv = dev_get_priv(dev); > > > - efi_status_t ret; > > > - efi_uintn_t size; > > > - u16 *bootorder; > > > > > > if (priv->fake_dev) { > > > bflow->state = BOOTFLOWST_READY; > > > return 0; > > > } > > > > > > - ret = efi_init_obj_list(); > > > - if (ret) > > > - return log_msg_ret("init", ret); > > > - > > > - /* Enable this method if the "BootOrder" UEFI exists. */ > > > - bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid, > > > - &size); > > > - if (bootorder) { > > > - free(bootorder); > > > - bflow->state = BOOTFLOWST_READY; > > > - return 0; > > > - } > > > + /* To be implemented */ > > > > The EFI boot manager can boot based on: > > > > * variable BootOrder > > * variable BootNext > > * an existing file EFI/BOOT/BOOT<arch>.EFI > > > > It obsoletes bootsmeth_efi. > > > > > > > > return -EINVAL; > > > > We must always run the EFI boot manager if it is enabled. So -EINVAL is > > wrong here. > > Well, I don't believe you have a solution, then. > > You did suggest putting bootmgr later, as we discussed on irc. > > For now, I think we should apply this patch (and series), while we > sort out how to make bootmgr more incremental. It should not be > scanning every available device before it starts, since that can be > very slow.
Heinrich and I talked the other day, and we think the right path is the "later" path, where we don't try and use efi bootmanager until everything has been probed, and also drop the single "efi" option. This should mean that by the time we would be trying efi bootmanager most if not everything that needs to be probed has been probed. It doesn't make any sense to have "efi bootmanger" be more incremental as conceptually it's point is to show the user all the options.
What is the single 'efi' option? I hope you don't mean the EFI bootmeth.
Yes, the single EFI bootmeth. Because part of the issue with that is to be compliant a bunch of things need to be probed. And rather than have an option to be only semi-compliant, the preference is to be compliant and just tried later in the boot sequence.
Well then you need a way to disable the single EFI bootmeth?
We have BOOTMETH_EFILOADER already.
Putting bootmanager at the very end is OK with me, if we really cannot figure out a way to know whether the system is using it or now. It is 'putting it in the middle' that I don't like.
In the case of no specified boot order, after block (and after very special things like FEL) and before network is what makes the most sense. We don't need to try and DHCP/etc for it, just need to know if the interface exists (and so the user can say / have configured, to try and boot it).
Apart from FEL, we also have ChromeOS, Android, QFW.
OK? Yes, bootstd needs to handle "we're in a special update things state". I'm not sure if QFW counts as a faux-block device or not. And ChromeOS I would have thought is "try and boot like $this from $device". I don't know if by "Android" you mean booting the OS, or the AVB state machine. The former would be like ChromeOS and the latter the special state machine case.
Standard boot is designed as a generalisation of the boot process and is able to cope with most use cases. Everything uses the same algorithm, at a high level.
That will be tricky as some of those use cases have their own required order of operations.
How to handle the case where bootorder only specifies a subset of options? Ideally we would just probe devices related to that subset. That is what I was getting at.
Yes, that should work just fine, especially if we're in the middle?
The big challenge here is that conceptually, "bootstd" and "efi bootmanager" are duplicate functionality. They are both "figure out what on the system we should boot". The compromise is to try "bootstd" on block devices first (the common case).
Are we trying to make boot slower?
We're already in the slow path, because we're making guesses. But no, we aren't trying to make anything slower. This should potentially faster in the non-EFI case since we won't be trying to EFI boot every block device until we have exhausted the non-EFI methods.
A better way to design this would be to integrate the EFI stuff with bootstd, rather than duplicating things. For example, a way to convert a BOOTxxxx device into a bootdev would permit faster booting, since we can just work through the boot order and request each device in turn.
Once we give up on that and ask the user, we need to probe all devices.
No, we're trying to untangle "EFI", "EFI bootmanager" and "bootstd".
By neutering bootstd?
No, by taking one generalization of the boot process algorithm out of another generalization of the boot process algorithm.
It would be better to update EFI to make use of bootdev, for example. Heinrich did a patch to use the 'hunt' feature of bootdev.
There's "EFI" and "EFI bootmanager" and I'm not sure which one you're referring to here. But yes, Heinrich has had suggestions on how to work with bootstd, including suggesting what I'm also seeing as the best path forward I believe.
The monolithic init of EFI_LOADER is creating quite a few problems. Am I the only one that sees it?
Yes, because your "monolithic init is a problem" is the subsystem maintainers "monolithic init makes us spec compliant".
And when we're in some sort of "probe the device and see what can be booted" the subsystem maintainers would rather be spec compliant.
We don't need to be noncompliant with spec. But some thoughtful design would help us a lot.
Maybe. But that's also not the part your problems with the EFI_LOADER subsystem that you've been talking about in this thread. This thread is about "can we probe less?" to which the answer seems to be "only if we stop being spec compliant". Or if strictly speaking still spec compliant but breaking the rule of least surprise and so forth.
And for the role I played in this confusion by suggesting how to integrate things privately and has now gone off the rails, I am sorry for the confusion and wasted efforts. I don't know if I was unclear or misspoke.
I'm not sure what that relates to?
I know at some points I had given you some advice on how to integrate EFI in to bootstd. And since that seems to have gone in the wrong direction I'm acknowledging that and trying to reset things.
Drop support for distroboot and move to using bootstd instead.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v2)
Changes in v2: - Convert the other DISTRO_DEFAULTS in the Kconfig too
arch/arm/Kconfig | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 7282c4123b0..b08d8d4ff27 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1155,7 +1155,7 @@ config ARCH_SUNXI select BINMAN select CMD_GPIO select CMD_MMC if MMC - select CMD_USB if DISTRO_DEFAULTS && USB_HOST + select CMD_USB if BOOTSTD_DEFAULTS && USB_HOST select CLK select DM select DM_GPIO @@ -1177,9 +1177,9 @@ config ARCH_SUNXI select SUNXI_GPIO select SYS_NS16550 select SYS_THUMB_BUILD if !ARM64 - select USB if DISTRO_DEFAULTS - select USB_KEYBOARD if DISTRO_DEFAULTS && USB_HOST - select USB_STORAGE if DISTRO_DEFAULTS && USB_HOST + select USB if BOOTSTD_DEFAULTS + select USB_KEYBOARD if BOOTSTD_DEFAULTS && USB_HOST + select USB_STORAGE if BOOTSTD_DEFAULTS && USB_HOST select SPL_USE_TINY_PRINTF if SPL select USE_PREBOOT select SYS_RELOC_GD_ENV_ADDR @@ -1187,7 +1187,7 @@ config ARCH_SUNXI imply CMD_DM imply CMD_GPT imply CMD_UBI if MTD_RAW_NAND - imply DISTRO_DEFAULTS + imply BOOTSTD_DEFAULTS imply DM_REGULATOR imply DM_REGULATOR_FIXED imply FAT_WRITE
These are not needed as bootstd handles the boot now. Drop them.
Keep BOOTCMD_SUNXI_COMPAT for now since it does not relate to distro boot.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v2)
Changes in v2: - Keep BOOTCMD_SUNXI_COMPAT
include/configs/sunxi-common.h | 75 +--------------------------------- 1 file changed, 1 insertion(+), 74 deletions(-)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index b29a25d5617..666553ccadb 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -156,76 +156,6 @@ "fdt ram " FDT_ADDR_R " 0x100000;" \ "ramdisk ram " RAMDISK_ADDR_R " 0x4000000\0"
-/**************************************************************************** - * definitions for the distro boot system * - ****************************************************************************/ -#ifdef CONFIG_MMC -#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1 -#define BOOTENV_DEV_MMC_AUTO(devtypeu, devtypel, instance) \ - BOOTENV_DEV_MMC(MMC, mmc, 0) \ - BOOTENV_DEV_MMC(MMC, mmc, 1) \ - "bootcmd_mmc_auto=" \ - "if test ${mmc_bootdev} -eq 1; then " \ - "run bootcmd_mmc1; " \ - "run bootcmd_mmc0; " \ - "elif test ${mmc_bootdev} -eq 0; then " \ - "run bootcmd_mmc0; " \ - "run bootcmd_mmc1; " \ - "fi\0" - -#define BOOTENV_DEV_NAME_MMC_AUTO(devtypeu, devtypel, instance) \ - "mmc_auto " - -#define BOOT_TARGET_DEVICES_MMC(func) func(MMC_AUTO, mmc_auto, na) -#else -#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) -#endif -#else -#define BOOT_TARGET_DEVICES_MMC(func) -#endif - -#ifdef CONFIG_AHCI -#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) -#else -#define BOOT_TARGET_DEVICES_SCSI(func) -#endif - -#ifdef CONFIG_USB_STORAGE -#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0) -#else -#define BOOT_TARGET_DEVICES_USB(func) -#endif - -#ifdef CONFIG_CMD_PXE -#define BOOT_TARGET_DEVICES_PXE(func) func(PXE, pxe, na) -#else -#define BOOT_TARGET_DEVICES_PXE(func) -#endif - -#ifdef CONFIG_CMD_DHCP -#define BOOT_TARGET_DEVICES_DHCP(func) func(DHCP, dhcp, na) -#else -#define BOOT_TARGET_DEVICES_DHCP(func) -#endif - -/* FEL boot support, auto-execute boot.scr if a script address was provided */ -#define BOOTENV_DEV_FEL(devtypeu, devtypel, instance) \ - "bootcmd_fel=" \ - "if test -n ${fel_booted} && test -n ${fel_scriptaddr}; then " \ - "echo '(FEL boot)'; " \ - "source ${fel_scriptaddr}; " \ - "fi\0" -#define BOOTENV_DEV_NAME_FEL(devtypeu, devtypel, instance) \ - "fel " - -#define BOOT_TARGET_DEVICES(func) \ - func(FEL, fel, na) \ - BOOT_TARGET_DEVICES_MMC(func) \ - BOOT_TARGET_DEVICES_SCSI(func) \ - BOOT_TARGET_DEVICES_USB(func) \ - BOOT_TARGET_DEVICES_PXE(func) \ - BOOT_TARGET_DEVICES_DHCP(func) - #ifdef CONFIG_OLD_SUNXI_KERNEL_COMPAT #define BOOTCMD_SUNXI_COMPAT \ "bootcmd_sunxi_compat=" \ @@ -242,8 +172,6 @@ #define BOOTCMD_SUNXI_COMPAT #endif
-#include <config_distro_bootcmd.h> - #ifdef CONFIG_USB_KEYBOARD #define CONSOLE_STDIN_SETTINGS \ "stdin=serial,usbkbd\0" @@ -296,7 +224,6 @@ "uuid_gpt_esp=" UUID_GPT_ESP "\0" \ "uuid_gpt_system=" UUID_GPT_SYSTEM "\0" \ "partitions=" PARTS_DEFAULT "\0" \ - BOOTCMD_SUNXI_COMPAT \ - BOOTENV + BOOTCMD_SUNXI_COMPAT
#endif /* _SUNXI_COMMON_CONFIG_H */
Some boards use a CONFIG option to specify the value of this variable. This is normally handled by efi_get_distro_fdt_name() but in the case of sunxi this does not work, since 'soc' is sunxi, but the files are in the allwinner directory.
Provide a work-around for this particular case.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v3)
Changes in v3: - Fix 'supressed' typo - Use backquotes to highlight DEFAULT_DEVICE_TREE
Makefile | 1 + doc/usage/environment.rst | 12 ++++++++++++ 2 files changed, 13 insertions(+)
diff --git a/Makefile b/Makefile index 81b73a1d8d9..07529e0bc4f 100644 --- a/Makefile +++ b/Makefile @@ -1861,6 +1861,7 @@ quiet_cmd_gen_envp = ENVP $@ $(CPP) -P $(cpp_flags) -x assembler-with-cpp -undef \ -D__ASSEMBLY__ \ -D__UBOOT_CONFIG__ \ + -DDEFAULT_DEVICE_TREE=$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE)) \ -I . -I include -I $(srctree)/include \ -include linux/kconfig.h -include include/config.h \ -I$(srctree)/arch/$(ARCH)/include \ diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst index 7bd9ffce8d8..1ab3ee7ced9 100644 --- a/doc/usage/environment.rst +++ b/doc/usage/environment.rst @@ -87,6 +87,18 @@ settings. For example::
#include <env/ti/mmc.env>
+Quotes are not suppressed, for example:: + + fdtfile=CONFIG_DEFAULT_DEVICE_TREE.dtb + # produces: fdtfile="sun7i-a20-pcduino3.dtb" + +For this particular issue you can use ``DEFAULT_DEVICE_TREE`` instead:: + + fdtfile=DEFAULT_DEVICE_TREE.dtb + # produces: fdtfile=sun7i-a20-pcduino3.dtb + +There is no general way to remove quotes. + If CONFIG_ENV_SOURCE_FILE is empty and the default filename is not present, then the old-style C environment is used instead. See below.
On Wed, Nov 13, 2024 at 08:09:37AM -0700, Simon Glass wrote:
Some boards use a CONFIG option to specify the value of this variable. This is normally handled by efi_get_distro_fdt_name() but in the case of sunxi this does not work, since 'soc' is sunxi, but the files are in the allwinner directory.
Provide a work-around for this particular case.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Tom Rini trini@konsulko.com
Convert these boards to use a text environment.
For the boards check, the only differences are extra spaces after the semicolons in 'dfu_alt_info_ram' and 'partitions', both of which are permitted.
Add in the special boot command for old kernels, dropping the unnecessary and confusing hex prefixes.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v4)
Changes in v4: - Drop UUID_GPT_SYSTEM and UUID_GPT_ESP definitions - Drop special case for ARM64's devicetree subdir - Drop unwanted quotations and indentation in KERNEL_COMPAT path
Changes in v2: - Keep bootcmd_sunxi_compat if OLD_SUNXI_KERNEL_COMPAT is enabled
board/sunxi/sunxi.env | 140 ++++++++++++++++++++++++++++ include/configs/sunxi-common.h | 165 --------------------------------- 2 files changed, 140 insertions(+), 165 deletions(-) create mode 100644 board/sunxi/sunxi.env
diff --git a/board/sunxi/sunxi.env b/board/sunxi/sunxi.env new file mode 100644 index 00000000000..ec6e07c228f --- /dev/null +++ b/board/sunxi/sunxi.env @@ -0,0 +1,140 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Common sunxi environment + * + * Copyright 2024 Google LLC + * Written by Simon Glass sjg@chromium.org + / + +/**************************************************************************** + * environment variables holding default load addresses * + ****************************************************************************/ +/* + * We cannot use expressions here, because expressions won't be evaluated in + * autoconf.mk. + */ +#ifdef CONFIG_ARM64 +/* + * Boards seem to come with at least 512MB of DRAM. + * The kernel should go at 512K, which is the default text offset (that will + * be adjusted at runtime if needed). + * There is no compression for arm64 kernels (yet), so leave some space + * for really big kernels, say 256MB for now. + * Scripts, PXE and DTBs should go afterwards, leaving the rest for the initrd. + */ +#define BOOTM_SIZE 0xa000000 +#define KERNEL_ADDR_R SDRAM_OFFSET(0080000) +#define KERNEL_COMP_ADDR_R SDRAM_OFFSET(4000000) +#define KERNEL_COMP_SIZE 0xb000000 +#define FDT_ADDR_R SDRAM_OFFSET(FA00000) +#define SCRIPT_ADDR_R SDRAM_OFFSET(FC00000) +#define PXEFILE_ADDR_R SDRAM_OFFSET(FD00000) +#define FDTOVERLAY_ADDR_R SDRAM_OFFSET(FE00000) +#define RAMDISK_ADDR_R SDRAM_OFFSET(FF00000) + +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 256) +/* + * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc. + * 32M uncompressed kernel, 16M compressed kernel, 1M fdt, + * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end. + */ +#define BOOTM_SIZE 0xa000000 +#define KERNEL_ADDR_R SDRAM_OFFSET(2000000) +#define FDT_ADDR_R SDRAM_OFFSET(3000000) +#define SCRIPT_ADDR_R SDRAM_OFFSET(3100000) +#define PXEFILE_ADDR_R SDRAM_OFFSET(3200000) +#define FDTOVERLAY_ADDR_R SDRAM_OFFSET(3300000) +#define RAMDISK_ADDR_R SDRAM_OFFSET(3400000) + +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 64) +/* + * 64M RAM minus 2MB heap + 16MB for u-boot, stack, fb, etc. + * 16M uncompressed kernel, 8M compressed kernel, 1M fdt, + * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end. + */ +#define BOOTM_SIZE 0x2e00000 +#define KERNEL_ADDR_R SDRAM_OFFSET(1000000) +#define FDT_ADDR_R SDRAM_OFFSET(1800000) +#define SCRIPT_ADDR_R SDRAM_OFFSET(1900000) +#define PXEFILE_ADDR_R SDRAM_OFFSET(1A00000) +#define FDTOVERLAY_ADDR_R SDRAM_OFFSET(1B00000) +#define RAMDISK_ADDR_R SDRAM_OFFSET(1C00000) + +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 32) +/* + * 32M RAM minus 2.5MB for u-boot, heap, stack, etc. + * 16M uncompressed kernel, 7M compressed kernel, 128K fdt, 64K script, + * 128K DT overlay, 128K PXE and the ramdisk in the rest (max. 5MB) + */ +#define BOOTM_SIZE 0x1700000 +#define KERNEL_ADDR_R SDRAM_OFFSET(1000000) +#define FDT_ADDR_R SDRAM_OFFSET(1d50000) +#define SCRIPT_ADDR_R SDRAM_OFFSET(1d40000) +#define PXEFILE_ADDR_R SDRAM_OFFSET(1d00000) +#define FDTOVERLAY_ADDR_R SDRAM_OFFSET(1d20000) +#define RAMDISK_ADDR_R SDRAM_OFFSET(1800000) + +#else +#error Need at least 32MB of DRAM. Please adjust load addresses. +#endif + +stdin=serial +#ifdef CONFIG_USB_KEYBOARD +stdin+=,usbkbd +#endif + +stdout=serial +stderr=serial +#ifdef CONFIG_VIDEO +stdout+=,vidconsole +stderr+=,vidconsole +#endif + +bootm_size=BOOTM_SIZE +kernel_addr_r=KERNEL_ADDR_R +fdt_addr_r=FDT_ADDR_R +scriptaddr=SCRIPT_ADDR_R +pxefile_addr_r=PXEFILE_ADDR_R +fdtoverlay_addr_r=FDTOVERLAY_ADDR_R +ramdisk_addr_r=RAMDISK_ADDR_R + +#ifdef CONFIG_ARM64 +kernel_comp_addr_r=KERNEL_COMP_ADDR_R +kernel_comp_size=KERNEL_COMP_SIZE +#endif + +dfu_alt_info_ram= + kernel ram KERNEL_ADDR_R 0x1000000; + fdt ram FDT_ADDR_R 0x100000; + ramdisk ram RAMDISK_ADDR_R 0x4000000 + +fdtfile=DEFAULT_DEVICE_TREE.dtb + +console=ttyS0,115200 + +uuid_gpt_esp=c12a7328-f81f-11d2-ba4b-00a0c93ec93b +#ifdef CONFIG_ARM64 +uuid_gpt_system=b921b045-1df0-41c3-af44-4c6f280d3fae +#else +uuid_gpt_system=69dad710-2ce4-4e3c-b16c-21a1d49abed3 +#endif + +partitions= + name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1}; + name=loader2,size=984k,uuid=${uuid_gpt_loader2}; + name=esp,size=128M,bootable,uuid=${uuid_gpt_esp}; + name=system,size=-,uuid=${uuid_gpt_system}; + +/* support booting a very old kernel */ +#ifdef CONFIG_OLD_SUNXI_KERNEL_COMPAT +bootcmd_sunxi_compat= + setenv root /dev/mmcblk0p3 rootwait; + if ext2load mmc 0 44000000 uEnv.txt; then + echo Loaded environment from uEnv.txt; + env import -t 44000000 ${filesize}; + fi; + setenv bootargs console=${console} root=${root} ${extraargs}; + ext2load mmc 0 43000000 script.bin && + ext2load mmc 0 48000000 uImage && + bootm 48000000 +#endif diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 666553ccadb..ceea26494ad 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -61,169 +61,4 @@ #define PHYS_SDRAM_0 CFG_SYS_SDRAM_BASE #define PHYS_SDRAM_0_SIZE 0x80000000 /* 2 GiB */
-/**************************************************************************** - * environment variables holding default load addresses * - ****************************************************************************/ -/* - * We cannot use expressions here, because expressions won't be evaluated in - * autoconf.mk. - */ -#ifdef CONFIG_ARM64 -/* - * Boards seem to come with at least 512MB of DRAM. - * The kernel should go at 512K, which is the default text offset (that will - * be adjusted at runtime if needed). - * There is no compression for arm64 kernels (yet), so leave some space - * for really big kernels, say 256MB for now. - * Scripts, PXE and DTBs should go afterwards, leaving the rest for the initrd. - */ -#define BOOTM_SIZE __stringify(0xa000000) -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(0080000)) -#define KERNEL_COMP_ADDR_R __stringify(SDRAM_OFFSET(4000000)) -#define KERNEL_COMP_SIZE __stringify(0xb000000) -#define FDT_ADDR_R __stringify(SDRAM_OFFSET(FA00000)) -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(FC00000)) -#define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(FD00000)) -#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(FE00000)) -#define RAMDISK_ADDR_R __stringify(SDRAM_OFFSET(FF00000)) - -#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 256) -/* - * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc. - * 32M uncompressed kernel, 16M compressed kernel, 1M fdt, - * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end. - */ -#define BOOTM_SIZE __stringify(0xa000000) -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(2000000)) -#define FDT_ADDR_R __stringify(SDRAM_OFFSET(3000000)) -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(3100000)) -#define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(3200000)) -#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(3300000)) -#define RAMDISK_ADDR_R __stringify(SDRAM_OFFSET(3400000)) - -#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 64) -/* - * 64M RAM minus 2MB heap + 16MB for u-boot, stack, fb, etc. - * 16M uncompressed kernel, 8M compressed kernel, 1M fdt, - * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end. - */ -#define BOOTM_SIZE __stringify(0x2e00000) -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(1000000)) -#define FDT_ADDR_R __stringify(SDRAM_OFFSET(1800000)) -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(1900000)) -#define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(1A00000)) -#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1B00000)) -#define RAMDISK_ADDR_R __stringify(SDRAM_OFFSET(1C00000)) - -#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 32) -/* - * 32M RAM minus 2.5MB for u-boot, heap, stack, etc. - * 16M uncompressed kernel, 7M compressed kernel, 128K fdt, 64K script, - * 128K DT overlay, 128K PXE and the ramdisk in the rest (max. 5MB) - */ -#define BOOTM_SIZE __stringify(0x1700000) -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(1000000)) -#define FDT_ADDR_R __stringify(SDRAM_OFFSET(1d50000)) -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(1d40000)) -#define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(1d00000)) -#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1d20000)) -#define RAMDISK_ADDR_R __stringify(SDRAM_OFFSET(1800000)) - -#else -#error Need at least 32MB of DRAM. Please adjust load addresses. -#endif - -#define MEM_LAYOUT_ENV_SETTINGS \ - "bootm_size=" BOOTM_SIZE "\0" \ - "kernel_addr_r=" KERNEL_ADDR_R "\0" \ - "fdt_addr_r=" FDT_ADDR_R "\0" \ - "scriptaddr=" SCRIPT_ADDR_R "\0" \ - "pxefile_addr_r=" PXEFILE_ADDR_R "\0" \ - "fdtoverlay_addr_r=" FDTOVERLAY_ADDR_R "\0" \ - "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" - -#ifdef CONFIG_ARM64 -#define MEM_LAYOUT_ENV_EXTRA_SETTINGS \ - "kernel_comp_addr_r=" KERNEL_COMP_ADDR_R "\0" \ - "kernel_comp_size=" KERNEL_COMP_SIZE "\0" -#else -#define MEM_LAYOUT_ENV_EXTRA_SETTINGS "" -#endif - -#define DFU_ALT_INFO_RAM \ - "dfu_alt_info_ram=" \ - "kernel ram " KERNEL_ADDR_R " 0x1000000;" \ - "fdt ram " FDT_ADDR_R " 0x100000;" \ - "ramdisk ram " RAMDISK_ADDR_R " 0x4000000\0" - -#ifdef CONFIG_OLD_SUNXI_KERNEL_COMPAT -#define BOOTCMD_SUNXI_COMPAT \ - "bootcmd_sunxi_compat=" \ - "setenv root /dev/mmcblk0p3 rootwait; " \ - "if ext2load mmc 0 0x44000000 uEnv.txt; then " \ - "echo Loaded environment from uEnv.txt; " \ - "env import -t 0x44000000 ${filesize}; " \ - "fi; " \ - "setenv bootargs console=${console} root=${root} ${extraargs}; " \ - "ext2load mmc 0 0x43000000 script.bin && " \ - "ext2load mmc 0 0x48000000 uImage && " \ - "bootm 0x48000000\0" -#else -#define BOOTCMD_SUNXI_COMPAT -#endif - -#ifdef CONFIG_USB_KEYBOARD -#define CONSOLE_STDIN_SETTINGS \ - "stdin=serial,usbkbd\0" -#else -#define CONSOLE_STDIN_SETTINGS \ - "stdin=serial\0" -#endif - -#ifdef CONFIG_VIDEO -#define CONSOLE_STDOUT_SETTINGS \ - "stdout=serial,vidconsole\0" \ - "stderr=serial,vidconsole\0" -#else -#define CONSOLE_STDOUT_SETTINGS \ - "stdout=serial\0" \ - "stderr=serial\0" -#endif - -#define PARTS_DEFAULT \ - "name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};" \ - "name=loader2,size=984k,uuid=${uuid_gpt_loader2};" \ - "name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};" \ - "name=system,size=-,uuid=${uuid_gpt_system};" - -#define UUID_GPT_ESP "c12a7328-f81f-11d2-ba4b-00a0c93ec93b" - -#ifdef CONFIG_ARM64 -#define UUID_GPT_SYSTEM "b921b045-1df0-41c3-af44-4c6f280d3fae" -#else -#define UUID_GPT_SYSTEM "69dad710-2ce4-4e3c-b16c-21a1d49abed3" -#endif - -#define CONSOLE_ENV_SETTINGS \ - CONSOLE_STDIN_SETTINGS \ - CONSOLE_STDOUT_SETTINGS - -#ifdef CONFIG_ARM64 -#define FDTFILE "allwinner/" CONFIG_DEFAULT_DEVICE_TREE ".dtb" -#else -#define FDTFILE CONFIG_DEFAULT_DEVICE_TREE ".dtb" -#endif - -#define CFG_EXTRA_ENV_SETTINGS \ - CONSOLE_ENV_SETTINGS \ - MEM_LAYOUT_ENV_SETTINGS \ - MEM_LAYOUT_ENV_EXTRA_SETTINGS \ - DFU_ALT_INFO_RAM \ - "fdtfile=" FDTFILE "\0" \ - "console=ttyS0,115200\0" \ - "uuid_gpt_esp=" UUID_GPT_ESP "\0" \ - "uuid_gpt_system=" UUID_GPT_SYSTEM "\0" \ - "partitions=" PARTS_DEFAULT "\0" \ - BOOTCMD_SUNXI_COMPAT - #endif /* _SUNXI_COMMON_CONFIG_H */
participants (5)
-
Andre Przywara -
Heinrich Schuchardt -
Ilias Apalodimas -
Simon Glass -
Tom Rini