On Wed, 3 Nov 2021 at 14:41, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote:
> [snip]
> > > 3. Anything else?
> > >
> > > For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties
> > > are present. There is no easy way to fix this.
> >
> > one clean and easy way would be to upstream a Qemu change to merge a
> > supplied overlay to the generated one. This the same idea as applying the
> > NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders do
> > their job properly for U-Boot : setting up the stage as needed.
>
> For the record, I believe Simon did propose this and the QEMU response
> was that no, you should dumpdtb, combine externally and pass that
> directly.
Well, our recommendation really was that the ideal thing would
be "you take the dtb that QEMU passes you at runtime, and at
runtime combine that with whatever extra information you want".
That looks just reasonable this way. Runtime merging may need to be done before control is actually transferred. We have that problem on real board where we need to inject a TPM device for measured boot and it is not énumerable and pluggable. With TFA we have the option to add the TPM description in the NT_FW_CONFIG and merge it at run time.
So we need a « -mergedtb » option for Qemu to have the same capability. This would merge the QEMU generated one with the command line provided.
The dumpdtb option is primarily intended as a debug feature,
so you can have a look at the dtb QEMU created to see why your
OS isn't booting; although you can script stuff up that does
a dumpdtb-modify-pass-to-QEMU that is pretty clunky given the
need to invoke QEMU twice with matching arguments both times.
-- PMM