Re: [PATCH v3 00/20] Convert extension support to UCLASS and adds its support to boot flows

Kory Maincent
2025-10-21T14:29:39Z

On Tue, 21 Oct 2025 07:49:07 -0600
Tom Rini <trini@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@chromium.org> wrote:
> >
> > > Hi Kory,
> > >
> > > On Tue, Oct 21, 2025, 10:02 Kory Maincent <kory.maincent@bootlin.com>
> > > wrote:
> > > > On Tue, 21 Oct 2025 09:40:58 +0200
> > > > Mattijs Korpershoek <mkorpershoek@kernel.org> wrote:
> > > >
> > > > > On Mon, Oct 20, 2025 at 11:17, Tom Rini <trini@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@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@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@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@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.

Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering