Am 14.06.2018 um 17:12 schrieb Simon Glass sjg@chromium.org:
HI Alex,
On 13 June 2018 at 04:08, Alexander Graf agraf@suse.de wrote:
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.
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