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

- StarFive: Add StarFive watchdog driver
- VisionFive2: Support device tree overlay for VisionFive2 board
- Andes: Fix PLIC-SW setting
- RISC-V: Fix NVMe support by implying NVME_PCI for QEMU
- RISC-V: Fix binman for 64 bit format load address

Merge patch series "bootflow: bootmeth_efi: Fix network efi boot."

To quote the author:

Currently bootmeth_efi crashes while doing a network (dhcp) boot.
This patch series fixes issues and both network and disk boot works.

# Do not modify or remove the line above.
# Everything below it will be ignored.
#
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# An empty message aborts the commit.

bootflow: bootmeth_efi: don't free buffer

bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Handle fdt not available.

While booting with efi, if fdt isn't available externally,
just use the built-in one.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: set bflow->fname from bootfile name

We need to set boot->fname before calling efi_set_bootdev
otherwise this crashes as bflow->fname is null.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootflow: bootmeth_efi: Set bootp_arch as hex

bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.

For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.

Setting it as hex string fixes the problem.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

arm: apple: t602x: Add missing MMIO regions to memmap

The memory maps for Apple's M2 Pro/Max/Ultra left MMIO space out which
was not used by any driver at the time. The display out exposed as
simple-framebuffer use a power-domain controlled by a device in an
unmapped region.
Add a map covering this region as well as another MMIO region in the
range 0x4'0000'0000 - 0x5'0000'0000. The added regions cover all MMIO
annotated in Apple's device tree in this range.

Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Eric Curtin <ecurtin@redhat.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>

Merge tag 'u-boot-amlogic-20231207' of https://source.denx.de/u-boot/custodians/u-boot-amlogic

- Add missing DM_USB_GADGET to amlogic boards

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi

The first four patches are actual fixes. The last three patches add
support for the apparently popular OrangePi Zero 3 board: multiple
people seem to be champing at the bit, so I'd rather give them
something real instead of people using random trees they found on the
Internet. It's actually mostly the new defconfig file anyway, so the
chances for regressions are very slim.

Merge tag 'efi-2024-01-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2024-01-rc5

Documentation:

* Update and correct support notes on clang
* sandbox: Fix VPL instructions

UEFI:

* Fix a bug in DisconnectController
* Provide better error messages for missing CONFIG_EFI_CAPSULE_ESL_FILE
* Create EFI memory reservations when booting via ACPI
* Make ACPI tables accessible in EFI app

configs: meson: enable missing DM_USB_GADGET

Since commit b96640cbfb ("ARM: meson: g12a: switch dwc2 otg to DM")
and commit e327e2affd ("ARM: meson: switch AXG & GX dwc2 otg to DM")
Amlogic boards now requires DM_USB_GADGET to have USB Gadget to work.

