dm: Add dm_remove_devices_active() for ordered device removal

This replaces dm_remove_devices_flags() calls in all boot
implementations to ensure non vital devices are consistently removed
first. All boot implementation except arch/arm/lib/bootm.c currently
just call dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL). This can result
in crashes when dependencies between devices exists. The driver model's
design document describes DM_FLAG_VITAL as "indicates that the device is
'vital' to the operation of other devices". Device removal at boot
should follow this.

Instead of adding dm_remove_devices_flags() with (DM_REMOVE_ACTIVE_ALL |
DM_REMOVE_NON_VITAL) everywhere add dm_remove_devices_active() which
does this.

Fixes a NULL pointer deref in the apple dart IOMMU driver during EFI
boot. The xhci-pci (driver which depends on the IOMMU to work) removes
its mapping on removal. This explodes when the IOMMU device was removed
first.

dm_remove_devices_flags() is kept since it is used for testing of
device_remove() calls in dm.

Signed-off-by: Janne Grunau <j@jannau.net>

iommu: apple: Mark device with DM_FLAG_VITAL

Avoids NULL pointer dereferences in apple_dart_unmap when the iommu
device is removed before its user. U-boot's device model does not track
dependencies between devices.
Observed on a M1 Ultra Mac Studio with v2024.10.

Acked-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Janne Grunau <j@jannau.net>

Prepare v2025.01-rc2

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

Merge patch series "Fix IOVA allocation in Apple dart iommu after global LMB mem map changes"

Janne Grunau <j@jannau.net> says:

The changes in "Make LMB memory map global and persistent" [1] break
mapping DMA memory in the USB xHCI driver when using the apple_dart
iommu present on Apple silicon systems.

The IOVA space used by the u-boot driver (low 4GB) and physical memory
do not overlap. The physical memory on this systems starts depending on
the SoC either at 0x10_0000_0000 or 0x100_0000_0000. It make no sense to
manage these distinct regions in a single LMB map. In addition every
device has its own iommu and IO address space so sharing a single memory
map between all iommu instances is not necessary.

To fix this issue restore the used subset (add, alloc and free) of the
previous pointer based LMB interface with "io_" as prefix.

To ensure that low level lmb functions do not use the global LMB
variable reorder lib/lmb.c so that the variable is not visible.

Tested with patches from my "Fix device removal order for Apple dart
iommu" series [2] to fix a separate issue.

The cosmetic commit has two checkpatch warnings in existing code which I
ignored.

[1] https://lore.kernel.org/u-boot/20240826115940.3233167-1-sughosh.ganu@linaro.org/
[2] https://lore.kernel.org/u-boot/20241031-iommu_apple_dart_ordering-v1-0-8a6877946d6b@jannau.net/

Link: https://lore.kernel.org/r/20241111-io_lmb_apple_dart_iommu-v3-0-32c05da51d72@jannau.net
Signed-off-by: Tom Rini <trini@konsulko.com>

iommu: apple: Manage IOVA separately from global LMB mem map

There is no overlap between the IOVA space managed by the iommu (here
the 32-bit address space) and physical RAM on Apple silicon systems. The
RAM starts at 0x10_0000_0000 or 0x100_0000_0000 so it's not possible to
manage the IOVA with the global memory LMB and use 1:1 translation.
In addition each device has its own iommu and does not need to share the
address space with all other devices. This should not be problem for
u-boot's limited use and hardware support.
Restore the private per instance LMB IOVA map.

Fixes: ed17a33fed2 ("lmb: make LMB memory map persistent and global")
Signed-off-by: Janne Grunau <j@jannau.net>

lmb: Add basic io_lmb functionality

