[PATCH v3 00/20] Convert extension support to UCLASS and adds its support to boot flows
Tom Rini
trini at konsulko.com
Tue Oct 21 16:36:26 CEST 2025
On Tue, Oct 21, 2025 at 04:29:19PM +0200, Kory Maincent wrote:
> On Tue, 21 Oct 2025 07:49:07 -0600
> Tom Rini <trini at konsulko.com> wrote:
>
> > On Tue, Oct 21, 2025 at 02:44:30PM +0200, Kory Maincent wrote:
> > > On Tue, 21 Oct 2025 10:52:05 +0100
> > > Simon Glass <sjg at chromium.org> wrote:
> > >
> > > > Hi Kory,
> > > >
> > > > On Tue, Oct 21, 2025, 10:02 Kory Maincent <kory.maincent at bootlin.com>
> > > > wrote:
> > > > > On Tue, 21 Oct 2025 09:40:58 +0200
> > > > > Mattijs Korpershoek <mkorpershoek at kernel.org> wrote:
> > > > >
> > > > > > On Mon, Oct 20, 2025 at 11:17, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > > On Mon, Oct 20, 2025 at 07:08:54PM +0200, Kory Maincent wrote:
> > > > > > >> On Mon, 20 Oct 2025 10:05:27 -0600
> > > > > > >> Tom Rini <trini at konsulko.com> wrote:
> > > > > > >>
> > > > > > >> > On Mon, Oct 20, 2025 at 05:23:45PM +0200, Kory Maincent wrote:
> > > > > > >> >
> > > > > > >> > > On Mon, 20 Oct 2025 08:37:29 -0600
> > > > > > >> > > Tom Rini <trini at konsulko.com> wrote:
> > > > > > >> > >
> > > > > > >> > > > On Mon, Oct 20, 2025 at 08:15:48AM -0600, Tom Rini wrote:
> > > > > > >> > > > > On Mon, Oct 20, 2025 at 11:50:09AM +0200, Kory Maincent
> > > > > > >> > > > > wrote:
> > > > > > >> > > > > > On Sun, 19 Oct 2025 10:48:37 -0600
> > > > > > >> > > > > > Tom Rini <trini at konsulko.com> wrote:
> > > > > > >> > > > > >
> > > > > > >> > > > > > > On Sun, Oct 19, 2025 at 02:05:51PM +0100, Simon Glass
> > > > > > >> > > > > > >
> > > > > wrote:
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > > Hi Kory,
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > On Mon, 13 Oct 2025 at 14:32, Kory Maincent (TI.com)
> > > > > > >> > > > > > > > <kory.maincent at bootlin.com> wrote:
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > This series converts the extension board framework
> > > > > > >> > > > > > > > > to
> > > > > use
> > > > > > >> > > > > > > > > UCLASS as requested by Simon Glass, then adds
> > > > > extension
> > > > > > >> > > > > > > > > support to pxe_utils and bootmeth_efi (not tested)
> > > > > > >> > > > > > > > > to enable extension boards devicetree load in the
> > > > > > >> > > > > > > > >
> > > > > standard
> > > > > > >> > > > > > > > > boot process.
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > I can't test the imx8 extension scan enabled by the
> > > > > > >> > > > > > > > > imx8mm-cl-iot-gate_defconfig as I don't have this
> > > > > > >> > > > > > > > >
> > > > > board.
> > > > > > >> > > > > > > > > I also can't test the efi bootmeth change as I
> > > > > > >> > > > > > > > > don't
> > > > > have
> > > > > > >> > > > > > > > > such board.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > You can test this with sandbox, using one of the
> > > > > bootmeth
> > > > > > >> > > > > > > > tests, perhaps. Let me know if you need help with
> > > > > > >> > > > > > > > this.
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > But the question is, does the real hardware platform
> > > > > > >> > > > > > > work before/after this, not does the sandbox test
> > > > > > >> > > > > > > still work before/after this.
> > > > > > >> > > > > >
> > > > > > >> > > > > > It seems the bootlflow scan is not working on the
> > > > > > >> > > > > > sandbox
> > > > > on next
> > > > > > >> > > > > > branch. Is this issue known?
> > > > > > >> > > > >
> > > > > > >> > > > > Is it fine on master? The next branch will be out of date
> > > > > > >> > > > >
> > > > > until it
> > > > > > >> > > > > re-opens with -rc2 being released (2 weeks from today).
> > > > > > >> > > >
> > > > > > >> > > > ... out of sync local calendar, 3 weeks from today, not 2.
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> > > bootstd test suit is not working on master with the
> > > > > sandbox_defconfig:
> > > > > > >> > > https://termbin.com/un0p
> > > > > > >> > >
> > > > > > >> > > Noticeable things are;
> > > > > > >> > > test/boot/bootdev.c:160, bootdev_test_any(): 0 ==
> > > > > > >> > > bootdev_find_by_any(seq, &dev, &mflags): Expected 0x0 (0), got
> > > > > > >> > > 0xffffffed (-19) Test: bootdev_test_any: bootdev.c (flat tree)
> > > > > > >> > > test/boot/bootdev.c:160, bootdev_test_any(): 0 ==
> > > > > > >> > > bootdev_find_by_any(seq, &dev, &mflags): Expected 0x0 (0), got
> > > > > > >> > > 0xffffffed (-19) Test 'bootdev_test_any' failed 2 times
> > > > > > >> > >
> > > > > > >> > > And a nice segfault:
> > > > > > >> > > Test: bootflow_set_arg: bootflow.c
> > > > > > >> > > Test: bootflow_system: bootflow.c
> > > > > > >> > > [3] 569337 segmentation fault (core dumped) ./u-boot
> > > > > > >> > >
> > > > > > >> > > Maybe things are missing to run sandbox_defconfig on my
> > > > > > >> > > computer? With the sandbox64_defconfig there is not core dump
> > > > > > >> > > anymore but
> > > > > there
> > > > > > >> > > is still the failed line:
> > > > > > >> > > Test 'bootdev_test_bootable' failed 2 times
> > > > > > >> > >
> > > > > > >> > > And the uboot is reboot infinitely during the bootflow test:
> > > > > > >> > > ./u-boot -T -c "ut bootstd"
> > > > > > >> > > https://termbin.com/alu5
> > > > > > >> >
> > > > > > >> > I see the same thing you do when running them outside of pytest,
> > > > > > >> > but they're also fine within pytest.
> > > > > > >> > https://docs.u-boot.org/en/latest/develop/pytest/usage.html
> > > > > > >> > should
> > > > > help
> > > > > > >> > get you started, and you can just run all of the ut tests under
> > > > > > >> >
> > > > > that.
> > > > > > >>
> > > > > > >> Weird I got errors also within pytest.
> > > > > > >> See the html test log attached generated by the following command:
> > > > > > >> ./test/py/test.py --bd sandbox -k bootstd
> > > > > > >
> > > > > > > Same. There's some implicit dependencies around I believe. Doing
> > > > > > > "-k
> > > > > ut"
> > > > > > > should work, as I tried that (via my wrapper around all this) as
> > > > > > > well
> > > > > as
> > > > > > > just running all the tests (which is longer).
> > > > > >
> > > > > > That's my understanding as well
> > > > > >
> > > > > > In Kory's log we see:
> > > > > >
> > > > > > MMC: Can't map file 'mmc1.img': Invalid argument
> > > > > > sandbox_mmc_probe() mmc1: Unable to map file 'mmc1.img'
> > > > > > Can't map file 'mmc1.img': Invalid argument
> > > > > > sandbox_mmc_probe() mmc1: Unable to map file 'mmc1.img'
> > > > > > mmc_probe() mmc1 - probe failed: -1
> > > > > > mmc2: 2 (SD)Can't map file 'mmc1.img': Invalid argument
> > > > > > sandbox_mmc_probe() mmc1: Unable to map file 'mmc1.img'
> > > > > > , mmc0: 0 (SD)
> > > > > >
> > > > > > These mmc1.img are needed for the bootstd tests to run properly.
> > > > > >
> > > > > > These mmc*.img are generated in test_ut.py (see setup_cros_image() for
> > > > > > example)
> > > > > >
> > > > > > So, In order to only run the bootstd tests, I think we need to to run:
> > > > > >
> > > > > > $ ./test/py/test.py --bd sandbox --build -k test_ut
> > > > > > $ ./test/py/test.py --bd sandbox --build -k bootstd
> > > > > >
> > > > > > Then we can just call:
> > > > > >
> > > > > > $ ./test/py/test.py --bd sandbox --build -k bootstd
> > > > >
> > > > > Ok after installing missing dependencies and running test_ut tests I
> > > > > have less
> > > > > errors but there are still bootflow errors. See the test-log attached.
> > > > > I suppose all the tests should pass, right?
> > > > >
> > > >
> > > > How are you running the tests? This is described in the docs. Search for
> > > > 'tests'.
> > > >
> > > > https://docs.u-boot.org/en/latest/develop/tests_sandbox.html#running-sandbox-tests-directly
> > > >
> > >
> > > As discussed in the email thread running test directly does not work and
> > > segfault for the bootflow command.
> > > We have to run it under the test.py command to makes it work.
> > >
> > > The log I sent was for the following command:
> > > $ ./test/py/test.py --bd sandbox --build -k test_ut
> > >
> > > The two errors on bootflow on master are:
> > > Test: bootflow_cmd_menu: bootflow.c
> > > test/boot/bootflow.c:673, bootflow_cmd_menu(): 0 == run_command("bootflow
> > > menu", 0): Expected 0x0 (0), got 0x1 (1)
> > >
> > > test/boot/bootflow.c:718, bootflow_scan_menu(): console:
> > > Expected 'Selected: Armbian',
> > > got '<no-more-output>'
> > >
> > > Tom do you face the same errors? If that's the case we should fix these.
> >
> > No, I can do:
> > $ git clean -dfx
> > $ ./test/py/test.py --bd sandbox --build -k test_ut
> > And the result is:
> > =============== 872 passed, 1 skipped, 608 deselected, 13398 warnings in
> > 55.73s ===============
> >
> > And this is on top of tree master right now.
>
> Oh ok weird, I just tried again on my side but still got 6 tests that failed.
> These tests are not related to my series so lets ignore these.
>
> Anyway, I don't see how I can test the extension support in bootmeth efi with
> sandbox, and it would be better to test it on a real board. Or at least that it
> does not break bootmeth efi for the current hardware platform.
Do you have other changes for v3? If not, I'll apply that soon and we
can add more tests in a follow-up, if Simon can explain his thinking on
how it would work. If you do have changes for v4, same comments about
testing apply but I'll move v3 to superseded in patchwork so I don't
forget.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251021/9f07b119/attachment.sig>
More information about the U-Boot
mailing list