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

[Roman Shaposhnik <roman@xxxxxxxxxx>]

On Thu, Aug 20, 2020 at 4:27 AM Oleksandr Andrushchenko
<Oleksandr_Andrushchenko@xxxxxxxx> wrote:
>
>
> 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

What I am wondering about (perhaps selfishly because of Project EVE)
is the availability
of VMs for u-boot.

IOW, with UEFI I can pick up a random "cloud" (or any other one
really) ARM VM image
and boot it as DomU simply because it seems that 99% of existing VMs
are packaged
with a EFI partition setup for a UEFI boot.

Stefano and I actually talked about availability of VMs that are
pre-set with u-boot, but
it seems that the only place where you can find something like that is
Xilinx (for their
Petalinux). Stefano also brought up a point that Yocto would generate
u-boot's boot.scr
scripts -- but I have no experience with that and would appreciate
other commenting.

All of that said, it would be simply awesome if we can have a wiki
page with examples
of where to get (or how to build) DomUs that would be setup for u-boot
sequence on ARM.

Thanks,
Roman.