Hi Tom, On 4/11/25 22:29, Tom Rini wrote: > On Mon, Mar 31, 2025 at 02:30:54PM +0200, Jerome Forissier wrote: > >> This series introduces threads and uses them for two things: >> - Improve the performance of the USB bus scanning code (scan multiple >> busses simultaneously), >> - 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. >> >> The schedule() and udelay() function are updated to become thread >> re-scheduling points, and mutex objects are introduced. With that 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 > > So, we're nearly there. But there's some CI problems. First, CI isn't > testing this because nothing enables UTHREADS.
Thanks for looking into this. I do have a TESTING patch [0] that enables this for various QEMU plaforms (arm, arm64, riscv32, riscv64) and for sandbox64. Please refer to the following CI pipeline [1]. [0] https://source.denx.de/u-boot/custodians/u-boot-net/-/commit/8460f6abefff [1] https://source.denx.de/u-boot/custodians/u-boot-net/-/pipelines/25706 > I don't know if we should > enable it by default on qemu_arm64 for example or not. Good question. Perhaps we could have a separate defconfig for the somewhat experimental stuff? > But for testing, > I added this to .gitlab-ci.yml (and something similar would work for > Azure): > qemu_arm64_uthread test.py: > variables: > TEST_PY_BD: "qemu_arm64" > TEST_PY_TEST_SPEC: "not sleep" > OVERRIDE: "-a CONFIG_UTHREAD=y -a CONFIG_CMD_SPAWN=y -a > CONFIG_UNIT_TEST=y" > <<: *buildman_and_testpy_dfn > > This however leads first to unrelated tests failing: > https://source.denx.de/u-boot/u-boot/-/jobs/1099921 Unrelated indeed. It turns out UNIT_TEST=y on qemu_arm64 is broken in master. I just posted a fix [2]. [2] https://lists.denx.de/pipermail/u-boot/2025-April/586897.html > And I didn't see if the new tests ran either. It seems you need to enable CMD_TIME too. In my testing patch I added -v (verbose) to the test.py command so that we can clearly see that lib_initjmp [3], lib_uthread [4] and lib_uthread_mutex [5] are run in CI. [3] https://source.denx.de/u-boot/custodians/u-boot-net/-/jobs/1103031#L457 [4] https://source.denx.de/u-boot/custodians/u-boot-net/-/jobs/1103031#L504 [5] https://source.denx.de/u-boot/custodians/u-boot-net/-/jobs/1103031#L505 Thanks, -- Jerome
