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. 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. Regards, Simon
