> From: Alexander Graf [mailto:ag...@suse.de] > Sent: Monday, May 16, 2016 7:21 AM > To: Bhupesh Sharma <bhupesh.sha...@nxp.com>; Amit Tomer > <amittome...@gmail.com> > Cc: york sun <york....@nxp.com>; u-boot@lists.denx.de; Peter Newton > <peter.new...@nxp.com> > Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot > > > > On 16.05.16 14:04, Bhupesh Sharma wrote: > > > > > >> -----Original Message----- > >> From: Alexander Graf [mailto:ag...@suse.de] > >> Sent: Monday, May 16, 2016 1:09 PM > >> To: Amit Tomer <amittome...@gmail.com> > >> Cc: Bhupesh Sharma <bhupesh.sha...@nxp.com>; york sun > >> <york....@nxp.com>; u-boot@lists.denx.de; Peter Newton > >> <peter.new...@nxp.com> > >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot > >> > >> > >> > >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer <amittome...@gmail.com>: > >>> > >>>> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma > >> <bhupesh.sha...@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.
Agreed, this should not become a U-Boot vs UEFI thread. And just to be sure it is clear to everyone, NXP currently offers both U-Boot and is starting to have UEFI firmware releases also. We are not dropping U-Boot just because we begin to have UEFI. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
