On Thu, Oct 15, 2026 at 03:55:03PM +0200, Ludwig Nussel wrote:
> On 10/13/26 17:01, Tom Rini wrote:
> > On Tue, Oct 13, 2026 at 08:47:48AM +0200, Ludwig Nussel wrote:
> > > On 10/12/26 16:44, Tom Rini wrote:
> > > > On Mon, Oct 12, 2026 at 02:26:55PM +0200, Ludwig Nussel wrote:
> > > > > [...]
> > > > >
> > > > > When I developed the patch OF_OMIT_DTB was "default". 68e65953400
> > > > > changed it
> > > > > to "def_bool". Would something like this make sense as a fix?
> > > > >
> > > > > --- a/dts/Kconfig
> > > > > +++ b/dts/Kconfig
> > > > > @@ -213,7 +213,8 @@ config OF_HAS_PRIOR_STAGE
> > > > > disabled in the board's defconfig file.
> > > > >
> > > > > config OF_OMIT_DTB
> > > > > - def_bool y if OF_HAS_PRIOR_STAGE && !BINMAN
> > > > > + def_bool y if OF_HAS_PRIOR_STAGE && !BINMAN && !ARCH_QEMU
> > > > > + def_bool n if ARCH_QEMU
> > > > > help
> > > > > As a special case, avoid writing a device tree file
> > > > > u-boot.dtb
> > > > > when
> > > > > building. Also don't include that file in u-boot.bin
> > > >
> > > > No, because commit 68e65953400 was fixing how the symbol had been
> > > > misused over time. I need to understand a bit better about what you're
> > > > doing here next, so we can see the path forward. In commit 99df7f471551
> > > > ("arm: Drop unused dts files") we dropped the empty dts file that was
> > > > being used to generate the dtb OF_OMIT_DTB required.
> > >
> > > Qemu provides it's own dt at a known address. Normally u-boot would just
> > > use
> > > that. The purpose of the series is to make u-boot check fit config
> > > signatures though. In order to check signatures, u-boot needs the trusted
> > > public keys in the dt. So in this scenario we need to merge u-boot's dt
> > > with
> > > qemu's.
> > >
> > > Maybe a better fix would be to remove OF_HAS_PRIOR_STAGE from ARCH_QEMU?
> > > Looks like this atm:
> > >
> > > config ARCH_QEMU:
> > > ...
> > > imply OF_HAS_PRIOR_STAGE if !TARGET_QEMU_ARM_SBSA
> >
> > 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
>
> I am not deep enough into the topic oversee all consequences. Something like
> this maybe?
>
> - imply OF_HAS_PRIOR_STAGE if !TARGET_QEMU_ARM_SBSA
>
> + imply OF_BOARD if !TARGET_QEMU_ARM_SBSA
>
> How does one get u-boot signkeys to work on real hardware that provides a
> device tree? Or is this just not a thing?It would either be in the device tree we're passed (OF_HAS_PRIOR_STAGE) or bundled. QEMU is in the funny spot where it comes from the prior stage. So that I'm clearer on the use case, is this about testing, or about using QEMU with U-Boot in some other case? -- Tom
signature.asc
Description: PGP signature
