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. > 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. [1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=yssvf17c6ab++-hepo4rc0oeeaez7pf...@mail.gmail.com/ [2] https://lore.kernel.org/u-boot/yvdlvpthuqr8j...@apalos.home/ [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1u1sxlod4lxf+vm+cgthom9mpz9p...@mail.gmail.com/ [4] https://lore.kernel.org/u-boot/yvggrqgvaihvd...@apalos.home/ [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.140829686.578781084.1635493248-857780164.1580291819 Regards /Ilias
