Hi Peter, On Tue, Aug 25, 2026 at 5:27 PM Peter Maydell <[email protected]> wrote: > > On Tue, 25 Aug 2026 at 05:20, Alistair <[email protected]> wrote: > > > > On Sat, 2026-06-27 at 23:42 +0800, Bin Meng wrote: > > > Real-board ZCU102 DTBs describe the UART, SDHCI and GQSPI nodes > > > in terms of ZynqMP PM firmware providers for clocks, resets, power > > > domains and pin control. QEMU does not model those runtime firmware > > > providers, so using such a DTB with -kernel currently requires users > > > to edit the DTB before Linux can probe the boot-critical devices. > > > > + zcu102_fdt_fixup_clocks(fdt, "/axi/serial@ff000000", > > > pss_ref_clk); > > > + zcu102_fdt_fixup_clocks(fdt, "/axi/serial@ff010000", > > > pss_ref_clk); > > > + zcu102_fdt_fixup_clocks(fdt, "/axi/mmc@ff170000", pss_ref_clk); > > > + zcu102_fdt_fixup_clocks(fdt, "/axi/spi@ff0f0000", pss_ref_clk); > > > > I don't think this is something QEMU should be doing. Modifying the DTB > > on the fly just seems very brittle and prone to breakage and confusion. > > It is something we do already in some limited cases on other boards where > we don't model all the hardware, for example in imx8mm_evk_modify_dtb() > we nop out some nodes and make some other minor tweaks. I'm not a > huge fan of having to do that but it's a pragmatic thing where we > don't have models of the hardware the kernel is expecting. > This patch does seem to make slightly more extensive edits than that, > though. >
This is the minimal dtb patch that could make direct Linux kernel booting succeed with a working UART. The SD and QSPI parts were added for testing other QEMU models (hw/sd/sd.c and hw/block/m25p80.c) too and I think that's useful. Current ZCU102 documentation does not explain how to make Linux kernel boot on QEMU thus we need a solution. Modeling the complete firmware boot is definitely a way that could avoid modifying the dtb, but that involves massive work and at this point I don't want to proceed with that way. Regards, Bin