These functions can be used with struct lmb pointers and will be used to
manage IOVA space in the apple_dart iommu driver. This restores part of
the pointer base struct lmb API from before commit ed17a33fed29 ("lmb:
make LMB memory map persistent and global").
io_lmb_add() and io_lmb_free() can trivially reuse exisiting lmb
functions. io_lmb_setup() is separate for unique error log messages.
io_lmb_alloc() is a simplified copy of _lmb_alloc_base() since the
later has unused features and internal use of the global LMB memory map.

Signed-off-by: Janne Grunau <j@jannau.net>

lmb: cosmetic: reorder functions and global LMB variable

Low lovel LMB functionality will be used to manage IOVA space in the
Apple dart iommu driver. This reordering ensures that those function
can not access the global LMB memory map variable.

Signed-off-by: Janne Grunau <j@jannau.net>

lmb: Do not use global LMB variable in _lmb_free()

It will be re-used with a lmb list pointer as argument for IOVA
allocations in the apple_dart iommu driver.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Janne Grunau <j@jannau.net>

Merge tag 'u-boot-rockchip-20241111' of https://source.denx.de/u-boot/custodians/u-boot-rockchip

CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/23280

- Add board:
        rk3328: FriendlyElec NanoPi R2S Plus
        rk3568: Qnap TS433
        rk3588: Cool Pi CM5 GenBook
- Move rk3399_force_power_on_reset to TPL for puma board;

rockchip: rk3399: move sysreset-gpio logic to TPL

If TPL_GPIO and TPL_PINCTRL_ROCKCHIP are enabled and a sysreset-gpio is
provided in the TPL Device Tree, this will trigger a system reset
similar to what's currently been done in SPL whenever the RK3399 "warm"
boots. Because there's currently only one user of sysreset-gpio logic,
and TPL is enabled on that board, so let's migrate the logic and that
board to do it in TPL.

There are three reasons for moving this earlier:
- faster boot time as we don't need to reach SPL to be able to reset the
  system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset works
  around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done from
  SPL, the following log can be observed:

"""
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45)
Channel 0: DDR3, 666MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
Channel 1: DDR3, 666MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
256B stride
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100)
Trying to boot from MMC2

U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45)
"""

possibly hinting at an issue within the SPL when loading the fitImage
from MMC2 instead of the normal course of events (a system reset).

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: tpl: allow to call board/SoC-specific code before DRAM init

This defines a weak tpl_board_init function that can be used for running
board/SoC-specific code before the DRAM init happens, similarly to
spl_board_init() for SPL.

Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3399: merge CRU check within rk3399_force_power_on_reset

To prepare to support forcing power on reset from TPL which would have
the exact same logic, just in an earlier stage, let's merge the CRU
check that triggers the power on reset with the rest of the logic.

Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

pinctrl: rockchip: allow to build for TPL

A later commit will make use of the pinctrl driver in TPL so let's add
the ability to build the Rockchip pinctrl driver in TPL.

Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk35xx-generic: Disable late boardinfo

Disable DISPLAY_BOARDINFO_LATE as the early boardinfo print of Model
should be enough.

  U-Boot 2025.01-rc1 (Nov 02 2024 - 16:04:16 +0000)

  Model: Generic RK3566/RK3568
  DRAM:  8 GiB (effective 7.7 GiB)
  Core:  250 devices, 24 uclasses, devicetree: separate
  MMC:   mmc@fe2b0000: 1, mmc@fe310000: 0
  Loading Environment from nowhere... OK
  In:    serial@fe660000
  Out:   serial@fe660000
  Err:   serial@fe660000
  Model: Generic RK3566/RK3568
  Hit any key to stop autoboot:  0
  =>

Enable CMD_MISC to make it easier to inspect data in OTP.

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

board: rockchip: Add FriendlyElec NanoPi R2S Plus

The FriendlyElec NanoPi R2S Plus is a single-board computer based on
Rockchip RK3328 SoC. It features e.g. 1 GB DDR4 RAM, 32 GB eMMC,
SD-card, 2x GbE LAN, optional M.2 SDIO Wi-Fi and 2x USB 2.0 host.

Features tested on a NanoPi R2S Plus 2309:
- SD-card boot
- eMMC boot
- Ethernet
- USB gadget
- USB host

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

arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus

The R2S Plus is basically an R2S with additional eMMC.

The eMMC configuration for the DTS has been extracted and copied from
rk3328-nanopi-r2.dts, v2017.09 branch from the friendlyarm/uboot-rockchip
repository.

Signed-off-by: Sergey Bostandzhyan <jin@mediatomb.cc>
Link: https://lore.kernel.org/r/20240814170048.23816-2-jin@mediatomb.cc
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: b8c02878292200ebb5b4a8cfc9dbf227327908bd ]

(cherry picked from commit c9bf98827964441f4dd16faa45bd4046f472e693)
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: Add support for rk3588 GenBook

Add support for Cool Pi GenBook, it works as a carrier board
connect with CM5 SOM.

Specification:
- Rockchip RK3588
- LPDDR5X 8/32 GB
- eMMC 64 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for RTL8852BE Wireless connection
- PCIE M.2 M Key for NVME connection
- eDP panel with 1920x1080

Tested by Armbian boot on USB disk.

Change-Id: I4d9b8572dc7c400077dde666633f3fea1b47dd03
Signed-off-by: Andy Yan <andyshrk@163.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: Make it possible to define per board boot_targets

Some board may want to have a different boot priority(a laptop
may want to usb has the highest boot priority for third-part
os installation). So let the board can define it's own
boot_targets.

Signed-off-by: Andy Yan <andyshrk@163.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Add support for rk3588 based Cool Pi CM5 GenBook

Cool Pi CM5 GenBook works as a carrier board connect with CM5 [0].

Specification:
- Rockchip RK3588
- LPDDR5X 8/32 GB
- eMMC 64 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for RTL8852BE Wireless connection
- PCIE M.2 M Key for NVME connection
- eDP panel with 1920x1080

This patch add basic support to bringup eMMC/USB HOST/WiFi/TouchPad/
Battery/PCIE NVME, and can also drive a HDMI output with out of tree
hdmi patches.

[0] https://www.crowdsupply.com/shenzhen-tianmao-technology-co-ltd/genbook-rk3588

