Hi Tom, On Tue, 29 Oct 2024 at 21:13, Tom Rini <tr...@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 <s...@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. Regards, Simon
