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. And I can't help mention (again) how unhelpful it is to bring up ideas that were rejected for good reason. -- Tom
signature.asc
Description: PGP signature
