On Sat, Oct 31, 2026 at 08:54:54AM +0000, Simon Glass wrote: > Hi, > > On Mon, 19 Oct 2026 at 19:19, Tom Rini <[email protected]> wrote: > > > > On Mon, Oct 19, 2026 at 08:57:41AM -0400, Simon Glass wrote: > > > Hi Tom, > > > > > > Tom Rini <[email protected]> wrote: > > > > > > > But then we would need to provide the whole device tree, yes? I think > > > > this ends up being a tricky case because we're on QEMU for this. We're > > > > just checking the signatures on later loaded FIT images. Maybe the > > > > series that adds SPL to QEMU could be helpful here, since we do have a > > > > normal path there for applying an overlay to a device tree, I would > > > > swear... > > > > > > Agreed, a whole DT is the wrong direction here: U-Boot cannot know > > > QEMU's runtime shape (memory, CPUs, devices from -device) so it must > > > keep using QEMU's DT at runtime. > > > > > > The merge code in patch 1 is already doing the right thing in > > > principle: take a small built-in DT that only carries the signature > > > nodes and merge it into QEMU's live DT. The remaining gap is just that > > > OF_OMIT_DTB=y means no built-in DT ever reaches the binary, so the > > > merge is a no-op by default. > > > > > > So I think the fix is to arrange for a tiny signature-only DT (e.g. > > > generated by binman from the keys, like the normal vboot flow) to be > > > embedded when FIT_SIGNATURE is on, and leave OF_HAS_PRIOR_STAGE alone. > > > An overlay fragment would work equally well and is probably cleaner, > > > since the intent really is 'apply these extra nodes on top of what the > > > prior stage gave us'. A test under test/py/tests covering the merge, > > > perhaps using sandbox or the SPL-on-QEMU path, would catch future > > > regressions where the merge silently early-exits again. > > > > So as I kinda thought, we're in a funny spot here, because it's QEMU. > > And so yes, going the overlay fragment path sounds like the right way > > forward because that also should match what real hardware would look > > like (we're given the tree by some prior stage and need to augment it). > > We might need a little re-tweaking of the Kconfig logic (some new flag > > to say we need to build overlays, and not fall back to "and now we try > > and build a dtb for the board") is probably required. > > > > > I can't help mention (again) that this would all be a lot simpler with: > > > > > > https://patchew.org/QEMU/[email protected]/ > > > > > > ...if we were able to explain how U-Boot's use of the devicetree > > > includes configuration information. > >https://patchew.org/QEMU/[email protected]/ > > And I can't help mention (again) how unhelpful it is to bring up ideas > > that were rejected for good reason. > > This prompted me to take another look at the thread from 5 years ago > [1] - it's been a long time! The objection in the end was basically > this: > > 'My take is that this is u-boot doing weird custom things with the DTB > that aren't "describe the hardware". You should be able to boot u-boot > by putting those custom DTB extra things in a separate blob and having > u-boot combine that with the actual DTB when it starts.' > > So this series is responding to that. I have heard a similar opinion > from a few others too, but that doesn't mean it is correct, or even > then, that projects should not try to accomodate each other's > differences. At bottom it comes back to the 'just describe the > hardware and refuse everything else' thing which comes up from time to > time, but that is not how U-Boot works. For good reason! > > Perhaps more bindings in dt-schema would help? I see that bootph is > pretty common in Linux now. Would adding verified boot's public-key > schema to dt-schema would make sense? > > One point raised in that thread was that allowing users to modify the > FDT using the QEMU cmdline is a recipe for breakages and user > confusion. That seems like a reasonable concern to me, although of > course in practice it isn't any different from having U-Boot do the > merge.
I wish that when you're told No, you would accept that and move on, and stop bringing up or just implementing stuff that's been rejected. U-Boot doesn't "need" something when you immediately follow up and note that the problem can be solved in a way that doesn't change upstream, either. Looking at that thread again, yes, you're wrong. My current reaction is that if you had gone with adding overlay support, which you explicitly call out not doing, maybe that would have been accepted and would have solved this problem. -- Tom
signature.asc
Description: PGP signature
