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.
cu
Ludwig
--
Ludwig Nussel
Siemens AG
www.siemens.com
