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

[Mattijs Korpershoek <mkorpershoek@kernel.org>]

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


>
> -- 
> Tom