From e1b04abb2267e57689ff94ebd3cf47cc78530a30 Mon Sep 17 00:00:00 2001 From: Daniel Rossier Date: Tue, 8 Sep 2026 17:22:27 +0200 Subject: [PATCH] linux: drop flash@0 from the virt64 guest DT MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The QEMU CFI pflash at address 0 belongs to the firmware, not to the guest. AVZ's agency_ipamap for virt64 (avz/arch/arm64/virt64/include/mach/ipamap.h) maps GICD, GICC->GICV, v2m, the peripherals from 0x08050000, the low PCIe MMIO window and the ECAM — nothing below 0x08000000. The region this node describes (0x0-0x08000000) is simply not backed for the guest. The node is not inert: unlike DRM_PL111, which virt64_soo_defconfig leaves off, MTD/CFI/PHYSMAP_OF are enabled in both guest configs, so the guest really does probe it. Measured on virt64 under AVZ with the node present: physmap-flash 0.flash: physmap platform flash device: [mem 0x00000000-0x03ffffff] physmap-flash 0.flash: map_probe failed Harmless — the probe fails gracefully, no fault, no panic, the boot carries on — but it is a failed probe and a misleading log line on every boot, for a device the guest can never reach. Nothing consumes it either: no MTD partitions are declared, and the only mention of MTD anywhere in the tree is `mtd-blacklist = "0 1 2 3 4 5 6"` in swupdate.cfg, which exists precisely to keep the updater away from them. It is a copy artefact: virt64.dts (the bare, non-guest DT) legitimately declares the same node, where address 0 really is the pflash, and the guest DT inherited it. Scope: this touches ONLY flash@0. clcd@8800000 and its panel stay exactly as they are — they are the DT half of the /dev/fb0 work (interrupt SPI 10 plus the panel-dpi + port/endpoint pair that pl111_modeset_init requires), and removing them would break the graphical display for anyone building the guest with virt64_defconfig. Verified by applying the patch standalone and compiling the result with dtc; the behaviour above was measured on an identical AVZ 6.3.1 / Linux 6.12 / virt64 setup. --- .../0002-virt64_guest.dts.patch | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/build/meta-linux/recipes-linux/linux/files/0001-linux-6.12-r0/0002-virt64_guest.dts.patch b/build/meta-linux/recipes-linux/linux/files/0001-linux-6.12-r0/0002-virt64_guest.dts.patch index 25cbdf3b1..4f1da83af 100644 --- a/build/meta-linux/recipes-linux/linux/files/0001-linux-6.12-r0/0002-virt64_guest.dts.patch +++ b/build/meta-linux/recipes-linux/linux/files/0001-linux-6.12-r0/0002-virt64_guest.dts.patch @@ -1,6 +1,6 @@ --- /dev/null 2026-03-20 16:30:38.468300202 +0100 +++ ./arch/arm64/boot/dts/arm/virt64_guest.dts 2026-03-20 16:55:19.220277261 +0100 -@@ -0,0 +1,425 @@ +@@ -0,0 +1,431 @@ +/dts-v1/; + +/ { @@ -324,11 +324,17 @@ + }; + }; + -+ flash@0 { -+ bank-width = <0x04>; -+ reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>; -+ compatible = "cfi-flash"; -+ }; ++ /* ++ * No flash@0 here, on purpose. The QEMU CFI pflash at address 0 ++ * belongs to the firmware, not to the guest: AVZ's agency_ipamap ++ * (arch/arm64/virt64/include/mach/ipamap.h) maps nothing below ++ * 0x08000000, so the region this node describes is simply not ++ * backed for the guest. Measured on virt64/AVZ with the node ++ * present and CONFIG_MTD_PHYSMAP_OF=y: the guest probes it and ++ * gets "physmap-flash 0.flash: map_probe failed" — harmless, but a ++ * failed probe and a misleading log line on every boot. The bare ++ * virt64.dts keeps the node, where address 0 really is the pflash. ++ */ + + cpus { + #size-cells = <0x00>;