Re: u-boot vs. uefi as boot loaders on ARM
On Thu, Aug 20, 2020 at 4:27 AM Oleksandr Andrushchenko 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 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.
Re: u-boot vs. uefi as boot loaders on ARM
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 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
Re: u-boot vs. uefi as boot loaders on ARM
Hi Roman, On 16/08/2020 21:45, Roman Shaposhnik wrote: On Sun, Aug 16, 2020 at 7:54 AM Julien Grall 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
Re: u-boot vs. uefi as boot loaders on ARM
On Sun, Aug 16, 2020 at 7:54 AM Julien Grall 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) > 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 Thanks, Roman.
Re: u-boot vs. uefi as boot loaders on ARM
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? Recent version of U-boot are also able to partially UEFI. This means you could easily use GRUB with U-boot. From my understanding, U-boot is just a bootloader. Therefore it will not provide runtime services (such as date & time). 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. Cheers, -- Julien Grall
u-boot vs. uefi as boot loaders on ARM
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? Any and all info on this would be very much appreciated! Thanks, Roman.
