lib: fdtdec: Parse the gzip/lzo headers only when dependencies have met

It might happen that CONFIG_GZIP and CONFIG_LZO are enabled but we might
have CONFIG_MULTI_DTB_FIT_LZO enabled in this case in the code path of
uncompress_blob() we parse the gzip headers first which results in
`Error: Bad gzipped data` being printed. To avoid this parse the gzip/lzo
headers only when dependencies have met.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Extend usage for OF_OVERLAY_LIST beyond SPL

Allow to use OF_OVERLAY_LIST also for the case that the overlays just
need be built, e.g. when they will be picked up by binman as artifacts
of the final U-Boot image. The IOT2050 boards have such a need when
switching to OF_UPSTREAM.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Makefile: Drop SPL_FIT_SOURCE support

The SPL_FIT_SOURCE is long superseded by SPL_FIT_GENERATOR which
is long superseded by binman, drop SPL_FIT_SOURCE support as there
are no more users.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>

Merge tag 'u-boot-stm32-20241017' of https://source.denx.de/u-boot/custodians/u-boot-stm

CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/22732

- stm32mp: fix boot issue with OP-TEE
- stm32mp: Add script to install U-Boot from SD/eMMC to SPI NOR on DH STM32MP15xx
- stm32mp: Switch to using upstream DT on DH STM32 DHSOM
- stm32mp: Generate u-boot.itb using binman on DH STM32 DHSOM

Merge tag 'u-boot-dfu-20241017' of https://source.denx.de/u-boot/custodians/u-boot-dfu

u-boot-dfu-20241017

CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/22742

Usb Gadget:
- Fix cdns3 endpoint configuration by setting maxpacket
- Fix dwc3 cache handling when using DMA

Fastboot:
- Make AVB_VERIFY depends on FASTBOOT

Merge https://source.denx.de/u-boot/custodians/u-boot-usb

MAINTAINERS: add TCPM section

Add new section for USB TypeC Port Manager (TCPM) support, which
is needed to figure out cable orientation of USB-C plus and to do
USB PD communication.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Marek Vasut <marex@denx.de>

rockchip: rock5b-rk3588: Enable USB-C PD support

Now that all code has been prepared update the default configuration to
make use of it.

Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

rockchip: rk3588-rock-5b: Add USB-C controller to u-boot.dtsi

Add USB-C controller (fusb302), which will be used by U-Boot to
initialize USB-PD. This is needed, because USB-PD communication
must happen within 5 seconds after the USB-C connector got plugged.
On my Rock 5B it often takes 5 seconds to jump to the Linux binary,
so it must happen before Linux is initialized.

This adds the DT node to the U-Boot specific file, since the Linux
kernel DT currently does not describe it to avoid a system reset.
The plan is to add it to the Linux DT with status = 'fail' and then
let U-Boot mark it as status = 'okay' if it properly dealt with
early USB-PD initialization. Until the Kernel DT has the node, let's
add it in U-Boot to get things going.

Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

board: rock5b-rk3588: enable USB-C in operating system

Since older U-Boot releases do not negotiate USB PD, the kernel
DT may not enable the USB-C controller by default to avoid a
regression. The plan is to upstream it with 'status = "fail";'
instead. U-Boot should then mark it as 'status = "okay";' if
it negotiated USB PD. Currently existing upstream kernel DTs do
not yet have the USB-C controller at all, so we ignore any
failures.

Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

usb: tcpm: fusb302: add driver

Now that the TCPM framework exists we can introduce fusb302
driver using it. This chip is a very common USB-C controller
chip with PD support, which can be found in the Radxa Rock 5B
among many other boards. Apart from Power Delivery, it also
handles detection of the cable orientation. That can be used
to control a mux for connecting the right USB3 lane pair to
the USB3 controller.

The driver is originally from the Linux kernel, but has been
adapted to the requirements of U-Boot and its TCPM framework.

Co-developed-by: Wang Jie <dave.wang@rock-chips.com>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

usb: tcpm: add core framework

This adds TCPM framework in preparation for fusb302 support, which can
handle USB power delivery messages. This is needed to solve issues with
devices, that are running from a USB-C port supporting USB-PD, but not
having a battery.

Such a device currently boots to the kernel without interacting with
the power-supply at all. If there are no USB-PD message replies within
5 seconds, the power-supply assumes the peripheral is not capable of
USB-PD. It usually takes more than 5 seconds for the system to reach
the kernel and probe the I2C based fusb302 chip driver. Thus the
system always runs into this state. The power-supply's solution to
fix this error state is a hard reset, which involves removing the
power from VBUS. Boards without a battery (or huge capacitors) will
reset at this point resulting in a boot loop.

This imports the TCPM framework from the kernel. The porting has
originally been done by Rockchip using hardware timers and the Linux
kernel's TCPM code from some years ago.

I had a look at upgrading to the latest TCPM kernel code, but that
beast became a lot more complex due to adding more USB-C features.
I believe these features are not needed in U-Boot and with multiple
kthreads and hrtimers being involved it is non-trivial to port them.
Instead I worked on stripping down features from the Rockchip port
to an even more basic level. Also the TCPM code has been reworked
to avoid complete use of any timers (Rockchip used SoC specific
hardware timers + IRQ to implement delayed work mechanism). Instead
the delayed state changes are handled directly from the poll loop.

Note, that (in contrast to the original Rockchip port) the state
machine has the same hard reset quirk, that the kernel has - i.e.
it avoids disabling the CC pin resistors for devices that are not
self-powered. Without that quirk, the Radxa Rock 5B will not just
end up doing a machine reset when a hard reset is triggered, but will
not even recover, because the CPU will loose power and the FUSB302
will keep this state because of leak voltage arriving through the RX
serial pin (assuming a serial adapter is connected).

This also includes a 'tcpm' command, which can be used to get
information about the current state and the negotiated voltage
and current.

Co-developed-by: Wang Jie <dave.wang@rock-chips.com>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Merge patch series "some serial rx buffer patches"

Rasmus Villemoes <ravi@prevas.dk> says:

Some small improvements to the serial rx buffer feature.

CI seems happy: https://github.com/u-boot/u-boot/pull/674

Link: https://lore.kernel.org/r/20241003141029.920035-1-ravi@prevas.dk

serial: embed the rx buffer in struct serial_dev_priv

