Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_DEVICE_INDEX to clarify this is the SD/MMC device
index, a number, as enumerated by U-Boot. Update the help text
accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Permit to select a bootmenu entry with a key shortcut. This is
especially useful in production or testing scenario to automate flashing
procedure or testing procedure.
The boot entry are changed to append the shortcut key to it.
Example:
1. Run default boot command.
2. Boot system via TFTP.
3. Boot production system from NAND.
4. Boot recovery system from NAND.
5. Load production system via TFTP then write to NAND.
6. Load recovery system via TFTP then write to NAND.
7. Load BL31+U-Boot FIP via TFTP then write to NAND.
8. Load BL2 preloader via TFTP then write to NAND.
9. Reboot.
a. Reset all settings to factory defaults.
0. Exit
0 is always reserved for Exit to console.
On pressing the keyboard key 2, the bootmenu entry 2 is selected and
executed.
Up to 34 key shortcut (0 excluded as reserved) are supported from 1-9
and a-z.
If a shortcut key not present in the bootmenu list is pressed, it is
simply ignored and eventually the autoboot is interrupted.
Capital A-Z are converted to lower a-z and the related option is
selected.
Suggested-by: Weijie Gao <weijie.gao@mediatek.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Petr Štetiar <ynezz@true.cz>
Tom Rini <trini@konsulko.com> says:
Hey all,
Related to my other series I've posted recently on cleaning up some
headers, this series here is the result of at least lightly auditing the
#includes used in include/[a-m]*.h. This ignores subdirectories, as at
least in part I think the top-level includes we've constructed are the
most likely places to have some extra transitive include paths. I'm sure
there's exceptions and I'll likely audit deeper once this first pass is
done. This only gets as far as "include/m*.h" because I didn't want this
to get too big. This also sets aside <miiphy.h> and <phy.h>. While
miiphy.h does not directly need <phy.h> there are *so* many users and I
think I had half of the tree just about not building when I first tried.
It might be worth further investigation, but it might just be OK as-is.
Link: https://lore.kernel.org/r/20250521230119.2084088-1-trini@konsulko.com
There are only a few things found in <mtd.h> today. Go through and audit
the C files which include <mtd.h> and remove it when not required. Then,
add it to the files which had either missed it or had an indirect
inclusion of it.
Signed-off-by: Tom Rini <trini@konsulko.com>
At this point in time, <ide.h> provides the IDE_BUS macro and the
function prototype for ide_set_reset, which is used with IDE_RESET. The
only files which should include this header are the ones that either use
that macro or that function. Remove <blk.h> from <ide.h> and remove
<ide.h> from places which do not need it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Bring in recent expo enhancements:
- multi-line text
- highlighting of menu items
- rationalisation of menu and expo code
- support for object alignment
- editable strings
- various bug fixes and tweaks
This also includes some required abuf improvements.
Adriano Cordova <adrianox@gmail.com> says:
Enable HTTP server in CI to support HTTP tests in pytest
QEMU does not emulate an HTTP server, unlike other services like DHCP or TFTP.
To enable HTTP tests during CI runs, start a simple Python HTTP server
on port 80. This allows tests that require HTTP access to run.
The HTTP server is launched on the host. For QEMU environments launched
with '-netdev,user' this means that the HTTP server runs together with DHCP
at 10.0.2.2. HTTP testing needs to be explicitly enabled with
env__efi_helloworld_net_http_test_skip = False.
We also default `WGET=y` in `ARCH_QEMU` configurations so that these HTTP
tests are included automatically when using QEMU in CI.
Link: https://lore.kernel.org/r/20250516085256.30386-1-adriano.cordova@canonical.com
Rather than returning a bootflow, return the index of the bootflow. This
will allow callers to do their own translation to bootflows or some
other data structure.
Also return a special code when the user tries to move the pointer, so
that the caller can cancel the boot-menu timeout, if this is in use.
Signed-off-by: Simon Glass <sjg@chromium.org>
Within tests it is useful to be able to control rendering of the expo.
Drop the automatic call to expo_render() within expo_poll() and adjust
its callers to handle this instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Split the starting piece of this function into bootflow_menu_start()
and the polling part into bootflow_menu_poll() so that it is possible
for the caller to be in control of the event loop.
Move the expo_destroy() call into the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Both bootflow_menu and cedit use similar logic to poll an expo. Move
this into the expo library so the code can be shared.
Update bootflow_menu_run() to return -EPIPE when the user quits without
choosing anything, since -EAGAIN is ambiguous and elsewhere means that
there is no input yet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tom Rini <trini@konsulko.com> says:
Hey all,
This is a v3 of Simon's series[1] and depends on the series[2] I posted
the other day that removes <env.h> from <command.h>. With this series
done, I believe we've tackled all of the current cases of headers which
include <env.h> without directly needing it. Much of this series is in
fact Simon's v2 with the main differneces being:
- Removing <env.h> from <net.h> at the end
- Removing env_to_ip() given how little it's used rather than shuffling
around where it's declared and un-inline'ing it. For a rarely used
helper, this ends up being cleaner I think. Especially looking at some
of the users (which called env_get repeatedly). If there's strong
opinion here about using the other method[3] we can do that instead.
- Setting aside for now how to handle CMD_ELF=y and NO_NET=y because
today it's actually fine as we unconditionally build lib/net_utils.c
where string_to_ip() is defined. I'm unsure if a further series is
warranted here or not. We rely on link-time optimization to keep code
readable too.
[1]: https://lore.kernel.org/all/20250501010456.3930701-1-sjg@chromium.org
[2]: https://lore.kernel.org/all/20250514225002.15361-1-trini@konsulko.com
[3]: https://lore.kernel.org/all/20250501010456.3930701-23-sjg@chromium.org
Link: https://lore.kernel.org/r/20250515234154.1859366-1-trini@konsulko.com
Now that env_get_ip() has been removed, the include file <net.h> does
not need anything from <env.h>. Furthermore, include/env.h itself
includes other headers which can lead to longer indirect inclusion
paths. To prepare to remove <env.h> from <net.h> fix all of the
remaining places which had relied on this indirect inclusion to instead
include <env.h> directly.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # net/lwip
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently, we have the function env_get_ip which takes an IP address
in string form and returns a struct in_addr representation of that
address. It is however little used and means that a number of places
indirectly (and unclearly) get <env.h> via <net.h>. To clean this up
start by replacing env_get_ip() calls with string_to_ip() calls. This is
generally a no-op as env_get_ip(str) is an inline of
string_to_ip(env_get(str)) but in a few cases we can or already have
stored the result of env_get(str) and can save the additional call.
Signed-off-by: Tom Rini <trini@konsulko.com>
The include file <command.h> does not need anything from <env.h>.
Furthermore, include/env.h itself includes other headers which can lead
to longer indirect inclusion paths. To prepare to remove <env.h> from
<command.h> fix all of the places which had relied on this indirect
inclusion to instead include <env.h> directly.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> # android, bcb
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # spawn
Signed-off-by: Tom Rini <trini@konsulko.com>
These files require <compiler.h> in order to have MEM_SUPPORT_64BIT_DATA
be defined but currently rely on a long indirect include path to get it.
Add this directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
In a number of cases we have C files which rely on a chain of indirect
include paths to get <linux/string.h> to be included via <command.h>. To
facilitate cleaning up <command.h> make this code directly include
<linux/string.h>.
Signed-off-by: Tom Rini <trini@konsulko.com>
Rasmus Villemoes <ravi@prevas.dk> says:
This started as a rather simple patch, 1/12, adding the ability to
more conveniently do regex matching in shell.
But with that, it became very easy to see what the slre library can
and especially what it cannot do, and that way I found both outright
bugs and a "wow, doesn't it support that syntax" gotcha. I couldn't
find any tests ('git grep slre -- test/' was empty), so I added a
small test suite and tweaked slre.c.
Link: https://lore.kernel.org/r/20250513084034.654865-1-ravi@prevas.dk
Currently, the only way to make use of regex matching in the shell is
by using "setexpr [g]sub" command. That's rather awkward for asking
whether a string matches a regex. At the very least, it requires
providing setexpr with a dummy target variable, but also, the return
value of setexpr doesn't say whether any substitutions were done, so
one would have to do some roundabout thing like
env set dummy "${string_to_test}"
setexpr sub dummy '<some regex>' ''
if test "${dummy}" != "${string_to_test}" ; then ...
When CONFIG_REGEX is set, teach the test command a new operator, =~,
which will allow one to more naturally write
if test "${string_to_test}" =~ '<some regex>' ; then ...
The =~ operator with similar functionality is also supported in bash
when using its "extended" test operator [[ ]].
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
This exported symbol has a very generic name. Rename it to indicate that
it relates to EFI and device-paths.
Fix checkpatch warnings related to use of multiple assignments.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
These functions are useful for the EFI app. As a first step towards
making these available outside lib/efi_loader, create a separate header
file and include it where needed. Add proper comments to the functions,
since many are missing at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Sean Edmond <seanedmond@microsoft.com> says:
In our datacenter application, a single DHCP server is servicing 36000+ clients.
Improvements are required to the DHCPv4 retransmission behavior to align with
RFC and ensure less pressure is exerted on the server:
- retransmission backoff interval maximum is configurable
(environment variable bootpretransmitperiodmax)
- initial retransmission backoff interval is configurable
(environment variable bootpretransmitperiodinit)
- transaction ID is kept the same for each BOOTP/DHCPv4 request
(not recreated on each retry)
For our application we'll use:
- bootpretransmitperiodmax=16000
- bootpretransmitperiodinit=2000
A new configuration BOOTP_RANDOM_XID has been added to enable a randomized
BOOTP/DHCPv4 transaction ID.
Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous
patch was accepted. A new patch fixes a possible double free() and
addresses latest review comments.
Link: https://lore.kernel.org/r/20240509023918.2504185-1-seanedmond@microsoft.com
The new config option BOOTP_RANDOM_XID will randomize the transaction ID
for each new BOOT/DHCPv4 exchange.
Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
- Enable option 209 by default
- Set pxelinux_configfile to NULL to avoid potential double free
- change hardcoded 209 to a define
Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
When decompressing GZIP-compressed image parts via the `imxtract` command,
explicitly handle the `Z_BUF_ERROR` return value from `gunzip()` to provide
a clearer diagnostic. This error typically indicates that the destination
buffer is too small to hold the uncompressed data.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
[trini: Rework to indent the whole case with { } due to not using the
C23 extension]
Signed-off-by: Tom Rini <trini@konsulko.com>
Unlike ARM and X86, booting 32-bit images on 64-bit CPUs is currently
not supported for Risc-V. Hence, for bootm, disallow booting a FIT
or a legacy image that was built for an arch type which is different
than the current arch and for booti, set the arch type to be the
same as the current arch.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Commit f6eff35b8c ("cmd: tlv_eeprom: handle -ENODEV error from
read_eeprom function") removed the needed 'return 0' after a successful
read. As a result, the usage message is shown when 'tlv_eeprom read' is
successfully called.
Let's fix it by adding the needed 'return 0'.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Reviewed-by: Stefan Roese <sr@denx.de>
These files require <compiler.h> in order to have MEM_SUPPORT_64BIT_DATA
be defined but currently rely on a long indirect include path to get it.
Add this directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
The help string for the `setenv -e' command shows a comma being used as
the separator between address and size for the -i option, which deals
with UEFI Variables contents passed as a buffer in memory.
This is no longer the case since commit 2b3fbcb59f ("efi_loader: use
':' as separator for setenv -i") and commit 8f0ac536d4 ("efi: change
'env -e -i' usage syntax"), which changed the separator from a comma to
a colon.
Therefore fix this last bit of the help string accordingly.
While at it, fix the comment of function do_env_set_efi(), which also
mentions a comma as separator.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Maxim Uvarov <maxim.uvarov@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Job IDs are positive integers greater than 1. 0 is not a valid job ID,
therefore fix the comparison in do_wait().
Fixes Coverity defects:
*** CID 550296: Control flow issues (NO_EFFECT)
/cmd/spawn.c: 172 in do_wait()
166 for (i = 0; i < CONFIG_CMD_SPAWN_NUM_JOBS; i++)
167 if (job[i])
168 ret = wait_job(i);
169 } else {
170 for (i = 1; i < argc; i++) {
171 id = dectoul(argv[i], NULL);
>>> CID 550296: Control flow issues (NO_EFFECT)
>>> This less-than-zero comparison of an unsigned value is never true.
"id < 0UL".
172 if (id < 0 || id >
CONFIG_CMD_SPAWN_NUM_JOBS)
173 return CMD_RET_USAGE;
174 idx = (int)id - 1;
175 ret = wait_job(idx);
176 }
177 }
*** CID 550297: Integer handling issues (INTEGER_OVERFLOW)
/cmd/spawn.c: 174 in do_wait()
168 ret = wait_job(i);
169 } else {
170 for (i = 1; i < argc; i++) {
171 id = dectoul(argv[i], NULL);
172 if (id < 0 || id >
CONFIG_CMD_SPAWN_NUM_JOBS)
173 return CMD_RET_USAGE;
>>> CID 550297: Integer handling issues (INTEGER_OVERFLOW)
>>> Expression "idx", where "(int)id - 1" is known to be equal to -1,
overflows the type of "idx", which is type "unsigned int".
174 idx = (int)id - 1;
175 ret = wait_job(idx);
176 }
177 }
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
CC: Tom Rini <trini@konsulko.com>
fix the following typos
- from "categorys" to "categories"
- from "indivdually" to "individually"
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Jerome Forissier <jerome.forissier@linaro.org> says:
This series introduces threads and uses them to improve the performance
of the USB bus scanning code and to implement background jobs in the
shell via two new commands: 'spawn' and 'wait'.
The threading framework is called 'uthread' and is inspired from the
barebox threads [2]. setjmp() and longjmp() are used to save and
restore contexts, as well as a non-standard extension called initjmp().
This new function is added in several patches, one for each
architecture that supports HAVE_SETJMP. A new symbol is defined:
HAVE_INITJMP. Two tests, one for initjmp() and one for the uthread
scheduling, are added to the lib suite.
After introducing threads and making schedule() and udelay() a thread
re-scheduling point, the USB stack initialization is modified to benefit
from concurrency when UTHREAD is enabled, where uthreads are used in
usb_init() to initialize and scan multiple busses at the same time.
The code was tested on arm64 and arm QEMU with 4 simulated XHCI buses
and some devices. On this platform the USB scan takes 2.2 s instead of
5.6 s. Tested on i.MX93 EVK with two USB hubs, one ethernet adapter and
one webcam on each, "usb start" takes 2.4 s instead of 4.6 s.
Finally, the spawn and wait commands are introduced, allowing the use of
threads from the shell. Tested on the i.MX93 EVK with a spinning HDD
connected to USB1 and the network connected to ENET1. The USB plus DHCP
init sequence "spawn usb start; spawn dhcp; wait" takes 4.5 seconds
instead of 8 seconds for "usb start; dhcp".
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=446674
[2] https://github.com/barebox/barebox/blob/master/common/bthread.c
Link: https://lore.kernel.org/r/20250418141114.2056981-1-jerome.forissier@linaro.org
Add a spawn command which runs another command in the background, as
well as a wait command to suspend the shell until one or more background
jobs have completed. The job_id environment variable is set by spawn and
wait accepts optional job ids, so that one can selectively wait on any
job.
Example:
=> date; spawn sleep 5; spawn sleep 3; date; echo "waiting..."; wait; date
Date: 2025-02-21 (Friday) Time: 17:04:52
Date: 2025-02-21 (Friday) Time: 17:04:52
waiting...
Date: 2025-02-21 (Friday) Time: 17:04:57
=>
Another example showing how background jobs can make initlizations
faster. The board is i.MX93 EVK, with one spinning HDD connected to
USB1 via a hub, and a network cable plugged into ENET1.
# From power up / reset
u-boot=> setenv autoload 0
u-boot=> setenv ud "usb start; dhcp"
u-boot=> time run ud
[...]
time: 8.058 seconds
# From power up / reset
u-boot=> setenv autoload 0
u-boot=> setenv ud "spawn usb start; spawn dhcp; wait"
u-boot=> time run ud
[...]
time: 4.475 seconds
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Make the do_ping() function in cmd/net.c a global one by getting rid of
the static qualifier, and move the prototype declaration from net-lwip.h
to net-common.h. This makes the function available to other parts of
U-Boot when CONFIG_NET=y, as was already the case when
CONFIG_NET_LWIP=y.
This is a peparation step to make the sandbox tests use a common API
between NET and NET_LWIP.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
CMD_PXE is already under CMD_NET in Kconfig that's why make no sense to
have another ifdef inside source code.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
The EFI selftest should match executing a real EFI binary
as closely as possible.
Use do_bootefi_exec() to enter the EFI selftest.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
As the system table already has pointers to the Simple Text Input and
Output Protocols we can directly use these instead of calling
OpenProtocol.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This file was using IS_ENABLED() to test for CONFIG flags but omitted
the CONFIG_ prefix and so did not work as expected.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
