On 22/11/2016 18:50, Simon Glass wrote:
Hi Alex,
On 19 November 2016 at 17:13, Alexander Graf <ag...@suse.de> wrote:
Am 20.11.2016 um 00:56 schrieb Simon Glass <s...@chromium.org>:
Hi Alex,
On 19 November 2016 at 14:47, Alexander Graf <ag...@suse.de> wrote:
Am 19.11.2016 um 21:02 schrieb Simon Glass <s...@chromium.org>:
Hi Alex,
On 19 November 2016 at 07:13, Alexander Graf <ag...@suse.de> wrote:
On 19/11/2016 14:48, Simon Glass wrote:
Hi Alex,
On 17 November 2016 at 10:31, Alexander Graf <ag...@suse.de> wrote:
Today we can compile a self-contained hello world efi test binary that
allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though,
by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from
including it in the u-boot binary for "bootefi hello". It also modifies
the efi_loader test case to enable travis to pick up the compiled file.
Because we're now no longer bloating the resulting u-boot binary, we
can enable compilation always, giving us good travis test coverage.
Signed-off-by: Alexander Graf <ag...@suse.de>
---
arch/arm/lib/Makefile | 2 +-
arch/x86/config.mk | 2 +-
arch/x86/lib/Makefile | 2 +-
cmd/Kconfig | 15 ++++++++++++++-
configs/qemu-x86_efi_payload64_defconfig | 1 +
lib/efi_loader/Makefile | 3 +++
test/py/tests/test_efi_loader.py | 2 +-
7 files changed, 22 insertions(+), 5 deletions(-)
Ick.
Can you not achieve the same effect just by copying the file somewhere?
Sure, we could. But the file is only defined inside the env of the
particular test case. So if you want to test against non-travis, you can
copy it wherever you like.
This way the travis description simplifies a lot, because we can just expose
the build directory as tftp root.
Or use .PRECIOUS on the existing file? You could copy it into the root
directory of the build, perhaps? It just seems like a lot of extra
stuff for a file that is already built.
I want to make sure that by default we never compile the hello world efi
example into the u-boot binary, but still have the file build tested and
available for travis.
So how about just having two cases:
1. Compile hello world and produce it as an output
2. As 1 but also build it into the U-Boot binary
Yes, that's precisely what this patch does :). I'm glad we agree.
Except that I don't think we need the extra CONFIG.
If that's the only disagreement we have, then let's have the extra
CONFIG. Having more usually shouldn't hurt.
The first one could be controlled by EFI_LOADER,
Unfortunately the hello world binary doesn't build on stm32 while there is no
reason to disable EFI_LOADER on that platform, so I want to keep the options
separately.
Well if no one can compile for stm32 then it is unlikely to work
anyway. Does anyone actually use Thumb 1 with EFI?
I've verified thumb 1 back in the day when I did the setjmp/longjmp
implementation, yeah.
Also, if someone comes in and enables a new architecture, I would like to make
the bar as low as I can for that. For that reason too, I would prefer to keep
it as a separate config option.
I think you might have it backwards. As someone who just enabled a new
architecture (x86) I can tell you that the best approach by far was to
use the embedded hello world test. In fact that is why I wrote it. It
provides a fast and easy to test to allow things to be brought up.
Using something like grub is so much more painful.
I think you might have it backwards :). Different people have different
approaches to problems. If someone wants to port the hello world example
first, I'm more than happy to have them do it. But if their flow is
different, I'm not going to be the one standing in their way.
My goal is to have EFI support enabled and working well for as many
devices as we can. The path to get there doesn't matter that much to me.
the second with the
existing option for the 'bootefi hello' command.
Yes, that too is what the patch does :).
So I think we should disable the one stm32 board until someone
actually gets it working, at least with the hello world test.
Can you prove that it doesn't work? So far the only thing that breaks is
your new hello world test code.
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
