[PATCH v4 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.
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): blk: Make functions available unconditionally bootstd: Avoid calling unavailable block functions bootstd: Avoid depending on BLK sunxi: Add a bootmeth for FEL 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 | 16 +- boot/Makefile | 1 + boot/bootdev-uclass.c | 3 + boot/bootmeth_fel.c | 84 +++++++ .../gardena-smart-gateway-mt7688_defconfig | 1 + doc/usage/environment.rst | 12 + include/blk.h | 9 +- include/configs/sunxi-common.h | 238 ------------------ 11 files changed, 269 insertions(+), 246 deletions(-) create mode 100644 board/sunxi/sunxi.env create mode 100644 boot/bootmeth_fel.c
Some boards still don't enable BLK but we want to be able to at least compile the code which relies on this. For example, bootstd includes calls to blk_...() functions, albeit with a check for BLK so that the code is eliminated by the compiler.
Reduce the scope of the BLK #ifdef to help with this.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
include/blk.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/blk.h b/include/blk.h index 1fc9a5b8471..eef6c8629e8 100644 --- a/include/blk.h +++ b/include/blk.h @@ -197,7 +197,6 @@ static inline void blkcache_free(void) {}
#endif
-#if CONFIG_IS_ENABLED(BLK) struct udevice;
/* Operations on block devices */ @@ -278,6 +277,8 @@ struct blk_ops { #endif /* CONFIG_BOUNCE_BUFFER */ };
+#if CONFIG_IS_ENABLED(BLK) + /* * These functions should take struct udevice instead of struct blk_desc, * but this is convenient for migration to driver model. Add a 'd' prefix @@ -291,6 +292,8 @@ unsigned long blk_dwrite(struct blk_desc *block_dev, lbaint_t start, unsigned long blk_derase(struct blk_desc *block_dev, lbaint_t start, lbaint_t blkcnt);
+#endif /* BLK */ + /** * blk_read() - Read from a block device * @@ -528,8 +531,10 @@ struct blk_desc *blk_get_by_device(struct udevice *dev); */ int blk_get_desc(enum uclass_id uclass_id, int devnum, struct blk_desc **descp);
-#else +#if !CONFIG_IS_ENABLED(BLK) + #include <errno.h> + /* * These functions should take struct udevice instead of struct blk_desc, * but this is convenient for migration to driver model. Add a 'd' prefix
When BLK is not enabled but BOOTSTD is, some features of standard boot become unavailable. Add a check for this in the only site that is currently apparent.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
boot/bootdev-uclass.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c index 807f8dfb064..64ec4fde493 100644 --- a/boot/bootdev-uclass.c +++ b/boot/bootdev-uclass.c @@ -434,6 +434,9 @@ int bootdev_find_by_label(const char *label, struct udevice **devp, struct uclass *uc; enum uclass_id id;
+ if (!CONFIG_IS_ENABLED(BLK)) + return -ENOSYS; + ret = label_to_uclass(label, &seq, &method_flags); if (ret < 0) return log_msg_ret("uc", ret);
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 1d50a83a2d2..ccbc113d8e2 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -400,7 +400,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"
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 ---
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 ccbc113d8e2..7b399ff00a7 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 b24f806d5bf..5bee34e8531 100644 --- a/boot/Makefile +++ b/boot/Makefile @@ -30,6 +30,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, +};
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 060636e9e2d..c6ad706dfff 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1147,7 +1147,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 @@ -1169,9 +1169,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 @@ -1179,7 +1179,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
Hi Andre,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
Regards, Simon
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit: - The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes! - However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like: - Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want? - Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Cheers, Andre
Hi Andre,
On Sun, 3 Nov 2024 at 03:36, Andre Przywara andre.przywara@arm.com wrote:
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Given that we are past rc1 the easiest thing might be to revert this:
f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups
until we can figure this out.
Can you try that?
Regards, Simon
From: Simon Glass sjg@chromium.org Date: Sun, 3 Nov 2024 07:46:44 -0700
Hi Simon,
Hi Andre,
On Sun, 3 Nov 2024 at 03:36, Andre Przywara andre.przywara@arm.com wrote:
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Given that we are past rc1 the easiest thing might be to revert this:
f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups
until we can figure this out.
Can you try that?
That will break setups that use the EFI bootmanager on platforms already converted to bootstd (such as various Rockchip boards and the Apple machines). I don't think that is acceptable as we've been shipping releases with working EFI bootmanager support on those platforms for several years already.
Hi Mark,
On Sun, 3 Nov 2024 at 09:15, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 3 Nov 2024 07:46:44 -0700
Hi Simon,
Hi Andre,
On Sun, 3 Nov 2024 at 03:36, Andre Przywara andre.przywara@arm.com wrote:
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Given that we are past rc1 the easiest thing might be to revert this:
f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups
until we can figure this out.
Can you try that?
That will break setups that use the EFI bootmanager on platforms already converted to bootstd (such as various Rockchip boards and the Apple machines). I don't think that is acceptable as we've been shipping releases with working EFI bootmanager support on those platforms for several years already.
This patch only went in in 2024.01 so I'm not sure how you have been shipping releases for several years. Are you sure those devices won't boot without bootmgr?
This issue will presumably block all bootstd migration if we don't find a solution, meaning that over 1000 boards will be stuck with the scripts, etc.
Regards, SImon
On Sun, 3 Nov 2024 at 19:06, Simon Glass sjg@chromium.org wrote:
Hi Mark,
On Sun, 3 Nov 2024 at 09:15, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 3 Nov 2024 07:46:44 -0700
Hi Simon,
Hi Andre,
On Sun, 3 Nov 2024 at 03:36, Andre Przywara andre.przywara@arm.com wrote:
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Given that we are past rc1 the easiest thing might be to revert this:
f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups
until we can figure this out.
Can you try that?
That will break setups that use the EFI bootmanager on platforms already converted to bootstd (such as various Rockchip boards and the Apple machines). I don't think that is acceptable as we've been shipping releases with working EFI bootmanager support on those platforms for several years already.
This patch only went in in 2024.01 so I'm not sure how you have been shipping releases for several years. Are you sure those devices won't boot without bootmgr?
This issue will presumably block all bootstd migration if we don't find a solution, meaning that over 1000 boards will be stuck with the scripts, etc.
I think we can be a little less melodramatic, I mean after all that's what they've been using up until now.
From: Simon Glass sjg@chromium.org Date: Sun, 3 Nov 2024 12:06:41 -0700
Hi Simon,
Hi Mark,
On Sun, 3 Nov 2024 at 09:15, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 3 Nov 2024 07:46:44 -0700
Hi Simon,
Hi Andre,
On Sun, 3 Nov 2024 at 03:36, Andre Przywara andre.przywara@arm.com wrote:
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Given that we are past rc1 the easiest thing might be to revert this:
f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups
until we can figure this out.
Can you try that?
That will break setups that use the EFI bootmanager on platforms already converted to bootstd (such as various Rockchip boards and the Apple machines). I don't think that is acceptable as we've been shipping releases with working EFI bootmanager support on those platforms for several years already.
This patch only went in in 2024.01 so I'm not sure how you have been shipping releases for several years. Are you sure those devices won't boot without bootmgr?
The old distrboot scripts call the bootmgr; see the BOOTENV_EFI_BOOTMGR define in include/config_distro_bootcmd.h. So before boards were converted to standard boot they had a working EFI bootmanager. When bootstd was introduced that broke, and the patch you mention fixed that. So yes, reverting that patch would remove functionality that has been there for several years.
This issue will presumably block all bootstd migration if we don't find a solution, meaning that over 1000 boards will be stuck with the scripts, etc.
Then let's fix the bootstd implementation.
Regards, SImon
Date: Sun, 3 Nov 2024 10:36:26 +0000 From: Andre Przywara andre.przywara@arm.com
Hi Andre,
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
The issue here is that the EFI bootmanager by its very nature considers all possible devices for which boot options have been included in the BootOptions EFI variable. So if you have enabled bootmeth_efi_mgr (and you probably should), and you have an active boot option (that is a boot option that is included in the BootOptions EFI variable) that points at eMMC or USB, it will try too boot using that boot option. So you'd think things would be fine as long as you don't add boot options for eMMC or USB to the BootOrder variable.
Unfortunately the EFI_LOADER code will automatically generate media device boot options for all the block devices that get added and adds those to the BootOrder variables in an attempt to implement the requirement to boot from removable media if everything else fails. But I think that's a mistake. I can't find a requirement to add boot options for these in the spec, let alone a requirement to add those to BootOrder. I suppose this fallback could be implemented as a separate bootmeth that can be low priority.
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Cheers, Andre
On Sun, 03 Nov 2024 18:54:38 +0100 Mark Kettenis mark.kettenis@xs4all.nl wrote:
Hi Mark,
Date: Sun, 3 Nov 2024 10:36:26 +0000 From: Andre Przywara andre.przywara@arm.com
Hi Andre,
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
The issue here is that the EFI bootmanager by its very nature considers all possible devices for which boot options have been included in the BootOptions EFI variable. So if you have enabled bootmeth_efi_mgr (and you probably should), and you have an active boot option (that is a boot option that is included in the BootOptions EFI variable) that points at eMMC or USB, it will try too boot using
I think that's the point: sunxi is one of the platforms that doesn't feature persistent UEFI variables, at least not when set via UEFI RT services. So we don't typically have any UEFI variables to help us point at the right boot location, which leaves us only with ...
that boot option. So you'd think things would be fine as long as you don't add boot options for eMMC or USB to the BootOrder variable.
Unfortunately the EFI_LOADER code will automatically generate media device boot options for all the block devices that get added and adds those to the BootOrder variables in an attempt to implement the requirement to boot from removable media if everything else fails.
... exactly removable media. So UEFI boot so far was relying on efi/boot/bootaa64.efi, though I think you can construct a more specific entry by manually setting (and storing!) this on the U-Boot shell.
Another complication is that very often microSD cards are either the only or the preferred "hard disk" for those boards, and they are surely removable, even though in those scenarios they are treated more like "fixed" disks.
The Allwinner BootROM is writing a boot source ID into SRAM, so we know whether we were booted from SD card, eMMC, or SPI flash, and set $mmc_bootdev accordingly. I need to check whether and how this is reflected in bootstd.
But I think that's a mistake. I can't find a requirement to add boot options for these in the spec, let alone a requirement to add those to BootOrder. I suppose this fallback could be implemented as a separate bootmeth that can be low priority.
Yeah, I also feel like splitting this up might help. So one bootmeth for removable media, and one BootOrder variable based.
But I think the culprit in this particular situation is this "global" flag, which makes it live outside of the priority scheme, IIUC: "When global bootmeths are available, these are typically checked before the above bootdev scanning."
Not sure if there is a good solution to this problem? Maybe check at least the boot device first, for all bootmeth's, and only then consult global bootmeth's? But then again we want to current behaviour for FEL script booting, I wonder if this could be modelled as some pseudo bootdev instead of marked as global (because we are booting via the BootROM's USB-OTG routines in this case).
Cheers, Andre
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Cheers, Andre
Date: Mon, 4 Nov 2024 13:34:29 +0000 From: Andre Przywara andre.przywara@arm.com
On Sun, 03 Nov 2024 18:54:38 +0100 Mark Kettenis mark.kettenis@xs4all.nl wrote:
Hi Mark,
Date: Sun, 3 Nov 2024 10:36:26 +0000 From: Andre Przywara andre.przywara@arm.com
Hi Andre,
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
The issue here is that the EFI bootmanager by its very nature considers all possible devices for which boot options have been included in the BootOptions EFI variable. So if you have enabled bootmeth_efi_mgr (and you probably should), and you have an active boot option (that is a boot option that is included in the BootOptions EFI variable) that points at eMMC or USB, it will try too boot using
I think that's the point: sunxi is one of the platforms that doesn't feature persistent UEFI variables, at least not when set via UEFI RT services. So we don't typically have any UEFI variables to help us point at the right boot location, which leaves us only with ...
Right. One of the suggested solutions for this was to store EFI variables on the ESP in a well-defined format and have the OS update that file directly. Ilias posted a diff for that some time ago, but I don't think this was committed. I did some testing of that approach on OpenBSD and I'm fairly confident I could make it work. But you'd probably need support from at least a few Linux distros to make this feasable. Anyway...
that boot option. So you'd think things would be fine as long as you don't add boot options for eMMC or USB to the BootOrder variable.
Unfortunately the EFI_LOADER code will automatically generate media device boot options for all the block devices that get added and adds those to the BootOrder variables in an attempt to implement the requirement to boot from removable media if everything else fails.
... exactly removable media. So UEFI boot so far was relying on efi/boot/bootaa64.efi, though I think you can construct a more specific entry by manually setting (and storing!) this on the U-Boot shell.
You can. But I don't think that is something you could expect the average user to do.
Another complication is that very often microSD cards are either the only or the preferred "hard disk" for those boards, and they are surely removable, even though in those scenarios they are treated more like "fixed" disks.
Well "removable media" is a bit of a misnomer here. The current UEFI spec says:
Searching for a default application to boot happens on both removable and fixed media types.
So the fallback actually needs to happen on "fixed" disks as well. At least that is what most UEFI implementations do (and is what EDK2 does). At this point OpenBSD (on all architectures, include amd64) pretty much relies on this as we don't configure any boot options at the moment. And it works on 99% of the machines out there.
The Allwinner BootROM is writing a boot source ID into SRAM, so we know whether we were booted from SD card, eMMC, or SPI flash, and set $mmc_bootdev accordingly. I need to check whether and how this is reflected in bootstd.
But I think that's a mistake. I can't find a requirement to add boot options for these in the spec, let alone a requirement to add those to BootOrder. I suppose this fallback could be implemented as a separate bootmeth that can be low priority.
Yeah, I also feel like splitting this up might help. So one bootmeth for removable media, and one BootOrder variable based.
But I think the culprit in this particular situation is this "global" flag, which makes it live outside of the priority scheme, IIUC: "When global bootmeths are available, these are typically checked before the above bootdev scanning."
Not sure if there is a good solution to this problem? Maybe check at least the boot device first, for all bootmeth's, and only then consult global bootmeth's? But then again we want to current behaviour for FEL script booting, I wonder if this could be modelled as some pseudo bootdev instead of marked as global (because we are booting via the BootROM's USB-OTG routines in this case).
To some extent, we already have a solution. We have BOOTMETH_EFILOADER, which is a per-device boot method which loads the default application. So that pretty much does what's needed for the fallback.
So if it was possible to disabled the autogeneration of the default media boot options you'd probably be closer to what you want for sunxi. I believe that'd make you lose the EFI boot menu options for the different devices though. So maybe the solution is for BOOTMETH_EFI_MGR to simply skip the autogenerated options and let BOOTMETH_EFILOADER take care of those?
Cheers,
Mark
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Cheers, Andre
H Mark, Peter,
On Mon, 4 Nov 2024 at 08:29, Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Mon, 4 Nov 2024 13:34:29 +0000 From: Andre Przywara andre.przywara@arm.com
On Sun, 03 Nov 2024 18:54:38 +0100 Mark Kettenis mark.kettenis@xs4all.nl wrote:
Hi Mark,
Date: Sun, 3 Nov 2024 10:36:26 +0000 From: Andre Przywara andre.przywara@arm.com
Hi Andre,
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
The issue here is that the EFI bootmanager by its very nature considers all possible devices for which boot options have been included in the BootOptions EFI variable. So if you have enabled bootmeth_efi_mgr (and you probably should), and you have an active boot option (that is a boot option that is included in the BootOptions EFI variable) that points at eMMC or USB, it will try too boot using
I think that's the point: sunxi is one of the platforms that doesn't feature persistent UEFI variables, at least not when set via UEFI RT services. So we don't typically have any UEFI variables to help us point at the right boot location, which leaves us only with ...
Right. One of the suggested solutions for this was to store EFI variables on the ESP in a well-defined format and have the OS update that file directly. Ilias posted a diff for that some time ago, but I don't think this was committed. I did some testing of that approach on OpenBSD and I'm fairly confident I could make it work. But you'd probably need support from at least a few Linux distros to make this feasable. Anyway...
that boot option. So you'd think things would be fine as long as you don't add boot options for eMMC or USB to the BootOrder variable.
Unfortunately the EFI_LOADER code will automatically generate media device boot options for all the block devices that get added and adds those to the BootOrder variables in an attempt to implement the requirement to boot from removable media if everything else fails.
... exactly removable media. So UEFI boot so far was relying on efi/boot/bootaa64.efi, though I think you can construct a more specific entry by manually setting (and storing!) this on the U-Boot shell.
You can. But I don't think that is something you could expect the average user to do.
Another complication is that very often microSD cards are either the only or the preferred "hard disk" for those boards, and they are surely removable, even though in those scenarios they are treated more like "fixed" disks.
Well "removable media" is a bit of a misnomer here. The current UEFI spec says:
Searching for a default application to boot happens on both removable and fixed media types.
So the fallback actually needs to happen on "fixed" disks as well. At least that is what most UEFI implementations do (and is what EDK2 does). At this point OpenBSD (on all architectures, include amd64) pretty much relies on this as we don't configure any boot options at the moment. And it works on 99% of the machines out there.
The Allwinner BootROM is writing a boot source ID into SRAM, so we know whether we were booted from SD card, eMMC, or SPI flash, and set $mmc_bootdev accordingly. I need to check whether and how this is reflected in bootstd.
But I think that's a mistake. I can't find a requirement to add boot options for these in the spec, let alone a requirement to add those to BootOrder. I suppose this fallback could be implemented as a separate bootmeth that can be low priority.
Yeah, I also feel like splitting this up might help. So one bootmeth for removable media, and one BootOrder variable based.
But I think the culprit in this particular situation is this "global" flag, which makes it live outside of the priority scheme, IIUC: "When global bootmeths are available, these are typically checked before the above bootdev scanning."
Not sure if there is a good solution to this problem? Maybe check at least the boot device first, for all bootmeth's, and only then consult global bootmeth's? But then again we want to current behaviour for FEL script booting, I wonder if this could be modelled as some pseudo bootdev instead of marked as global (because we are booting via the BootROM's USB-OTG routines in this case).
To some extent, we already have a solution. We have BOOTMETH_EFILOADER, which is a per-device boot method which loads the default application. So that pretty much does what's needed for the fallback.
So if it was possible to disabled the autogeneration of the default media boot options you'd probably be closer to what you want for sunxi. I believe that'd make you lose the EFI boot menu options for the different devices though. So maybe the solution is for BOOTMETH_EFI_MGR to simply skip the autogenerated options and let BOOTMETH_EFILOADER take care of those?
Cheers,
Mark
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Cheers, Andre
I am not seeing an obvious solution here, certainly not one we can implement at rc1.
Perhaps, Mark, you can carry a patch for your needs until we sort this out? I certainly did not understand the complexities introduced by the patch[1] to enable bootmgr within bootstd.
Regards, SImon
[1] f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups
From: Simon Glass sjg@chromium.org Date: Tue, 5 Nov 2024 08:14:53 -0700
Heinrich, did you see this discussion concerning the EFI boot manager?
Simon,
H Mark, Peter,
On Mon, 4 Nov 2024 at 08:29, Mark Kettenis mark.kettenis@xs4all.nl wrote:
Date: Mon, 4 Nov 2024 13:34:29 +0000 From: Andre Przywara andre.przywara@arm.com
On Sun, 03 Nov 2024 18:54:38 +0100 Mark Kettenis mark.kettenis@xs4all.nl wrote:
Hi Mark,
Date: Sun, 3 Nov 2024 10:36:26 +0000 From: Andre Przywara andre.przywara@arm.com
Hi Andre,
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote: > > 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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
The issue here is that the EFI bootmanager by its very nature considers all possible devices for which boot options have been included in the BootOptions EFI variable. So if you have enabled bootmeth_efi_mgr (and you probably should), and you have an active boot option (that is a boot option that is included in the BootOptions EFI variable) that points at eMMC or USB, it will try too boot using
I think that's the point: sunxi is one of the platforms that doesn't feature persistent UEFI variables, at least not when set via UEFI RT services. So we don't typically have any UEFI variables to help us point at the right boot location, which leaves us only with ...
Right. One of the suggested solutions for this was to store EFI variables on the ESP in a well-defined format and have the OS update that file directly. Ilias posted a diff for that some time ago, but I don't think this was committed. I did some testing of that approach on OpenBSD and I'm fairly confident I could make it work. But you'd probably need support from at least a few Linux distros to make this feasable. Anyway...
that boot option. So you'd think things would be fine as long as you don't add boot options for eMMC or USB to the BootOrder variable.
Unfortunately the EFI_LOADER code will automatically generate media device boot options for all the block devices that get added and adds those to the BootOrder variables in an attempt to implement the requirement to boot from removable media if everything else fails.
... exactly removable media. So UEFI boot so far was relying on efi/boot/bootaa64.efi, though I think you can construct a more specific entry by manually setting (and storing!) this on the U-Boot shell.
You can. But I don't think that is something you could expect the average user to do.
Another complication is that very often microSD cards are either the only or the preferred "hard disk" for those boards, and they are surely removable, even though in those scenarios they are treated more like "fixed" disks.
Well "removable media" is a bit of a misnomer here. The current UEFI spec says:
Searching for a default application to boot happens on both removable and fixed media types.
So the fallback actually needs to happen on "fixed" disks as well. At least that is what most UEFI implementations do (and is what EDK2 does). At this point OpenBSD (on all architectures, include amd64) pretty much relies on this as we don't configure any boot options at the moment. And it works on 99% of the machines out there.
The Allwinner BootROM is writing a boot source ID into SRAM, so we know whether we were booted from SD card, eMMC, or SPI flash, and set $mmc_bootdev accordingly. I need to check whether and how this is reflected in bootstd.
But I think that's a mistake. I can't find a requirement to add boot options for these in the spec, let alone a requirement to add those to BootOrder. I suppose this fallback could be implemented as a separate bootmeth that can be low priority.
Yeah, I also feel like splitting this up might help. So one bootmeth for removable media, and one BootOrder variable based.
But I think the culprit in this particular situation is this "global" flag, which makes it live outside of the priority scheme, IIUC: "When global bootmeths are available, these are typically checked before the above bootdev scanning."
Not sure if there is a good solution to this problem? Maybe check at least the boot device first, for all bootmeth's, and only then consult global bootmeth's? But then again we want to current behaviour for FEL script booting, I wonder if this could be modelled as some pseudo bootdev instead of marked as global (because we are booting via the BootROM's USB-OTG routines in this case).
To some extent, we already have a solution. We have BOOTMETH_EFILOADER, which is a per-device boot method which loads the default application. So that pretty much does what's needed for the fallback.
So if it was possible to disabled the autogeneration of the default media boot options you'd probably be closer to what you want for sunxi. I believe that'd make you lose the EFI boot menu options for the different devices though. So maybe the solution is for BOOTMETH_EFI_MGR to simply skip the autogenerated options and let BOOTMETH_EFILOADER take care of those?
Cheers,
Mark
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Cheers, Andre
I am not seeing an obvious solution here, certainly not one we can implement at rc1.
Perhaps, Mark, you can carry a patch for your needs until we sort this out? I certainly did not understand the complexities introduced by the patch[1] to enable bootmgr within bootstd.
Well obviously that is possible. But it doesn't make sense to me. I don't think we should convert more boards to use standard boot if that means that U-Boot's EFI bootmanager can't be used for booting those boards.
Another thing that doesn't make sense to me is that if you revert that commit, the efi_mgr bootmeth only "works" in sandbox. At that point enabling it by default makes no sense anymore.
If you really wanted to switch sunxi to use standard boot and drop the EFI bootmanager support, I think you should just disable BOOTMETH_EFI_BOOTMGR option for sunxi.
Regards, SImon
[1] f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups
On Mon, 04 Nov 2024 16:29:20 +0100 Mark Kettenis mark.kettenis@xs4all.nl wrote:
Hi Mark, Simon,
Date: Mon, 4 Nov 2024 13:34:29 +0000 From: Andre Przywara andre.przywara@arm.com
On Sun, 03 Nov 2024 18:54:38 +0100 Mark Kettenis mark.kettenis@xs4all.nl wrote:
Hi Mark,
Date: Sun, 3 Nov 2024 10:36:26 +0000 From: Andre Przywara andre.przywara@arm.com
Hi Andre,
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
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(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
The issue here is that the EFI bootmanager by its very nature considers all possible devices for which boot options have been included in the BootOptions EFI variable. So if you have enabled bootmeth_efi_mgr (and you probably should), and you have an active boot option (that is a boot option that is included in the BootOptions EFI variable) that points at eMMC or USB, it will try too boot using
I think that's the point: sunxi is one of the platforms that doesn't feature persistent UEFI variables, at least not when set via UEFI RT services. So we don't typically have any UEFI variables to help us point at the right boot location, which leaves us only with ...
Right. One of the suggested solutions for this was to store EFI variables on the ESP in a well-defined format and have the OS update that file directly. Ilias posted a diff for that some time ago, but I don't think this was committed. I did some testing of that approach on OpenBSD and I'm fairly confident I could make it work. But you'd probably need support from at least a few Linux distros to make this feasable. Anyway...
that boot option. So you'd think things would be fine as long as you don't add boot options for eMMC or USB to the BootOrder variable.
Unfortunately the EFI_LOADER code will automatically generate media device boot options for all the block devices that get added and adds those to the BootOrder variables in an attempt to implement the requirement to boot from removable media if everything else fails.
... exactly removable media. So UEFI boot so far was relying on efi/boot/bootaa64.efi, though I think you can construct a more specific entry by manually setting (and storing!) this on the U-Boot shell.
You can. But I don't think that is something you could expect the average user to do.
Exactly, I don't think anyone really does that outside of testing.
Another complication is that very often microSD cards are either the only or the preferred "hard disk" for those boards, and they are surely removable, even though in those scenarios they are treated more like "fixed" disks.
Well "removable media" is a bit of a misnomer here. The current UEFI spec says:
Searching for a default application to boot happens on both removable and fixed media types.
Ah, has that changed lately? I remember that was always a problem years ago, when this was quite PC centric, where CD-ROM / USB stick vs. harddisk was a quite clear distinction. And I dimly remember some Linux distribution were ignoring this anyway already, to make things work?
So the fallback actually needs to happen on "fixed" disks as well. At least that is what most UEFI implementations do (and is what EDK2 does). At this point OpenBSD (on all architectures, include amd64) pretty much relies on this as we don't configure any boot options at the moment. And it works on 99% of the machines out there.
Well, that certainly sounds good enough for me. While I wish it would behave like "real computers", the reality in sunxi land is somewhat different, and there are a lot of people still using some custom boot scripts.
The Allwinner BootROM is writing a boot source ID into SRAM, so we know whether we were booted from SD card, eMMC, or SPI flash, and set $mmc_bootdev accordingly. I need to check whether and how this is reflected in bootstd.
But I think that's a mistake. I can't find a requirement to add boot options for these in the spec, let alone a requirement to add those to BootOrder. I suppose this fallback could be implemented as a separate bootmeth that can be low priority.
Yeah, I also feel like splitting this up might help. So one bootmeth for removable media, and one BootOrder variable based.
But I think the culprit in this particular situation is this "global" flag, which makes it live outside of the priority scheme, IIUC: "When global bootmeths are available, these are typically checked before the above bootdev scanning."
Not sure if there is a good solution to this problem? Maybe check at least the boot device first, for all bootmeth's, and only then consult global bootmeth's? But then again we want to current behaviour for FEL script booting, I wonder if this could be modelled as some pseudo bootdev instead of marked as global (because we are booting via the BootROM's USB-OTG routines in this case).
To some extent, we already have a solution. We have BOOTMETH_EFILOADER, which is a per-device boot method which loads the default application. So that pretty much does what's needed for the fallback.
Ah, so that is separate, right? In that case just BOOTMETH_EFILOADER sounds good enough for me!
So if it was possible to disabled the autogeneration of the default media boot options you'd probably be closer to what you want for sunxi. I believe that'd make you lose the EFI boot menu options for the different devices though. So maybe the solution is for BOOTMETH_EFI_MGR to simply skip the autogenerated options and let BOOTMETH_EFILOADER take care of those?
Not sure if that breaks something else, but could we just disable CONFIG_EFI_BOOTMETH_EFI_BOOTMGR for sunxi? default y if !ARCH_SUNXI? At least for now, until this is sorted? As this would probably unblock this series. I need to test this at home, but if the old boot scripts and bootaa64.efi still work in the right order, I am happy with bootstd.
Cheers, Andre
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Cheers, Andre
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 cd5107d287c..63eb739f28b 100644 --- a/Makefile +++ b/Makefile @@ -1863,6 +1863,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 cc33d3ec0f2..379125a1982 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.
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 ---
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 (4)
-
Andre Przywara -
Mark Kettenis -
Peter Robinson -
Simon Glass