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>
ret is assigned a value 0 which is never used but
is immediately overwritten in the next statement.
Addresses-Coverity-ID: 453304 ("Unused value")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The 'return 0;' statement is not reachable. Remove it.
'else' is superfluous after an if statement with return.
Addresses-Coverity-ID: 352451 ("Logically dead code")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Sometimes, when only one bootdev is available, and it fails to probe, we
end up in an infinite loop calling probe() on the same device over and
over. With only debug level log output.
Break the loop if we fail to probe the same device twice in a row, and
promote the probe failure message to log_warning().
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
At this point, EFI boot manager interfaces is fully independent from
bootefi command. So just rename the configuration parameter.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.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>
ab_control_store() can return an error if writing to disk fails.
In this case, we have to pass the error code to the caller.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
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>
Sometimes the kernel is built as an EFI application rather than a
binary. We still want to support compression for this case.
For arm64 the entry point is set later in the bootm_load_os() function,
since these images are typically relocated due to the 2MB-alignment
requirement of arm64 images. But since the EFI image is not in the same
format, we need to update the entry point earlier.
Set the entry point always, for kernel_noload to resolve this problem.
It should be harmless to do this always.
Signed-off-by: Simon Glass <sjg@chromium.org>
If line overflows readline it will not be returned, fix this behavior,
make it optional and documented properly.
Signed-off-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20240105072212.6615-6-clamor95@gmail.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
If we call efi_binary_run() with size parameter set to zero, we get an error
Not a PE-COFF file
Fill the missing value.
Fixes: 1373ffde52 ("Merge tag 'v2024.01-rc5' into next")
Fixes: 7017fc54a5 ("bootmeth: use efi_loader interfaces instead of bootefi command")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass <sjg@chromium.org> says:
This series continues refactoring the bootm code to allow it to be used
with CONFIG_COMMAND disabled. The OS-handling code is refactored and
a new bootm_run() function is created to run through the bootm stages.
This completes the work.
A booti_go() function is created also, in case it proves useful, but at
last for now standard boot does not use this.
This is cmdd (part d of CMDLINE refactoring)
It depends on dm/bootstda-working
which depends on dm/cmdc-working
Create a common function used by the three existing bootz/i/m_run()
functions, to reduce duplicated code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
In a few places, the booti command is used to handle a boot. We want
these to be done without needing CONFIG_CMDLINE, so add a new
booti_run() function to handle this.
So far this is not used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
In a few places, the bootz command is used to handle a boot. We want
these to be done without needing CONFIG_CMDLINE, so add a new
bootz_run() function to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
In quite a few places, the bootm command is used to handle a boot. We
want these to be done without needing CONFIG_CMDLINE, so add a new
bootm_run() function to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Use struct bootm_info with this function, to avoiding needing to
create a new one.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Rename the function to bootm_run_states() to better indicate ts
purpose. The 'do_' prefix is used to indicate a command processor,
which this is now not.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Use the bootm_info struct to hold the information required by bootm.
Now that none of the functions called from do_bootm_states() needs an
argv[] list, change the arguments of do_bootm_states() as well. Take
care to use the same value for boot_progress even though it is a little
inconsistent.
For booti make sure it only uses argv[] and argc at the top of the
function, so we can eventually refactor to remove these parameters.
With bootm, some OSes need access to the arguments provided to the
command, so set these up in the bootm_info struct, for bootm only.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This is an exported function, so move the function comment to the
bootm.h header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add fields for the three bootm parameters and other things needed for
booting. Also add a helper to set up the struct correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adjust boot_os_fn to use struct bootm_info instead of the separate
argc, argv and image parameters. Update the handlers accordingly. Few
of the functions make use of the arguments, so this improves code size
slightly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Use reset_cpu() to reset the board, copying the logic from the 'reset'
command. This makes more sense than directly calling the do_reset()
function with the arguments passsed to the bootm command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
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 <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In general terms, we -include include/linux/kconfig.h and so normal
U-Boot code does not need to also #include it. However, for code which
is shared with userspace we may need to add it so that either our full
config is available or so that macros such as CONFIG_IS_ENABLED() can be
evaluated. In this case make sure that we guard these includes with a
test for USE_HOSTCC so that it clear as to why we're doing this.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
extlinux.conf can set fdtdir. fdtdir look for fdt file using
information found in the environment variable. The function does
not report any error in the case the file is not found
Scanning for bootflows in all bootdevs
Seq Method State Uclass Part Name Filename
--- ----------- ------ -------- ---- ------------------------ ----------------
Scanning global bootmeth 'efi_mgr':
No EFI system partition
No EFI system partition
Failed to persist EFI variables
Scanning bootdev 'mmc@fa10000.bootdev':
0 extlinux ready mmc 1 mmc@fa10000.bootdev.part_ /boot/extlinux/extlinux.conf
** Booting bootflow 'mmc@fa10000.bootdev.part_1' with extlinux
1: am62x-sk-buildroot
Retrieving file: /boot/Image
append: console=ttyS2,115200n8 root=PARTUUID=c586a30c-0bf1-4323-aba8-779c814ee135 rw
rootfstype=ext4 rootwait earlycon=ns16550a,mmio32,0x02800000
Retrieving file: /boot/k3-am623_ccm_m3.dtb
Skipping fdtdir /boot/ for failure retrieving dts
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit 51bb33846a ("bootm: Support string substitution in
bootargs") introduced a feature of bootargs string substitution
and changed a flag used in bootm_process_cmdline_env() call
to be either true or false. With this flag value,
condition in bootm_process_cmdline()
`if (flags & BOOTM_CL_SUBST)` is never true
and process_subst() is never called.
Add a simple test to verify if substitution works OK.
Signed-off-by: Piotr Kubik <piotr.kubik@iopsys.eu>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <takahiro.akashi@linaro.org>
To quote the author:
This little series corrects a problem I noticed with arm64 images,
where the kernel is not recognised if compression is used:
U-Boot> tftp image.fit
Using ethernet@7d580000 device
TFTP from server 192.168.4.7; our IP address is 192.168.4.147
Filename 'image.fit'.
Load address: 0x1000000
Loading: ################################################## 23 MiB
20.5 MiB/s
done
Bytes transferred = 24118272 (1700400 hex)
U-Boot> bootm
## Loading kernel from FIT Image at 01000000 ...
Using 'conf-768' configuration
Trying 'kernel' kernel subimage
Description: Linux
Type: Kernel Image (no loading done)
Compression: gzip compressed
Data Start: 0x01000120
Data Size: 13662338 Bytes = 13 MiB
Verifying Hash Integrity ... OK
Bad Linux ARM64 Image magic!
With this series:
U-Boot> tftp 20000000 image.fit
Using ethernet@7d580000 device
TFTP from server 192.168.4.7; our IP address is 192.168.4.147
Filename 'image.fit'.
Load address: 0x20000000
Loading: ################################################## 23.5 MiB
20.8 MiB/s
done
Bytes transferred = 24642560 (1780400 hex)
U-Boot> bootm 0x20000000
## Loading kernel from FIT Image at 20000000 ...
Using 'conf-768' configuration
Trying 'kernel' kernel subimage
Description: Linux
Type: Kernel Image (no loading done)
Compression: zstd compressed
Data Start: 0x20000120
Data Size: 14333475 Bytes = 13.7 MiB
Verifying Hash Integrity ... OK
Using kernel load address 80000
## Loading fdt from FIT Image at 20000000 ...
Using 'conf-768' configuration
Trying 'fdt-768' fdt subimage
Description: Raspberry Pi 4 Model B
Type: Flat Device Tree
Compression: zstd compressed
Data Start: 0x215f820c
Data Size: 9137 Bytes = 8.9 KiB
Architecture: AArch64
Verifying Hash Integrity ... OK
Uncompressing Flat Device Tree to 3aff3010
Booting using the fdt blob at 0x3aff3010
Working FDT set to 3aff3010
Uncompressing Kernel Image (no loading done) to 80000
Moving Image from 0x80000 to 0x200000, end=2b00000
Using Device Tree in place at 000000003aff3010, end 000000003afff4c4
Working FDT set to 3aff3010
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
The problem is that the arm64 magic is checked before the image is
decompressed. However this is only part of it. The kernel_noload image
type doesn't work with compression, since the kernel is not loaded. So
this series deals with that by using an lmb-allocated buffer for the
uncompressed kernel.
Another issue is that the arm64 handling is done too early, before the
image is loaded. This series moves it to after loading, so that
compression can be handled.
A patch is included to show the kernel load-address, so it is easy to
see what is going on.
One annoying feature of arm64 is that the image is often copied to
another address. It might be possible for U-Boot to figure that out
earlier and decompress it to the right place, but perhaps not.
With all of this it should be possible to boot a compressed kernel on
any of the 990 arm64 boards supported by Linux, although I have only
tested two.
It is not currently possible to execute the kernel in-place without
loading it. Use lmb to allocate memory for it.
Co-developed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
If the image is compressed, then the existing check fails, since the
header is wrong.
Move the check later in the boot process, after the kernel is
decompressed. This allows use of bootm with compressed kernels, while
still permitting an uncompressed kernel to be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The destination address for decompression (or copying) is useful
information. Show this to the user while booting, e.g.:
Uncompressing Kernel Image (no loading done) to 2080000
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
efi_get_var() allocates memory which has to be freed after the value of
the variable is consumed. Free the memory properly
Fixes: f2bfa0cb17 ("bootstd: Make efi_mgr bootmeth work for non-sandbox setups")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
This may as well happen before the general event is emitted, so move it.
This will allow us to use the livetree for the event part, but the
flattree for the earlier part.
Signed-off-by: Simon Glass <sjg@chromium.org>
This code dates from around 2008:
56844a22b7 powerpc: Fix bootm to boot up again with a Ramdisk
Since then we have added FDT relocation which provides enough space
for expansion. We have also added all sorts of fixups earlier in
image_setup_libfdt() which require more space, with ramdisk being the
least of them.
Therefore this extra hack for ramdisk seems unnecessary. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
To quote the author:
It would be useful to be able to boot an OS when CONFIG_CMDLINE is
disabled. This could allow reduced code size.
Standard boot provides a way to handle programmatic boot, without
scripts, so such a feature is possible. The main impediment is the
inability to use the booting features of U-Boot without a command line.
So the solution is to avoid passing command arguments and the like to
code in boot/
A similar process has taken place with filesystems, for example, where
we have (somewhat) separate Kconfig options for the filesystem commands
and the filesystems themselves.
This series starts the process of refactoring the bootm logic so that
it can be called from standard boot without using the command line.
Mostly it removes the use of argc, argv and cmdtbl from the internal
logic.
Some limited tidy-up is included, but this is kept to smaller patches,
rather than trying to remove all #ifdefs etc. Some function comments
are added, however.
A simple programmatic boot is provided as a starting point.
This work will likely take many series, so this is just the start.
Size growth with this series for firefly-rk3288 (Thumb2) is:
arm: (for 1/1 boards) all +23.0 rodata -49.0 text +72.0
This should be removed by:
https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/11
but it is not included in this series as it is already large enough.
No functional change is intended in this series.
Changes in v3:
- Add a panic if programmatic boot fails
- Drop RFC tag
Changes in v2:
- Add new patch to adjust position of unmap_sysmem() in boot_get_kernel()
- Add new patch to obtain command arguments
- Fix 'boot_find_os' typo
- Pass in the command name
- Use the command table to provide the command name, instead of "bootm"
Add some functions which provide an argument to a command, or NULL if
the argument does not exist.
Use the same numbering as argv[] since it seems less confusing than the
previous idea.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
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 <sjg@chromium.org>
Rather than passing the full list of command arguments, pass only those
which are needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move this code into a function to reduce code size and make it easier
to understand. Drop the unnecessary 0x to help a little with code size.
Use this in bootm_find_images()
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Rather than passing it all the command-line args, pass in the pieces
that it needs. These are the image address, the ramdisk address/name
and the FDT address/name.
Ultimately this will allow usage of this function without being called
from the command line.
Move the function comment to the header file and tidy it a little.
Signed-off-by: Simon Glass <sjg@chromium.org>
The normal bootm flow calls bootm_find_other() can call the
BOOTM_STATE_FINDOTHER state as part of its processing. Fix the
condition there so that this hack can be removed.
Also drop the confusing check for the OS type, since do_bootm_tee() is
only called if the condition is met - see bootm_os_get_boot_func()
Signed-off-by: Simon Glass <sjg@chromium.org>
The normal bootm flow calls bootm_find_other() can call the
BOOTM_STATE_FINDOTHER state as part of its processing. Fix the
condition there so that this hack can be removed.
Signed-off-by: Simon Glass <sjg@chromium.org>
The Android mechanism uses the loadaddr envrionment-variable to get the
load address, if none is provided. This is equivalent to
image_load_addr so use that instead, converting it to a string as
needed.
This change will permit passing img_addr to this function, in a future
change.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
