[U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it

Simon Glass sjg at chromium.org
Tue Nov 22 18:50:50 CET 2016


Hi Alex,

On 19 November 2016 at 17:13, Alexander Graf <agraf at suse.de> wrote:
>
>
>> Am 20.11.2016 um 00:56 schrieb Simon Glass <sjg at chromium.org>:
>>
>> Hi Alex,
>>
>>> On 19 November 2016 at 14:47, Alexander Graf <agraf at suse.de> wrote:
>>>
>>>
>>>> Am 19.11.2016 um 21:02 schrieb Simon Glass <sjg at chromium.org>:
>>>>
>>>> Hi Alex,
>>>>
>>>>> On 19 November 2016 at 07:13, Alexander Graf <agraf at suse.de> wrote:
>>>>>
>>>>>
>>>>>> On 19/11/2016 14:48, Simon Glass wrote:
>>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>>> On 17 November 2016 at 10:31, Alexander Graf <agraf at 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 <agraf at 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


More information about the U-Boot mailing list