DHCP and DHCPv6 use the same value defined in
https://www.iana.org/assignments/dhcpv6-parameters#processor-architecture
to encode the processor architecture type. We should only use a single
Kconfig symbol for both protocols.
Furthermore we should make the value customizable. This allows for instance
to choose between "x86 BIOS" or "x64 UEFI".
As "x86 BIOS" is encoded as 0, we should not use this value to switch
off transmission of the DHCP option. Use 0xFF instead.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Change from "Baseboard Information" to "Chassis information".
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Sughosh Ganu <sughosh.ganu@linaro.org> says:
The LMB module has a bunch for API's which are used for allocating
memory. There are a couple of API's for requesting memory, and two
more for reserving regions of memory. Replace these different API's
with a single one, lmb_alloc_mem(). The type of allocation to be made
is specified through one of the parameters to the function.
Additionally, the two API's for reserving regions of memory,
lmb_reserve() and lmb_alloc_addr() are the same with one
difference. One can reserve any memory region with lmb_reserve(),
while lmb_alloc_addr() actually checks that the memory region being
requested is part of the LMB memory map. Reserving memory that is not
part of the LMB memory map is pretty futile -- the allocation
functions do not allocate memory which has not been added to the LMB
memory map.
This series also removes the functionality allowing for reserving
memory regions outside the LMB memory map. Any request for reserving a
region of memory outside the LMB memory map now returns an -EINVAL
error.
Certain places in the common code using the LMB API's were not
checking the return value of the functions. Checks have been added for
them. There are some calls being made from the architecture/platform
specific code which too do not check the return value. Those have been
kept the same, as I do not have the platform with me to check if it
causes any issues on those platforms.
In addition, there is a patch which refactors code in
lmb_overlaps_region() and lmb_can_reserve_region() so that both
functionalities can be put in a single function, lmb_overlap_checks().
Finally, a new patch has been added which checks the return value of
the lmb allocation function before copying the device-tree to the
allocated address.
Link: https://lore.kernel.org/r/20250617104346.1379981-1-sughosh.ganu@linaro.org
[trini: Rework arch/arm/mach-snapdragon/board.c merge]
Signed-off-by: Tom Rini <trini@konsulko.com>
There is no need to have two separate API's for freeing up memory. Use
a single API lmb_free() to achieve this.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.
Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.
There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
