Hi Tom, On Wed, 28 May 2025 at 16:05, Tom Rini <tr...@konsulko.com> wrote: > > On Wed, May 28, 2025 at 03:32:08PM +0100, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 28 May 2025 at 15:12, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Wed, May 28, 2025 at 08:35:37AM +0100, Simon Glass wrote: > > > > Hi Ilias, > > > > > > > > On Tue, 27 May 2025 at 10:20, Ilias Apalodimas > > > > <ilias.apalodi...@linaro.org> wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Tue, 27 May 2025 at 11:20, Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > > > Hi Ilias, > > > > > > > > > > > > On Sat, 24 May 2025 at 19:13, Ilias Apalodimas > > > > > > <ilias.apalodi...@linaro.org> wrote: > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Sat, 24 May 2025 at 15:09, Simon Glass <s...@chromium.org> > > > > > > > wrote: > > > > > > > > > > > > > > > > A previously rejected patch to move the EFI public cerificate > > > > > > > > out of the > > > > > > > > devicetree has recently been applied. This series reverts the > > > > > > > > change, > > > > > > > > pending further discussion as to why it was accepted. > > > > > > > > > > > > > > I spent a good amount of time, writing the commit message an > > > > > > > explaining why this patch was sent > > > > > > > > > > > > Yes, that is [1] and I did read it carefully before sending my > > > > > > series. > > > > > > > > > > > > From my POV there are two things wrong there: > > > > > > - The signature is not an internal U-Boot ABI. > > > > > > > > > > It is, as it is for every firmware that builds out there. EDKII does > > > > > the same thing. > > > > > > > > I mean that in U-Boot's case it is a published and documented > > > > interface, or was until a few weeks ago. > > > > > > > > > > > > > > > It is how U-Boot works, > > > > > > so if a build systems wants to inject a key it should use that > > > > > > mechanism, not add a new mechanism into U-Boot's build system. If it > > > > > > would help to have some documentation somewhere which says this, I > > > > > > would be happy to send a patch to add something > > > > > > - QEMU is blocked from accepting devicetree additions due to another > > > > > > Linaro employee's refusal to accept a patch[2] > > > > > > > > > > It's not blocked. It has been NAK'ed and IMHO for a very good reason. > > > > > > > > > > > > > > > > > > (which btw wasn't 'rejected', you > > > > > > > forcefully reverted it back then with no agreements from anyone) > > > > > > > > > > > > The original series [4] was applied (I believe accidentally) against > > > > > > my objections. Heinrich pulled the revert [5]. I went ahead and did > > > > > > the QEMU patch, to help with your issue*. > > > > > > > > > > Heinrich applied the patches initially, and you send the revert, that > > > > > none of the patch reviewers ack'ed. > > > > > You reasoning back then is that the RO functionality was moot, because > > > > > we didn't have it. It's here now. > > > > > > > > That was one aspect of my reasoning, but of course we can copy the > > > > signature into protected memory, make the devicetree readonly, etc. if > > > > desired. > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > why we prefer to do it this way. tl;dr early boot loaders that > > > > > > > pass as > > > > > > > a DT is a problem now. > > > > > > > If there's a good reason to revert it, please explain it on the > > > > > > > commit message > > > > > > > > > > > > The reasoning hasn't changed from the discussion three years ago - > > > > > > please see [4]. There's also lots of discussion on your original > > > > > > series and my revert, e.g the cover letter. A highly relevant part > > > > > > of > > > > > > this is that devicetree is where config should be stored, so the > > > > > > build > > > > > > system has control over what is placed there. > > > > > > > > > > > > But in any case, it isn't right to send the series again, under a > > > > > > different name, e.g. not mentioning device tree. > > > > > > > > > > > > [..] > > > > > > > > > > > > Regards, > > > > > > Simon > > > > > > > > > > > > * The QEMU patch is still outstanding after three years. Could you > > > > > > please talk to Peter Maydell and see if you can get this resolved? I > > > > > > have sent it twice since, most recently in April [7] but there was > > > > > > not > > > > > > even a reply. > > > > > > > > > > Because they NAK'ed it a few years ago, and aren't willing to take it. > > > > > I don't think there's anything to discuss and for the record I agree > > > > > with the QEMU maintainers on this. > > > > > > > > Yes, I agree that discussion is unlikely to be fruitful. My point > > > > remains though that your series should not have been applied, given > > > > the previous discussion. > > > > > > > > This thread and the links should provide context for the future, if > > > > needed. > > > > > > > > One other thing I forgot for the record is that [8] and [9] are only > > > > needed due to Linaro's refusal to accept the QEMU patch or propose a > > ^^^^^ > > > > > convenient alternative. > > > > > > > > For now I've applied this series to my tree. > > > > > > You can do whatever you like in your downstream tree, but please stop > > > implying that "Linaro" is in charge of QEMU. They very much are not and > > > I don't want other communities to think that you and your attitude > > > represent the U-Boot project. > > > > That wasn't my intention at all. Where are you reading that? > > > > I am just pointing out that Linaro rejected [2]. Ilias (also at > > Linaro) has stated that he agreed with the decision. Do you agree with > > my analysis here? > > And then your analysis here are where it sure sounds like you blame > Linaro for what the QEMU project is doing. I am 100% certain that if > Ilias and Peter left Linaro today, tomorrow they would still reject your > changes on technical, not implicitly nefarious business, grounds.
Not the QEMU project, just the ARM maintainer, who I believe is Peter Maydell who I believe works at Linaro. I think it is important to call out this sort of thing, so people know where the roadblocks are for U-Boot in the firmware world. This is certainly one of them. Ilias, re 'obvious violation of the DT spec', DT schema has an /options node. Linux has quite a lot of stuff which is configuration rather than hardware - e.g. see Documentation/devicetree/bindings/mtd/partitions/partition.yaml We've discussed this a lot so I'm not expecting to change any minds here, but I am firmly of the view that U-Boot uses devicetree for its configuration and it needs to stay that way. BTW I just read [2] again. I'm even more convinced that QEMU needs this feature and surprised that Peter took the line he did. It would be an interesting exercise to send a patch adding some bootph tags to QEMU :-) Regards, Simon > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20250401112729.2181793-1-ilias.apalodi...@linaro.org/ > > > > > > [2] > > > > > > https://patchwork.kernel.org/project/qemu-devel/patch/20210926183410.256484-1-...@chromium.org/#24481799 > > > > > > [3] > > > > > > https://lore.kernel.org/u-boot/CAPnjgZ2uM=n8Qo-a=DUkx5VW5Bzp5Xy8=wgmrw8esqubk00...@mail.gmail.com/ > > > > > > [4] > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=253693&state=*&archive=both > > > > > > [5] > > > > > > https://patchwork.ozlabs.org/project/uboot/cover/20210802144431.2396678-1-...@chromium.org/ > > > > > > [6] > > > > > > https://patchwork.kernel.org/project/qemu-devel/patch/20250405191352.2597585-1-...@chromium.org/ > > > > > > [7] > > > > > > https://patchwork.kernel.org/project/qemu-devel/patch/20250405191352.2597585-1-...@chromium.org/ > > > > [8] > > > > https://lore.kernel.org/u-boot/20250510134253.1581164-2-...@chromium.org/ > > > > [9] https://docs.u-boot.org/en/latest/develop/devicetree/dt_qemu.html > > > > > > -- > > > Tom > > -- > Tom