The initialization of upriv->buf doesn't check for a NULL return. But
there's actually no point in doing a separate, unconditional malloc()
in post_probe; we can just make serial_dev_priv contain the rx buffer
itself, and let the (larger) allocation be handled by the driver core
when it allocates the ->per_device_auto. The total run-time memory
used is mostly the same, we reduce the code size a little, and as a
bonus, struct serial_dev_priv does not contain the unused members when
!SERIAL_RX_BUFFER.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

serial: add build-time sanity check of CONFIG_SERIAL_RX_BUFFER_SIZE

The help text says it must be a power of 2, and the implementation
does rely on that. Enforce it.

A violation gives a wall of text, but the last few lines should be
reasonably obvious:

drivers/serial/serial-uclass.c:334:9: note: in expansion of macro ‘BUILD_BUG_ON_NOT_POWER_OF_2’
  334 |         BUILD_BUG_ON_NOT_POWER_OF_2(CONFIG_SERIAL_RX_BUFFER_SIZE);

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

serial: do not overwrite not-consumed characters in rx buffer

Before the previous patch, pasting a string of length x >
CONFIG_SERIAL_RX_BUFFER_SIZE results in getting the
last (x%CONFIG_SERIAL_RX_BUFFER_SIZE) characters from that string.

With the previous patch, one instead gets the last
CONFIG_SERIAL_RX_BUFFER_SIZE characters repeatedly until the ->rd_ptr
catches up.

Both behaviours are counter-intuitive, and happen because the code
that checks for a character available from the hardware does not
account for whether there is actually room in the software buffer to
receive it. Fix that by adding such accounting. This also brings the
software buffering more in line with how most hardware FIFOs
behave (first received characters are kept, overflowing characters are
dropped).

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

serial: fix circular rx buffer edge case

The current implementation of the circular rx buffer falls into a
common trap with circular buffers: It keeps the head/tail indices
reduced modulo the buffer size. The problem with that is that it makes
it impossible to distinguish "buffer full" from "buffer empty",
because in both situations one has head==tail.

This can easily be demonstrated: Build sandbox with RX_BUFFER enabled,
set the RX_BUFFER_SIZE to 32, and try pasting the string

  01234567890123456789012345678901

Nothing seems to happen, but in reality, all characters have been read
and put into the buffer, but then tstc ends up believing nothing is in
the buffer anyway because upriv->rd_ptr == upriv->wr_ptr.

A better approach is to let the indices be free-running, and only
reduce them modulo the buffer size when accessing the array. Then
"empty" is head-tail==0 and "full" is head-tail==size. This does rely
on the buffer size being a power-of-two and the free-running
indices simply wrapping around to 0 when incremented beyond the
maximal positive value.

Incidentally, that change from signed to unsigned int also improves
code generation quite a bit: In C, (signed int)%(signed int) is
defined to have the sign of the dividend (so (-35) % 32 is -3, not
29), and hence despite the modulus being a power-of-two, x % 32 does
not actually compile to the same as a simple x & 31 - on x86 with -Os,
it seems that gcc ends up emitting an idiv instruction, which is quite
expensive.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

stm32mp: cosmetic: remove empty comment block in configs file

This is cosmetic change.

Remove the empty comment blocks remaining after conversion to Kconfig
of CONFIG_SYS_MAX_NAND_DEVICE and CONFIG_SERVERIP.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: stm32: Add script to install U-Boot from SD/eMMC to SPI NOR on DH STM32MP15xx DHSOM

Make the dh_update_sd_to_sf script generic, rename it to dh_update_block_to_sf
and implement two specific dh_update_sd_to_sf and dh_update_emmc_to_sf scripts
which load U-Boot from either SD or eMMC and install it into SPI NOR.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

stm32mp: fix name of optee reserved memory node

In OP-TEE, the "optee_core@" node is reserved, appended in non secure
device tree (see mark_tzdram_as_reserved() function under CFG_DT) so
this name must be checked in optee_get_reserved_memory().
We keep the check on /reserved-memory/optee@ node to have backward
compatibility with STMT32Image booting, when the reserved node is
already present in U-Boot or SPL device tree with name "optee@".

This patch solves a boot issue on board with OP-TEE for U-Boot
compiled with stm32mp15_defconfig and without secure configuration
device tree (stm32mp157c-dk2.dts for example).

