On Mon, Oct 19, 2026 at 02:02:25PM +0200, Ludwig Nussel wrote:
> On 10/15/26 17:20, Tom Rini wrote:
> > 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?
>
> I'm using qemu with u-boot for development of course but the main use case
> is testing the entire OS in pipelines. The less software layers need an
> actual hardware the better after all.Right, OK. And it's something where QEMU is good-enough to the real hardware flow that you get useful information, very neat. I think with what I suggested in the other email just now, there should be a path forward for what you want to be able to test. -- Tom
signature.asc
Description: PGP signature
