Introduce a new config option: RETRY_BOOTCMD. When enabled this causes
hush shell to re-run "bootcmd" when the auto-boot counter times out.
Tested-by: Danila Tikhonov <danila@jiaxyga.com> # google-sunfish
Tested-by: Jens Reidel <adrian@mainlining.org> # xiaomi-davinci
Link: https://lore.kernel.org/r/20250331-qcom-phones-v4-2-f52e57d3b8c6@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The option ONENAND_BOOT is never set, so remove it. The option
SYS_ONENAND_BOOT was never migrated to Kconfig and any platforms which
supported that have long been removed from the code, so remove the
reference there as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
So far only VBE-simple is implemented in U-Boot. This supports a single
image which can be updated in situ.
It is often necessary to support two images (A and B) so that the board
is not bricked if the update is interrupted or is bad.
In some cases, a non-updatable recovery image is desirable, so that the
board can be returned to a known-good state in the event of a serious
failure.
Introduce ABrec which provides these features. It supports three
independent images and the logic to select the desired one on boot.
While we are here, fix a debug message to indicate the function it
called. Provide a maintainers entry for VBE.
Note that fwupdated only supports VBE-simple so far, but supports for
ABrec will appear in time.
Signed-off-by: Simon Glass <sjg@chromium.org>
VBE uses a crc8 checksum to verify that the nvdata is valid, so make
sure it is available if VBE is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
With VBE we want to use FIT in all phases of the boot. Add Kconfig
options to support this.
Disable the options for sandbox_vpl for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
This reverts commit 1fdf53ace1, reversing
changes made to e5aef1bbf1.
I had missed that this caused too much size growth on rcar3_salvator-x.
Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass <sjg@chromium.org> says:
This includes various patches towards implementing the VBE abrec
bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
fatures are available in VPL.
Link: https://lore.kernel.org/r/20241207172412.1124558-1-sjg@chromium.org
VBE uses a crc8 checksum to verify that the nvdata is valid, so make
sure it is available if VBE is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
With VBE we want to use FIT in all phases of the boot. Add Kconfig
options to support this.
Disable the options for sandbox_vpl for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
The SPL_FIT_GENERATOR is long superseded by binman, drop SPL_FIT_GENERATOR
support as there are no more users.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/22109373594b6a5d1110be9420ccd8fbb93a61d3.1730452668.git.michal.simek@amd.com
Update android bootmeth to support non-A/B image.
Enable AB support only when ANDROID_AB is enabled.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Link: https://lore.kernel.org/r/20241126-adnroidv2-v4-2-11636106dc69@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
I enabled IMX_HAB on an imx8mp board, but even though I knew about the
implementation, I forgot that I had to provide a sane value for
SPL_LOAD_FIT_ADDRESS. The help text for IMX_HAB doesn't mention this
implicit requirement, and there's no build-time warning; the default
0x0 value just ends up being returned from
board_spl_fit_buffer_addr(), obviously resulting in a non-booting
board.
The existing imx8m* board configs that set a non-zero value currently
all use 0x44000000. The actual value doesn't matter too much, but 0 is
always wrong for imx8m platforms. So just use 0x44000000 as default
for those platforms.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
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 <marek.vasut+renesas@mailbox.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_simplefb.c APIs rely on video-uclass APIs and structures to
fill/update framebuffer information, so compile it only when VIDEO
Kconfig is enabled, as otherwise below warning can be seen if VIDEO
Kconfig is disabled:
"boot/fdt_simplefb.c:96:12: warning: fdt_simplefb_enable_existing_node
defined but not used [-Wunused-function]
96 | static int fdt_simplefb_enable_existing_node(void *blob)"
Reported-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
The SPL_FIT_SOURCE is long superseded by SPL_FIT_GENERATOR which
is long superseded by binman, drop SPL_FIT_SOURCE support as there
are no more users.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by
adding a new net/lwip/ directory and the NET_LWIP symbol. Network
support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent
commits will introduce the lwIP code, re-work the NETDEVICE integration
and port some of the NET commands and features to lwIP.
SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols
that are part of NET (such as arp_init(), arp_timeout_check(),
arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be
added later.
Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP
because of dependencies on net_loop(), tftp_timeout_ms,
tftp_timeout_count_max and other NET things. Let's add a dependency on
!NET_LWIP for now.
SANDBOX can select NET_LWIP but doing so will currently disable the eth
dm tests as well as the wget tests which have strong dependencies on the
NET code.
Other adjustments to Kconfig files are made to fix "unmet direct
dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when
the default networking stack is set to NET_LWIP ("default NET_LWIP"
instead of "default NET" in Kconfig).
The networking stack is now a choice between NO_NET,
NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be
'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
:hile we had hoped to be able to remove these options finally, it was
missed that zynq still requires these currently.
This reverts commit 5b9261fb0b and
commit 099b6df556.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
The SPL_FIT_GENERATOR is long superseded by binman, drop SPL_FIT_GENERATOR
support as there are no more users.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The SPL_FIT_SOURCE is long superseded by SPL_FIT_GENERATOR which
is long superseded by binman, drop SPL_FIT_SOURCE support as there
are no more users.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
The EFI_LOADER and EFI config options are randomly scattered under lib/
making it cumbersome to navigate and enable options, unless you really
know what you are doing. On top of that the existing options are in
random order instead of a logical one.
So let's move things around a bit and move them under boot/. Present a
generic UEFI entry where people can select Capsules, Protocols,
Services, and an option to compile U-Boot as an EFI for X86
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add the basic code to create a handoff structure in SPL, so it can be
passed to the next phase. For now this is not plumbed in.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a 'upl' command to work with Universal Payload features. For now it
only supports reading and writing a handoff structure.
Signed-off-by: Simon Glass <sjg@chromium.org>
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 <sjg@chromium.org>
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 <sjg@chromium.org>
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 <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
A valid memory location to stash bootstage information at will be
architecture dependent. Move the existing defaults to the main Kconfig
file for this option and set 0x0 as the default only for sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <sjg@chromium.org>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Marek Mojík <marek.mojik@nic.cz> says:
Hello all,
this is a continuation of previous work by Pali to add support for the
Turris 1.x board. As the patches were based on u-boot v2022.04, a
nontrivial rebasing was needed.
Some notes:
- Some options that are in SD defconfig are disabled in NOR defconfig
because over the years u-boot grew and the old NOR defconfig will not
fit into NOR memory.
- SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We
were not able to fix this yet)
Add support for CZ.NIC Turris 1.x routers.
CZ.NIC Turris 1.0 (RTRS01) and 1.1 (RTRS02) are open source routers, they
have dual-core PowerPC Freescale P2020 CPU and are based on reference
Freescale P2020RDB-PC-A board design.
Hardware design is fully open source, all firmware and hardware design
files are available at Turris project website:
https://docs.turris.cz/hw/turris-1x/turris-1x/https://project.turris.cz/en/hardware.html
The P2020 BootROM can load U-Boot either from NOR flash or from SD card.
We add the new defconfigs, turris_1x_nor_defconfig, which configures
U-Boot for building the NOR image, and turris_1x_sdcard_defconfig, which
configures U-Boot for building an image suitable for SD card.
The defconfig for NOR image is stripped-down a - many config options
enabled in SD defconfig are disabled for NOR defconfig. This is because
U-Boot grew non-trivially in the last two years and it would not fit
into the space allocated for U-Boot in the NOR memory. In the future we
may try to use LTO to reduce the size of the code and enable more
options.
The design of CZ.NIC Turris 1.x routers is based on Freescale P2020RDB-PC-A
board, so some code from boards/freescale/p1_p2_rdb_pc is used and linked
into Turris 1.x board code.
Turris 1.x code in this patch uses modern distroboot and can boot Linux
kernel from various locations, including NAND, SD card, USB flash disks,
NVMe disks or SATA disks (connected to extra SATA/SCSI PCIe controllers).
Via distroboot is implemented also rescue NOR boot for factory recovery,
triggered by reset button, like on other existing Turris routers.
SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We were
not able to fix this yet)
[ Because various CONFIG_ macros were migrated to Kconfig since the last
time this worked on upstream U-Boot (in 2022), a non-trivial rebasing
was needed and some issues were solved. ]
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Reviewed-by: Marek Behún <kabel@kernel.org>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Simon reports that after enabling all algorithms on the TPM some boards
fail since they don't have enough storage to accommodate the ~5KB growth.
The choice of hash algorithms is determined by the platform and the TPM
configuration. Failing to cap a PCR in a bank which the platform left
active is a security vulnerability. It might allow unsealing of secrets
if an attacker can replay a good set of measurements into an unused bank.
If MEASURED_BOOT or EFI_TCG2_PROTOCOL is enabled our Kconfig will enable
all supported hashing algorithms. We still want to allow users to add a
TPM and not enable measured boot via EFI or bootm though and at the same
time, control the compiled algorithms for size reasons.
So let's add a function tpm2_allow_extend() which checks the TPM active
PCRs banks against the one U-Boot was compiled with. We only allow
extending PCRs if the algorithms selected during build match the TPM
configuration.
It's worth noting that this is only added for TPM2.0, since TPM1.2 is
lacking a lot of code at the moment to read the available PCR banks.
We unconditionally enable SHA1 when a TPM is selected, which is the only
hashing algorithm v1.2 supports.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook-link
This fixes a handful of typos in various help texts in Kconfig configs.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
default n doesn't need to be specified. It is default option anyway.
Similar changes have been done by commit 18370f1497 ("Kconfig: Remove all
default n/no options").
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass <sjg@chromium.org> says:
This series is the culmanation of the current line of refactoring
series. It adjusts pxe to call the booting functionality directly
rather than going through the command-line interface.
With this is is possible to boot using the extlinux bootmeth without
the command line enabled.
It also updates fastboot to do a similar thing.
Use the new CONFIG_BOOTM symbol to determine whether SYS_BOOT_LEN is
visible or not, since we want to support decompression when CMDLINE is
disabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Booting an OS does not require the 'bootm' command, so change the
condition for these options.
Move them into boot/ so they don't depend on CMDLINE
Note that CMD_BOOTM_PRE_LOAD has been put directly into the bootm code
so will need some additional refactoring (and a test!) to allow it to
change over.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Create a separate Kconfig option which enables the bootm logic,
separate from the 'bootm' command. This will eventually allow booting
without CMDLINE enabled.
Update boards which disable CMD_BOOTM to disable BOOTM instead, since
CMD_BOOTM now depends on BOOTM
Signed-off-by: Simon Glass <sjg@chromium.org>
The boot menu shows Android first and then a timestamp option. Move
these later since they are less commonly used.
Signed-off-by: Simon Glass <sjg@chromium.org>
If UEFI is enabled in U-Boot, we want it to conform to the UEFI
specification. This requires enabling the boot manager boot method.
Reported-by: E Shattow <lucent@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
With the relatively new button API in U-Boot, it's now much easier to
model the common usecase of mapping arbitrary actions to different
buttons during boot - for example entering fastboot mode, setting some
additional kernel cmdline arguments, or booting with a custom recovery
ramdisk, to name a few.
Historically, this functionality has been implemented in board code,
making it fixed for a given U-Boot binary and requiring the code be
duplicated and modified for every board.
Implement a generic abstraction to run an arbitrary command during boot
when a specific button is pressed. The button -> command mapping is
configured via environment variables with the following format:
button_cmd_N_name=<button label>
button_cmd_N=<command to run>
Where N is the mapping number starting from 0. For example:
button_cmd_0_name=vol_down
button_cmd_0=fastboot usb 0
This will cause the device to enter fastboot mode if volume down is held
during boot.
After we enter the cli loop the button commands are no longer valid,
this allows the buttons to additionally be used for navigating a boot
menu.
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Tegra30
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Some code moved from cmd/bootefi.c is actually necessary only for "bootefi
<addr>" command (starting an image manually loaded by a user using U-Boot
load commands or other methods (like JTAG debugger).
The code will never been opted out as unused code by a compiler which
doesn't know how EFI boot manager is implemented. So introduce a new
configuration, CONFIG_EFI_BINARY_EXEC, to enforce them opted out
explicitly.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Building sandbox_defconfig with
CONFIG_CMD_CEDIT=y
CONFIG_EXPO=n
fails with
cmd/cedit.c:258:(.text.do_cedit_run+0x4c):
undefined reference to `expo_apply_theme
Fix the dependencies.
Fixes: a0874dc4ac ("expo: Add a configuration editor")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