Fixes: 5fe9e0deabb1 ("stm32mp: allow calling optee_get_reserved_memory()
from U-Boot")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

doc: clarify scmi device tree for stm32mp15 boards

Clarify the usage of SCMI specific device tree to use with
stm32mp15_defconfig and with OP-TEE.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: stm32mp: enable data cache after LMB configuration for STM32MP1

Move the stm32mp1 data cache reconfiguration after the lmb init call
board_r::initr_lmb to allow parsing of the reserved region with
no-map tag.

After this patch the DDR is not fully mapped up to arch_early_init_r()
call, only the relocation region is mapped, but it is enough for
the first board_r initialization phases; later, when arch_early_init_r()
is called, the LMB is already initialized and the function
lmb_is_reserved_flags() function is functional, this LMB function
is called in the weak function dram_bank_mmu_setup() when
dcache_enable() is executed.

Without this change, as LMB is not initialized when it is used in
dram_bank_mmu_setup, the OP-TEE region is mapped cache-able by U-Boot
and we have some firewall violation since "LMB memory map global and
persistent" series.

Fixes: ed17a33fed29 ("lmb: make LMB memory map persistent and global")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

stm32mp: compute ram_top based on the optee base address only for STM32MP1

Reserved memory for OP-TEE is located at end of DDR for STM32MP1 SoC only
(STM32MP13 and STM32MP15) and the OP-TEE reserved memory is located at the
beginning of DDR for STM32MP25 SoC, before CONFIG_TEXT_BASE and
with reserved memory for companion coprocessor. So the ram_top is limited
by OP-TEE reserved memory only for STM32MP1 SoC.

This patch solves an issue for ram_top value on STM32MP25 SoC because the
generic reserved memory management, based on LMB, is no more used before
relocation.

Fixes: 8242f14a3e6f ("stm32mp: compute ram_top based on the optee base address")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Generate u-boot.itb using binman on DH STM32 DHSOM

Describe the u-boot.its generation in stm32mp15xx-dhsom-u-boot.dtsi
binman {} DT node as a replacement for current CONFIG_SPL_FIT_SOURCE
use, dispose of both u-boot-dhcom.its and u-boot-dhcor.its.

Use fdt-SEQ/config-SEQ to generate a list of fdt-N fitImage images {} and
matching configuration {} node entries. The configuration node entry names
no longer encode _somrevN_boardrevN suffix, which was never really used, so
drop this functionality by default. Rework board_fit_config_name_match() to
match on the new configuration node entry names.

Users who do need the match on _somrevN_boardrevN can either replace the
fdt-SEQ/config-SEQ with fixed fdt-N/config-N nodes which each encode the
matching 'description = "NAME_somrevN_boardrevN"' to restore the old
behavior verbatim, or better use SPL DT overlays for U-Boot control DT
the same way e.g. i.MX8MP DHCOM does to support multiple SoM and board
variants.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Switch to using upstream DT on DH STM32 DHSOM

Enable OF_UPSTREAM to use upstream DT and add st/ prefix to the
DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
including *-u-boot.dtsi from arch/$(ARCH)/dts/ directory.

The previous setup used generic SoC prefix like stm32mp15xx-dhco* for
generic DTs which could be used on any STM32MP15xx DHSOM variant. The
new setup uses specific SoC prefix stm32mp157c-dhco* to match Linux DT
names. Since the hardware present on STM32MP153 and STM32MP157 is not
enabled in the board configuration and not supported by U-Boot except
for the DSI host, using the existing Linux DTs poses no issue even on
plain STM32MP151A based SoMs.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Duplicate cpu0-opp-table node into stm32mp15-u-boot.dtsi

The cpu0-opp-table {} node does not exist in upstream Linux stm32mp151.dtsi
file, in order to enable conversion to OF_UPSTREAM, duplicate the node from
current U-Boot stm32mp151.dtsi into stm32mp15-u-boot.dtsi. This makes STM32
DTs buildable even with OF_UPSTREAM enabled. No functional change, since the
current U-Boot stm32mp151.dtsi already contains the cpu0-opp-table {} node,
stm32mp15-u-boot.dtsi is applied at the end, and does not bring in any new
content.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: stm32: Update MAINTAINERS file globs for STM32MP DHSOM

Update the MAINTAINERS file glob to cover all of STM32MP DHSOM related files.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

Merge patch series "Introduce the lwIP network stack"

Jerome Forissier <jerome.forissier@linaro.org> says:

This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip
library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP
stack [2] [3] as an alternative to the current implementation in net/,
selectable with Kconfig, and ultimately keep only lwIP if possible. Some
reasons for doing so are:
- Make the support of HTTPS in the wget command easier. Javier T. and
Raymond M. (CC'd) have some additional lwIP and Mbed TLS patches to do
so. With that it becomes possible to fetch and launch a distro installer
such as Debian etc. using a secure, authenticated connection directly
from the U-Boot shell. Several use cases:
  * Authentication: prevent MITM attack (third party replacing the
binary with a different one)
  * Confidentiality: prevent third parties from grabbing a copy of the
image as it is being downloaded
  * Allow connection to servers that do not support plain HTTP anymore
(this is becoming more and more common on the Internet these days)
- Possibly benefit from additional features implemented in lwIP
- Less code to maintain in U-Boot

Prior to applying this series, the lwIP stack needs to be added as a
Git subtree with the following command:

 $ git subtree add --squash --prefix lib/lwip/lwip \
   https://github.com/lwip-tcpip/lwip.git  STABLE-2_2_0_RELEASE

Notes

1. A number of features are currently incompatible with NET_LWIP:
DFU_TFTP, FASTBOOT, SPL_NET, ETH_SANDBOX, ETH_SANDBOX_RAW, DM_ETH. They
all make assumptions on how the network stack is implemented and/or
pull sybols that are not trivially exported from lwIP. Some interface
rework may be needed.

2. Due to the above, and in order to provide some level of testing of the
lwIP code in CI even when the legacy NET is the default, a new QEMU
configuration is introduced (qemu_arm64_lwip_defconfig) which is
based on qemu_arm64_defconfig with NET_LWIP and CMD_*_LWIP enabled.
In addition to that, this series has some [TESTING] patches
which make NET_LWIP the default.

[1] https://lore.kernel.org/all/20231127125726.3735-1-maxim.uvarov@linaro.org/
[2] https://www.nongnu.org/lwip/
[3] https://en.wikipedia.org/wiki/LwIP

Link: https://lore.kernel.org/r/cover.1729070678.git.jerome.forissier@linaro.org

MAINTAINERS: net: lwip: add myself as a maintainer

Add myself as a maintainer for the lwIP network stack integration code
and network commands as well as the sandbox ethernet driver for lwIP.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

CI: add qemu_arm64_lwip to the test matrix

Build and run qemu_arm64_lwip_defconfig in CI. This tests the lightweight
IP (lwIP) implementation of the dhcp, tftpboot and ping commands.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>

net: lwip: add TFTP_BLOCKSIZE

Add support for setting the TFTP block size. The default value (1468)
is fine for Ethernet and allows a better throughput than the TFTP
default (512), if the server supports the blksize option of course.

I tested this change with qemu_arm64_lwip_defconfig. The throughput is
now 875 KiB/s vs. 313 KiB/s before. That is still a low number, but I
think we can't expect more without implementing the windowsize option.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: lwip: tftp: add support of blksize option to client

The TFTP protocol uses a default block size of 512 bytes. This value is
sub-optimal for ethernet devices, which have a MTU (Maximum Transmission
Unit) of 1500 bytes. When taking into acount the overhead of the IP and
UDP layers, this leaves 1468 bytes for the TFTP payload.

This patch introduces a new function: tftp_client_set_blksize() which
may be used to change the block size from the default. It has to be
called after tftp_client_init() and before tftp_get(). If the server
does not support the option, the client will still accept to receive
512-byte blocks.

Submitted upstream: https://savannah.nongnu.org/patch/index.php?10462

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

configs: add qemu_arm64_lwip_defconfig

Add qemu_arm64_lwip_defconfig which #include's qemu_arm64_defconfig and
selects NET_LWIP instead of NET. This config has all the supported net
commands enabled.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

cmd: bdinfo: enable -e when CONFIG_CMD_NET_LWIP=y

Support "bdinfo -e" when lwIP is selected.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

net: lwip: add wget command

Add support for the wget command with NET_LWIP. The command normally
expects a URL: wget [loadaddr] url, but it also accepts the legacy
syntax: wget [loadaddr] [server:]file.
The server IP may alternatively be supplied via ${httpserverip} which
has higher priority than ${serverip}.

Based on code initially developed by Maxim U.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Co-developed-by: Maxim Uvarov <muvarov@gmail.com>
Cc: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: split cmd/net.c into cmd/net.c and cmd/net-common.c

Extract some code from cmd/net.c that will be useful in a subsequent
commit to implement wget with NET_LWIP.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: lwip: add dns command

Add CMD_DNS when NET_LWIP is enabled to provide the dns command using
lwIP.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: lwip: add ping command

Add support for the the ping command with NET_LWIP. The implementation
is derived from lwIP's contrib/apps/ping/ping.c.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: lwip: add TFTP support and tftpboot command

Implement do_tftpb(). This implementation of the tftp command
supports an optional port number. For example:

 tftp 192.168.0.30:9069:file.bin

It also supports taking the server IP from ${tftpserverip} if
defined, before falling back to ${serverip}.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: lwip: tftp: bind to TFTP port only when in server mode

The TFTP app should not bind to the TFTP server port when configured as
a client. Instead, the local port should be chosen from the dynamic
range (49152 ~ 65535) so that if the application is stopped and started
again, the remote server will not consider the new packets as part of
the same context (which would cause an error since a new RRQ would be
unexpected).

Submitted upstream: https://savannah.nongnu.org/patch/?10480

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: lwip: add DHCP support and dhcp commmand

Add what it takes to enable NETDEVICES with NET_LWIP and enable DHCP as
well as the dhcp command. CMD_TFTPBOOT is selected by BOOTMETH_EFI due
to this code having an implicit dependency on do_tftpb().

Note that PXE is likely non-fonctional with NET_LWIP (or at least not
100% functional) because DHCP option 209 is not supported by the lwIP
library. Therefore, BOOTP_PXE_DHCP_OPTION cannot be enabled.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: lwip: build lwIP

Build the lwIP library when NET_LWIP is enabled. The following files
are adaptation layers written specially for U-Boot:

 lib/lwip/u-boot/arch/cc.h
 lib/lwip/u-boot/arch/sys_arch.h (empty)
 lib/lwip/u-boot/limits.h (empty)
 lib/lwip/u-boot/lwipopts.h

They were initially contributed by Maxim in a previous RFC patch series.

The lwIP stack needs to be added as a Git subtree with the following
command:

 $ git subtree add --squash --prefix lib/lwip/lwip \
   https://github.com/lwip-tcpip/lwip.git  STABLE-2_2_0_RELEASE

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Co-developed-by: Maxim Uvarov <muvarov@gmail.com>
Cc: Maxim Uvarov <muvarov@gmail.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: eth-uclass: add function eth_start_udev()

Add a function to start a given network device, and update eth_init()
to use it.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: split net into net{,-common,-legacy,-lwip}

Make net.h a wrapper which includes net-common.h and either
net-legacy.h or net-lwip.h based on NET_LWIP. The function
copy_filename() can be useful when NET_LWIP is enabled, therefore
move it out of net/net.c which is built only when networking choice
is NET and create a new file net/net-common.c.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net: introduce alternative implementation as net/lwip/

Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by
adding a new net/lwip/ directory and the NET_LWIP symbol. Network
support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent
commits will introduce the lwIP code, re-work the NETDEVICE integration
and port some of the NET commands and features to lwIP.

SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols
that are part of NET (such as arp_init(), arp_timeout_check(),
arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be
added later.

Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP
because of dependencies on net_loop(), tftp_timeout_ms,
tftp_timeout_count_max and other NET things. Let's add a dependency on
!NET_LWIP for now.

SANDBOX can select NET_LWIP but doing so will currently disable the eth
dm tests as well as the wget tests which have strong dependencies on the
NET code.

Other adjustments to Kconfig files are made to fix "unmet direct
dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when
the default networking stack is set to NET_LWIP ("default NET_LWIP"
instead of "default NET" in Kconfig).

The networking stack is now a choice between NO_NET,
NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be
'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

test: boot: fix bootflow_cmd_label for when DSA_SANDBOX is disabled

When DSA_SANDBOX is not set, the sandbox tests fail as follows:

 $ ./test/py/test.py --build-dir=$(pwd) -k bootdev_test_any
 [...]
 Scanning for bootflows with label '9'
 [...]
 Cannot find '9' (err=-19)

This is due to the device list containing two less entries than
expected. Therefore, look for label '7' when DSA_SANDBOX is disabled.

The actual use case is NET_LWIP=y (to be introduced in later patches)
which implies DSA_SANDBOX=n for the time being.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>

test: boot: fix bootdev_test_any for when DSA_SANDBOX is disabled

When DSA_SANDBOX is not set, the sandbox tests fail as follows:

 $ ./test/py/test.py --build-dir=$(pwd) -k bootdev_test_any
 [...]
 Test: bootdev_test_any: bootdev.c
 test/boot/bootdev.c:156, bootdev_test_any(): "mmc2" = media->name: Expected "mmc2", got "mmc0"
 [...]

This is due to the device list containing two less entries than
expected. Therefore, adjust the expected index to be two less when
DSA_SANDBOX is disabled.

The actual use case is NET_LWIP=y (to be introduced in later patches)
which implies DSA_SANDBOX=n for the time being.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

sandbox: add dummy driver ETH_SANDBOX_LWIP

Introduce ETH_SANDBOX_LWIP which enables a mock driver similar to
ETH_SANDOX but without the dependencies on the legacy network stack
(NET) so that it may be enabled when the lwIP stack (NET_LWIP) is
introduced. The driver does nothing at this stage but its presence
will allow dm_test_iommu_noiommu [1] to pass.

[1] ./u-boot -T -c "ut dm dm_test_iommu_noiommu"

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

configs: use syntax CONFIG_FOO=n in tools-only_defconfig

The tools-only defconfig causes troubles on MacOSX due to the default
C compiler being Clang (LLVM) rather than GCC and more specifically
due to [1]. Therefore replace "# CONFIG_FOO is not set" with the
equivalent "CONFIG_FOO=n" using the following command:

 $ sed -i -e 's/# \(CONFIG_[^ ]*\) is not set/\1=n/' \
       configs/tools-only_defconfig

This fixes the tools_only_macOS CI job on GitHub [2].

[1] https://github.com/llvm/llvm-project/issues/78778
[2] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=9105&view=results

Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Merge commit 'f3f86fd1fe0fb288356bff78f8a6fa2edf89e3fc' as 'lib/lwip/lwip'

Squashed 'lib/lwip/lwip/' content from commit 0a0452b2c39b

git-subtree-dir: lib/lwip/lwip
git-subtree-split: 0a0452b2c39bdd91e252aef045c115f88f6ca773

Revert "Makefile: Drop SPL_FIT_GENERATOR / SPL_FIT_SOURCE support" changes

:hile we had hoped to be able to remove these options finally, it was
missed that zynq still requires these currently.

This reverts commit 5b9261fb0b1ed087387f2036d279fd3f4bb20a61 and
commit 099b6df556c95f5d06864612e9199eab7ba50ed3.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Merge https://source.denx.de/u-boot/custodians/u-boot-usb

Merge patch series "Make EFI memory allocations synchronous with LMB"

Sughosh Ganu <sughosh.ganu@linaro.org> says:

This is part two of the series to have the EFI and LMB modules have a
coherent view of memory. Part one of this goal was to change the LMB
module to have a global and persistent memory map. Those patches have
now been applied to the next branch.

These patches are changing the EFI memory allocation API's such that
they rely on the LMB module to allocate RAM memory. This fixes the
current scenario where the EFI memory module has no visibility of the
allocations/reservations made by the LMB module. One thing to note
here is that this is limited to the RAM memory region, i.e. the
EFI_CONVENTIONAL_MEMORY type. Any other memory type that is to be
added to the EFI memory map, still gets handled by the EFI memory
module.

Changes since V3:
* Add comments for the LMB_NOOVERWRITE and LMB_NONOTIFY flags
* Drop use of is_addr_in_ram() function
* Drop use of CONFIG_MEM_MAP_UPDATE_NOTIFY symbol to check if the
  notification needs to be sent.
* s/lmb_notify/lmb_should_notify
* Put a check for EFI_LOADER in the lmb_should_notify() function

Some test logs to highlight the issue that is being fixed by the series.

Without patch series
--------------------

lmb_dump_all:
 memory.count = 0x1
 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none
 reserved.count = 0x3
 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map
 reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map
 reserved[2] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite

=> efidebug memmap -- does not show regions allocated by lmb

Missing TPMv2 device for EFI_TCG_PROTOCOL
Type             Start            End              Attributes
================ ================ ================ ==========
CONVENTIONAL     0000000040000000-000000007f751000 WB
BOOT DATA        000000007f751000-000000007f756000 WB
RUNTIME DATA     000000007f756000-000000007f757000 WB|RT
BOOT DATA        000000007f757000-000000007f758000 WB
RUNTIME DATA     000000007f758000-000000007f77a000 WB|RT
BOOT DATA        000000007f77a000-000000007f781000 WB
BOOT CODE        000000007f781000-00000000807b5000 WB
RUNTIME DATA     00000000807b5000-00000000807b6000 WB|RT
BOOT CODE        00000000807b6000-00000000817c0000 WB
RUNTIME CODE     00000000817c0000-00000000817d0000 WB|RT
BOOT CODE        00000000817d0000-0000000082100000 WB
=>

Trying to allocate EFI memory with already allocated region succeeds(should fail)
---------------------------------------------------------------------------------

=> efi_mem alloc 2000 42000000
Address returned 0x42000000

=> efidebug memmap
Type             Start            End              Attributes
================ ================ ================ ==========
CONVENTIONAL     0000000040000000-0000000042000000 WB
BOOT DATA        0000000042000000-0000000042002000 WB
CONVENTIONAL     0000000042002000-000000007f751000 WB
BOOT DATA        000000007f751000-000000007f756000 WB
RUNTIME DATA     000000007f756000-000000007f757000 WB|RT
BOOT DATA        000000007f757000-000000007f758000 WB
RUNTIME DATA     000000007f758000-000000007f77a000 WB|RT
BOOT DATA        000000007f77a000-000000007f781000 WB
BOOT CODE        000000007f781000-00000000807b5000 WB
RUNTIME DATA     00000000807b5000-00000000807b6000 WB|RT
BOOT CODE        00000000807b6000-00000000817c0000 WB
RUNTIME CODE     00000000817c0000-00000000817d0000 WB|RT
BOOT CODE        00000000817d0000-0000000082100000 WB
=>

With patch series
-----------------

lmb_dump_all:
 memory.count = 0x1
 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none
 reserved.count = 0x4
 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map
 reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map
 reserved[2] [0x7f74f000-0x7f77dfff], 0x0002f000 bytes flags: no-notify, no-overwrite
 reserved[3] [0x7f77ea00-0x820fffff], 0x02981600 bytes flags: no-overwrite

=> efidebug memmap
Type             Start            End              Attributes
================ ================ ================ ==========
BOOT DATA        000000000e100000-000000000f000000 WB
CONVENTIONAL     0000000040000000-0000000042000000 WB
BOOT DATA        0000000042000000-0000000042200000 WB
CONVENTIONAL     0000000042200000-000000007f74e000 WB
BOOT DATA        000000007f74e000-000000007f753000 WB
RUNTIME DATA     000000007f753000-000000007f754000 WB|RT
BOOT DATA        000000007f754000-000000007f755000 WB
RUNTIME DATA     000000007f755000-000000007f777000 WB|RT
BOOT DATA        000000007f777000-00000000807b6000 WB
RUNTIME DATA     00000000807b6000-00000000807b7000 WB|RT
BOOT DATA        00000000807b7000-00000000817c0000 WB
RUNTIME CODE     00000000817c0000-00000000817d0000 WB|RT
BOOT DATA        00000000817d0000-0000000082100000 WB

Trying to allocate EFI memory with already allocated region fails
-----------------------------------------------------------------

=> efi_mem alloc 2000 42000000
efi_allocate_pages failed 800000000000000e
=>

Trying to allocate EFI memory with non-allocated region succeeds
----------------------------------------------------------------

=> efi_mem alloc 2000 42200000
Address returned 0x42200000

=> efidebug memmap
Type             Start            End              Attributes
================ ================ ================ ==========
BOOT DATA        000000000e100000-000000000f000000 WB
CONVENTIONAL     0000000040000000-0000000042000000 WB
BOOT DATA        0000000042000000-0000000042202000 WB
CONVENTIONAL     0000000042202000-000000007f74d000 WB
BOOT DATA        000000007f74d000-000000007f752000 WB
RUNTIME DATA     000000007f752000-000000007f753000 WB|RT
BOOT DATA        000000007f753000-000000007f754000 WB
RUNTIME DATA     000000007f754000-000000007f776000 WB|RT
BOOT DATA        000000007f776000-00000000807b5000 WB
RUNTIME DATA     00000000807b5000-00000000807b6000 WB|RT
BOOT DATA        00000000807b6000-00000000817c0000 WB
RUNTIME CODE     00000000817c0000-00000000817d0000 WB|RT
BOOT DATA        00000000817d0000-0000000082100000 WB
=>

lmb_dump_all:
 memory.count = 0x1
 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none
 reserved.count = 0x5
 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map
 reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map
 reserved[2] [0x42200000-0x42201fff], 0x00002000 bytes flags: no-notify, no-overwrite
 reserved[3] [0x7f74e000-0x7f77cfff], 0x0002f000 bytes flags: no-notify, no-overwrite
 reserved[4] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite

Link: https://lore.kernel.org/r/20241015153717.401371-1-sughosh.ganu@linaro.org

lmb: replace the double-underscore with single-underscore for all functions

A bunch of static functions in the LMB module have used a
double-undersore for the function names. It was suggested to use a
single-underscore instead, as the double-underscore is usually used
by library functions. Replace the double-underscore with
single-underscore for all functions.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Suggested-by: Simon Glass <sjg@chromium.org>

efi_memory: rename variable to highlight overlap with free memory

The variable overlap_only_ram is used to specify that the new memory
region that is being created needs to come from the free memory pool
-- this is done by carving out the memory region from the free
memory. The name is a bit confusing though, as other allocated memory
regions, like boot-services code and data are also part of the RAM
memory. Rename the variable to overlap_conventional to highlight the
fact that it is the free/conventional memory that is being referred to
in this context.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

lmb: remove call to efi_lmb_reserve()

The EFI memory allocations are now being done through the LMB
module. With this change, there is no need to get the EFI memory map
and set aside EFI allocated memory.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

efi_memory: do not add RAM memory to the memory map

The EFI_CONVENTIONAL_MEMORY type, which is the usable RAM memory is
now being managed by the LMB module. Remove the addition of this
memory type to the EFI memory map. This memory now gets added to the
EFI memory map as part of the LMB memory map update event handler.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

x86: e820: use the lmb API for adding RAM memory

The EFI_CONVENTIONAL_MEMORY type is now being managed through the LMB
module. Add a separate function, lmb_arch_add_memory() to add the RAM
memory to the LMB memory map. The efi_add_known_memory() function is
now used for adding any other memory type to the EFI memory map.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>

layerscape: use the lmb API's to add RAM memory

The EFI memory allocations are now being done through the LMB module,
and hence the memory map is maintained by the LMB module. Use the
lmb_arch_add_memory() API function to add the usable RAM memory to the
LMB's memory map.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>

lmb: allow for boards to specify memory map

Some architectures have special or unique aspects which need
consideration when adding memory ranges to the list of available
memory map. Enable this config in such scenarios which allow
architectures and boards to define their own memory map.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>

stm32mp: remove efi_add_known_memory() function definition

The efi_add_known_memory() function for the stm32mp platforms is adding
the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled
through the LMB module -- the lmb_add_memory() adds this memory to the
memory map. Remove the definition of the now superfluous
efi_add_known_memory() function.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

ti: k3: remove efi_add_known_memory() function definition

The efi_add_known_memory() function for the TI K3 platforms is adding
the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled
through the LMB module -- the lmb_add_memory() adds this memory to the
memory map. Remove the definition of the now superfluous
efi_add_known_memory() function.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

efi_memory: do not add U-Boot memory to the memory map

The memory region occupied by U-Boot is reserved by LMB, and gets
added to the EFI memory map through a call from the LMB module. Remove
this superfluous addition to the EFI memory map.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

lmb: notify of any changes to the LMB memory map

In U-Boot, LMB and EFI are two primary modules who provide memory
allocation and reservation API's. Both these modules operate with the
same regions of memory for allocations. Use the LMB memory map update
event to notify other interested listeners about a change in it's
memory map. This can then be used by the other module to keep track of
available and used memory.

There is no need to send these notifications when the LMB module is
being unit-tested. Add a flag to the lmb structure to indicate if the
memory map is being used for tests, and suppress sending any
notifications when running these unit tests.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>

efi: memory: use the lmb API's for allocating and freeing memory

Use the LMB API's for allocating and freeing up memory. With this, the
LMB module becomes the common backend for managing non U-Boot image
memory that might be requested by other modules.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>

lmb: add and reserve memory above ram_top

U-Boot does not use memory above ram_top. However, this memory does
need to get registered as part of the memory map, so that subsystems
like EFI pass it on to the operating system as part of the EFI memory
map. Add memory above ram_top and reserve it with the LMB_NOOVERWRITE
flag so that it does not get allocated or re-used.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Suggested-by: Mark Kettenis <kettenis@openbsd.org>

lmb: add a flag to allow suppressing memory map change notification

Add a flag LMB_NONOTIFY that can be passed to the LMB API's for
reserving memory. This will then result in no notification being sent
from the LMB module for the changes to the LMB's memory map.

While here, also add a description of the memory attributes that the
flags signify.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>

lmb: add versions of the lmb API with flags

The LMB module is to be used as a backend for allocating and freeing
up memory requested from other modules like EFI. These memory requests
are different from the typical LMB reservations in that memory
required by the EFI module cannot be overwritten, or re-requested. Add
versions of the LMB API functions with flags for allocating and
freeing up memory. The caller can then use these API's for specifying
the type of memory that is required. For now, these functions will be
used by the EFI memory module.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

test: Drop mention of old flags in a comment

A comment in test-main.c was not updated with the recent rename. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Makefile: Drop SPL_FIT_GENERATOR support

The SPL_FIT_GENERATOR is long superseded by binman, drop SPL_FIT_GENERATOR
support as there are no more users.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Makefile: Drop SPL_FIT_SOURCE support

The SPL_FIT_SOURCE is long superseded by SPL_FIT_GENERATOR which
is long superseded by binman, drop SPL_FIT_SOURCE support as there
are no more users.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>

test: Fix skip check for sleep command test

When the config option CMD_MISC was renamed to CMD_SLEEP the check
in the test for the sleep command was not updated. Do that now.

Fixes: 16060854095 ("cmd: Rename CMD_MISC to CMD_SLEEP")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

CI: Do not test "sleep" in QEMU

When we have platforms being emulated by QEMU we cannot rely on the
"sleep" command running for the expected wall-clock amount of time. Even
with our current allowance for deviation from expected time, it will
still fail from time to time. Exclude the sleep test here.

Signed-off-by: Tom Rini <trini@konsulko.com>

net: correct wget_connected debug messages

* Remove duplicate debug message in wget_connected()
* Correct typo 'Connctd'

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

net/wget: set filesize

After downloading a file with wget the file size may be needed in follow up
actions, e.g.

* write file to device
* calculate hash

Let wget set the environment variable filesize.

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Revert "mmc: dw_mmc: Extract FIFO data transfer into a separate routine"

The commit 0252924ac6d4 ("mmc: dw_mmc: Extract FIFO data transfer into a
separate routine") unintentionally changed behavior of the FIFO data
transfer routine.

When data is read and size reaches 0 the original loop would wait on
DWMCI_INTMSK_DTO or timeout. The remaining size to read and buf position
is no longer tracked across dwmci_data_transfer_fifo() calls and because
of this an extra call to fifo() and dwmci_fifo_ready() may now trigger a
FIFO underflow timeout error and slows down FIFO reading.

  Buswidth = 4, clock: 50000000
  Sending CMD16
  Sending CMD17
  dwmci_fifo_ready: FIFO underflow timeout
  Sending CMD16
  Sending CMD18
  dwmci_fifo_ready: FIFO underflow timeout
  Sending CMD12
  ## Checking hash(es) for config config-1 ... OK

This reverts commit 0252924ac6d4af69061bb9589d16b30c5bdb7178 to restore
the old working behavior.

Fixes: 0252924ac6d4 ("mmc: dw_mmc: Extract FIFO data transfer into a separate routine")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Tiger
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge patch series "test: Minor fixes to test.py"

Simon Glass <sjg@chromium.org> says:

This series collects together the patches from the Labgrid series which
are not related to Labgrid, or at least can be applied independently of
using Labgrid to run the lab.

Link: https://lore.kernel.org/r/20241010002907.19383-1-sjg@chromium.org

Merge patch series to add a "fallback" keyword to extlinux.conf parsing

This series from Martyn Welch <martyn.welch@collabora.com> adds the
ability to have a "fallback" option in extlinux.conf parsing, which can
be in turn used in A/B style update mechanisms.

Link: https://lore.kernel.org/u-boot/20241009131548.929439-1-martyn.welch@collabora.com/

test: Add tests for the bootmeth set command

We have added a "set" sub command to bootmeth, add some tests to check
it's operation.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

test: Fix mulptiplex_log typo

Fix a typo in a comment.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add command to enable setting of bootmeth specific properties

We have previously added logic to allow a "fallback" option to be
specified in the extlinux configuration. Provide a command that allows
us to set this as the preferred default option when booting.

Combined with the bootcount functionality, this allows the "altbootcmd"
to provide a means of falling back to a previously known good state
after a failed update. For example, if "bootcmd" is set to:

    bootflow scan -lb

We would set "altbootcmd" to:

    bootmeth set extlinux fallback 1; bootflow scan -lb

Causing the boot process to boot from the fallback option.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

test: Tidy up remaining exceptions

Use the new handle_exception() function from ConsoleBase also.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: Add logic to enable booting from fallback option

The "fallback" extlinux config option allows us to set an alternative
default boot option for when it has been detected that the default is
failing. Implement the logic required to boot from this option when
desired.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

test: Detect dead connections

When the connection to a board dies, assume it is dead forever until
some user action is taken. Skip all remaining tests. This avoids CI
runs taking an hour, with hundreds of 30-second timeouts all to no
avail.

Signed-off-by: Simon Glass <sjg@chromium.org>

boot: pxe_utils: Add fallback support

When configured correctly, we can detect when boot fails after the boot
process has been handed over to the kernel through the use of U-Boot's
bootcount support. In some instances, such as when we are performing
atomic updates via a system such as OSTree, it is desirable to provide a
fallback option so that we can return to a previous (hopefully working)
state.

Add a "fallback" option to the supported extlinux configuration options
that points to a label like "default" so that we can utilise this in
later commits.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

test: Separate out the exception handling

The tests currently catch a very broad Exception in each case. This is
thrown even in the event of a coding error.

We want to handle exceptions differently depending on their severity,
so that we can avoid hour-long delays waiting for a board that is
clearly broken.

As a first step, create some new exception types, separating out those
which are simply an unexpected result from executed a command, from
those which indicate some kind of hardware failure.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Move the receive code into a function

There is quite a bit of code to deal with receiving data from the target
so move it into its own receive() function.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Create a common function to get the config

The settings are decoded in two places. Combine them into a new
function, before (in a future patch) expanding the number of items.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Avoid failing skipped tests

When a test returns -EAGAIN this should not be considered a failure.
Fix what seems to be a problem case, where the pytests see a failure
when a test has merely been skipped.

We cannot squash the -EAGAIN error in ut_run_test() since the failure
count is incremented by its caller, ut_run_test_live_flat()

The specific example here is on snow, where a test is compiled into the
image but cannot run, so returns -EAGAIN to skip:

    test/py/tests/test_ut.py sssnow # ut bdinfo bdinfo_test_eth
    Test: bdinfo_test_eth: bdinfo.c
    Skipping: Console recording disabled
    test/test-main.c:486, ut_run_test_live_flat(): 0 == ut_run_test(uts,
    test, test->name): Expected 0x0 (0), got 0xfffffff5 (-11)
    Test bdinfo_test_eth failed 1 times
    Skipped: 1, Failures: 1
    snow # F+u-boot-test-reset snow snow

The fix is simply to respect the return code from ut_run_test(), so do
that.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Use a constant for the test timeout

Declare a constant rather than open-coding the same value twice.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Merge patch series "mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it"

Takahiro Kuwano <Takahiro.Kuwano@infineon.com> says:

This series is equivalent to the one for Linux MTD submitted by
Pratyush Yadav.

https://patchwork.ozlabs.org/project/linux-mtd/list/?series=217759&state=*

Changes in v3:
  - Rebase

Changes in v2:
  - Fix an issue in setting macronix_octal_fixups
  - Rework fixup hooks

Takahiro Kuwano (6):
  mtd: ubi: Do not zero out EC and VID on ECC-ed NOR flashes
  mtd: spi-nor: Allow flashes to specify MTD writesize
  mtd: spi-nor: Check nor->info before setting macronix_octal_fixups
  mtd: spi-nor: Replace default_init() hook with late_init()
  mtd: spi-nor: Call spi_nor_post_sfdp_fixups() only after
    spi_nor_parse_sfdp()
  mtd: spi-nor: Set ECC unit size to MTD writesize in Infineon SEMPER
    flashes

drivers/mtd/spi/spi-nor-core.c | 88 +++++++++++++++++++++-------------
 drivers/mtd/ubi/build.c        |  4 +-
 drivers/mtd/ubi/io.c           |  9 +++-
 include/linux/mtd/spi-nor.h    |  1 +
 4 files changed, 65 insertions(+), 37 deletions(-)

Link: https://lore.kernel.org/r/cover.1728964655.git.Takahiro.Kuwano@infineon.com

mtd: spi-nor: Set ECC unit size to MTD writesize in Infineon SEMPER flashes

The Infineon SEMPER NOR flash family uses 2-bit ECC by default with each
ECC block being 16 bytes. Under this scheme multi-pass programming to an
ECC block is not allowed. Set the writesize to make sure multi-pass
programming is not attempted on the flash.

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

mtd: spi-nor: Call spi_nor_post_sfdp_fixups() only after spi_nor_parse_sfdp()

This patch follows the upstream linux commit:
5273cc6df984("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only
when SFDP is defined")

spi_nor_post_sfdp_fixups() was called regardless of if
spi_nor_parse_sfdp() had been called or not. late_init() should be
instead used to initialize the parameters that are not defined in SFDP.

Ideally spi_nor_post_sfdp_fixups() is called only after successful parse
of SFDP. However, in case SFDP support is disabled by .config, that can
break current functionality. Therefore, we would call it after
spi_nor_parse_sfdp() regardless of its return value.

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

mtd: spi-nor: Replace default_init() hook with late_init()

default_init() is wrong, it contributes to the maze of initializing
flash parameters. We'd like to get rid of it because the flash
parameters that it initializes are not really used at SFDP parsing time,
thus they can be initialized later.

Ideally we want SFDP to initialize all the flash parameters. If (when)
SFDP tables are wrong, we fix them with the post_sfdp/bfpt hooks, to
emphasize that SFDP is indeed wrong. When there are parameters that are
not covered by SFDP, we initialize them in late_init() - these
parameters have nothing to do with SFDP and they are not needed earlier.
With this we'll have a clearer view of who initializes what.

There are six default_init() hooks implemented just for initializing
octal_dtr_enable() and/or setup() hooks that called later on.
Just moving those to late_init() does not change functionality.

Suggested-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

mtd: spi-nor: Check nor->info before setting macronix_octal_fixups

The macronix_octal_fixups should be set only when mfr and flags match.

Fixes: df3d5f9e41 ("mtd: spi-nor: add support for Macronix Octal flash")
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Cc: JaimeLiao <jaimeliao.tw@gmail.com>

mtd: spi-nor: Allow flashes to specify MTD writesize

Some flashes like the Infineon SEMPER NOR flash family use ECC. Under
this ECC scheme, multi-pass writes to an ECC block is not allowed.
In other words, once data is programmed to an ECC block, it can't be
programmed again without erasing it first.

Upper layers like file systems need to be given this information so they
do not cause error conditions on the flash by attempting multi-pass
programming. This can be done by setting 'writesize' in 'struct
mtd_info'.

Set the default to 1 but allow flashes to modify it in fixup hooks. If
more flashes show up with this constraint in the future it might be
worth it to add it to 'struct flash_info', but for now increasing its
size is not worth it.

This patch replicates the following upstream linux commit:
afd473e85827 ("mtd: spi-nor: core: Allow flashes to specify MTD writesize")

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

mtd: ubi: Do not zero out EC and VID on ECC-ed NOR flashes

For NOR flashes EC and VID are zeroed out before an erase is issued to
make sure UBI does not mistakenly treat the PEB as used and associate it
with an LEB.

But on some flashes, like the Infineon Semper NOR flash family,
multi-pass page programming is not allowed on the default ECC scheme.
This means zeroing out these magic numbers will result in the flash
throwing a page programming error.

Do not zero out EC and VID for such flashes. A writesize > 1 is an
indication of an ECC-ed flash.

This patch replicates the following upstream linux commit:
f669e74be820 ("ubi: Do not zero out EC and VID on ECC-ed NOR flashes")

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>

usb: dwc3: invalidate dcache on buffer used in interrupt handling

On Qualcomm systems, the setup buffer and even buffers are in
a bad state at interrupt handling, so invalidate the dcache lines
for the setup_buf and event buffer to make sure we read correct
data written by the hardware.

This fixes the following error:
dwc3-generic-peripheral usb@a600000: UNKNOWN IRQ type -1
dwc3-generic-peripheral usb@a600000: UNKNOWN IRQ type 4673109

and invalid situation in dwc3_gadget_giveback() because setup_buf content
is read at 0s and leads to fatal crash fixed by [1].

[1] https://lore.kernel.org/all/20240528-topic-sm8x50-dwc3-gadget-crash-fix-v1-1-58434ab4b3d3@linaro.org/

Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20241011-u-boot-dwc3-gadget-dcache-fixup-v4-3-5f3498d8035b@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

usb: dwc3: fix dcache flush range calculation

The current flush operation will omit doing a flush/invalidate on
the first and last bytes if the base address and size are not aligned
with CACHELINE_SIZE.

This causes operation failures Qualcomm platforms.

Take in account the alignment and size of the buffer and also
flush the previous and last cacheline.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20241011-u-boot-dwc3-gadget-dcache-fixup-v4-2-5f3498d8035b@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>