[PATCH v9 02/11] efi_loader: Add a test app

[Tom Rini]

On Wed, Oct 30, 2024 at 08:44:04AM +0100, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 29 Oct 2024 at 21:13, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Tue, Oct 29, 2024 at 08:22:10PM +0100, Simon Glass wrote:
> >
> > > Add a simple app to use for testing. This is intended to do whatever it
> > > needs to for testing purposes. For now it just prints a message and
> > > exits boot services.
> > >
> > > There was a considerable amount of discussion about whether it is OK to
> > > call exit-boot-services and then return to U-Boot. This is not normally
> > > done in a real application, since exit-boot-services is used to
> > > completely disconnect from U-Boot. However, since this is a test, we
> > > need to check the results of running the app, so returning is necessary.
> > > It works correctly and it provides a nice model of how to test the EFI
> > > code in a simple way.
> > >
> > > Signed-off-by: Simon Glass <sjg at chromium.org>
> >
> > This approach has been specifically rejected with an explained
> > rationale: It breaks how UEFI applications work and you cannot run
> > further UEFI tests in sandbox without resetting.
> >
> > Since as you note, you can't reset in a C-based test, rework this to be
> > a python test where we can safely reset the system and verify that. I
> > believe Heinrich even noted that a test which checks ExitBootServices()
> > working as expected would be helpful as we only have a watchdog test
> > currently.
> 
> Unfortunately I believe this is the wrong direction, as we are unable
> to check the state of anything once a reset has happened. Thus I
> cannot build on this test, e.g. to see what happened to the devices
> and whether they are still bound. It becomes just a 'black box' test.
> None of the other bootflow tests work this way, BTW.

That's unfortunate in a number of ways then really. It's good when we
can test the state machine is still where we expect it. It's better when
we can test that the functionality works for real. It would probably be
generically useful to have some verification functions that can dump the
state of DM before we finish ourselves up and hand things over to the
OS. We could even make use of this in test/py/tests/test_net_boot.py
when we're booting Linux to make sure it's working as expected.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241030/c6afff20/attachment.sig>