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

[Alexander Graf]

On 22/11/2016 18:50, Simon Glass wrote:
> 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.

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