Pull request net-20260209.
net:
- airoha: mdio support for the switch
- phy: mscc: allow RGMII with internal delay for the VSC8541
- dwc_eth_qos: Update tail pointer handling
net-legacy:
- Stop conflating return value with file size in net_loop()
net-lwip:
- wget: rework the '#' printing
- tftp: add support of tsize option to client
The net_loop() currently conflates return value with file size
at the end of successful transfer, in NETLOOP_SUCCESS state.
The return type of net_loop() is int, which makes this practice
workable for file sizes below 2 GiB, but anything above that will
lead to overflow and bogus negative return value from net_loop().
The return file size is only used by a few sites in the code base,
which can be easily fixed. Change the net_loop() return value to
always be only a return code, in case of error the returned value
is the error code, in case of successful transfer the value is 0
or 1 instead of 0 or net_boot_file_size . This surely always fits
into a signed integer.
By keeping the return code 0 or 1 in case of successful transfer,
no conditionals which depended on the old behavior are broken, but
all the sites had to be inspected and updated accordingly.
Fix the few sites which depend on the file size by making them
directly use the net_boot_file_size variable value. This variable
is accessible to all of those sites already, because they all
include net-common.h .
Signed-off-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Unmap the sysmem that got mapped by this command.
Use symbolic return value for the command while updating
the return value handling.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
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 <marek.vasut+renesas@mailbox.org>
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 <marek.vasut+renesas@mailbox.org>
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 <yuya.hamamachi.sx@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> 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/20260119223305.3022690-1-mikhail.kshevetskiy@iopsys.eu
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 <jonas@kwiboo.se>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Return symbolic value CMD_RET_FAILURE instead of literal "1" when
failing to switch the partition to improve readability.
Signed-off-by: Yao Zi <me@ziyao.cc>
Tested-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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 <me@ziyao.cc>
Tested-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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 <me@ziyao.cc>
Tested-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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/aWKQOW_ajq0DsbYA@big-apple.aprisoft.de/
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <quentin.schulz@cherry.de>
Signed-off-by: David Lechner <dlechner@baylibre.com>
README.falcon was converted to ReST/HTML in 2023.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Addresses above 4 GiB don't fit into 8 digits.
Use 13 digits which encompass up to 15 TiB.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
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 <mkorpershoek@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
Link: https://lore.kernel.org/r/20260112-bootconfig-v5-4-79b242159ac7@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
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 <mkorpershoek@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
Link: https://lore.kernel.org/r/20260112-bootconfig-v5-2-79b242159ac7@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
The usage of the net sub-system was missing the complete command for “net
stats”.
Signed-off-by: Link Mauve <linkmauve@linkmauve.fr>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
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 <andrew.goodbody@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
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 <fberder@outlook.fr>
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 <quentin.schulz@cherry.de>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Julien Stephan <jstephan@baylibre.com> 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/20250630-read_edid_cleanup-v1-0-ec7d425472c7@baylibre.com
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 <jstephan@baylibre.com>
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 <michal.simek@amd.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
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 <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The config is wrongly written, result
in only support socdk board.
Fixes: 92dcb3ad5d98 ("cmd/dma: implement dmareset command")
Signed-off-by: Brian Sune <briansune@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
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 <marek.vasut+renesas@mailbox.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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 <heinrich.schuchardt@canonical.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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 <trini@konsulko.com>
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 <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
The last user of it was removed in a previous commit so let's remove its
support entirely.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
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 <quentin.schulz@cherry.de>
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 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/20251123225711.227016-1-heinrich.schuchardt@canonical.com
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 <heinrich.schuchardt@canonical.com>
Heiko Schocher <hs@nabladev.com> 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/20251118043042.27726-1-hs@nabladev.com
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 <hs@nabladev.com>
Quentin Schulz <foss+uboot@0leil.net> 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/94ed1988-13e8-4fe3-bdff-ba2c9973c556@foss.st.com/
and
https://lore.kernel.org/u-boot/2a3aa43a-ce19-41e1-ab56-556629ce5cf9@foss.st.com/
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/20251112-led-old-dt-v1-0-2892d49517db@cherry.de
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 <quentin.schulz@cherry.de>
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 <heinrich.schuchardt@canonical.com>
Acked-by: Kory Maincent <kory.maincent@bootlin.com>
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 <mikhail.kshevetskiy@iopsys.eu>
