u-boot.git/boot/Makefile, branch v2025.01-rc2

x86: coreboot: Allow building an expo for editing CMOS config

2024-11-04T03:27:12Z

Coreboot provides the CMOS layout in the tables it passes to U-Boot. Use that to build an editor for the CMOS settings. Signed-off-by: Simon Glass

boot: Introduce BOOTSTD_MENU to control bootflow menu build

2024-10-24T17:19:55Z

The bootflow_menu.c code depends on e.g. scene_txt_set_font(), which is only built when CONFIG_EXPO is enabled. Introduce new Kconfig symbol BOOTSTD_MENU which depends on EXPO to prevent triggering errors like these in case e.g. CONFIG_VIDEO=n : " boot/bootflow_menu.c:158:(.text+0x8851): undefined reference to `scene_txt_set_font' " Make the symbol depend on BOOTSTD_FULL as well to get rid of the Makefile dependency workaround. Since BOOTSTD_FULL is not available in SPL, do not define SPL variant of BOOTSTD_MENU. Fix up bootflow test accordingly. Signed-off-by: Marek Vasut Reviewed-by: Simon Glass

global: Rename SPL_TPL_ to PHASE_

2024-10-11T17:44:48Z

Use PHASE_ as the symbol to select a particular XPL build. This means that SPL_TPL_ is no-longer set. Update the comment in bootstage to refer to this symbol, instead of SPL_ Signed-off-by: Simon Glass

global: Rename SPL_ to XPL_

2024-10-11T17:44:48Z

Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is no-longer set. Signed-off-by: Simon Glass

global: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILD

2024-10-11T17:44:48Z

Complete this rename for all directories outside arch/ board/ drivers/ and include/ Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass

boot: Drop unnecessary ifdef for LOAD_FIT

2024-10-11T17:44:46Z

Use the normal SPL_TPL_ approach for this option. Signed-off-by: Simon Glass Reviewed-by: Tom Rini

upl: Add support for writing a upl handoff

2024-08-09T22:03:20Z

Universal Payload provides a standard way of handing off control between two firmware phases. Add support for writing the handoff information from a structure. Signed-off-by: Simon Glass

upl: Add support for reading a upl handoff

2024-08-09T22:03:19Z

Universal Payload provides a standard way of handing off control between two firmware phases. Add support for reading the handoff information into a structure. Signed-off-by: Simon Glass

boot: provide CONFIG_BOOTMETH_QFW Kconfig parameter

2024-07-19T22:48:07Z

U-Boot is often used conjunction with QEMU to boot via EFI or syslinux. Here the QFW boot method is not needed. At least for qemu-riscv64_smode_defconfig the kernel parameter is used to specify the U-Boot binary. Trying to run U-Boot as a kernel makes no sense. Provide Kconfig parameter CONFIG_BOOTMETH_QFW to decide if the QFW boot method shall be provided. Signed-off-by: Heinrich Schuchardt Reviewed-by: Simon Glass

bootstd: Add a bootmeth for Android

2024-07-18T19:51:30Z

Android boot flow is a bit different than a regular Linux distro. Android relies on multiple partitions in order to boot. A typical boot flow would be: 1. Parse the Bootloader Control Block (BCB, misc partition) 2. If BCB requested bootonce-bootloader, start fastboot and wait. 3. If BCB requested recovery or normal android, run the following: 3.a. Get slot (A/B) from BCB 3.b. Run AVB (Android Verified Boot) on boot partitions 3.c. Load boot and vendor_boot partitions 3.d. Load device-tree, ramdisk and boot The AOSP documentation has more details at [1], [2], [3] This has been implemented via complex boot scripts such as [4]. However, these boot script are neither very maintainable nor generic. Moreover, DISTRO_DEFAULTS is being deprecated [5]. Add a generic Android bootflow implementation for bootstd. For this initial version, only boot image v4 is supported. [1] https://source.android.com/docs/core/architecture/bootloader [2] https://source.android.com/docs/core/architecture/partitions [3] https://source.android.com/docs/core/architecture/partitions/generic-boot [4] https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h [5] https://lore.kernel.org/r/all/20230914165615.1058529-17-sjg@chromium.org/ Reviewed-by: Simon Glass Reviewed-by: Julien Masson Tested-by: Guillaume La Roque Signed-off-by: Mattijs Korpershoek