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

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

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.
> >
> > > 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].
> >
> > > I'm sorry if you find this a bit sharp.
> >
> > Which part? The first one wrt to selftests is not sharp.  It's
> > manipulative and utterly unacceptable for me, not to mention entirely
> > fabricated.
> >
> > The latter on bootloading fragmentation, I am always happy to discuss.
> 
> My comment was about the push-back I feel I have received when
> requesting tests. It was a poor choice of words since it suggests this
> is an ongoing problem when in fact many tests have been written. So I
> would like to withdraw that and I am sorry for saying that and for
> upsetting you. I certainly agree that Linaro has written lots of tests
> and this is great. Thank you to you and Linaro for that. The business
> of how the tests are written can be handled in other threads.

Thanks, I appreciate this.  Let's just forget this ever happened.  The discussions are
usually constructive and I am happy with the general progress, despite
of the differences of opinion.

> 
> >
> > > But someone needs to be
> > > pointing these things out. I don't know who else is doing so. ARM
> > > firmware has got noticeably more complicated and fragmented in the
> > > last five years, hasn't it? What can Linaro do to address that? I am
> > > very happy to help and provide part of the solution, but it needs a
> > > shared vision.
> >
> > There's a TF-A mailing list, we can certainly engage there and try to align
> > our ideas/designs.
> >
> > >
> > > It's not even just a Linaro/ARM problem. On the x86 side it is fast
> > > becoming a living nightmare.
> > >
> > > Perhaps the problem here is just the pandemic response and the
> > > inability for people to get into a room and brainstorm / collaborate /
> > > hack on ideas? I know you have made big efforts to engage, Ilias. We
> > > have spoken many times and I'm sure f2f would be easier.
> > >
> >
> >
> >
> > >
> > > It's not even just a Linaro/ARM problem. On the x86 side it is fast
> > > becoming a living nightmare.
> > >
> > > Perhaps the problem here is just the pandemic response and the
> > > inability for people to get into a room and brainstorm / collaborate /
> > > hack on ideas? I know you have made big efforts to engage, Ilias. We
> > > have spoken many times and I'm sure f2f would be easier.
> >
> > Maybe,  hopefully travelling will restart soon.
> 
> I think the whole issue in this thread comes down to a matter of alignment.
> 
> As you can tell, I am frustrated with where things are headed and hope
> we can course-correct at some point.

This is a matter of perspective to me.  I've accepted the fact that
firmware gets more complex.  Whether I personally like it or not is a
different story.  One thing  that's clear to me though is that we either
have to adapt, or slowly become irrelevant.

Thanks
/Ilias
> 
> Regards,
> Simon
> 
> 
> >
> > [1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz7pFA2g@mail.gmail.com/
> > [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/
> > [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mpz9pAgw@mail.gmail.com/
> > [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/
> > [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.140829686.578781084.1635493248-857780164.1580291819
> >
> > Regards
> > /Ilias