Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]

On Fri, Oct 29, 2021 at 01:20:52PM +0300, Ilias Apalodimas wrote:
> Hi Simon,
> 
> [...]
> 
> > > >
> > > > Why me? Perhaps Linaro could take this on instead of working in a
> > > > separate tool and domain? You guys could really pull things together
> > > > and reduce the fragmentation, if you took it on.
> > > >
> > > > Honestly it is hard enough to even get Linaro people to write a test
> > > > for code they have written. What gives?
> > >
> > > That's completely inaccurate.  We've added selftests for *every*
> > > single feature we've sent for EFI up to now.  Functionality wise the
> > > past 2 years we've added
> > > - EFI variables
> > > - EFI secure boot
> > > - capsule updates
> > > - initrd loading
> > > - efi TCG protocol
> > > - ESRT tables
> > > - RNG protocol
> > >
> > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests
> > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi()
> > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName()
> > > ce62b0f8f45f1 test/py: Fix efidebug related tests
> > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule
> > > de489d82e3189 test: test the ESRT creation
> > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test
> > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates
> > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs
> > >
> > > and I am pretty sure I am forgetting more on functionality and selftests.
> > >
> > > So basically we've either contributed  new selftests for *everything*
> > > we've or fixed the existing ones.  The only thing that's not merged is
> > > the TCG selftests which are on upstream review.
> > 
> > Er, I didn't say or mean that no tests were written, just that there
> > is too much push-back on it. Heinrich put a huge amount of effort into
> 
> There's no pushback at all, apart from the TPM one. (and for a very good
> reason I've explained over and over again).   In fact we add the sefltests 
> as part of our patchsets. 

And, for that set of TPM things, I agree with NOT making sandbox the
requirement there.  As QEMU is able to provide a TPM that will see real
world usage, that's what we need to validate against primarily.

> > the tests and basically created a strong base for it. Congrats and
> > huge kudos to him. As to Linaro, no offence intended, and it is great
> > that all these tests have been added. Thank you for your efforts and
> > it is very helpful. But I think you miss my point. Or perhaps you
> > don't even agree with it? I sent an email about this on one patch just
> > a day or two ago.
> 
> I guess you mean [1].  I've lost count of how many times I responded to
> this. Threads [2], [3] and [4] are just a few examples,  so I just got
> tired or replying the same thing over and over.
> 
> So bottom line, we are contributing selftests as always, we just don't agree 
> with the way *you* want this specific TPM test, trying to force us into sandbox.
> So instead of respecting what we have (which btw is acceptable from u-boot's 
> perspective and cleans up a lot of the TPM crud along the way), you went ahead
> making misleading statements on the selftests we contribute, in general.  What's
> even more annoying is that, as I showed you, we pretty much add a selftest
> for *every* feature we add.  Excellent ...  that's certainly ... encouraging ... and
> very productive.
> 
> > 
> > As to the leadership side (my bigger point), Linaro is leading us all
> > down this fragmented path, with TF-A, FIP, more and more binaries and
> > larger firmware diagrams. Or do you disagree with that too?
> > 
> 
> Of course I disagree.  People decided not to use SPL for their own reasons.
> I am certainly not qualified to answer why Arm choose to do that, but it seems
> to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure
> U-Boot is compatible and remains the de-facto choice for embedded boot
> loaders playing nicely with all the new FSBLs come up with.  If you
> cosinder SPL and U-Boot the center of the known universe, we certainly view
> things differently.  FWIW it's *our* work mostly that made U-Boot SystemReady
> compliant, which is something Arm pushes for [5].

Let me say for the record that I am appreciative of the fact the Linaro
has been putting so much effort in to U-Boot, both in terms of tests and
also in general SystemReady compliance work.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]