The generic name 'EFI' would be more useful for common EFI features. At
present it just refers to the EFI app and stub, which is confusing.

Rename it to EFI_CLIENT

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

This directory was created when U-Boot gained the ability to run as an
EFI app in 2015. Since then the EFI-loader feature has been added.

The code in lib/efi is not actually used by the loader, so the name is
confusing.

Rename the directory to efi_client to indicate that it includes files
just for U-Boot being a client of EFI, i.e. the EFI app and stub.

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

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>

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

This series replaces the dynamic initcalls (with function pointers) with
static calls, and gets rid of initcall_run_list(), init_sequence_f,
init_sequence_f_r and init_sequence_r. This makes the code simpler and the
binary slighlty smaller: -2281 bytes/-0.21 % with LTO enabled and -510
bytes/-0.05 % with LTO disabled (xilinx_zynqmp_kria_defconfig).

Execution time doesn't seem to change noticeably. There is no impact on
the SPL.

The inline assembly fixes, although they look unrelated, are triggered
on some platforms with LTO enabled. For example: kirkwood_defconfig.

CI: https://source.denx.de/u-boot/custodians/u-boot-net/-/pipelines/25514

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

Now that all initcalls have been converted to static calls, remove
initcall_run_list().

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

Tom Rini <trini@konsulko.com> says:

This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.

Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com

It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.

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

Rename the C and header files to use the membuf basename, to match the
functions.

Add a MAINTAINERS entry while we are here.

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

The lone user of this driver has been removed for some time. Remove this
driver as well.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20250227205101.4127604-2-trini@konsulko.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Update the build rule so that hash algorithms are only included in an
SPL build if they are requested. This helps to reduce code size.

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