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

Tue Nov 2 15:53:31 CET 2021

Hi Ilias,

On Fri, 29 Oct 2021 at 04:20, Ilias Apalodimas
<ilias.apalodimas at linaro.org> 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.
>
> > 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.

>
> > 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.

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