Re: u-boot vs. uefi as boot loaders on ARM

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

On 8/20/20 1:50 PM, Julien Grall wrote:
> Hi Roman,
>
> On 16/08/2020 21:45, Roman Shaposhnik wrote:
>> On Sun, Aug 16, 2020 at 7:54 AM Julien Grall <julien@xxxxxxx> wrote:
>>> On 15/08/2020 21:43, Roman Shaposhnik wrote:
>>>> Hi!
>>>
>>> Hi,
>>>
>>>> with the recent excellent work by Anastasiia committed to the u-boot's
>>>> main line, we now have two different ways of bringing ARM DomUs.
>>>>
>>>> Is there any chance someone can educate the general public on pros
>>>> and cons of both approaches?
>>>>
>>>> In Project EVE we're still using uefi on ARM (to stay closer to the more
>>>> "ARM in the cloud" use case) but perhaps the situation now is more
>>>> nuanced?
>>>
>>> UEFI is just standard, so I am guessing you are referring to
>>> Tianocore/EDK2. am I correct?
>>
>> Yes, but I was actually referring to both in a way (I should've been
>> clearer tho).
>> To be more explicit my question was around trying to compare a "standardized"
>> way of botting a generic DomU on ARM (and that standard is UEFI with one
>> particular implementation that works out of the box with Xen being TC/EDK2) 
>> with
>> a more ad-hoc u-boot style of booting.
>>
>>> Recent version of U-boot are also able to partially UEFI. This means you
>>> could easily use GRUB with U-boot.
>>
>> Yup -- which complicated things even more. And it is funny you should mention
>> it, since we actually started with TC/EDK2 for RaspberryPi4 as a board
>> bootloader,
>> but quickly switched to u-boot with UEFI shim layer, since it was much 
>> smaller,
>> better supported (still?) and gave us all we needed to boot Xen on RPi4 as a
>> UEFI payload.
>>
>>>  From my understanding, U-boot is just a bootloader. Therefore it will
>>> not provide runtime services (such as date & time).
>>
>> It actually does provide some of that (see below)
>
> Cool! Although, it looks mostly related to the environment variable though.
>
>>
>>> Furthermore, the
>>> interface is less user friendly, you will have to know the memory layout
>>> in order to load binaries.
>>>
>>> On the other hand, Tianocore/EDK2 is very similar to what non-embedded
>>> may be used to. It will not require you to know your memory layout. But
>>> this comes at the cost of a more complex bootloader to debug.
>>
>> That's literally the crux of my question -- trying to understand what use 
>> cases
>> either one of them is meant for. Especially given that this shim layer is now
>> quite capable:
>> https://github.com/ARM-software/u-boot/blob/master/doc/README.uefi#L127
>
> While I can see major differences when using either on baremetal (you have 
> better control on the Device-Tree with U-boot), it is much less clear in a 
> guest. Maybe Anastasiia can explain why they decided to add support in 
> U-boot? :).

Well, there are many SoC vendors provide u-boot as their boot loader,

so it was natural for us to add pvblock to it (Renesas, Xilinx, iMX, RPi, you 
name it).

So this is the only reason I guess
> Cheers,
>
Regards,

Oleksandr