Hi Alex,
On 4 October 2016 at 09:50, Alexander Graf agraf@suse.de wrote:
Am 04.10.2016 um 17:37 schrieb Simon Glass sjg@chromium.org:
Hi Alex,
On 3 October 2016 at 21:15, Alexander Graf agraf@suse.de wrote:
Am 03.10.2016 um 23:50 schrieb Simon Glass sjg@chromium.org:
Hi,
On 27 September 2016 at 15:28, Tom Rini trini@konsulko.com wrote:
On Mon, Sep 26, 2016 at 09:36:19AM +0200, Alexander Graf wrote:
On 25.09.16 23:27, Simon Glass wrote:
It is useful to have a basic sanity check for EFI loader support. Add a
'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2: None
arch/arm/lib/HelloWorld32.efi | Bin 0 -> 11712 bytes
IIRC U-Boot as a whole is GPL licensed, which means that any binaries
shipped inside would also need to be GPL compatibly licensed which again
means that the source code (and build instructions?) for this .efi file
would need to be part of the tree, no?
Yeah, I'm not super comfortable with this.
Do you think we should drop these binary patches? I could always put
the binaries somewhere along with instructions on how to get them.
I think that's the best option, yes. You can always just add a url to the
readme to point people into the right direction.
OK. One problem is that we cannot write a test for it unless we actually run an EFI application.
Well, you could always provide a binary disk image that you run in qemu as test case. That one doesn't have to be gpl compliant thn because it's not derived work :).
I do think it is useful to be able to test the platform though.
I don't disagree, but I would argue that for the average u-boot user it
brings no additional value ;). And people like you who know how to enable a
new architecture probably also know how to get a file into their target's
memory.
I wonder if we can build our own hello world application? I think I did it once. But there is EFI library code that we would need to bring in (perhaps a small amount).
We could. The main problem is the PE header.
What is tricky about that?
Maybe we can trick around that with bincopy -O binary though. Hmm :).
Yes I think it is possible, and desirable. But for now I've gone with using an external patch. I may come back to this another time.
Regards, Simon