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>
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>
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>
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>
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>
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>
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>
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 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>
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>
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>
Implement initjmp() for Arm. 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>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add the HAVE_INIJMP symbol to be set by architectures that support
initjmp(), 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.
Add the initjmp() prototype to <include/setjmp.h> since it is common to
all architectures.
Add an entry to the API documentation: doc/api/setjmp.rst.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Christian Marangi <ansuelsmth@gmail.com> says:
This is continuation of the initial patchset for airoha
support.
Some are trivial fix for spi.
A new concept to setup SPI from detected NAND.
Sadly DTS node still need to be merged upstream so we
are currently adding them to u-boot dtsi and it's planned
to be dropped once they are accepted in upstream kernel.
Link: https://lore.kernel.org/r/20250407200208.25594-1-ansuelsmth@gmail.com
Add Airoha SPI NAND driver to permit usage of attached SNAND on the
Airoha AN7581 SoC. While SPI controller supports DMA transation, due to
U-Boot limitation we currently limit it to single command in Manual
mode.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Call SPI setup_for_spinand() if supported and defined to configure the
SPI slave for the attached NAND. This is needed to configure the SPI
with the NAND page size and spare size for correct configuration of the
device.
Call it as soon as the NAND is detected to correctly handle SPI
controller with select_op_variant detection.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
A common device attached to SPI are SPI NAND and some device might
require to have info on the attached NAND to know the flash page size
and spare size.
To support this, introduce setup_for_spinand() that pass the attached
spinand info from manufacturer.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
[trini: Switch to forward declaration of struct spinand_info]
Signed-off-by: Tom Rini <trini@konsulko.com>
Drop unneeded spi.h header include from spinand.h, nothing included by
spi.h is actually used in this header and .c should correctly included
spi.h if actually needed.
Replace spi.h with linux/bitops.h as this is what is actually required
for spinand.h
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Port Linux kernel regmap_set/clear_bits shorthands to set and clear bits
in a regmap. These are handy if only specific bits needs to be applied
or cleared and makes it easier to port regmap based driver from kernel
upstream.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Enable Mediatek MMC driver in Airoha AN7581 EVB defconfig to add support
for it in default images.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add eMMC nodes with the fixed regulator and fixed clock. It's also
needed to assign the clock and set it to 200MHz as it's set to 150Mhz by
default.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Airoha new SoC implement the same Mediatek driver for MMC. Permit to
also build for Airoha arch.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add airoha Ethernet driver for Airoha AN7581 SoC. This is a majorly
rewritten and simplified version of the Linux airoha_eth.c driver.
It's has been modified to support a single RX/TX ring to reflect U-Boot
implementation with recv and send API.
The struct and the define are kept as similar as possible to upstream
one to not diverge too much.
The AN7581 SoC include an Ethernet Switch based on the Mediatek MT753x
but doesn't require any modification aside from setting the CPU port and
applying the Flood configuration hence it can be handled entirely in the
Ethernet driver.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add the driver for the Airoha EN8811H 2.5 Gigabit PHY. The PHY supports
100/1000/2500 Mbps with auto negotiation only.
The driver uses two firmware files, for which updated versions are added to
linux-firmware already.
Based on the Linux upstream 8811 driver code(air_en8811h.c),
I have modified the relevant process to align with the U-Boot boot sequence.
and have validated this on Banana Pi BPI-R3 Mini.
The MD32 FW is currently stored in eMMC partition 1 on Banana Pi BPI-R3 Mini,
and it is loaded from there.
Signed-off-by: Lucien.Jheng <lucienzx159@gmail.com>
Line 171 in README is describing that before relocation no code
should use global variable because global variables are placed
to BSS section which is initialized to 0 after relocation.
In the case of ZynqMP, where DTB reselection is enabled, the EEPROM
is read again after relocation. This prevents the issue from being
observed. However, in Versal Gen 2, where DTB reselection is also
enabled, the EEPROM is not read after relocation because it is not
yet wired in board_init(). This leads to a situation where the code
accesses an incorrect memory location, because none is really
checking the board_info is valid or not. To fix, move the board_info
into the data section and also check whether it is valid or not.
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Link: https://lore.kernel.org/r/20250409162553.588285-1-padmarao.begari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
HBM stands for high bandwidth memory and is a type of memory interface used
in 3D-stacked DRAM (dynamic random access memory) in some AMD GPUs (aka
graphics cards), as well as the server, high-performance computing (HPC)
and networking and client space. High Bandwidth Memory(HBM) has total 16
channels, one channel is divided into two pseudo channels which makes its
32 banks each with some amount of memory.
And then we have DDR_LOW PS low, DDR_HIGH0 PS high, DDR_HIGH1 PS very high
and pretty much there should be also place for PL DDR. So maximum number of
memory banks will be 36, updating the CONFIG_NR_DRAM_BANKS to 36.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20250410092528.3713904-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
