When Falcon Mode is enabled on RISC-V, use CONFIG_VAL
to check PAYLOAD_ARGS_ADDR, not CONFIG_IS_ENABLED.

Fixes: 10c4ab898c25 ("spl: riscv: falcon: move fdt blob to specified address")
Signed-off-by: Randolph <randolph@andestech.com>
Tested-by: Leo Yu-Chi Liang <ycliang@andestech.com>

Additional testing of the changes introduced in commit 33e06dcbe57a "common:
usb-hub: Reset hub port before scanning") revealed that some USB 2.0 and 3.0
flash drives didn't work in U-Boot on some Allwinner SoCs that support USB
2.0 interfaces only.  More precisely, some of the tested USB 2.0 and 3.0
flash drives failed to be detected and work on an OrangePi Zero 3, based on
the Allwinner H616 SoC that supports USB 2.0 only, while the same USB flash
drives worked just fine on a Pine64 H64, based on the Allwinner H6 SoC that
supports both USB 2.0 and USB 3.0 interfaces.

The USB ID of the above-mentioned USB 3.0 flash drive that failed to work is
1f75:0917 (Innostor Technology Corporation IS917 Mass storage), it is 32 GB
in size and sold under the PNY brand.  The mentioned USB 2.0 drive is some
inexpensive no-name drive with an invalid USB ID.

Resetting USB 3.0 hubs only, which this patch introduces to the USB hub
resets, has been tested to work as expected, resolving the identified issues
on the Allwinner H616, while not introducing any new issues on other tested
Allwinner SoCs.  Thus, let's fix it that way.

According to the USB 3.0 specification, resetting a USB 3.0 port is required
when an attached USB device transitions between different states, such as
when it resumes from suspend.  Though, the Linux kernel performs additional
USB 3.0 port resets upon initial USB device attachment, as visible in commit
07194ab7be63 ("USB: Reset USB 3.0 devices on (re)discovery") in the kernel
source, to ensure proper state of the USB 3.0 hub port and proper USB mode
negotiation during the initial USB device attachment and enumeration.

These additional types of USB port resets don't exist for USB 2.0 hubs,
according the USB 2.0 specification.  The resets seem to be added to the USB
3.0 specification as part of the port and device mode negotiation.

The Linux kernel resets USB 3.0 (i.e. SuperSpeed) hubs only, as visible in
commit 10d674a82e55 ("USB: When hot reset for USB3 fails, try warm reset.")
in the kernel source.  The check for SuperSpeed hubs is performed in a way
that also applies to newer SuperSpeed Plus (USB 3.1 or 3.2) hubs as well,
which hopefully makes it future proof.

Fixes: 33e06dcbe57a ("common: usb-hub: Reset hub port before scanning")

Link:
https://lore.kernel.org/u-boot/20240207102327.35125-1-i@shantur.com/T/#u
Link:
https://lore.kernel.org/u-boot/20240201164604.13315fa6@donnerap.manchester.arm.com/T/#u

Signed-off-by: Shantur Rathore <i@shantur.com>
Helped-by: Dragan Simic <dsimic@manjaro.org>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>

Introduce str_avb_io_error() and str_avb_slot_error() functions,
that provide a pointer to AVB runtime error message.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Link: https://lore.kernel.org/r/20240209192045.3961832-6-igor.opaniuk@foundries.io
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Make error prints more verbose with additional context.
Also s/print/debug/g for prints, which might be relevant only
for debugging purposes.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Link: https://lore.kernel.org/r/20240209192045.3961832-4-igor.opaniuk@foundries.io
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Move SPDX license identifiers to the first line, so it conforms
to license placement rule [1]:

Placement:
The SPDX license identifier in kernel files shall be added at the first
possible line in a file which can contain a comment.  For the majority
of files this is the first line, except for scripts which require the
'#!PATH_TO_INTERPRETER' in the first line.  For those scripts the SPDX
identifier goes into the second line.

[1] https://www.kernel.org/doc/Documentation/process/license-rules.rst

Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Link: https://lore.kernel.org/r/20240209192045.3961832-3-igor.opaniuk@foundries.io
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

mmc_switch_part() is used for switching between hw partitions
on eMMC (boot0, boot1, user, rpmb).
There is no need to do that for SD card.

This fixes the avb command usage on SD cards.

Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20240209192045.3961832-2-igor.opaniuk@foundries.io
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

With the relatively new button API in U-Boot, it's now much easier to
model the common usecase of mapping arbitrary actions to different
buttons during boot - for example entering fastboot mode, setting some
additional kernel cmdline arguments, or booting with a custom recovery
ramdisk, to name a few.

Historically, this functionality has been implemented in board code,
making it fixed for a given U-Boot binary and requiring the code be
duplicated and modified for every board.

Implement a generic abstraction to run an arbitrary command during boot
when a specific button is pressed. The button -> command mapping is
configured via environment variables with the following format:

  button_cmd_N_name=<button label>
  button_cmd_N=<command to run>

Where N is the mapping number starting from 0. For example:

  button_cmd_0_name=vol_down
  button_cmd_0=fastboot usb 0

This will cause the device to enter fastboot mode if volume down is held
during boot.

After we enter the cli loop the button commands are no longer valid,
this allows the buttons to additionally be used for navigating a boot
menu.

Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Tegra30
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

A number of assorted fixes

In event_type_name() we should avoid possible buffer overruns by checking
the type argument.

Addresses-Coverity-ID: 478862 Out-of-bounds access
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

rk3036 soc has limit internal sram, and not able to support spl
framework.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>