Signed-off-by: Andy Yan <andyshrk@163.com>
Link: https://lore.kernel.org/r/20240730102433.540260-3-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 4a8c1161b843c366776fc872a6fe45b743b2983e ]

(cherry picked from commit dc6316da23734d9321e09f8c8a7669f4b4cb9f75)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

board: rockchip: add support for Qnap TS433 devices

The Qnap TS433 is a 4-bay NAS based around the RK3568.

Two SATA bays are connected to the RK3568's own SATA controllers while
the other two are connected to a JMicron SATA controller living on the
PCIe bus.

It provides one 2.5Gb and one 1Gb ethernet port as well as 3 usb ports.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

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

mtd: spi-nor: Fix integer overflow in stacked memories support

The 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
adds new SPI bus flags, but also introduces a completely new set of
SPI bus flags in another location. The existing flags field is type
u8, while the new separate flags are BIT(8) and higher. Use of those
new flags triggers integer overflow.

Drop the newly introduced flags which were never used anywhere in the
code. Move the one remaining flag which was used in the correct place
and change it from BIT(8) to BIT(6) so it fits the u8 flags.

Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Addresses-Coverity-ID: 510804 Extra high-order bits
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>

board: hoperun: Switch to use complete DTS files from upstream DTS

For upstream Linux kernel we use below DTBs for HiHope boards:
- r8a774a1-hihope-rzg2m-ex.dtb
- r8a774e1-hihope-rzg2h-ex.dtb
- r8a774b1-hihope-rzg2n-ex.dtb

Update the CONFIG_OF_LIST to match the above. Now that we have switched
upstream DTS, drop deleting the nodes and also rename the
r8a774*-u-boot.dtsi files to r8a774*-ex-u-boot.dtsi to match the OF_LIST
files so that the `bootph-all` property gets applied to required nodes
in upstream DTS.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>

configs: hihope_rzg2: Set correct MMC device for U-Boot env

Currently we set CONFIG_SYS_MMC_ENV_DEV=1 which is wrong:
  Loading Environment from MMC... MMC: no card present
  *** Warning - No block device, using default environment

This issue was introduced when we switched to using upstream Linux device
trees for the hihope boards which named the MMC devices differently.

Correct to dev 0 so that the U-Boot environment can be loaded from the
correct storage device.

Fixes: 18fb23b13158 ("ARM: dts: renesas: Switch to using upstream DT on 64bit Renesas SoCs")
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

arm: renesas: Fix RZ/G2L GICR base address

When support for the Renesas RZ/G2L SoC was added, the GICR base address
for CPU1 was accidentally used. We should instead supply the GICR base
address for CPU0 so that interrupts are correctly configured for the
CPU core that U-Boot is actually using.

Fixes: 387d4275ab0e ("arm: rmobile: Add basic RZ/G2L family support")
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>

dt-bindings: Drop unused RZ/G2L devicetree bindings

We are now using the dts/upstream subtree for the RZ/G2L SoC family so
we can drop unused dt-bindings headers.

Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

ARM: dts: Drop unused RZ/G2L devicetrees

We are now using the dts/upstream subtree for the RZ/G2L SoC family so
we can drop unused devicetree files from arch/arm/dts.

Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

board: rzg2l: Update MAINTAINERS file to match dts/upstream paths

We are now using the dts/upstream subtree for the RZ/G2L SoC family, so
update the board MAINTAINERS file to match rz-smarc dtsi files in this
subtree.

Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Merge tag 'u-boot-imx-master-20241105' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/23262

- Improve imx9 boot medium autodection.
- Add possibility to skip DCD on i.MX8.
- Switch to using upstream DT on DH i.MX6 DHCOM.
- Add support for i.MX6DL DHCOM SoM on PDK2 carrier board.
- Handle FIELD_RETURN on i.MX HAB.

Merge tag 'efi-2025-01-rc2-2' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2025-01-rc2-2

Documentation:

* correct title and author of rst2pdf generated pdf
* describe CONFIG_DEBUG_SBI_CONSOLE
* remove vile language

UEFI

* correct printf codes in mkeficapsule
* add an EFI test app
* move default filename to a function
* move get_efi_pxe_arch() to efi_helper
* allow reporting the host defaults in efidebug
* drop sandbox PXE architecture

Other:

* do not reserve extra 16 KiB of stack in lmb
* disable the sandbox virtio blk device
* provide -N command line flag to control EFI default boot file name
  on the sandbox
* provide a unit test for the efi bootmeth

arm: mach-imx: imx8m: re-use SNVS init routine

Working with HAB on the i.MX8MP we've encountered a case where a board
that successfully authenticates u-boot when booting Linux subsequently
fails to properly bring up the RTC.

The RTC registers live in the low-power block of the Secure Non-Volatile
Storage (SNVS) block.

The root cause of the error has been traced to the HAB handing off the
SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the
Non-Privileged Software Access Enable bit is zero.

