[U-Boot] [PATCH v5 10/13] efi: sandbox: Add a simple 'bootefi test' command

[Alexander Graf]

> Am 14.06.2018 um 17:12 schrieb Simon Glass <sjg at chromium.org>:
> 
> HI Alex,
> 
>> On 13 June 2018 at 04:08, Alexander Graf <agraf at suse.de> wrote:
>> 
>> 
>>> On 12.06.18 23:57, Simon Glass wrote:
>>> Hi Alex,
>>> 
>>>> On 12 June 2018 at 08:11, Alexander Graf <agraf at suse.de> wrote:
>>>> 
>>>> 
>>>>> On 12.06.18 15:48, Simon Glass wrote:
>>>>> Hi Alex,
>>>>> 
>>>>>> On 12 June 2018 at 02:28, Alexander Graf <agraf at suse.de> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 12.06.18 07:26, Simon Glass wrote:
>>>>>>> This jumps to test code which can call directly into the EFI support. It
>>>>>>> does not need a separate image so it is easy to write tests with it.
>>>>>>> 
>>>>>>> This test can be executed without causing problems to the run-time
>>>>>>> environemnt (e.g. U-Boot does not need to reboot afterwards).
>>>>>>> 
>>>>>>> For now the test just outputs a message. To try it:
>>>>>>> 
>>>>>>> ./sandbox/u-boot -c "bootefi test"
>>>>>>> U-Boot 2017.09-00204-g696c9855fe (Sep 17 2017 - 16:43:53 -0600)
>>>>>>> 
>>>>>>> DRAM:  128 MiB
>>>>>>> MMC:
>>>>>>> Using default environment
>>>>>>> 
>>>>>>> In:    serial
>>>>>>> Out:   serial
>>>>>>> Err:   serial
>>>>>>> SCSI:  Net:   No ethernet found.
>>>>>>> IDE:   Bus 0: not available
>>>>>>> Found 0 disks
>>>>>>> WARNING: booting without device tree
>>>>>>> Hello, world!
>>>>>>> Test passed
>>>>>>> 
>>>>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>>>> 
>>>>>> From Heinrich's comments it sounded like it wouldn't be hard to make the
>>>>>> selftest work. That sounds more appealing to me to be honest :).
>>>>> 
>>>>> Yes and in fact my hope was to run the tests automatically as part of
>>>>> 'make tests'
>>>>> 
>>>>> But rather than expanding the scope of this series, can we get this in
>>>>> first? Having EFI support in sandbox is a substantial step forward.
>>>> 
>>>> I agree that it would be amazing to have it in, I just want to make sure
>>>> we're walking into the right direction. And what I want to have is an
>>>> easy way to execute EFI binaries from user space :).
>>> 
>>> That's a different thing entirely from the purpose of my series. My
>>> series is designed to allow EFI applications to be *linked* with
>>> sandbox and run just like normal C code, with a full unified stack
>>> trace, etc.
>>> 
>>> I think this is a very useful feature separate from running EFI
>>> binaries in user space.
>> 
>> I understand that and I agree that it's useful. I just don't want to
>> drive us into a corner where it blocks the other use case.
> 
> I don't thing it does. Am I missing something?

Anything exposed via efi interfaces has to contain host virtual adresses, as binary payloads are not aware of the virt/phys memory offset.

> I take it you'd like to boot grub on sandbox. I imagine that will take
> more work, but should be possible.

I tried, it almost works. I guess the aarch64 version could even succeed.

> 
> The primary purpose from my side is to enable easier testing.

I agree on that part. So let's make sure both use cases get enabled! :)

Alex