sunxi: mmc: remove usage of struct sunxi_ccm_reg

The Allwinner MMC code uses a complex C struct, modelling the clock
device's register frame. We rely on sharing the member names across all
Allwinner SoCs, which is fragile.

Drop the usage of the struct in the MMC code, by using #define'd
register names and their offset, and then adding those names to the base
pointer. This requires to define those offsets for all SoCs, but since we
only use between four and six clock registers in the MMC code, this is
easily done.

This removes one common user of the clock register struct.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: clock: H6: drop usage of struct sunxi_ccm_reg

U-Boot drivers often revert to using C structures for modelling hardware
register frames. This creates some problems:
- A "struct" is a C language construct to group several variables
  together. The details of the layout of this struct are partly subject
  to the compiler's discretion (padding and alignment).
- The "packed" attribute would force a certain layout, but we are not
  using it.
- The actual source of information from the data sheet is the register
  offset. Here we create an artificial struct, carefully tuning the
  layout (with a lot of reserved members) to match that offset. To help
  with correctness, we put the desired information as a *comment*,
  though this is purely for the human reader, and has no effect on the
  generated layout. This sounds all very backwards.
- Using a struct suggests we can assign a pointer and then access the
  register content via the members. But this is not the case, instead
  every MMIO register access must go through specific accessor functions,
  to meet the ordering and access size guarantees the hardware requires.
- We share those structs in code shared across multiple SoC families,
  though most SoCs define their own version of the struct. Members must
  match in their name, across every SoC, otherwise compilation will fail.
  We work around this with even more #ifdefs in the shared code.
- Some SoCs have an *almost* identical layout, but differ in a few
  registers. This requires hard to maintain #ifdef's in the struct
  definition.
- Some of the register frames are huge: the H6 CCU device defines 127
  registers. We use 15 of them. Still the whole frame would need to be
  described, which is very tedious, but for no reason.
- Adding a new SoC often forces people to decide whether to share an
  existing struct, or to create a new copy. For some cases (say like 80%
  similarity) this works out badly either way.

The Linux kernel heavily frowns upon those register structs, and instead
uses a much simpler solution: #define REG_NAME <offset>
This easily maps to the actual information from the data sheet, and can
much simpler be shared across multiple SoCs, as it allows to have all
SoC versions visible, so we can use C "if" statements instead of #ifdef's.
Also it requires to just define the registers we need, and we can use
alternative locations for some registers much more easily.

Drop the usage of "struct sunxi_ccm_reg" in the H6 SPL clock code, by
defining the respective register names and their offsets, then adding
them to the base pointer.
We cannot drop the struct definition quite yet, as it's also used in
other drivers, still.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: armv8: FEL: save and restore SP_IRQ

Thanks for Jernej's JTAG debugging effort, it turns out that the BROM
expects SP_IRQ to be saved and restored, when we want to enter back into
FEL after the SPL's AArch64 stint.
Save and restore SP_IRQ as part of the FEL state handling. The banked
MRS/MSR access to SP_IRQ, without actually being in IRQ mode, was
introduced with the ARMv7 virtualisation extensions. The Arm Cortex-A8
cores used in the A10/A13s or older F1C100s SoCs would not support that,
but this code here is purely in the ARMv8/AArch64 code path, so it's
safe to use unconditionally.

Reported-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: armv8: FEL: save and restore GICv3 registers

To be able to return to the BootROM FEL USB debug code, we must restore
the core's state as accurately as possible after the SPL has been run.
Since the BootROM runs in AArch32, but the SPL uses AArch64, this requires
a core reset, which clears the core's state.
So far we were saving and restoring the required registers like SCTLR
and VBAR, but could ignore the interrupt controller's state (GICC), since
that lives in MMIO registers, unaffected by a core reset.
Newer Allwinner SoCs now feature a GICv3 interrupt controller, which keeps
some GIC state in architected system registers, and those are cleared
when we switch back to AArch32.

To enable FEL operation on the Allwinner A523 SoC,
Add AArch32 assembly code to save and restore the ICC_PMR and ICC_IGRPEN1
system registers. The other GICv3 sysregs are either not relevant for the
BROM operation, or haven't been changed from their reset defaults by the
BROM anyway.

This enables FEL operation on the Allwinner A523 family of SoCs.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

watchdog: sunxi: add A523 support

The Allwinner A523 SoC moved the watchdog into a separate MMIO frame,
and also shifted the registers a bit: the control, config, and mode
register are located four bytes earlier.

Add the new compatible string, and connect it to the new struct
describing the new register layout.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stefan Roese <sr@denx.de>

sunxi: Kconfig: Remove obsolete USBx_* pin symbols

Now that the USB PHY driver uses the device tree to get the VBUS detect
and USB ID GPIOs, these Kconfig symbols are unused. Remove them from
their Kconfig definition, and also from all defconfig files.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

phy: sun4i-usb: Determine USB OTG detection pin from devicetree

So far Allwinner boards controlled the USB OTG ID detection via the
respective GPIO pin specified in Kconfig, as a string. All boards should
have the same GPIO already specified in the devicetree, in the
usb0_id_det-gpios property.