Configure SNVS to allow unpriv access to SNVS LP for imx8m and imx8mp.

This commit generalizes 723f8359c1 ("imx: mx7: snvs: Add an SNVS init
routine") to also be used on i.MX8M SoCs, and was testeed on i.MX8MP.

Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>

arm: mach-imx: move snvs module

Commit 723f8359c1 ("imx: mx7: snvs: Add an SNVS init routine") noted
that the init_snvs() call likely applies to other i.MX processors, and
this has been found to be true for i.MX8MP.

Move snvs module for future re-use.

Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>

ARM: dts: imx: Switch to using upstream DT on DH i.MX6 DHCOM

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

Signed-off-by: Marek Vasut <marex@denx.de>

ARM: dts: imx6dl: Add support for i.MX6DL DHCOM SoM on PDK2 carrier board

Add support for the DH electronics i.MX6DL DHCOM SoM and a PDK2 evaluation
board. The evaluation board features three serial ports, USB OTG, USB host
with an USB hub, Fast or Gigabit ethernet, eMMC, uSD, SD, analog audio,
PCIe and HDMI video output.

All of the aforementioned features except for mSATA are supported, mSATA
is not available on i.MX6DL and is only available on DHCOM populated with
i.MX6Q SoC which is already supported upstream.

Backport from linux-next commit
c3f5d76a6e03 ("ARM: dts: imx6dl: Add support for i.MX6DL DHCOM SoM on PDK2 carrier board")

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>

tools: imx8image: add possibility to skip dcd

Currently U-Boot always adds DCD Image to boot container.
On imx8qxp SoC it is possible to init RAM from within SCFW,
and adding a DCD image type to the boot container in this case
breaks booting (No debug output anymore from SCFW! Nor any
output from SPL), so we need to configure a dcd skip somehow.

This patch adds a new imx8image_cmd entry CMD_DCD_SKIP and a
new entry in imximage.cfg "DCD_SKIP". If set to "true"
no DCD image type will be added to the container.

Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

imx9: Improve boot mode autodetection

Improve "mmcautodetect=yes" boot mode autodetection to able to use it
if CONFIG_ENV_IS_NOWHERE=y is used for i.MX9 SoCs and i.MX93 EVK board.

If both CONFIG_ENV_IS_IN_MMC=y and CONFIG_ENV_IS_NOWHERE=y are in the
defconfig, CONFIG_ENV_IS_IN_MMC=y will be overiden default
CONFIG_ENV_IS_NOWHERE settings.

Goal is in this patch to able to use the boot mode autodetection
if defconfig use only CONFIG_ENV_IS_NOWHERE=y option
(without CONFIG_ENV_IS_IN_MMC) for any i.MX9 SoC.

Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>

imx: hab: Make imx_hab_is_enabled dependent on FIELD_RETURN

The decision on whether HAB is enabled is solely based on the SEC_CONFIG
fuse. The HAB FIELD_RETURN feature is able to permanently disable HAB on
a CPU, after which it is able to boot unsigned firmware. U-Boot however
does not take into account the FIELD_RETURN mode, and refuses to boot
unsigned software when the feature is enabled.

Also take the FIELD_RETURN fuse into account when deciding whether HAB
is enabled. When The FIELD_RETURN fuse is blown, HAB is not enabled.

Tested on i.MX8M Mini, i.MX8M Plus, i.MX8M Nano and i.MX6ULL

Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>

imx: hab: rename imx_sec_config_fuse_t to imx_fuse

The imx_sec_config_fuse_t structure is not specific to the sec_config
fuse, but can be used for all fuse words.

Rename the structure to a more generic name to be reused for other
fuses.

Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>

test: efi: boot: Add a test for the efi bootmeth

Add a simple test of booting with the EFI bootmeth, which runs the app
and checks that it can call 'exit boot-services' (to check that all the
device-removal code doesn't break anything) and then exit back to
U-Boot.

This uses a disk image containing the testapp, ready for execution by
sandbox when needed.

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

test: efi: boot: Set up an image suitable for EFI testing

Create a new disk for use with tests, which contains the new 'testapp'
EFI app specifically intended for testing the EFI loader.

Attach it to the USB device, since most testing is currently done with
mmc.

Initially this image will be used to test the EFI bootmeth.

Fix a stale comment in prep_mmc_bootdev() while we are here.

For now this uses sudo and a compressed fallback file, like all the
other bootstd tests. Once this series is in, the patch which moves
this to use user-space tools will be cleaned up and re-submitted.

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

sandbox: virtio: Disable the sandbox virtio blk device

This is not implemented so cannot actually be used to read blocks.
Disable it until it is implemented, to avoid causing a hang with EFI,
which probes every available BLK device.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Issue: https://source.denx.de/u-boot/u-boot/-/issues/37

efi_loader: Drop sandbox PXE architecture

Rather than returning 0, just return an error, since sandbox is not used
with PXE at present.

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

sandbox: Report host default-filename in native mode

When the --native flag is given, pretend to be running the host
architecture rather than sandbox.

Allow the same control for PXE too.

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

efi_loader: Allow reporting the host defaults

Add an 'efidebug filename' command to report the default filename and
PXE architecture.

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

efi_loader: Move get_efi_pxe_arch() to efi_helper

Move this function from the EFI bootmeth to the common efi_helper file.
No functional change is intended.

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

efi: Move default filename to a function

Use a function to obtain the device EFI filename, so that we can control
how sandbox behaves.

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

sandbox: Add a -N flag to control on-host behaviour

Sandbox is its own architecture, but sometimes we want to mimic the host
architecture, e.g. when running an EFI app not built by U-Boot.

Add a -N/--native flag which tells sandbox to reflect the architecture
of the host.

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

efi_loader: Add a test app

Add a simple app to use for testing. This is intended to do whatever it
needs to for testing purposes. For now it just prints a message and
exits boot services.

There was a considerable amount of discussion about whether it is OK to
call exit-boot-services and then return to U-Boot. This is not normally
done in a real application, since exit-boot-services is used to
completely disconnect from U-Boot. For now, this part is skipped.

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

doc: qemu-riscv: describe CONFIG_DEBUG_SBI_CONSOLE

In main U-Boot the SBI DBCN extension can be used to supply a debug
console.

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

doc: conf.py: correct title and author of generated pdf

Adjust the PDF output options for rst2pdf:

* Set start document to 'index'.
* Set title to 'Das U-Boot'.
* Set author to 'The U-Boot development community'.

Correct documentation link.

Remove obsolete FIXME.

Link: https://rst2pdf.org/static/manual.html
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: Change efi_dp_from_mem() to use size

All call sites are using size rather than end addresses,
so instead - as previously done - calculating an end address
everywhere, just modify the function to use size and internally
calculate the end address

Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Patrick Wildt <pwildt@google.com>
Signed-off-by: Moritz Fischer <moritzf@google.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

tools: mkeficapsule: use %zd to print ssize_t.

For printing a ssize_t variable we must use %zd and not %ld to avoid
a -Wformat error on 32-bit systems.

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

doc: remove vile language

lmb: Drop extra 16KB of stack space

There is already a defined stack-size which is used to reserve space for
the stack. It is confusing to add more in the lmb module, since then the
memory map (with meminfo command) seems to have a hole in it.

Drop this unnecessary feature.

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

arm64: dts: rockchip: add product-data eeproms to QNAP TS433

The device contains two i2c-connected eeproms holding some product-
specific values. One sitting on the mainboard and one on the statically
connected backplane.

While the eeprom chips themself have a size of 512 byte, the eeprom data
only uses 256 byte each, probably to stay compatible with other models.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240810211438.286441-3-heiko@sntech.de
[ upstream commit: da6f4130234448122fe3e66c8116f7d9eea8a5c7 ]

(cherry picked from commit 0b3109708caf5002ba188ae28eae9ce46b2c39b4)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: actually enable pmu-io-domains on qnap-ts433

Contrary to the vendor-kernel the pmu-io-domains are not enabled by
default. This resulted in the value not being set according to the
regulator, which in turn made the gmac0 interface that is connected
to the vccio4 supply inoperable.

Fixes: 64b7f16fb394 ("arm64: dts: rockchip: add 2 pmu_io_domain supplies for Qnap-TS433")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240805162052.3345768-1-heiko@sntech.de
[ upstream commit: 40cc4257169712f0ae3835820a4c5afbdd1a16ff ]

(cherry picked from commit f509fcb1fb82117e551b489592ac5714a6c5cd8d)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: Simplify network PHY connection on qnap-ts433

While it requires to have the right phy driver loaded (i.e. motorcomm)
to make the phy asserting the right delays, this is generally the
preferred way to define the MAC <-> PHY connection.

Signed-off-by: Uwe Kleine-König <ukleinek@debian.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240304084612.711678-2-ukleinek@debian.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: e8d45544f806f3b55c30345de84262cbb9504902 ]

(cherry picked from commit e0bbe061fd537bd7b113c53eb046bbcbf0e6597d)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: add 2 pmu_io_domain supplies for Qnap-TS433

Add the two supplies for the pmu-io-domains that are defined in the
vendor devicetree for the TS433.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-15-heiko@sntech.de
[ upstream commit: 64b7f16fb3947e5d08d9e9b860ce966250e45d52 ]

(cherry picked from commit 9b4d4c02b5762196063ab03c5439f96cbbaf2485)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: enable gpu on Qnap-TS433

The TS433 doesn't provide display output, but the gpu nevertheless can be
used for compute tasks for example.

So there is no reason not to enable it.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-14-heiko@sntech.de
[ upstream commit: 9130eb62586f4cef0557d0378fb7e78d7397ab2d ]

(cherry picked from commit e324a9e8ea083ebdca207b5ca2ed86d2b5f862a0)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: add missing pmic information on Qnap-TS433

Fill in the missing pieces for RK809 pmic used on the TS433.

The regulator setup comes from the vendor-devicetree, so without proper
schematics its accuracy is somewhat unclear, but it looks really similar
to all the other rk3568 boards, so follows the reference design it seems.

The one caveat is related to vcc3v3_sd. This regulator needs to stay on.
When turned off because of no users, access to both PCIe controllers
will stall. Maybe this rail does supply the 100MHz refclk generation
or so.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-13-heiko@sntech.de
[ upstream commit: ee078c7daa98353496410b715a5acbb41d7d3a90 ]

(cherry picked from commit 48951cb085998a5c8e3650351a794b136dac648f)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: define cpu-supply on the Qnap-TS433

The TS433 seems to use a silergy,syr827 regulator for the cpu supply.
At least that is the compatible used in the vendor devicetree, though
it could very well also be another fan53555 clone.

Define the needed regulator node and hook up the cpu-supply to the
cpu cores.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-12-heiko@sntech.de
[ upstream commit: 99b36ba910d896bddbb9a190ca686c6d9cd0325f ]

(cherry picked from commit 2f0afd1a3cbf6f3192dc7a5c496affab718671b3)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: add gpio-keys to Qnap-TS433

The TS433 has 3 buttons, power and copy in the front as well as a reset
pinhole button on the back. The power-button is connected to the embedded
controller while the other two buttons are just gpio connected.

Add the gpio-keys definition for the two buttons we can handle right now.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-11-heiko@sntech.de
[ upstream commit: 9b682d31b24f1f70b5b4d0618095d46e0722b9d8 ]

(cherry picked from commit f0b858c751382ee9faf18f9b19b0817c6b50ac1c)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: enable the tsadc on the Qnap-TS433

Enable the tsadc node to allow for temperature measurements of the soc.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-10-heiko@sntech.de
[ upstream commit: 2dfdddd9d20306fd0d04b88fcbbf36d76fb67f11 ]

(cherry picked from commit d33949501abd1145ea572b605844f0ef4247478d)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: add hdd leds to Qnap-TS433

Add the 4 gpio-controlled LEDs to the Qnap-TS433.

They are meant for individual disk activitivy, but I haven't found a
way for how to connect them to their individual sata slot yet.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-9-heiko@sntech.de
[ upstream commit: ea91aabf18bcad6f5eceae6848ea6570ea61f126 ]

(cherry picked from commit 5a11b1bb40ac7b39e04077c045c3e3409fa352e2)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: add board-aliases for Qnap-TS433

Add the aliases for the internal network interface as well as the emmc
on the board and make sure the dedicated RTC is always the first one.

The TS433 actually has two rtc devices. One coming from the rk809 pmic
without added functionality and also a dedicated RTC from Mycrocrystal
that is battery backed to keep the time.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-8-heiko@sntech.de
[ upstream commit: dadd4256e12360d3ff1f6481b2e4697f9d890caf ]

(cherry picked from commit cb53815764403f7f17967a32eec2aeb6625b396f)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: enable sata1+2 on Qnap-TS433

The TS433 has 4 bays. The last two are accessed via a pci-connected
sata controller, while the first two are accessed via the rk3568's
sata controllers. Enable these two now.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-7-heiko@sntech.de
[ upstream commit: 673c1353b3d476b9c5df6b84a777ed171e5594f5 ]

(cherry picked from commit dfa45bbda057851d0c2167b4c311c0301637cc19)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: add stdout path on Qnap-TS433

As most Rockchip boards do, the TS433 also uses uart2 for its serial
output. Set the correct chosen entry for it.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-6-heiko@sntech.de
[ upstream commit: e1cb5d8a92e41171bf4d5ddc459bd96372500901 ]

(cherry picked from commit 1e1af2af2192490a3d174624ac1bb976aa6afffa)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: enable usb ports on Qnap-TS433

Enable usb controllers and phys and add regulator infrastructure for the
usb ports on the TS433.

Of course there are no schematics available for the device, so the
regulator information comes from the vendor-devicetree with unknown
accuracy.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-5-heiko@sntech.de
[ upstream commit: d992203f57c5caad0dbd4a9c669d79b315873c81 ]

(cherry picked from commit bb745ef13efb9f6589f9eda8f66664bf263a13f3)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: enable uart0 on Qnap-TS433

Uart0 is connected to an MCU on the board that handles system control
like the fan-speed. So far no driver for it is available though.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-4-heiko@sntech.de
[ upstream commit: 07ef8be476bebd77cba3ca4804be03cc0dba414f ]

(cherry picked from commit aaa5b1c4bd8f0e4327078d513f0eef05cb829bcf)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm64: dts: rockchip: enable second PCIe controller on the Qnap-TS433

The TS433 uses both pcie controllers for sata and the 2nd network
interface. Set the needed data-lanes in the pcie3 phy and enable
the second pcie controller, as well as remove the bifurcation comment.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-3-heiko@sntech.de
[ upstream commit: 0f5f87a1d602a33028522784eb005647fa1b5c11 ]

(cherry picked from commit 7d8f260e65cc84076ec9456954de0f136948a2c8)

arm64: dts: rockchip: add PCIe supply regulator to Qnap-TS433

Add the vcc3v3-supply regulator and its link to the pcie controllers.

Tested-by: Uwe Kleine-König <ukleinek@debian.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240723195538.1133436-2-heiko@sntech.de
[ upstream commit: e0ec6d48226fb3d4df18895b56f0b7a94c0fe474 ]

(cherry picked from commit 59939b4343db08fa08098238160007e6ded72be9)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

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

CI: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/23239

- configs: visionfive2 defconfig: re-enable SPL_SYS_MMCSD_RAW_MODE
- driver: sifive ccache: enable TRUNKCLOCKGATE & REGIONCLOCKGATE
- board: support 64bit Microblaze V

riscv: Introduce configuration for 64bit version Microblaze V

The commit 7576ab2facae ("riscv: Add support for AMD/Xilinx MicroBlaze V")
added support for 32bit version. 64bit version is also available that's why
wire it up too.
DT is providing description for generic QEMU target.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

xilinx: mbv: Align smode_defconfig with upstream QEMU

Align smode defconfig with upstream QEMU. It could be the part of commit
9d688e6da5c9 ("riscv: mbv: Align DT with QEMU").

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

xilinx: mbv: Place DTB by default to DDR location

DTB should be also placed to DDR. It should be the part of commit
9d688e6da5c9 ("riscv: mbv: Align DT with QEMU").

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

configs: visionfive2: re-enable SPL_SYS_MMCSD_RAW_MODE

To restore MMC boot, enable SPL_SYS_MMCSD_RAW_MODE and recover
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION and
SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION.

Fixes: 2a00d73d081 ("spl: mmc: Try to clean up raw-mode options")
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

driver: sifive ccache: enable TRUNKCLOCKGATE and REGIONCLOCKGATE

Enable the clock gating bit of ccache when the platform has the ccache0.

Signed-off-by: Nick Hu <nick.hu@sifive.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

bios_emulator: fix first argument of pci_{read,write}_config_* function calls

When compiling for riscv64, a bunch of warning is produced for the file
drivers/bios_emulator/besys.c. This patch fixes a portion of those warnings,
caused by incorrect first argument to pci_{read,write}_config_* functions.

Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>

drivers/video/vesa: use MTRRs only on x86

MTRR functionality is available only on x86, so this driver cannot be compiled
on other architectures. Fix this with preprocessor directives.

Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>

bios_emulator: define the comment symbol for RISC-V assembler too

The bios_emulator driver cannot be compiled for RISC-V because the x86emu.h
header file doesn't define the comment symbol ("#") for the assembler.
With this patch, use the same symbol as for e.g. x86.

Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>

bootmenu: add reprint check

Record the last active menu item and check if it equals to the
current selected item before reprint.

Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Tested-by: Daniel Golle <daniel@makrotopia.org>

menu: add support to check if menu needs to be reprinted

This patch adds a new callback named need_reprint for menu.
The need_reprint will be called before printing the menu. If the
callback exists and returns FALSE, menu printing will be canceled.

This is very useful if the menu was not changed. It can save time
for serial-based menu to handle more input data.

Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Tested-by: Daniel Golle <daniel@makrotopia.org>

menu: fix the logic checking whether ESC key is pressed

It's observed that the bootmenu on a serial console sometimes
incorrectly quitted with superfluous characters filled to command
line input:

>  *** U-Boot Boot Menu ***
>
>      1. Startup system (Default)
>      2. Upgrade firmware
>      3. Upgrade ATF BL2
>      4. Upgrade ATF FIP
>      5. Load image
>      0. U-Boot console
>
>
>  Press UP/DOWN to move, ENTER to select, ESC to quit
>MT7988> [B

Analysis shows it was caused by the wrong logic of bootmenu_loop:

At first the bootmenu_loop received the first ESC char correctly.

However, during the second call to bootmenu_loop, there's no data
in the UART Rx FIFO. Due to the low baudrate, the second char of
the down array key sequence hasn't be fully received.

But bootmenu_loop just did a mdelay(10), and then treated it as a
single ESC key press event. It didn't even try tstc() again after
the 10ms timeout.

This patch fixes this issue by letting bootmenu_loop check tstc()
twice.

Tested-By: E Shattow <lucent@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge patch series "U-boot: arm: Refine the booting on Total Compute"

Leo Yan <leo.yan@arm.com> says:

This patch series is to refine the booting on Arm Total Compuate
platform.

It changes to use the info passed in DTB for initialization DRAM info,
and dynamically initializes the booting envoironment variables.

Another big change is to use an envoironment file for boot commands,
based on it, the series extends to support multiple block devices
(MMC and virtio). And the env file is extended for booting Debian.

The last commit is to update memory mapping info based on the DRAM info
passed via DT binding.

Link: https://lore.kernel.org/r/20241025171821.624702-1-leo.yan@arm.com

arm: total_compute: Update memory mapping info

This commit introduces build_mem_map() function for updating the mem_map
structure with copying info from gd->bd->bi_dram, so that it can keep
the consistence for DRAM info passed via DT.

The page table size is calculated prior to mem_map is ready, introduce
the get_page_table_size() function for a predefined table size.

Signed-off-by: Leo Yan <leo.yan@arm.com>

arm: total_compute: Support Debian boot

Add booting option for Debian system.

Signed-off-by: Leo Yan <leo.yan@arm.com>

arm: total_compute: Dynamically detect block device

Dynamically detect block device in the boot command, this allows to
support both MMC and virtio block devices.

Signed-off-by: Leo Yan <leo.yan@arm.com>

arm: total_compute: Minor improvement for boot arguments

Tell the AVB command that is loading from MMC.

Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

arm: total_compute: move the boot command to an env file

The boot command for Total Compute has many aspects and changes from time
to time. So move it to an .env file where it can be a proper script.

Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

arm: total_compute: Remove unused bootm_size

The whole DRAM bank is used for loading and U-boot can detect the
overlap between the kernel and initramfs. So it is safe to drop
bootm_size.

Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

arm: total_compute: Initialize environment variables

Initialize the environment variables 'fdt_addr_r' and 'kernel_addr_r'
during the misc init phase. The static configurations are not needed,
remove them.

Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

arm: total_compute: depend on TF-A for hardware description

On Total Compute, TF-A passes the info via DT binding for the hardware
description - includes the serial, memory, and arm_ffa nodes.

This commit initializes the fdt base address based on the passed the
register x1.

The similar implementation has already been done for the raspberry pi,
so borrow a lot of it.

Co-developed-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com>
Signed-off-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

Merge patch series "Fixes to allow 'ut bootm' to pass when run interactively"

Andrew Goodbody <andrew.goodbody@linaro.org> says:

Starting a sandbox session and running 'ut bootm' on the command
line instead of using pytest with --verbose will result in some
test failures. This series makes the tests more deterministic so
that they will better control their environment and hence will
work as expected whether or not they are invoked with '--verbose'.
The series starts with a small fix to the parameters of
bootm_process_cmdline that one commit incorrectly added using a bool
when it had been updated to take flags by the preceeding commit.

Link: https://lore.kernel.org/r/20241101130254.473017-1-andrew.goodbody@linaro.org

test: bootm: Ensure GD_FLG_SILENT is reset

Some bootm tests expect that GD_FLG_SILENT is reset in order
to work as expected. This is the state if the test is run with
'pytest --verbose' but not if run from, say, the sandbox command
line.
So reset the flag for those tests that rely on it being reset. This
has to be done in each test as the test infrastructure will set it
again before every test when not invoked with 'pytest --verbose'.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>

test: bootm: bootm_process_cmdline_env takes flags

The function bootm_process_cmdline_env takes flags as its third
parameter, not a bool. Correct the usage by replacing 'true'
with BOOTM_CL_ALL so that the intent is clear.
A similar change was made throughtout this file in the previous
commit to the one mentioned below as being fixed.

Fixes: 4448fe8e4e7c ("bootm: Allow updating the bootargs in a buffer")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>

usb: Fix test dependency on ext4write command

The tests test_usb_ext4load_ext4write, test_usb_ext2load and
test_usb_load depend on the command ext4write being present not just
the feature of being able to write to an ext4 file system. So update
their dependencies to include the ext4write command itself. This will
prevent spurious test failures when running the USB tests against USB
storage with an ext2/ext4 partition but no ext4write command available.

Fixes: 1c5b6edad381 ("test/py: usb: Add tests for USB device")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Love Kumar <love.kumar@amd.com>

usb: Fix test failure with multiple partitions

When test_usb_load finds multiple partitions of the same type then
it will cause a test failure. The call to write the test file will
write a different test file to each partition but only return the
name and size of the last one written. So the test then fails to
load the test file from the first partition as it uses the name of
a file on a different partition.

Refactor the code so that only one test file is written at a time
and is written to only the partition being tested at that time. This
allows the correct file name to always be available to the code that
runs the load command. This reduces the number of files written and
also the number of calls to crc32 needed.

Fixes: 1c5b6edad381 ("test/py: usb: Add tests for USB device")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Love Kumar <love.kumar@amd.com>

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

CI: https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/23152
CI: https://dev.azure.com/simon0972/u-boot/_build/results?buildId=71&view=results

- alist enhancements and fixes
- minor test and sandbox fixes
- some more x86/coreboot patches

sandbox: Fix comment for nomap_sysmem() function

This should say 'cast' rather than 'case', so fix it.

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

sandbox: Add a way to show the sandbox memory-mapping

This is mostly hidden in the background, but it is sometimes useful to
look at it. Add a function to allow this.

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