Add it to the boards configs as returned by:
$ grep -L DM_USB_GADGET $(grep -l CONFIG_USB_GADGET $(grep -l MESON configs/*))

Fixes: b96640cbfb ("ARM: meson: g12a: switch dwc2 otg to DM")
Fixes: e327e2affd ("ARM: meson: switch AXG & GX dwc2 otg to DM")
Link: https://lore.kernel.org/r/20231206-u-boot-m2s-fix-usb-gadget-v1-1-1c4c66cd10f3@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>

sunxi: H616: Add OrangePi Zero 3 board support

The OrangePi Zero 3 is a small development board featuring the Allwinner
H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI
connector and two USB sockets.
The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for
which was recently added to U-Boot.

Add a defconfig file selecting the right drivers and DRAM options.
Since the .dts file was synced from the Linux kernel repo already, we
just need to add one line to the Makefile to actually build the .dtb.

The DRAM parameters were derived from the values found in the BSP DRAM
drivers on the SPI NOR flash.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Mikhail Kalashnikov <iuncuim@gmail.com>
Tested-by: Bob McChesney <bob@electricworry.net>
Tested-by: Stephen Graf <stephen.graf@gmail.com>

sunxi: H616: remove default AXP305 selection

The original H616 devices released about three years ago were typically
paired with an X-Powers AXP305 PMIC. Newer devices uses the smaller
AXP313, and there seem to be far more systems with this PMIC around now.

Remove the default AXP305 selection for the H616 SoC from the Kconfig,
and move the PMIC selection into the board defconfig files instead.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

mtd: spi-nor: Add support for zBIT ZB25VQ128

Add support for the zBIT ZB25VQ128 (128M-bit) SPI NOR flash memory chip,
as used on the Xunlong Orange Pi Zero 3 board.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>

sunxi: dts: arm64: update emac for Orange Pi Zero 3

The current emac setting is not suitable for Orange Pi Zero 3,
move it back to Orange Pi Zero 2 DT. Also update phy mode and
delay values for emac on Orange Pi Zero 3.
With these changes, Ethernet now looks stable.

Fixes: 95c3b0635ea4 ("sunxi: dts: arm64: update devicetree files from Linux-v6.6-rc6")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: correct documentation for SPI flashing

The mtd_debug write does not work in this context. The flashcp command does
work, provides both the erase and write functions and with the verbose
option gives good feedback.

Signed-off-by: Stephen Graf <stephen.graf@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>

sunxi: h616: (really) lower SPL stack address to avoid BROM data

When using the USB OTG FEL mode on the Allwinner H616, the BootROM
stores some data at the end of SRAM C. This is also the location where
we place the initial SPL stack, so it will overwrite this data.
We still need the BROM code after running the SPL, so should leave that
area alone.
Interestingly this does not seem to have an adverse effect, I guess on
the "way out" (when we return to FEL after the SPL has run), this data
is not needed by the BROM, for just the trailing end of the USB operation.
However this is still wrong, and we should not clobber BROM data.

Lower the SPL stack address to be situated right below the swap buffers
we use in sunxi-fel: that should be out of the way of everyone else.

This obsoletes a previous commit (eb53e7743c8f) with the same name:
that one was changing the address in an *unused* macro in sunxi_common.h,
so the previous patch didn't have any effect at all.

Fixes: eb53e7743c8f ("sunxi: h616: lower SPL stack address to avoid BROM data")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: H616: OrangePi Zero 2: enable USB power supply

The OrangePi Zero 2 has a USB VBUS regulator, controlled by pin PC16.
This is correctly described in the DT, but the patches for supporting
this are still pending.

Meanwhile add our good old CONFIG_USB1_VBUS_PIN to the defconfig file,
to enable power on the USB port and allow using a USB flash drive, for
instance.

Fixes: 6acc5fa581b4 ("sunxi: H616: enable USB support for H616 boards")
Reported-by: Mikhail Kalashnikov <iuncuim@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

starfive: visionfive2: add device tree overlay support

device tree overlay support requires fdtoverlay_addr_r to be set

before
~~~~~~
Invalid fdtoverlay_addr_r for loading overlays

after
~~~~~
Retrieving file: /boot/overlay/rtc-ds3231.dtbo

Signed-off-by: John Clark <inindev@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

riscv: binman: fix the load field format

Using /bits/ 64 prefix for 64 bits address

Signed-off-by: Randolph <randolph@andestech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

riscv: andes: Fix enable register settings of PLICSW

On 32-core platform, hart31 gets stuck at secondary_hart_loop
as the corresponding enable bit is not set in enable_ipi().
We should program the next word (0x2f84) which is assigned
as the enable register of hart31. It should be done in the same
way when we invoke riscv_send_ipi() to trigger software interrupt
on hart31.

The following diagram shows the enable bits of the fixed PLICSW
scheme.

   Pending regs: 0x1000  x---0---0---0---0------0---0
Pending hart ID:             0   1   2   3 ... 30  31
   Interrupt ID:         0   1   2   3   4 ... 31  32
                         |   |   |   |   |      |   |
    Enable regs: 0x2000  x---1---0---0---0-...--0---0---> hart0
                         |   |   |   |   |      |   |
                 0x2080  x---0---1---0---0-...--0---0---> hart1
                         |   |   |   |   |      |   |
                 0x2100  x---0---0---1---0-...--0---0---> hart2
                         |   |   |   |   |      |   |
                 0x2180  x---0---0---0---1-...--0---0---> hart3
                         .   .   .   .   .      .   .
                         .   .   .   .   .      .   .
                         .   .   .   .   .      .   .
                 0x2f00  x---0---0---0---0-...--1---0---> hart30
                         |   |   |   |   |      |   |
                 0x2f80  x---0---0---0---0-...--0---1---> hart31
                         <-------- word 0 -------><--- word 1 --->

This patch includes some cleanups to macros/functions.

Fixes: ebf11273220a ("riscv: andes: Rearrange Andes PLICSW to single-bit-per-hart strategy")
Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com>
Reviewed-by: Randolph <randolph@andestech.com>

risc-v: qemu: imply NVME_PCI

CONFIG_NVME=y without CONFIG_NVME_PCI=y does not provide working NVMe
support. Instead of implying CONFIG_NVME we must imply CONFIG_NVME_PCI
which will select CONFIG_NVME.

Fixes: e64db0d92e32 ("riscv: qemu: Enable e1000 and nvme support")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>

configs: visionfive2: Enable watchdog driver

Enables StarFive Watchdog driver and WDT command.

Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

riscv: dts: jh7110: Add watchdog device tree node

Adds jh7110 watchdog device tree node.

Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

watchdog: Add StarFive Watchdog driver

Add to support StarFive watchdog driver. The driver is imported from
linux kernel's drivers/watchdog/starfive-wdt.c without jh7100 support
because there is no support of jh7100 SoC in u-boot yet.
Howver, this patch has been kept the variant coding style because JH7100
can be added later and have a consistency with the linux driver.

Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

clk: starfive: jh7110: Add watchdog clocks

Add JH7110_SYSCLK_WDT_APB and JH7110_SYSCLK_WDT_CORE clocks for JH7110
watchdog device.

Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

efi_loader: Make DisconnectController follow the EFI spec

commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
tried to fix the UninstallProtocol interface which must reconnect
any controllers it disconnected by calling ConnectController()
in case of failure. However, the reconnect functionality was wired in
efi_disconnect_all_drivers() instead of efi_uninstall_protocol().

As a result some SCT tests started failing.
Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
 - Calls ConnectController for DriverImageHandle1
 - Calls DisconnectController for DriverImageHandle1 which will
   disconnect everything apart from TestProtocol4. That will remain
   open on purpose.
 - Calls ConnectController for DriverImageHandle2. TestProtocol4
   which was explicitly preserved was installed wth BY_DRIVER attributes.
   The new protocol will call DisconnectController since its attributes
   are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
   test expects EFI_ACCESS_DENIED which works fine.

   The problem is that DisconnectController, will eventually call
   EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
   this will call CloseProtocol -- the binding protocol is defined in
   'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
   If that close protocol call fails with EFI_NOT_FOUND, the current code
   will try to mistakenly reconnect all drivers and the subsequent tests
   that rely on the device being disconnected will fail.

Move the reconnection in efi_uninstall_protocol() were it belongs.

Fixes: commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: create memory reservations in ACPI case

ACPI tables cannot convey memory reservations for ARM and RISC-V.
x86 uses the BIOS E820 table for this purpose. We cannot simply ignore the
device-tree when booting via ACPI. We have to assign EfiReservedMemory
according to the prior stage device-tree ($fdtaddr) or as fallback the
control device-tree ($fdtcontroladdr).

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

efi: Correct display of table GUIDs

The printf() %pU option decodes GUIDs so it is not necessary to do this
first. Drop the incorrect code.

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

efi: Collect the ACPI tables in the app

Locate these so that they can be displayed using the 'acpi' command.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

scripts/Makefile.lib: print error when no public key is specified

The current build system embeds the EFI Signature List(ESL)
into the dtb to be used in the EFI capsule authentication.
This ESL file is specified through the CONFIG_EFI_CAPSULE_ESL_FILE
Kconfig option. If CONFIG_EFI_CAPSULE_ESL_FILE is not specified,
U-boot build ends up with failure but the cause of failure is not
easily understandable. Current error message is as follows.

FATAL ERROR: Error reading file into data: Is a directoryCheck /home/ubuntu/src/ledge/u-boot/arch/arm/dts/.synquacer-sc2a11-developerbox.dtb.pre.tmp for errors
make[2]: *** [scripts/Makefile.lib:355: arch/arm/dts/synquacer-sc2a11-developerbox.dtb] Error 1
make[1]: *** [dts/Makefile:44: arch-dtbs] Error 2
make: *** [Makefile:1165: dts/dt.dtb] Error 2
make: *** Waiting for unfinished jobs....

This commit shows the error message that CONFIG_EFI_CAPSULE_ESL_FILE
must be specified when the EFI capsule authentication is enabled, then
terminate the build with error.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Weizhao Ouyang <o451686892@gmail.com>

doc: sending_patches.rst: s/Superseeded/Superseded

This is a common typo listed in scripts/spelling.txt. Fix it to match the
patchwork status, which is superseded.

Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: clang: Update and correct support notes

At this point, clang can be used on both 32bit and 64bit targets without
issue. Make note of logic we have that will inform clang of the
architecture to build for.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

sandbox: Fix VPL instructions

Fix the devicetree used with sandbox. This is needed because the
default (full) devicetree must be used by all phases of boot, with
sandbox.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Prepare v2024.01-rc4

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

efi_loader: generated SMBIOS table below 4 GiB

We currently use an outdated format 32-bit format for SMBIOS tables.
So we must allocate SMBIOS tables below 4 GiB.

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

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-watchdog

- Correct watchdog timeout print message (Chanho Park)

watchdog: Correct watchdog timeout print message

The wdt_start function takes timeout_ms as a parameter and starts the
watchdog with this value. However, when you output the message, it shows
the default timeout value for the watchdog device.
So this patch fixes that part to output the correct timeout value.

Before -->
StarFive # wdt start 3000
WDT:   Started watchdog@13070000 without servicing  (60s timeout)

After -->
StarFive # wdt start 3000
WDT:   Started watchdog@13070000 without servicing  (3s timeout)

Fixes: c2fd0ca1a822 ("watchdog: Integrate watchdog triggering into the cyclic framework")
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge branch 'master-rpc-off' of https://source.denx.de/u-boot/custodians/u-boot-sh

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-usb

- USB XHCI fixes

ARM: dts: renesas: Disable RPC driver on R8A779G0 V4H White Hawk board

As requirement of CR side, QSPI Flash usage via RPC driver shall
be disabled and leaving the control of this module to CR side.
Perform DT modification to disable the RPC SPI.

Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Cong Dang <cong.dang.xn@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: Do not modify defconfig, modify the DT instead, this way
        the RPC SPI can be enabled without recompiling the U-Boot
itself. Update commit message accordingly.]

ARM: dts: renesas: Clean up R8A779G0 V4H RPC SPI DT node

Use the phandle reference to &rpc node in arch/arm/dts/r8a779g0.dtsi
and remove properties which are already in arch/arm/dts/r8a779g0.dtsi.
No functional change and no resulting DT change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

usb: USB_XHCI_PCI depends on PCI

Compiling with CONFIG_USB_XHCI_PCI and CONFIG_PCI=n results in

    usb/host/xhci-pci.c:48:(.text.xhci_pci_probe+0x44):
    undefined reference to `dm_pci_write_config32

Add the missing Kconfig dependency.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: dwc3-generic: Use combined glue and ctrl node for RK3588

Like Rockchip RK3328 and RK3568, the RK3588 also have a single node to
represent the glue and ctrl for USB 3.0.

Use rk_ops as driver data to select correct ctrl node for RK3588 DWC3.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: storage: Use the correct CBW lengths

USB UFI uses fixed 12-byte commands (as does RBC, which is not
supported), but SCSI does not have this limitation. Use the correct
command block lengths depending on the subclass.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: hub: Add missing reset recovery delay

Some devices like YubiKeys need more time before SET_ADDRESS. The spec
says we need to wait 10ms.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: xhci: Fix DMA address calculation in queue_trb

We need to get the DMA address before incrementing the pointer, as that
might move us onto another segment.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: xhci: Do not panic on event timeouts

Now that we always check the return value, just return NULL on timeouts.
We can still log the error since this is a problem, but it's not reason
to panic.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: xhci: Fail on attempt to queue TRBs to a halted endpoint

This isn't going to work, don't pretend it will and then end up timing
out.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: xhci: Recover from halted bulk endpoints

There is currently no codepath to recover from this case. In principle
we could require that the upper layer do this explicitly, but let's just
do it in xHCI when the next bulk transfer is started, since that
reasonably implies whatever caused the problem has been dealt with.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: xhci: Allow context state errors when halting an endpoint

There is a race where an endpoint may halt by itself while we are trying
to halt it, which results in a context state error. See xHCI 4.6.9 which
mentions this case.

This also avoids BUGging when we attempt to stop an endpoint which was
already stopped to begin with, which is probably a bug elsewhere but
not a good reason to crash.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: xhci: Better error handling in abort_td()

If the xHC has a problem with our STOP ENDPOINT command, it is likely to
return a completion directly instead of first a transfer event for the
in-progress transfer. Handle that more gracefully.

We still BUG() on the error code, but at least we don't end up timing
out on the event and ending up with unexpected event errors.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>

usb: xhci: Guard all calls to xhci_wait_for_event

xhci_wait_for_event returns NULL on timeout, so the caller always has to
check for that. This addresses immediate explosions in this part
of the code when timeouts happen, but not the root cause for the
timeout.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Marek Vasut <marex@denx.de>

MAINTAINERS: Step up as co-maintainer of Tegra SOC platform

Update maintainers for Tegra SoC platform. Include device trees
and drivers which contain tegra in the name.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-samsung

i2c: Bugfix in i2c_get_chip_by_phandle()

The "i2cbcdev" sneaked in when implementing this function for the
bootcounter use case. Obviously the intention was to use prop_name
instead.

Fixes: b483552773 (i2c: Implement i2c_get_chip_by_phandle())
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>

configs: Remove unneeded SYS_CONFIG_NAME from a*y17lte defconfigs

As correct default SYS_CONFIG_NAME value is now set in
board/samsung/axy17lte/Kconfig (in commit "board: samsung: Fix
SYS_CONFIG_NAME configs in axy17lte Kconfig"), the SYS_CONFIG_NAME
option can be safely removed from all a*y17lte defconfigs. That removal
doesn't change resulting .config files.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

board: samsung: Fix SYS_CONFIG_NAME configs in axy17lte Kconfig

There is a couple of issues related to SYS_CONFIG_NAME config in
axy17lte Kconfig.

1. The global SYS_CONFIG_NAME in axy17lte Kconfig overrides
   SYS_CONFIG_NAME for all boards specified after this line in
   arch/arm/mach-exynos/Kconfig:

       source "board/samsung/axy17lte/Kconfig"

   Right now it's the last 'source' line there, so the issue is not
   reproducible. But once some board is moved or added after this line
   the next build error will happen:

       GEN     include/autoconf.mk.dep
     In file included from ./include/common.h:16:
     include/config.h:3:10: fatal error: configs/exynos78x0-common.h.h:
                            No such file or directory
         3 | #include <configs/exynos78x0-common.h.h>
           |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     compilation terminated.

   That's happening because axy17lte Kconfig defines SYS_CONFIG_NAME
   option in global namespace (not guarded with any "if TARGET_..."), so
   it basically rewrites the correct SYS_CONFIG_NAME defined in the
   hypothetical boards which might appear after axy17lte in mach-exynos
   Kconfig.

2. Another side of the issue is that SYS_CONFIG_NAME is defined
   incorrectly in axy17lte Kconfig:

       config SYS_CONFIG_NAME
           default "exynos78x0-common.h"

   The .h extension should not have been specified there. It's leading
   to a build error, as the generated include file has a double '.h'
   extension.

3. Each target in axy17lte/Kconfig defines its own SYS_CONFIG_NAME. But
   all of those in fact incorrect, as corresponding
   include/configs/<CONFIG_SYS_CONFIG_NAME>.h header files don't exist.

4. The global SYS_CONFIG_NAME pretty much repeats the help description
   from arch/Kconfig and doc/README.kconfig.

Corresponding defconfig files (a*y17lte_defconfig) fix above issues by
overriding SYS_CONFIG_NAME and correctly setting it to
"exynos78x0-common".

Fix all mentioned issues by removing the incorrect global
SYS_CONFIG_NAME and instead specifying it (correctly) in SYS_CONFIG_NAME
options for each target instead.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Fixes: 3e2095e960b4 ("board: samsung: add support for Galaxy A series of 2017 (a5y17lte)")
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

serial: s5p: Use dev_read_addr_ptr() to get base address

As the address read from device tree is being cast to a pointer, it's
better to use dev_read_addr_ptr() API for getting that address. The more
detailed explanation can be found in commit a12a73b66476 ("drivers: use
dev_read_addr_ptr when cast to pointer").

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

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

u-boot-dfu-20231124

- Fix reinit for ChipIdea controller
- Add missing newline in fastboot error handling

serial: s5p: Improve coding style

Just some minor style fixes. No functional change.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

serial: s5p: Use named constants for register values

Get rid of magic numbers in s5p_serial_init() when writing to UART
registers. While at it, use BIT() macro for existing constants when
appropriate.

No functional change.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

serial: s5p: Use livetree API to get "id" property

Use dev_read_u8_default() instead of fdtdec_get_int() to read the "id"
property from device tree, as suggested in [1]. dev_* API is already
used in this driver, so there is no reason to stick to fdtdec_* API.
This also fixes checkpatch warning:

    WARNING: Use the livetree API (dev_read_...)

[1] doc/develop/driver-model/livetree.rst

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

serial: s5p: Remove common.h inclusion

It's not really needed here anymore. Remove it, as common.h is going
away at some point.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

Merge tag 'efi-2024-01-rc4' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2024-01-rc4

Documentation

* Add HiSilicon board documentation to HTML docs
* Fix building with Sphinx 6.0

UEFI

* Increase default variable store size to 128K
* Check return value of efi_append_scrtm version
* Create shortened boot options in eficonfig command

Other

* Avoid incorrect error message in mkimage

usb: fastboot: Add missing newline in pr_err

Add missing newline in pr_err.

Signed-off-by: Simon Holesch <simon@holesch.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20231120002024.32865-2-simon@holesch.de
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

usb: ci: Fix gadget reinit

The ChipIdea device controller wasn't properly cleaned up when disabled.
So enabling it again left it in a broken state. The problem occurred for
example when the host unbinds the driver and binds it again.

During the first setup, when the out request is queued, the endpoint is
primed (`epprime`). If the endpoint is then disabled, it stayed primed
with the initial buffer. So after the endpoint is re-enabled, the device
controller and device driver were out of sync: the new out request was
in the driver queue head, yet not submitted, but the "complete" function
was still called, since the endpoint was primed with the old buffer.

With the fastboot function this error led to the (rather confusing)
error message "buffer overflow".

Fixed by clearing the primed buffers with the `epflush` (`ENDPTFLUSH`)
register.

Signed-off-by: Simon Holesch <simon@holesch.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20231120002024.32865-1-simon@holesch.de
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

cmd: eficonfig: create shortened boot options

The boot options created by eficonfig should use shortened device-paths to
avoid problems if drives are enumerated in a different sequence.

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

efi_loader: improve efi_var_from_file() description

It is unclear to developers why efi_var_from_file() returns EFI_SUCCESS if
file ubootefi.var is missing or corrupted. Improve the description.

Reported-by: Weizhao Ouyang <o451686892@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Weizhao Ouyang <o451686892@gmail.com>

efi_loader: Correctly account the SCRTM event creation

The result of efi_append_scrtm_version() is overwritten before anyone
checks its result. Check it and exit the function on failures

Addresses-Coverity-ID: 467399 Code maintainability issues (UNUSED_VALUE)
Fixes: commit 97707f12fdab ("tpm: Support boot measurements")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: Increase default variable store size to 128K

In commit 9fd3f881c6ed ("efi_loader: Increase default variable store size to 64KiB")
Alper has a detailed explanation of why the size needs to be bumped to at
least 64K.  However enabling Secure boot, writing db, KEK, PK etc keys
will further increase the size so bump it to 128K.

It's worth noting that when U-Boot stores the EFI variables in an RPMB the
available storage is defined statically in StandAloneMM at build time.
The U-Boot code is detecting the available true size on the fly during
writes. When StandAloneMM is present this size defines the reserved
memory U-Boot can use to copy any runtime variables, before booting an
OS.

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

doc: typo fdtaddr_addr_r

%s/fdtaddr_addr_r/fdt_addr_r/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

docs: Fix the docs build with Sphinx 6.0

Sphinx 6.0 removed the execfile_() function, which we use as part of the
configuration process.  They *did* warn us...  Just open-code the
functionality as is done in Sphinx itself.

Tested (using SPHINX_CONF, since this code is only executed with an
alternative config file) on various Sphinx versions from 2.5 through 6.0.

Reported-by: Martin Liška <mliska@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Rebased for U-Boot
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: add HiSilicon board documentation to HTML docs

Add the README files for the HiSilicon boards to the HTML documentation.
This required a bit of reformatting.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

mkimage: do not write incorrect error message

When running 'mkimage -l' is called for a valid StarFive file an error
message "Error: invalid marker bytes" is written by the Renesas SPKG
driver.

mkimage -l may be invoked without specifying an image type. In this case
mkimage iterates over all image type drivers to find the one that matches.
None of the non-matching drivers should write an error message.

Fix the Renesas SPKG driver.

Fixes: afdfcb11f97c ("tools: spkgimage: add Renesas SPKG format")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Prepare v2024.01-rc3

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

configs: Resync with savedefconfig

Rsync all defconfig files using moveconfig.py

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

scsi: set dma direction to NONE for TEST UNIT READY

SCSI device scan code was executing TEST UNIT READY command without
explicitly setting dma direction in struct scsi_cmd to NONE, so command
was passed to driver with dma direction set to DMA_FROM_DEVICE,
inherited from older usage.

With WDC SDINDDH6-64G ufs device, that caused TEST UNIT READY to
return error.

Fix that, by explicitly setting dma direction to NONE for
TEST UNIT READY, and restoring it back DMA_FROM_DEVICE for the
following READ CAPACITY.

Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Reviewed-by: Marek Vasut <marex@denx.de>

Merge branch 'master-mmc-clock' of https://source.denx.de/u-boot/custodians/u-boot-sh

Merge branch '2023-11-17-assorted-important-fixes'

- Revert HAFDBS changes, correct spl_imx_romapi for eMMC, fix the virtio
  rng in one case, fix bootstd in one case, and correct a Kconfig
  description.

bootstd: Avoid freeing a non-allocated buffer

EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.

A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.

Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.

Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.

Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>

Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available"

This reverts commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.

Signed-off-by: Chris Packham <judge.packham@gmail.com>

Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present"

This reverts commit 836b8d4b205d2175b57cb9ef271e638b0c116e89. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.

Signed-off-by: Chris Packham <judge.packham@gmail.com>

Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present"

This reverts commit c1da6fdb5c239b432440721772d993e63cfdeb20. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.

Signed-off-by: Chris Packham <judge.packham@gmail.com>

imx: spl_imx_romapi: fix emmc fast boot mode case

This fixes a regression in the eMMC fast boot mode case where the buffer
was missing 464 bytes.

The code figures out how many bytes must at least be fetched to honor
the current read, rounds that up to the ss->pagesize [which is a no-op
in the USB download case because that has ->pagesize==1], fetches that
many bytes, but then recorded the original upper bound as the new end of
the valid data. However, this did not take into account the rounding up
to the ss->pagesize. Fix this by recording the actual bytes downloaded.

Fixes: 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of spl_load_simple_fit() to get full FIT size")
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Fabio Estevam <festevam@gmail.com>

imx: spl_imx_romapi: fix comment about stream(usb) download failure

Fix comment about Stream(USB) download failure.

Fixes: 1cbebc786276 ("imx: add rom api support")
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>

spl: fix TPL_SYS_MALLOC_F description

This config option enables the malloc() pool in TPL not the SPL.  Fix
the description to accurately reflect this.

Fixes: fd8497dae54 (spl: Create proper symbols for enabling the malloc() pool)
Signed-off-by: John Keeping <jkeeping@inmusicbrands.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

virtio: rng: gracefully handle 0 byte returns

According to the virtio v1.x "entropy device" specification, a virtio-rng
device is supposed to always return at least one byte of entropy.
However the virtio v0.9 spec does not mention such a requirement.

The Arm Fixed Virtual Platform (FVP) implementation of virtio-rng always
returns 8 bytes less of entropy than requested. If 8 bytes or less are
requested, it will return 0 bytes.
This behaviour makes U-Boot's virtio_rng_read() implementation go into an
endless loop, hanging the system.

Work around this problem by always requesting 8 bytes more than needed,
but only if a previous call to virtqueue_get_buf() returned 0 bytes.

This should never trigger on a v1.x spec compliant implementation, but
fixes the hang on the Arm FVP.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Peter Hoyes <peter.hoyes@arm.com>

Merge tag 'dm-pull-15nov23' of https://source.denx.de/u-boot/custodians/u-boot-dm

patman correct import of u_boot_pylib
correct long-standing EFI framebuffer bug
minor test refactor

bootstage: Correct exhasuted typo

Correct this typo in the warning message shown when no more bootstage
records can be added.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

sandbox: Close file after mmaping it

After opening pathname, we must close ifd once we are done with it.

Fixes: b9274095c2c ("sandbox: Add a way to map a file into memory")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dm: Do not enable debug messages by default

CONFIG_DM_WARN has a text indicating that these messages should only
provided when debugging. This implies that the setting must be default no.

We should still create debug messages.

Reported-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

patman: Correct Python 3.6 behaviour

The importlib_resources import is not actually used. Fix this so that
patman can run on Python 3.6 to some extent, once
'pip3 install importlib-resources' has been run.

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

patman: Avoid using func_test at top level

Import this only when it is needed, since it is not present when
installed via 'pip install'.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: https://source.denx.de/u-boot/u-boot/-/issues/26

patman: Correct easy pylint warnings in __main__

Tidy up the code a little to reduce the number of pylint warnings.

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

patman: Move the main program into a function

Add a new run_patman() function to hold the main logic.

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

patman: Split out arg parsing into its own file

Move this code into a separate cmdline module, as is done with the
other tools.

Use the same HAS_TESTS check as buildman

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

expo: Correct background colour

Use the correct background colour when using white-on-black.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

bootstd: Add a return code to bootflow menu

Return an error when the user does not select an OS, so we know whether
to boot or not.

Move calling of bootflow_menu_run() into a separate function so we can
call it from other places.

Expand the test to cover these cases.

Add some documentation also, while we are here.

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

bootstd: Refactor mmc prep to allow a different scan

Adjust scan_mmc4_bootdev() and related function so that the caller can
do its own 'bootflow scan' command. This allows it to change the flags
if needed.

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