[U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Tom Rini]

On Wed, Aug 30, 2017 at 04:16:34AM +0800, Simon Glass wrote:
> Hi,
> 
> On 29 August 2017 at 22:16, Rob Clark <robdclark at gmail.com> wrote:
> > On Tue, Aug 29, 2017 at 8:57 AM, Leif Lindholm <leif.lindholm at linaro.org> wrote:
> >> On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:
> >>> > > > I would add command
> >>> > > > bootefi selftest.efi
> >>> > > > to run the tests and provide the python wrapper code to add it to the
> >>> > > > test suite.
> >>> > >
> >>> > > I think that's a great idea, yes.
> >>> > I wonder how far we are from running UEFI tests (either the official
> >>> > ones, or I seem to remember hearing about some other test suite which
> >>> > didn't require UEFI shell)?
> >>>
> >>> Let's ask Leif, Ard and Dong.
> >>>
> >>> The official test suite definitely needs the UEFI Shell. Is the suite
> >>> publicly available by now?
> >>
> >> In binary form, you can access it already from the links on
> >> http://uefi.org/testtools
> >>
> >> Yes, 2.5 is latest release. No this is not a restriction ... the SCT
> >> releases have been lagging the specification releases a fair bit.
> >>
> >> The 2.5a package contains AARCH64, IA32 and X64 support (not ARM).
> >> Not that it couldn't contain ARM, it just hasn't been packaged.
> >>
> >>> > That seems more useful long term than re-inventing comprehensive UEFI
> >>> > test suite.  (Also, beyond just running shim/fallback/grub, I don't
> >>> > really have time to invent new tests for the stack of efi_loader
> >>> > patches I have.)
> >>>
> >>> Yes and no - it depends on the availability of the official suite :/.
> >>
> >> UEFI SCT is not yet open source/free software. Obviously, this is
> >> something Linaro has been lobbying for since day one of our
> >> involvement. There used to be little understanding for this, but that
> >> attitude has shifted substantially.
> >
> > So, if/until UEFI SCT is not an option, what about:
> >
> >   https://01.org/linux-uefi-validation
> >
> > (thx to pjones for pointing that out to me)
> 
> Well in any case I'm not looking for a large functional test suite at
> this stage. It certainly could be useful, but not as a replacement for
> unit tests. The latter is for fast verification (so that everyone can
> run it as part of 'make tests') and easy identification of the
> location of bugs.

I want to chime in here.  Unless we're talking hours of time, if "make
tests" takes 5 minutes to run, but that includes doing some sort of full
validation suite to the relevant EFI code, that seems like a win to me.
And if someone else is responsible for the contents of the tests and we
just have to confirm our expected results, that's an even bigger win.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170901/6b47ad1d/attachment.sig>