On Sun, Sep 17, 2017 at 1:58 PM, Simon Glass <s...@chromium.org> wrote: > Hi Heinrich, > > On 15 September 2017 at 02:06, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: >> This patch series provides: >> * corrections for the EFI event services >> * a test framework to check the EFI API implementation >> * unit tests covering the event services >> >> The EFI selftest is written such that it could be easily turned >> into a standalone EFI application. But this would require >> modifying the build procedures for EFI. Objcopy cannot generate >> the necessary relocations. >> >> The unit tests are identified by entries in a linker generated >> array to make them as self sufficient as possible. >> >> A Python test case is supplied to call run the EFI tests. >> >> Tested with Travis CI >> https://travis-ci.org/xypron2/u-boot/jobs/275733784 >> >> Of all my efi_loader patches these are the first I would like >> to see merged. >> >> Simon has commented on some other patches that he misses >> comments for all EFI API functions. I will add these with >> a separate patch. >> >> Heinrich Schuchardt (10): >> efi_loader: allow return value in EFI_CALL >> efi_selftest: provide an EFI selftest application >> test/py: add a test calling the EFI selftest >> efi_loader: implement queueing of the notification function >> efi_loader: efi_set_timer: reset signaled state >> efi_selftest: provide unit test for event services >> efi_loader: implement task priority level (TPL) >> efi_selftest: test task priority levels >> efi_loader: notify when ExitBootServices is invoked >> efi_selftest: check notification of ExitBootServices >> > > This progress makes significant progress on EFI testing at last. I'm > very pleased to see it. Thank you for all the work you have put into > this. > > In addition to this (not instead of) I would like to see EFI code > running under sandbox. I don't at present see a good reason why this > cannot be done. I am going to try to enable EFI loader support in > sandbox to a basic level and then we can see how hard it is to get > some of your tests running directly in sandbox. If that works out then > we can add that into the mix.
fwiw, I started on trying to get EFI_LOADER working in sandbox earlier today.. but ran into issues w/ setjmp. I probably should have kept my WIP but it was nothing too hard to reproduce (kconfig adds an "|| SANDBOX" to depends, and one or two "#elif defined(CONFIG_SANDBOX)".. nothing that would take too long to get back to the point I was at stuck on setjmp/longjmp (and lack of standard system hdrs).. I just switched to qemu Other than booting a real OS, seems theoretically possible to get EFI_LOADER working in sandbox. It should be enough to (w/ suitable 'host bind') load/run Shell.efi and eventually SCT.efi. BR, -R > I think this would make for an easier development environment for new > EFI features. For some years I have developed all new features in > sandbox and find it painful and unproductive when I need to test every > change manually on a board. It should also allow us to run your tests > (perhaps with some adaptation) with 'make tests' on a local machine > using sandbox. Ultimately it should be possible to expand test > coverage to cover all significant EFI logic. > > [..] > > Regards, > Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