Convert the usage of the Kconfig configured GPIO over to query that
information from the devicetree, then use the existing DM GPIO
infrastructure to request the GPIO.
Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to
avoid claiming it multiple times.

This removes the need to name that GPIO in the defconfig file.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

phy: sun4i-usb: Determine VBUS detection pin from devicetree

So far Allwinner boards controlled the USB VBUS detection via the
respective GPIO pin specified in Kconfig, as a string. All boards should
have the same GPIO already specified in the devicetree, in the
usb0_vbus_det-gpios property.

Convert the usage of the Kconfig configured GPIO over to query that
information from the devicetree, then use the existing DM GPIO
infrastructure to request the GPIO.
Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to
avoid claiming it multiple times.

This removes the need to name that GPIO in the defconfig file.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

gpio: axp: Remove virtual VBUS enable GPIO

Now that this functionality is modeled using the device tree and
regulator uclass, the named GPIO is not referenced anywhere. Remove
it, along with the rest of the support for AXP virtual GPIOs.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: Remove obsolete USBx_VBUS_PIN Kconfig symbols

Now that the USB PHY driver uses the device tree to get VBUS supply
regulators, these Kconfig symbols are unused. Remove them.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

phy: sun4i-usb: Control supplies via the regulator uclass

The device tree binding for the PHY provides VBUS supplies as regulator
references. Now that all boards have the appropriate regulator uclass
drivers enabled, the PHY driver can switch to using them. This replaces
direct GPIO usage, which in some cases needed a special DM-incompatible
"virtual" GPIO from the PMIC.

The following boards provided a value for CONFIG_USB0_VBUS_PIN, but are
missing the "usb0_vbus-supply" property in their device tree. None of
them have the MUSB controller enabled in host or OTG mode, so they
should see no impact:
 - Ainol_AW1_defconfig / sun7i-a20-ainol-aw1
 - Ampe_A76_defconfig / sun5i-a13-ampe-a76
 - CHIP_pro_defconfig / sun5i-gr8-chip-pro
 - Cubieboard4_defconfig / sun9i-a80-cubieboard4
 - Merrii_A80_Optimus_defconfig / sun9i-a80-optimus
 - Sunchip_CX-A99_defconfig / sun9i-a80-cx-a99
 - Yones_Toptech_BD1078_defconfig / sun7i-a20-yones-toptech-bd1078
 - Yones_Toptech_BS1078_V2_defconfig /
   sun6i-a31s-yones-toptech-bs1078-v2
 - iNet_3F_defconfig / sun4i-a10-inet-3f
 - iNet_3W_defconfig / sun4i-a10-inet-3w
 - iNet_86VS_defconfig / sun5i-a13-inet-86vs
 - iNet_D978_rev2_defconfig / sun8i-a33-inet-d978-rev2
 - icnova-a20-swac_defconfig / sun7i-a20-icnova-swac
 - sun8i_a23_evb_defconfig / sun8i-a23-evb

Similarly, the following boards set CONFIG_USB1_VBUS_PIN, but do not
have "usb1_vbus-supply" in their device tree. Neither of them have USB
enabled at all, so again there should be no impact:
 - Cubieboard4_defconfig / sun9i-a80-cubieboard4 (also for USB3)
 - sun8i_a23_evb_defconfig / sun8i-a23-evb

The following boards use a different pin for USB1 VBUS between their
defconfig and their device tree. Depending on which is correct, they
may be broken:
 - Linksprite_pcDuino3_Nano_defconfig (PH11) /
   sun7i-a20-pcduino3-nano (PD2)
 - icnova-a20-swac_defconfig (PG10) / sun7i-a20-icnova-swac (PH6)

Finally, this board has conflicting pins given for its USB2 VBUS:
 - Lamobo_R1_defconfig (PH3) / sun7i-a20-lamobo-r1 (PH12)

Signed-off-by: Samuel Holland <samuel@sholland.org>
[Andre: use regulator_set_enable_if_allowed()]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: Enable PMIC drivevbus regulator support for USB supplies

On many boards, the USB ports are powered by the PMIC's "drivevbus"
regulator. In preparation for switching the USB PHY driver to use the
regulator uclass instead of a virtual GPIO pin, ensure these boards
have AXP PMIC regulator support enabled.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

power: regulator: Add a driver for the AXP PMIC drivevbus

AXP PMICs have a pin which can either report the USB VBUS state, or
driving a regulator that supplies USB VBUS. Add a regulator driver for
controlling this pin. The selection between input and output is done via
the x-powers,drive-vbus-en pin on the PMIC (parent) node.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: enable MMU_PGPROT proper page table protection

Select the new MMU_PGPROT Kconfig symbol for all Allwinner board builds,
to use a write-protected .rodata, non-executable .data and .rodata
sections, and non-writable .text sections.

This might trigger runtime exceptions in misbehaving drivers, which
should then be fixed.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: h616: defconfigs: enable eMMC

Now that eMMC is working properly on H616 devices, it became apparent
that some boards were missing the right defconfig bits to enable eMMC
access.

