On Tue, Oct 21, 2025 at 06:54:27PM +0200, Kory Maincent wrote: > On Tue, 21 Oct 2025 08:36:26 -0600 > Tom Rini <[email protected]> wrote: > > > On Tue, Oct 21, 2025 at 04:29:19PM +0200, Kory Maincent wrote: > > > On Tue, 21 Oct 2025 07:49:07 -0600 > > > Tom Rini <[email protected]> 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 <[email protected]> wrote: > > > > > > > > > > > Hi Kory, > > > > > > > > > > > > On Tue, Oct 21, 2025, 10:02 Kory Maincent > > > > > > <[email protected]> > > > > > > wrote: > > > > > > > On Tue, 21 Oct 2025 09:40:58 +0200 > > > > > > > Mattijs Korpershoek <[email protected]> wrote: > > > > > > > > > > > > > > > On Mon, Oct 20, 2025 at 11:17, Tom Rini <[email protected]> > > > > > > > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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) <[email protected]> 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. > > As I said: "I saw that as I removed the extension hunter in this series it > brings new test errors that need to be fixed." > I think it is better avoid these CI build test errors and send a v4.
Thanks for clarifying, yes, I missed that at some point in this long thread. :( -- Tom
signature.asc
Description: PGP signature
