[U-Boot] [PATCH 00/10] efi_loader: event services & API test

[Rob Clark]

On Sun, Sep 17, 2017 at 1:58 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Heinrich,
>
> On 15 September 2017 at 02:06, Heinrich Schuchardt <xypron.glpk at 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