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. > >> >> 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? > > 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. > >> 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. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
