| Age | Commit message (Collapse) | Author |
|---|
|
The current implementation casts an address to a pointer. Make it more
sandbox-friendly by using map_sysmem().
Use symbolic return value for the command while updating
the return value handling.
Signed-off-by: Marek Vasut <[email protected]>
|
|
The current implementation casts an address to a pointer. Make it more
sandbox-friendly by using map_sysmem().
Convert 'addr' variable to unsigned long, as that is the return type of
hextoul() and address parameter type of map_sysmem().
Signed-off-by: Marek Vasut <[email protected]>
|
|
The only call site of gzwrite() is cmd/unzip.c do_gzwrite(), where
the 'len' parameter passed to gzwrite(..., len, ...) function is of
type unsigned long. This usage is correct, the 'len' parameter is
an unsigned integer, and the gzwrite() function currently supports
input data 'len' of up to 4 GiB - 1 .
The function signature of gzwrite() function in both include/gzip.h
and lib/gunzip.c does however list 'len' as signed integer, which
is not correct, and ultimatelly limits the implementation to only
2 GiB input data 'len' .
Fix this, update gzwrite() function parameter 'len' data type to
size_t consistently in include/gzip.h and lib/gunzip.c .
Furthermore, update gzwrite() function 'szwritebuf' parameter in
lib/gunzip.c from 'unsigned long' to 'size_t' to be synchronized
with include/gzip.h . Rewrite the other parameters to size_t and
off_t and propagate the change too.
Since the gzwrite() function currently surely only supports input
data size of 4 GiB - 1, add input data size check. The limitation
comes from the current use of zlib z_stream .avail_in parameter,
to which the gzwrite() function sets the entire input data size,
and which is of unsigned int type, which cannot accept any number
beyond 4 GiB - 1. This limitation will be removed in future commit.
Reported-by: Yuya Hamamachi <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
Mikhail Kshevetskiy <[email protected]> says:
It was noted that a GPT partition with the maximum available partition
number (ex: /dev/mmcblk128) can't be read/write from U-Boot using
read/write commands. Futher investigation shows that the problem is
deeper.
This set of patches fixes uncovered issues.
Link: https://lore.kernel.org/r/[email protected]
|
|
GPT disk partition with max available number (ex: /dev/mmcblk128) can't
be used from U-Boot. Here is an example:
=> mmc part
Partition Map for mmc device 0 -- Partition Type: EFI
Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00001000 0x000013ff "env1"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
guid: 5452574f-2211-4433-5566-778899aabb02
2 0x00001400 0x000017ff "env2"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
guid: 5452574f-2211-4433-5566-778899aabb03
.................
8 0x00158000 0x0034bfff "apps"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
guid: 5452574f-2211-4433-5566-778899aabb09
128 0x00000420 0x00000fff "fip"
attrs: 0x0000000000000000
type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
guid: 5452574f-2211-4433-5566-778899aabb01
=> gpt setenv mmc 0 fip
error!
=> gpt setenv mmc 0 apps
success!
The error is caused by invalid boundary checks. This patch fixes an
issue.
Fixes: 12fc1f3bb223 ("cmd: gpt: add eMMC and GPT support")
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Acked-by: Quentin Schulz <[email protected]>
|
|
The ip_addr_t of lwIP has support for both IPv6 and IPv4 addresses.
Some lwIP commans is directly accessing the internal addr field of the
ip_addr_t instead of using ipaddr helper functions.
Change to use ipaddr helper functions where appropriate to remove direct
access of the internal addr field. Also change a few instances from ip4
to the version less ipaddr helpers.
There is no intended functional change, besides the change from using
ip4 addr helper to using version less ipaddr helper.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-mmc
- Add DMA support for mediatek mmc
- Cleanup mmc cmd
- Fix typos in mmc
[trini: Fix "quoted string split across lines" checkpatch warning]
Signed-off-by: Tom Rini <[email protected]>
|
|
Return symbolic value CMD_RET_FAILURE instead of literal "1" when
failing to switch the partition to improve readability.
Signed-off-by: Yao Zi <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Currently when any of speed_mode, part, or dev fails to be parse as a
number, no error is reported. In this case __init_mmc_device() is called
with weird arguments, probably zeroes if there's no digit prefixing the
argument, which is especially confusing when the invocation occasionally
succeeds.
Let's check whether arguments are valid numbers without trailing
characters. This is quite helpful for speed_mode: it requires an index
instead of a mode name, one may easily pass in a string, which will be
parsed as zero (MMC_LEGACY), without carefully reading the
documentation, then finds the MMC device is under an unexpected mode.
Signed-off-by: Yao Zi <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Replace the big if-else block in do_mmc_dev() with switch-case and use
fallthrough to remove the duplicated code for parsing dev and part.
Signed-off-by: Yao Zi <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
After talking with someone from the NetBSD project, platforms that do
not boot with a device tree (and so would be using our BOOTM_NETBSD
support) a very few in number. So we can remove this option from being
enabled by default and save a little space in most places with platforms
that need it still being able to re-enable it, if needed. Ideally, in a
few years we can instead just remove the code entirely.
Link: https://lore.kernel.org/r/[email protected]/
Signed-off-by: Tom Rini <[email protected]>
|
|
Fix typo with correct spelling of "purposes".
Also change "debug" to "debugging" while touching this since that is
the more common phrasing.
Reviewed-by: Quentin Schulz <[email protected]>
Signed-off-by: David Lechner <[email protected]>
|
|
README.falcon was converted to ReST/HTML in 2023.
Signed-off-by: J. Neuschäfer <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Addresses above 4 GiB don't fit into 8 digits.
Use 13 digits which encompass up to 15 TiB.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu
u-boot-dfu-20260116
CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/29018
Android:
* Fix missing dependency for BOOTMETH_ANDROID
* Add bootconfig support
* Add 'get ramdisk' command to abootimg
DFU:
* Improve error handling in dfu_fill_entity()
USB Gadget:
* ci_udc: Ensure ci_ep->desc is valid before using it
* ci_udc: Add additional debug prints
|
|
Add support for retrieving ramdisk address and size from Android boot
images. This command allows users to extract the ramdisk information
for boot image v3+ which combines vendor ramdisk, boot ramdisk and
bootconfig sections.
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Guillaume La Roque (TI.com) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Use map_to_sysmem() to convert header pointers to physical addresses
in parse_hdr functions, and add proper map_sysmem()/unmap_sysmem()
calls in android_image_get_data() for sandbox compatibility.
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Guillaume La Roque (TI.com) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
The usage of the net sub-system was missing the complete command for “net
stats”.
Signed-off-by: Link Mauve <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
After the preparatory patches moved most of the NFS code into common
files we now add the code to enable NFS support with lwIP.
Signed-off-by: Andrew Goodbody <[email protected]>
Acked-by: Jerome Forissier <[email protected]>
|
|
If memory allocation for verify_buf fails, then one
needs to make sure that memory allocated for buf is
released.
Signed-off-by: Francois Berder <[email protected]>
|
|
CMD_NET_LWIP has never existed so it cannot be right. I'm guessing the
intent was to allow print_eth() to be called when NET_LWIP is defined
(NET means "legacy networking stack" as opposed to NET_LWIP which is the
newest (and incompatible) stack). There probably was some mix-up
between CMD_NET and NET options.
The dependency on CMD_NET seems unnecessary as it seems perfectly fine
to run bdinfo without CMD_NET (build and run tested). So let's instead
make the dependency on NET || NET_LWIP.
Let's sync the unit test as well.
Fixes: 95744d2527cb ("cmd: bdinfo: enable -e when CONFIG_CMD_NET_LWIP=y")
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
code duplication"
Julien Stephan <[email protected]> says:
Commit 2dcf143398ad ("dm: video: Repurpose the 'displayport' uclass to 'display'")
left the display_read_edid() function unused by mistake.
This series addresses that oversight and introduces a new useful cmd.
Patch 1:
- Refactors display_read_timing() to use the existing
display_read_edid() function, eliminating redundant code.
- Marks display_read_edid() as static since it is not used outside of
the file.
Patch 2:
- Adds a new read_edid command, which can be very useful for debugging
or developing new display drivers.
- As this command uses display_read_edid(), the function is made
non-static again.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a new command to read EDID info from connected display.
When applicable EDID can also be retrieved by commands such as:
i2c dev x
i2c edid 0x50
but the new read_edid function relies on the implementation of the
read_edid callback from DISPLAY driver.
Signed-off-by: Julien Stephan <[email protected]>
|
|
Document the bdinfo -a, -e and -m options in the long help, but only
when they can be used. The string concatenation is a bit odd with two
newlines, but it does render properly once in U-Boot CLI.
Tested-by: Michal Simek <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
|
|
The usage of the LMB library and the device-tree source are not related.
Remove the dependency in the bdinfo output and adjust the unit test.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Prepare v2026.01-rc5
|
|
The config is wrongly written, result
in only support socdk board.
Fixes: 92dcb3ad5d98 ("cmd/dma: implement dmareset command")
Signed-off-by: Brian Sune <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Avoid NULL pointer dereference in case 'env select' is invoked
without parameters, check the arg count and make sure it is at
least 2, otherwise print usage.
The crash is easy to trigger e.g. in sandbox:
$ ./u-boot -Tc "env select"
Fixes: a97d22ebba23 ("cmd: env: add env select command")
Signed-off-by: Marek Vasut <[email protected]>
Tested-by: Vincent Stehlé <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Running `wget cacert builtin` leads to a crash in _set_cacert():
Unhandled exception: Load access fault
Function _set_cacert() dereferences variable wget_info.
We must initialize it before executing the cacert sub-command.
Fixes: d3761a31ef09 ("lwip: split net/lwip/wget.c")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Building this code on 64bit platforms leads to warnings (and so errors
in CI). Rather than rework the code, as this is a deprecated filesystem,
don't try and disallow building on 64bit hosts.
Signed-off-by: Tom Rini <[email protected]>
|
|
Prepare v2026.01-rc4
|
|
To the exception of red_led_on in the arm-specific assembly code, all
code interacting with the red status LED was guarded by the
CONFIG_LED_STATUS_RED symbol, which is enabled in none of the upstream
defconfigs.
Since the last board which overrode the weak red_led_on function got
migrated to the new LED mechanism, there's also no user of the
arm-specific assembly code anymore, therefore it can be removed along
the other unreachable code sections.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
The last user of it was removed in a previous commit so let's remove its
support entirely.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
The last user of coloured_LED_init has been recently removed, so we can
remove all places it's called and defined as it does nothing now.
Nobody makes use of the yellow and blue status LEDs from the legacy API,
so let's remove all references to it.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Heinrich Schuchardt <[email protected]> says:
Many C unit tests are not executed if CONFIG_CONSOLE_RECORD is not set.
Hence Tom suggested to let UNIT_TEST imply CONSOLE_RECORD.
The first patch makes the skipped C unit tests visible.
The rest of the series deals with hidden bugs in our tests.
The 'fdt get value' command returned incorrect values on low-endian
systems. So this needed fixing too.
Link: https://lore.kernel.org/r/[email protected]
|
|
The 32bit cells of a device-tree property are big-endian. When printing
them via 0x08x we must first convert to the host endianness.
Remove the restriction to 20 bytes length. This would not allow to read an
SHA256 value.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Heiko Schocher <[email protected]> says:
Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02
TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C
u-boot=> tpm2 init
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
u-boot=>
Implement sm3 hash, so we can fix this problem.
Link: https://lore.kernel.org/r/[email protected]
|
|
add sm3 256 hash support, so TPM2 chips which report
5 pcrs with sm3 hash do not fail with:
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
Signed-off-by: Heiko Schocher <[email protected]>
|
|
add the U-Boot specific parts for the SM3 hash
implementation:
Signed-off-by: Heiko Schocher <[email protected]>
|
|
cmd doc"
Quentin Schulz <[email protected]> says:
u-boot,boot-led and u-boot,error-led aren't actually handled by some
generic code but rather by board or architecture specific code. They
also aren't properties that are part of the official dt-binding so they
cannot be upstreamed. For u-boot,boot-led, there's actually a proper
replacement which is /options/u-boot/boot-led[1] (+ CONFIG_LED_BOOT=y).
For Rockchip boards, either nothing (for RK3066, PX30 and RK3399) was
using that property or (for RK3188) the code handling it was guarded by
symbols that were not enabled in the defconfig. For those, the property
and guarded code are removed.
For the Sam9x60 Curiosity, it seems that even though the LED is
controlled whenever CONFIG_LED is enabled, it isn't enabled by default
in the defconfig (but the code was added without modifying the
defconfig, explicitly leaving a choice to the user). I decided to keep
that feature by simply migrating it to the new API, though I cannot test
it as I do not own the device.
The STM32 boards will be migrated in the near future once their upstream
(kernel) Device Trees gain the new way to specify this (via
/options/u-boot/boot-led). I'll let Patrice handle this, see
https://lore.kernel.org/u-boot/[email protected]/
and
https://lore.kernel.org/u-boot/[email protected]/
After this, only one user of u-boot,boot-led will be left, based on
STM32: board/dhelectronics/dh_stm32mp1/board.c. @Patrice, maybe that's
something you want to have a look at as well, this seems to be some
evaluation kit?
The only users of u-boot,error-led are STM32 boards, so I'll leave this
to Patrice as well, I do not know what's the way to go for that one.
In any case, I would like to not encourage people to use out-of-spec DT
properties when there is another option (u-boot,boot-led), so I remove
the properties from the dt-binding document from U-Boot.
The help text for the blink subcommand of the led command was misleading
so this is now fixed.
This also moves the content of doc/README.LED into the doc/api/led.rst,
while clearly stating one shouldn't be using this anymore.
This also gets rid of dt-binding that we already have in dts/upstream.
Finally, this adds documentation for the led shell command.
[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116
Link: https://lore.kernel.org/r/[email protected]
|
|
The blink subcommand actually requires an additional parameter
(blink-freq) but not the others.
In order to simplify the help text, split the blink subcommand help text
from the off|on|toggle subcommands.
Then, fix the help text so that it is clear that the frequency is
required.
While at it, specify the duty cycle.
Fixes: ffe2052d6e8a ("dm: led: Add a new 'led' command")
Signed-off-by: Quentin Schulz <[email protected]>
|
|
extension_get_list() will return NULL if there is no extension device.
Check for this situation.
Addresses-Coverity-ID: 638557 - Null pointer dereferences (NULL_RETURNS)
Fixes: 2d12958ee71b ("boot: Remove legacy extension board support")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Kory Maincent <[email protected]>
|
|
Prepare v2026.01-rc3
|
|
As was noted by Heinrich Schuchardt, some SoCs may not support 64-bit
divisions. Fix an issue by using lldiv() instead.
The code assumes that the benchmark never takes more than 4294 seconds
and thus the difference will be less than U32_MAX.
Also replace (speed / 1024) by (speed >> 10) to avoid potential 64-bit
division.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
This is a natural buddy to the existing "part number", allowing one to
get the partition name for a given partition number.
Acked-by: Quentin Schulz <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Quentin Schuloz <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
|
|
successful get_info
Not all ->get_info implementations necessarily populate all the string
members of struct disk_partition.
Currently, only part_get_info_by_type() (and thereby part_get_info)
ensure that the uuid strings are initialized; part_get_info_by_type()
and part_get_info_by_uuid() do not. In fact, the latter could lead to
a false positive match - if the ->get_info backend does not populate
info->uuid, stale contents in info could cause the strncasecmp() to
succeed.
None of the functions currently ensure that the ->name and ->type
strings are initialized.
Instead of forcing all callers of any of these functions to
pre-initialize info, or all implementations of the ->get_info method
to ensure there are valid C strings in all four fields, create a small
helper function and factor all invocations of ->get_info through that.
This also consolidates the -ENOSYS check and standardizes on using
log_debug() for reporting absence, instead of the current mix of
PRINTF and log_debug(). It does mean we have to special-case -ENOSYS
in the error cases inside the loops in the _by_uuid() and _by_name()
functions, but it's still a net win in #LOC.
Acked-by: Quentin Schulz <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
|
|
Update the command to show the size and selected file, since this is
useful information at times. Add a heading so it is clear what each
field refers to.
Add a simple test as well.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Anshul Dalal <[email protected]> says:
Hi all,
We currently make use of CMD_BOOTI and CMD_BOOTZ in the SPL boot flow in
falcon mode, this isn't correct since all CMD_* configs are only meant
for U-Boot proper and not the SPL.
Therefore this patch set adds new LIB_BOOT[IMZ] configs that allow for
more granular selection of their respective compilation targets.
Additionally, this also allows us to more easily disable support for
raw images from secure falcon mode (SPL_OS_BOOT_SECURE) by doing the
following:
config LIB_SPL_BOOTI
...
depends on SPL_OS_BOOT && !SPL_OS_BOOT_SECURE
...
Link: https://lore.kernel.org/r/[email protected]
|
|
Using CMD_* configs from spl doesn't make logical sense. Therefore
this patch replaces the checks for CMD_BOOTx with newly added library
symbols LIB_BOOT[IMZ] and SPL_LIB_BOOT[IMZ] which are enabled by their
respective CMD_* or SPL_* counterparts.
On platforms with non-secure falcon mode, SPL_BOOTZ is enabled by
default for 32-bit ARM systems and SPL_BOOTI is enabled by default for
64-bit ARM and RISCV.
The respective C files (image.c/zimage.c) are compiled based on library
symbols $(PHASE_)LIB_BOOTx instead which are in turn selected by both
CMD_BOOTx and SPL_BOOTx as required.
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
to boot flows"
Kory Maincent (TI.com) <[email protected]> says:
This series converts the extension board framework to use UCLASS as
requested by Simon Glass, then adds extension support to pxe_utils
and bootmeth_efi (not tested) to enable extension boards devicetree load
in the standard boot process.
I can't test the imx8 extension scan enabled by the
imx8mm-cl-iot-gate_defconfig as I don't have this board.
I also can't test the efi bootmeth change as I don't have such board.
Link: https://lore.kernel.org/r/20251030-feature_sysboot_extension_board-v5-0-cfb77672fc68@bootlin.com
|
