[U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Bhupesh Sharma]

> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Monday, May 16, 2016 5:51 PM
> On 16.05.16 14:04, Bhupesh Sharma wrote:
> >
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf at suse.de]
> >> Sent: Monday, May 16, 2016 1:09 PM
> >> To: Amit Tomer <amittomer25 at gmail.com>
> >> Cc: Bhupesh Sharma <bhupesh.sharma at nxp.com>; york sun
> >> <york.sun at nxp.com>; u-boot at lists.denx.de; Peter Newton
> >> <peter.newton at nxp.com>
> >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> >>
> >>
> >>
> >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer <amittomer25 at gmail.com>:
> >>>
> >>>> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
> >> <bhupesh.sharma at nxp.com> wrote:
> >>>> Note that UEFI firmware support is already available on LS2080A-
> RDB
> >>>> and allows Booting distributions like CentOS on the same.
> >>>
> >>> Sorry to intervene here but it's about having the EFI support
> inside
> >>> u-boot itself that may *not* required to have separate UEFI
> firmware
> >>> to boot various distributions.
> >>>
> >>> Please correct, if it's not right ?
> >>
> >> It's correct. The idea is to allow everyone to boot using the uEFI
> >> entry point in Linux (or any other OS), regardless of whether they
> >> want to run U-Boot or a TianoCore based formware.
> >>
> >> This might seem useless today for embedded use cases, but some
> >> features are only available via an EFI entry, such as kASLR. You can
> >> also invoke Linux directly using the "bootefi" command, as Linux is
> >> an EFI binary itself. That way the boot path doesn't become much
> >> longer than with booti today.
> >>
> >
> > The default firmware being offered by NXP to boot distros on LS2080A
> and variants is UEFI.
> >
> > EFI application support in u-boot doesn't present a solution to
> things
> > like run-time variable/service support that is required by distros to
> > update firmware components on the go. And there are several other
> > services being offered by UEFI to help distro boot e.g. secure uefi
> boot through x.509 certifications compliant to UEFI specifications.
> 
> Don't get me wrong - I think it's great if there is a TianoCore based
> firmware for LS2080A. But I didn't get the impression that there is a
> TianoCore based firmware for every NXP SoC out there, so enabling all
> of them to use the U-Boot provided uEFI implementation is still a win.
> 
> That said, there's nothing that keeps us from implementing the bits you
> mentioned in U-Boot either. There is support for RTS in U-Boot, we just
> didn't convert any drivers (RTC comes to mind first) yet.
> 
> There's also no support for uEFI environment variables, but mostly
> because most systems I've used this code on so far just didn't have any
> storage to put them.
> 
> Certification checks also shouldn't be an issue if someone cared enough
> about them.
> 
> But I don't think we need a discussion of TianoCore vs U-Boot. What
> everyone really wants is to have things "just work". And some customers
> just prefer U-Boot for various reasons that are outside of my control.
> If they can run the same boot path as everyone else, it makes life for
> me as distribution vendor easier. And unlike other people in the
> community, I don't think being a TianoCore+ACPI messiah is any helpful
> for that goal.

Alex - that's exactly my point. UEFI is currently planned as the default
firmware on all QorIQ-LS ARMv8 SoCs for supporting distros. It's good to have a
u-boot based solution for SoCs which don't support UEFI, but having both supported to boot distros 
causes confusion to the end user (IMHO), as the capabilities would vary drastically.

Regarding adding support for run-time variable/services, we can always port
everything over from the UEFI specifications - ACPI, run-time variable/services
into u-boot. I think it's a great alternative on SoCs which don't have UEFI support available.

But LS2080A and friends (LS1043A) already have UEFI support available and support
distros like CentOS to be installed and boot'ed. So, these SoCs would not require
an equivalent u-boot + EFI_Application like environment to boot distro.

Regards,
Bhupesh