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. Regards, Simon [1] https://patchew.org/QEMU/[email protected]/
