| Age | Commit message (Collapse) | Author |
|---|
|
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 <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/22109373594b6a5d1110be9420ccd8fbb93a61d3.1730452668.git.michal.simek@amd.com
|
|
Platform has been switched to binman that's why there is no need for this
script and also Kconfig symbols.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/cf438091e43c4c9d535a9cfa2886673aa42a4370.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 <[email protected]>
Signed-off-by: Guillaume La Roque <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Signed-off-by: Baruch Siach <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Devarsh Thakkar <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
|
|
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 <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
:hile we had hoped to be able to remove these options finally, it was
missed that zynq still requires these currently.
This reverts commit 5b9261fb0b1ed087387f2036d279fd3f4bb20a61 and
commit 099b6df556c95f5d06864612e9199eab7ba50ed3.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Read the UPL early in boot so that it is available. For now none of the
information is used.
Signed-off-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Mattijs Korpershoek <[email protected]> says:
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:
a. Get slot (A/B) from BCB
b. Run AVB (Android Verified Boot) on boot partitions
c. Load boot and vendor_boot partitions
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.
This has been tested on sandbox using:
$ ./test/py/test.py --bd sandbox --build -k test_ut
This has also been tested on the AM62X SK EVM using TI's Android SDK[6]
To test on TI board, the following (WIP) patch is needed as well:
https://gitlab.baylibre.com/baylibre/ti/ti-u-boot/-/commit/84cceb912bccd7cdd7f9dd69bca0e5d987a1fd04
[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/[email protected]/
[6] https://software-dl.ti.com/processor-sdk-android/esd/AM62X/09_02_00/docs/android/Overview.html
|
|
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/[email protected]/
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Julien Masson <[email protected]>
Tested-by: Guillaume La Roque <[email protected]>
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Marek Mojík <[email protected]> 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 <[email protected]>
Signed-off-by: Marek Mojík <[email protected]>
Reviewed-by: Marek Behún <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Simon Glass <[email protected]> # chromebook-link
|
|
Prepare v2024.07-rc5
|
|
Correct the links to the FIT documentation in boot/Kconfig.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
This fixes a handful of typos in various help texts in Kconfig configs.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
default n doesn't need to be specified. It is default option anyway.
Similar changes have been done by commit 18370f14975c ("Kconfig: Remove all
default n/no options").
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
enabled""
As reported by Jonas Karlman this series breaks booting on some AArch64
platforms with common use cases. For now the best path forward is to
revert the series.
This reverts commit 777c28460947371ada40868dc994dfe8537d7115, reversing
changes made to ab3453e7b12daef47b9e91da2a2a3d48615dc6fc.
Link: https://lore.kernel.org/u-boot/[email protected]/
Signed-off-by: Tom Rini <[email protected]>
|
|
Simon Glass <[email protected]> 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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]> # Tegra30
Signed-off-by: Caleb Connolly <[email protected]>
|
|
We need BOOTSTD_DEFAULT when BOOTSTD_FULL is selected.
Signed-off-by: Shantur Rathore <[email protected]>
|
|
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 <[email protected]>
|
|
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: a0874dc4ac71 ("expo: Add a configuration editor")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The "fdt" command is convenient for making small changes to the OS FDT,
especially during development. This is easy when the kernel and FDT are
loaded separately, but can be cumbersome for FIT images, requiring to
unpack the image, manually apply overlays, etc.
Add an option to execute a command "fdt_fixup" from the environment at
the beginning of image_setup_libfdt() (after overlays are applied, and
before the other fixups).
Signed-off-by: Matthias Schiffer <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Now that efi_loader subsystem provides interfaces that are equivalent
with bootefi command, we can replace command invocations with APIs.
Signed-off-by: AKASHI Takahiro <[email protected]>
|
|
At present bootstd requires CONFIG_CMDLINE to operate. Add a new
'programmatic' boot which can be used when no command line is available.
For now it does almost nothing, since most bootmeths require the
command line.
Signed-off-by: Simon Glass <[email protected]>
|
|
In order for a predefined "preboot" or "bootcmd" to be executed by the
running system we must have a command line. Add CMDLINE as a
dependency.
Signed-off-by: Tom Rini <[email protected]>
|
|
As this particular bootmeth requires the command line and assorted
commands to function, make sure we have CMDLINE enabled.
Signed-off-by: Tom Rini <[email protected]>
|
|
This particular option is required for booting all image types,
regardless of if we are starting an OS via command line or something
else. Move the question for SYS_BOOTM_LEN to be by the question for
LEGACY_IMAGE_FORMAT, as that's where our generic OS questions start.
Signed-off-by: Tom Rini <[email protected]>
|
|
We split BOOT_DEFAULTS to have BOOT_DEFAULTS_FEATURES and
BOOT_DEFAULTS_CMDS that in turn list general features or commands that
we want enabled when BOOT_DEFAULTS is selected. We only select
BOOT_DEFAULTS_CMDS if CMDLINE is set.
Signed-off-by: Tom Rini <[email protected]>
|
|
The implementation of DISTRO_DEFAULTS is done in environment scripts and
requires the command line in order to work. Because of this, select
CMDLINE here.
Signed-off-by: Tom Rini <[email protected]>
|
|
Make AUTOBOOT depend on CMDLINE since it is mostly meaningless without it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