Add the eMMC device number to the Tanix TX1 and the X96 Mate defconfig,
also the eMMC boot option to the TX1. Oddly enough the X96 Mate had
just this bit already.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: h6/h616: Reuse common DRAM infrastructure

H616 rank and size detection code is superior to the H6. Nevertheless,
they are structurally the same. Split functions from H616 into new file
and reuse them in H6 DRAM driver too. This should also fix some bugs for
H6 too, like incorrect DRAM size detection.

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
[Andre: back out panic if test fails to allow 2^11 columns]
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: h6: dram: split dram_para struct

This change is same as in commit 78aa00c38e86 ("sunxi: H616: dram: split
struct dram_para"), but for H6. This is needed in order to extract
common code between H6 and H616 later.

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>

sunxi: H6: DRAM: Constify function parameters

Constify parameters for two reasons:
- Allow more compile time optimizations
- It will allow later sharing of common code with H616 (when it will be
  rearranged some more)

Commit does same kind of changes as commit 457e2cd665bd ("sunxi: H616:
dram: const-ify DRAM function parameters")

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>

sunxi: H6: Remove useless DRAM timings parameter

This is just cosmetic fix for later easier rework.

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>

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

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

- riscv: lib: Simplify FDT retrieving process
- board: k1: pinctrl: Add pinctrl support for bananapi-f3
- binman: riscv: Fix binman_sym functionality
- board: starfive: visionfive2: Reorder board detection logic
- board: starfive: Add DeepComputing FML13V01 support

Merge tag 'efi-2025-07-rc1-3' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2025-07-rc1-3

Documentation:

* add documentation for the DeepComputing FML13V01
* fix typos

UEFI:

* build with HII configuration protocol
* print image load address in StartImage

Boards:

* qemu-riscv raise CONFIG_NR_DRAM_BANKS
* add support for the DeepComputing FML13V01 board via
  starfive_visionfive2_defconfig
* add UNIT_TESTS to big-endian Malta boards

configs: add UNIT_TESTS to big-endian Malta boards

We currently only run the unit tests on low-endian boards.
We should run them on big-endian, too.

Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: jh7110: describe debug UART

Provide the settings for using the debug UART in SPL.

Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: starfive: use jh7110_common.rst

To avoid duplicate maintenance just include jh7110_common.rst to describe
the usage of the different boot sources.

Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: starfive: use consistent formatting

Always use ---- for the H2 level.

Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: add DeepComputing FML13V01 documentation

Describe building U-Boot for the board and booting.

Carve out common information for JH7110 boards into an include.

Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

board: starfive: spl: support DeepComputing FML13V01

On the DeepComputing Framework motherboard (FML13V01) choose the matching
FIT configuration.

Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

board: starfive: DeepComputing FML13V01 fdt selection

We support all JH7110 boards with starfive_visionfive2_defconfig.
The relevant device-tree is selected at runtime based on EEPROM data.

Support setting $fdtfile to the file name of the DeepComputing Framework
motherboard (FML13V01) device-tree.

Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

riscv: dts: jh7110: add DeepComputing FML13V01 device-tree

Add the u-boot device-tree include needed to support the
DeepComputing Framework motherboard (FML13V01).

Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

configs: add jh7110-deepcomputing-fml13v01 to VF2 defconfig

The DeepComputing Framework motherboard is a JH7110 device support by the
upstream kernel. Add its device-tree to the list of device-trees to be
included into the starfive_visionfive_defconfig.

Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

configs: qemu-riscv raise CONFIG_NR_DRAM_BANKS

The number of memory banks in QEMU is not bounded by 1.

In this example we have two banks:

    qemu-system-riscv64 \
    -machine virt \
    -nographic \
    -m 8192 \
    -smp 8,sockets=2,cores=4,threads=1 \
    -numa node,cpus=0-3,mem=4096 \
    -numa node,cpus=4-7,mem=4096 \
    -kernel u-boot

As we will see RISC-V NUMA systems using U-Boot
we should be able to emulate these.

Use the default value defined in /Kconfig as 4.

Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: fix typo 'to'

Fix typo from "to" to "do"

Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

doc: fix typo commnad

fix typo from "commnad" to "command"

Signed-off-by: Aristo Chen <aristo.chen@canonical.com>

doc: arch: arm64: fix typos

Fix typo from "recommened" to "recommended"

Signed-off-by: Aristo Chen <aristo.chen@canonical.com>

doc: remove duplicated "commands"

The "commands" are duplicated, so remove one of them

Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

efi_loader: print image load address in StartImage

When starting image add the image load address to the debug output.

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

efi_loader: build with HII configuration protocol

Without the HII configuration protocol the debug version of the UEFI shell
cannot be used.

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

board: starfive: visionfive2: Order board detection logic to match config

Refactor inside-out EEPROM-checking logic to better match the board-seeking
callback and ordered list of targets from starfive_visionfive2_config since
the JH7110 OF_UPSTREAM migration.

Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

doc: board: starfive: visionfive2: add missing format command to Flashing

Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

doc: jh7110: describe debug UART

Provide the settings for using the debug UART in SPL.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>

doc: starfive: use jh7110_common.rst

To avoid duplicate maintenance just include jh7110_common.rst to describe
the usage of the different boot sources.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>

doc: starfive: use consistent formatting

Always use ---- for the H2 level.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>

doc: add DeepComputing FML13V01 documentation

Describe building U-Boot for the board and booting.

Carve out common information for JH7110 boards into an include.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>

board: starfive: spl: support DeepComputing FML13V01

On the DeepComputing Framework motherboard (FML13V01) choose the matching
FIT configuration.

Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>

board: starfive: DeepComputing FML13V01 fdt selection

We support all JH7110 boards with starfive_visionfive2_defconfig.
The relevant device-tree is selected at runtime based on EEPROM data.

Support setting $fdtfile to the file name of the DeepComputing Framework
motherboard (FML13V01) device-tree.

Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>

riscv: dts: jh7110: add DeepComputing FML13V01 device-tree

Add the u-boot device-tree include needed to support the
DeepComputing Framework motherboard (FML13V01).

Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>

configs: add jh7110-deepcomputing-fml13v01 to VF2 defconfig

The DeepComputing Framework motherboard is a JH7110 device support by the
upstream kernel. Add its device-tree to the list of device-trees to be
included into the starfive_visionfive_defconfig.

Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>

riscv: Provide __image_copy_{start_end} symbols in linkerscript

Binman looks for __image_copy_start to determine the base address of an
entry if elf-base-sym isn't specified, which is missing in RISC-V port.
This causes binman skips RISC-V SPL entries without filling addresses
into its .binman_sym_table section.

This patch defines __image_copy_start in linkerscript of both SPL and
proper U-Boot to ensure binman_sym functions correctly with the default
binman.dtsi. The paired symbol, __image_copy_end, is introduced as well
for completeness.

Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

riscv: dts: starfive: Prevent binman from relocating symbols in SPL

SPL and proper U-Boot are split into two images with default binman
configuration of StarFive VisionFive 2, thus proper U-Boot symbols
cannot be found in the SPL image. This fixes errors like

  Section '/binman/spl-img': Symbol '_binman_u_boot_any_prop_size'
    in entry '/binman/spl-img/mkimage/u-boot-spl/u-boot-spl-nodtb':
      Entry 'u-boot-any' not found in list (u-boot-spl-nodtb,
      u-boot-spl-dtb,u-boot-spl,mkimage,spl-img)

Fixes: 90602e779d3 ("riscv: dts: starfive: generate u-boot-spl.bin.normal.out")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Yao Zi <ziyao@disroot.org>

riscv: dts: binman.dtsi: Switch to u-boot-nodtb entry for proper U-Boot

Switch to u-boot-nodtb entry which precisely represents a proper U-Boot
and could be matched with u_boot_any. This allows RISC-V ports that make
use of binman to be built without disabling SPL_BINMAN_UBOOT_SYMBOLS
explicitly, which is set to y by default.

Fixes: 0784510f741 ("riscv: sifive: unleashed: Switch to use binman to generate u-boot.itb")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

configs: qemu-riscv raise CONFIG_NR_DRAM_BANKS

The number of memory banks in QEMU is not bounded by 1.

In this example we have two banks:

    qemu-system-riscv64 \
    -machine virt \
    -nographic \
    -m 8192 \
    -smp 8,sockets=2,cores=4,threads=1 \
    -numa node,cpus=0-3,mem=4096 \
    -numa node,cpus=4-7,mem=4096 \
    -kernel u-boot

As we will see RISC-V NUMA systems using U-Boot
we should be able to emulate these.

Use the default value defined in /Kconfig as 4.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

MAINTAINERS: visionfive2: Add match N: starfive pattern

Add match N:starfive pattern to visionfive2 board. Now
starfive pattern just related to JH7110 IC.

Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Reviewed-by: Marek Vasut <marex@denx.de>

config: Enable pinctrl in bananapi-f3

Add pinctrl support in bananapi-f3 platform

Signed-off-by: Huan Zhou <me@per1cycle.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

riscv: dts: k1: add pinctrl property in dts.

Add pinctrl node in device tree and update
in bananapi f3 dts.

Signed-off-by: Huan Zhou <me@per1cycle.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

board: sifive: Remove dead board_fdt_blob_setup

CONFIG_OF_BOARD isn't enabled on SiFive Unleashed and Unmatched, thus
board_fdt_blob_setup is actually dead code on these platforms. Let's
remove it.

Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

board: starfive: Remove duplicated board_fdt_blob_setup

The default version should work for Starfive VisionFive 2.

Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

board: qemu: riscv: Remove duplicated board_fdt_blob_setup

The default version should work for RISC-V QEMU.

Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

riscv: lib: Add a default implementation of board_fdt_blob_setup

It's common for S-Mode proper U-Boot to retrieve a FDT blob along with
taking control from SBI firmware. Add a weak version of
board_fdt_blob_setup to make use of it by default, avoiding copy-pasting
similar functions among boards.

Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

tools/make_pip: Use venv when invoking pip

Recent Ubuntu versions (24.04+) disallow pip by default when
installing packages. The recommended approach is to use a virtual
environment (venv) instead.
Because of this, "make pip" is failing on such versions.

To prepare CI container migration to Ubuntu 24.04, use a venv in the
make_pip script.

Note: This has been reported on [1]

[1] https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/37

Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

CI: Update to latest containers

This changes to using "venv" rather than "virtualenv" for Python
sandboxing.

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

python: Use and refer to the venv module rather than virtualenv

Using some form of sandbox with Python modules is a long standing best
practice with the language. There are a number of ways to have a Python
sandbox be created. At this point in time, it seems the Python community
is moving towards using the "venv" module provided with Python rather
than a separate tool. To match that we make the following changes:

- Refer to a "Python sandbox" rather than virtualenv in comments, etc.
- Install the python3-venv module in our container and not virtualenv.
- In our CI files, invoke "python -m venv" rather than "virtualenv".
- In documentation, tell users to install python3-venv and not
  virtualenv.

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

Merge patch series "Add PCIe support for TI AM64 SoC"

Hrushikesh Salunke <h-salunke@ti.com> says:

TI's AM64 SoC has a single instance of Cadence PCIe Controller. This
series enables support for PCIe in AM64 SoC and to configure it in
Root-Complex mode of operation.

Link: https://lore.kernel.org/r/20250416120830.138965-1-h-salunke@ti.com

configs: am64x_evm_a53_defconfig: Enable configs for PCIe support

TI's AM64 SoC has single instance of PCIe Controller namely PCIe0 which
is Cadence PCIe Controller. To support PCIe functionality with PCIe0
instance in Root-Complex mode enable corresponding configs. Also enable
configs to support NVMe over PCIe.

Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>

pci: pcie_cdns_ti: Enable PCIe root-complex mode in AM64 SoC

TI's AM64 SoC has single instance of PCIe Controller namely PCIe0 which
is Cadence PCIe Controller. Add support to configure PCIe0 in Root-
Complex mode of operation.

Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>

pci: pcie_cdns_ti: Include linux/sizes.h header

Driver uses macro SZ_4G to configure inbound base address register.
The macro is used without including the header file in which it is
defined. Fix this.

Fixes: 59ad5480098 ("pci: Add TI K3 Cadence PCIe Controller")
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>

Merge patch series "arm: mach-k3: remove some firewalls left over by ROM"

Bryan Brattlof <bb@ti.com> says:

This small series is here to remove some firewalls setup by ROM during
their boot and clean things up for Linux later on. Ideally this would be
a simple call to remove_fwl_configs() however the location of the
firewall is problematic (could potentially crash the core) when we're
currently executing from the memory region protected by the firewall.

So we need to introduce a function which allows us to disable specific
firewall regions and skip others to ensure boot stability.

Link: https://lore.kernel.org/r/20250414-firewalls-v1-0-89090085c08b@ti.com

arm: mach-k3: am625: remove any firewalls ROM has configured for HSRAM

ROM will configure a firewall to only allow HSRAM to be touched by the
R5 core. Any outside entity like DMA or the A53s will not have access to
this region. This can be problematic when U-Boot, running on the A53,
loads firmware that runs out of this region.

To simplify things remove the firewall here and let the remote core
firmware place a new firewall themselves if they wish for the memory
region.

Signed-off-by: Bryan Brattlof <bb@ti.com>

arm: mach-k3: support disabling a single firewall region

During boot some firewall regions could contain the R5's code which if
we change the firewalls settings will crash the core. To get around this
issue, define a new function which allows us to specify specific regions
we want unlocked.

Signed-off-by: Bryan Brattlof <bb@ti.com>

Merge patch series "More MMC fixes"

Judith Mendez <jm@ti.com> says:

This patch series fixes MMC_HS_52 mode in am654_sdhci driver,
as well as HIGH_SPEED_ENA and UHS_MODE_SELECT for HS modes.

Also add TI_COMMON_CMD_OPTIONS to K3 Sitara board a53 defconfigs.

Link: https://www.ti.com/lit/er/sprz574a/sprz574a.pdf
Link: https://lore.kernel.org/r/20250417234334.3661321-1-jm@ti.com

configs: am62*_evm_a53_defconfig: Add TI_COMMON_CMD_OPTIONS

Add TI_COMMON_CMD_OPTIONS config options to Sitara K3 boards at
a53 stage since we rely on most of the commands implied for testing
and debugging purposes. Since all commands are now enabled by
default, remove the redundant CMD_* options in the a53 defconfigs.

Also add MMC_REG & MMC_SPEED_MODE_SET useful commands to
TI_COMMON_CMD_OPTIONS.

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>

mmc: am654_sdhci: Add am654_sdhci_set_control_reg

This patch adds am654_sdhci_set_control_reg to am654_sdhci.

This is required to fix UHS_MODE_SELECT for TI K3 boards.

If any of HIGH_SPEED_ENA, V1P8_SIGNAL_ENA, UHS_MODE_SELECT
are set, then data will be launched on the pos-edge of the
clock.

Since K3 SoCs did not meet timing requirements for High Speed
SDR mode at rising clock edge, none of these three should be
set, therefore limit UHS_MODE_SELECT to only be set for modes
above MMC_HS_52.

This fixes MMC write issue on am64x evm at mode High Speed
SDR.

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>

mmc: am654_sdhci: Fix HIGH_SPEED_ENA

High Speed enable bit switches data launch from the falling
clock edge (half cycle timing) to the rising clock edge (full
cycle timing). For all SD UHS modes, data launch must happen
at the rising clock edge, so set HIGH_SPEED_ENA for SDR12 and
SDR25 modes. For all HS modes, data launch must happen at the
falling clock edge, so do not set HIGH_SPEED_ENA for MMC_HS_52.

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>

mmc: am654_sdhci: Add MMC_HS_52 to timing data

This patch adds MMC_HS_52 to the timing data structure.

Previously, this bus mode tap settings were not populated and
were instead populated for MMC_HS which is a different bus mode
up to 26MHz. Since we intended these settings according to the
device data sheet[0] for MMC_HS_52 up to 52MHz, populate MMC_HS
tap settings for MMC_HS_52.

While we are here, fix typo in ti,itap-del-sel-mms-hs.

[0] https://www.ti.com/lit/ds/symlink/am625.pdf Table 7-79

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>

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

u-boot-dfu-20250425

Usb gadget:
- Fix ACM gadget release
- Allow ACM gadget restart after releasing it
- Add 'enabled' flag to usb_ep structure

DFU:
- Fix alt buffer clearing for DeveloperBox board

cmd: cls: do not repeat clearing of console

There is no need to repeat the command to clear the console. Remove
it's repeat attribute.

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

spi: cadence-qspi: Add disable STIG mode quikrs.

Adding quirk to disable STIG mode since cadence controller has
issue for read/write using the STIG mode. STIG mode is enabled
by default since 2023.04 for small read/write(<8bytes).

Updated STIG mode reading from dev_get_driver_data by assigning
to platdata struct before read quirks variable.

The STIG mode is disabled for normal read case and enabled
for QSPI Jedec ID read/write since it requires STIG read/write.

Porting from linux implementation
https://lore.kernel.org/all/20241204063338.296959-1-niravkumar
.l.rabara@intel.com/T/

Signed-off-by: Boon Khai Ng <boon.khai.ng@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>

arm: mach-k3: r5: j7200: Add clk dev data for WKUP UART

Add clk and dev data for wakeup uart to enable wakeup
UART as console.

Reported-by: KEERTHY <j-keerthy@ti.com>
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>

mach-k3: common_fdt: Move carveout struct

Labels are not allowed before declarations. Move the carveout struct
at the beginning and only update 'end' at this point.

This will fix following error:

arch/arm/mach-k3/common_fdt.c: In function 'fdt_fixup_reserved':
arch/arm/mach-k3/common_fdt.c:156:2: error: a label can only be part of a statement and a declaration is not a statement
  156 |  struct fdt_memory carveout = {
      |  ^~~~~~
make[1]: *** [scripts/Makefile.build:256: arch/arm/mach-k3/common_fdt.o] Error 1
make: *** [Makefile:1919: arch/arm/mach-k3] Error 2

Fixes: 096aa229a9e ("mach-k3: common_fdt: create a reserved memory node")

Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>

mach-k3: add eMMC FS boot support for am62[ap]

This makes spl_mmc_boot_mode consistent across am62x, 62a and 62p.

If MMCSD_MODE_EMMCBOOT is returned, FS boot fails since it checks for FS
on the hardware partitions, not the UDA. So to allow FS boot from EMMC,
the function should return MMCSD_MODE_FS instead which allows us to read
from FS on the UDA.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

arm: dts: am62a: allow booting from eMMC

The bootph-all property in u-boot enables driver initialization prior to
relocation, this is necessary to use the device as boot media.

sdhci0 is the phandle for eMMC on am62a, so this change allows us to use
eMMC as a boot media.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

configs: set SPL_TEXT_BASE by default for k3 platforms

SPL_TEXT_BASE is used as the load address for the main domain SPL on k3
platforms.

Since the config value is the same for every board, this patch sets the
value 0x80080000 as default for all 64-bit ARCH_K3, 0x43c00000 as
default for the R5 cores and deletes the instances of SPL_TEXT_BASE in
individual defconfigs.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

test/py: spi: Prevent to overwrite the reserved memory

Update SPI negative tests to prevent SF command from overwriting the
reserved memory area.

Signed-off-by: Love Kumar <love.kumar@amd.com>

smbios: Do not look up children of invalid nodes

If there is no UCLASS_SYSINFO device available, parent_node will be
ofnode_null(). Calling ofnode_find_subnode() then triggers an assertion:

  drivers/core/ofnode.c:598: ofnode_find_subnode: Assertion `ofnode_valid(node)' failed.

Check for a valid parent_node, not just that OF_CONTROL is enabled.

Fixes: 44ffb6f0ecaf ("smbios: Allow properties to come from the device tree")
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>

net: dwc_eth_qos: Fix hang when freeing packet after stop

If eqos_free_pkt() is called after eqos_stop(), eqos_stop_resets() will
have been called already. This may prevent accessing the MMIO space to
update the RX descriptor tail pointer, so we must skip the descriptor
maintenance logic. This is okay because the descriptors and tail pointer
will all be rewritten anyway during the next call to eqos_start().

This hang was observed after a failed TFTP transaction:

  eqos_recv(dev=000000047fb57330, flags=1):
  eqos_recv: *packetp=000000c3ffb5c080, length=151

  TFTP error: 'file <FILE> not found for <IP>' (1)
  Not retrying...
  eqos_stop(dev=000000047fb57330):
  eqos_stop: OK
  eqos_free_pkt(packet=000000c3ffb5c080, length=151)
  <HANG>

Fixes: ba4dfef1469f ("net: add driver for Synopsys Ethernet QoS device")
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>

Merge patch series "Uthreads"

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

This series introduces threads and uses them to improve the performance
of the USB bus scanning code and to implement background jobs in the
shell via two new commands: 'spawn' and 'wait'.

The threading framework is called 'uthread' and is inspired from the
barebox threads [2]. setjmp() and longjmp() are used to save and
restore contexts, as well as a non-standard extension called initjmp().
This new function is added in several patches, one for each
architecture that supports HAVE_SETJMP. A new symbol is defined:
HAVE_INITJMP. Two tests, one for initjmp() and one for the uthread
scheduling, are added to the lib suite.

After introducing threads and making schedule() and udelay() a thread
re-scheduling point, the USB stack initialization is modified to benefit
from concurrency when UTHREAD is enabled, where uthreads are used in
usb_init() to initialize and scan multiple busses at the same time.
The code was tested on arm64 and arm QEMU with 4 simulated XHCI buses
and some devices. On this platform the USB scan takes 2.2 s instead of
5.6 s. Tested on i.MX93 EVK with two USB hubs, one ethernet adapter and
one webcam on each, "usb start" takes 2.4 s instead of 4.6 s.

Finally, the spawn and wait commands are introduced, allowing the use of
threads from the shell. Tested on the i.MX93 EVK with a spinning HDD
connected to USB1 and the network connected to ENET1. The USB plus DHCP
init sequence "spawn usb start; spawn dhcp; wait" takes 4.5 seconds
instead of 8 seconds for "usb start; dhcp".

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=446674
[2] https://github.com/barebox/barebox/blob/master/common/bthread.c

Link: https://lore.kernel.org/r/20250418141114.2056981-1-jerome.forissier@linaro.org

configs: qemu: enable UTHREAD and CMD_SPAWN in various defconfigs

Enable UTHREAD and CMD_SPAWN on supported QEMU platforms for testing
purposes.

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

MAINTAINERS: add UTHREAD

Add myself as the maintainer for the UTHREAD framework, the spawn/wait
commands and the associated tests.

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

test: cmd: add test for spawn and wait commands

Test the spawn and wait commands.

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

cmd: add spawn and wait commands

Add a spawn command which runs another command in the background, as
well as a wait command to suspend the shell until one or more background
jobs have completed. The job_id environment variable is set by spawn and
wait accepts optional job ids, so that one can selectively wait on any
job.

Example:

 => date; spawn sleep 5; spawn sleep 3; date; echo "waiting..."; wait; date
 Date: 2025-02-21 (Friday)    Time: 17:04:52
 Date: 2025-02-21 (Friday)    Time: 17:04:52
 waiting...
 Date: 2025-02-21 (Friday)    Time: 17:04:57
 =>

Another example showing how background jobs can make initlizations
faster. The board is i.MX93 EVK, with one spinning HDD connected to
USB1 via a hub, and a network cable plugged into ENET1.

 # From power up / reset
 u-boot=> setenv autoload 0
 u-boot=> setenv ud "usb start; dhcp"
 u-boot=> time run ud
 [...]
 time: 8.058 seconds

 # From power up / reset
 u-boot=> setenv autoload 0
 u-boot=> setenv ud "spawn usb start; spawn dhcp; wait"
 u-boot=> time run ud
 [...]
 time: 4.475 seconds

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

dm: usb: initialize and scan multiple buses simultaneously with uthread

Use the uthread framework to initialize and scan USB buses in parallel
for better performance. The console output is slightly modified with a
final per-bus report of the number of devices found, common to UTHREAD
and !UTHREAD. The USB tests are updated accordingly.

Tested on two platforms:

1. arm64 QEMU on a somewhat contrived example (4 USB buses, each with
one audio device, one keyboard, one mouse and one tablet)

 $ make qemu_arm64_defconfig
 $ make -j$(nproc) CROSS_COMPILE="ccache aarch64-linux-gnu-"
 $ qemu-system-aarch64 -M virt -nographic -cpu max -bios u-boot.bin \
     $(for i in {1..4}; do echo -device qemu-xhci,id=xhci$i \
         -device\ usb-{audio,kbd,mouse,tablet},bus=xhci$i.0; \
     done)

2. i.MX93 EVK (imx93_11x11_evk_defconfig) with two USB hubs, each with
one webcam and one ethernet adapter, resulting in the following device
tree:

 USB device tree:
   1  Hub (480 Mb/s, 0mA)
   |  u-boot EHCI Host Controller
   |
   +-2  Hub (480 Mb/s, 100mA)
     |  GenesysLogic USB2.1 Hub
     |
     +-3  Vendor specific (480 Mb/s, 350mA)
     |    Realtek USB 10/100/1000 LAN 001000001
     |
     +-4   (480 Mb/s, 500mA)
           HD Pro Webcam C920 8F7CD51F

   1  Hub (480 Mb/s, 0mA)
   |  u-boot EHCI Host Controller
   |
   +-2  Hub (480 Mb/s, 100mA)
     |   USB 2.0 Hub
     |
     +-3  Vendor specific (480 Mb/s, 200mA)
     |    Realtek USB 10/100/1000 LAN 000001
     |
     +-4   (480 Mb/s, 500mA)
          Generic OnLan-CS30 201801010008

Note that i.MX was tested on top of the downstream repository [1] since
USB doesn't work in the upstream master branch.

[1] https://github.com/nxp-imx/uboot-imx/tree/lf-6.6.52-2.2.0
    commit 6c4545203d12 ("LF-13928 update key for capsule")

The time spent in usb_init() ("usb start" command) is reported on
the console. Here are the results:

        | CONFIG_UTHREAD=n | CONFIG_UTHREAD=y
--------+------------------+-----------------
QEMU    |          5628 ms |          2212 ms
i.MX93  |          4591 ms |          2441 ms

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

dm: usb: move bus initialization into new static function usb_init_bus()

To prepare for the introduction of threads in the USB initialization
sequence, move code out of usb_init() into a new helper function:
usb_init_bus() and count the number of USB controllers initialized
successfully by using the DM device_active() function.

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

test: lib: add uthread_mutex test

Add a test for uthread mutexes.

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

test: lib: add uthread test

Add a thread framework test to the lib tests. Update the API
documentation to use the test as an example.

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

lib: time: hook uthread_schedule() into udelay()

Introduce a uthread scheduling loop into udelay() when CONFIG_UTHREAD
is enabled. This means that any uthread calling into udelay() may yield
to uthread and be scheduled again later. There is no delay in the
scheduling loop because tests have shown that such a delay can have a
detrimental effect on the console (input drops characters).

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

cyclic: invoke uthread_schedule() from schedule()

Make the schedule() call from the CYCLIC framework a uthread scheduling
point too. This makes sense since schedule() is called from a lot of
places where uthread_schedule() needs to be called.

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

uthread: add uthread_mutex

Add struct uthread_mutex and uthread_mutex_lock(),
uthread_mutex_trylock(), uthread_mutex_unlock() to protect shared data
structures from concurrent modifications.

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

uthread: add cooperative multi-tasking interface

Add a new internal API called uthread (Kconfig symbol: UTHREAD) which
provides cooperative multi-tasking. The goal is to be able to improve
the performance of some parts of U-Boot by overlapping lengthy
operations, and also implement background jobs in the U-Boot shell.
Each uthread has its own stack allocated on the heap. The default stack
size is defined by the UTHREAD_STACK_SIZE symbol and is used when
uthread_create() receives zero for the stack_sz argument.

The implementation is based on context-switching via initjmp()/setjmp()/
longjmp() and is inspired from barebox threads [1]. A notion of thread
group helps with dependencies, such as when a thread needs to block
until a number of other threads have returned.

The name "uthread" comes from "user-space threads" because the
scheduling happens with no help from a higher privileged mode, contrary
to more complex models where kernel threads are defined. But the 'u'
may as well stand for 'U-Boot' since the bootloader may actually be
running at any privilege level and the notion of user vs. kernel may
not make much sense in this context.

[1] https://github.com/barebox/barebox/blob/master/common/bthread.c

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

test: lib: add initjmp() test

Test the initjmp() function when HAVE_INITJMP is set. Use the test as an
example in the API documentation.

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

sandbox: add initjmp()

Add initjm[() to sandbox, a non-standard extension to setjmp()/
longjmp() allowing to initialize a jump buffer with a function pointer
and a stack pointer. This will be useful to later introduce threads.
With this new function it becomes possible to longjmp() to a particular
function pointer (rather than to a point previously reached during
program execution as is the case with setjmp()), and with a custom stack.
Both things are needed to spin off a new thread. Then the usual
setjmp()/longjmp() pair is enough to save and restore a context, i.e.,
switch thread. The implementation is taken verbatim from barebox [1] with
the exception of the additional stack_sz argument. It is quite complex
because contrary to U-Boot platform code we don't know how the system's
C library implements the jump buffer, so we can't just write the function
and stack pointers into it.

[1] https://github.com/barebox/barebox/blob/b2a15c383ddc/arch/sandbox/os/setjmp.c

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

riscv: add initjmp()

Implement initjmp() for RISC-V, a non-standard extension to setjmp()/
longjmp() allowing to initialize a jump buffer with a function pointer
and a stack pointer. This will be useful to later introduce threads.
With this new function it becomes possible to longjmp() to a particular
function pointer (rather than to a point previously reached during
program execution as is the case with setjmp()), and with a custom stack.
Both things are needed to spin off a new thread. Then the usual
setjmp()/longjmp() pair is enough to save and restore a context, i.e.,
switch thread.

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