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