From: Alexander Graf [mailto:agraf@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@suse.de] Sent: Monday, May 16, 2016 1:09 PM To: Amit Tomer amittomer25@gmail.com Cc: Bhupesh Sharma bhupesh.sharma@nxp.com; york sun york.sun@nxp.com; u-boot@lists.denx.de; Peter Newton peter.newton@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@gmail.com:
On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
bhupesh.sharma@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