On 12.06.18 23:57, Simon Glass wrote:
> Hi Alex,
> On 12 June 2018 at 08:11, Alexander Graf <ag...@suse.de> wrote:
>> On 12.06.18 15:48, Simon Glass wrote:
>>> Hi Alex,
>>> On 12 June 2018 at 02:28, Alexander Graf <ag...@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 <s...@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.

U-Boot mailing list

Reply via email to