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

[Julien Grall <julien@xxxxxxx>]

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? :).
Cheers,

--
Julien Grall