linux: drop flash@0 from the virt64 guest DT - #327
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The QEMU CFI pflash at address 0 belongs to the firmware, not to the guest.
AVZ's
agency_ipamapfor virt64 (avz/arch/arm64/virt64/include/mach/ipamap.h) maps GICD, GICC→GICV, v2m, the peripherals from0x08050000, the low PCIe MMIO window and the ECAM — nothing below0x08000000. The region this node describes (0x0-0x08000000) is simply not backed for the guest.The node is not inert. Unlike
DRM_PL111, whichvirt64_soo_defconfigleaves off,CONFIG_MTD/MTD_CFI/MTD_PHYSMAP/MTD_PHYSMAP_OFare enabled in both guest configs, so the guest really does probe it. Measured on virt64 under AVZ with the node present:Harmless — the probe fails gracefully, no fault, no panic, the boot carries on to userspace — 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 anywhere, and the only mention of MTD in the tree is
mtd-blacklist = "0 1 2 3 4 5 6"inswupdate.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 — the display is deliberately untouched
This changes only
flash@0.clcd@8800000and itspanelstay exactly as they are: they are the DT half of the/dev/fb0work (interrupt SPI 10, plus thepanel-dpi+port/endpointpair thatpl111_modeset_initrequires), and removing them would break the graphical display for anyone building the guest withvirt64_defconfig.Verification
dtc.clcd/panelconfirmed still present after the change.Note, unrelated to this change
0023-virt64_guest.dts.patchsits in the same directory but is not in the series —0001-linux-6.12-r0-patches.increferences only0002-. It looks like a leftover from an updiff duplication and gives the misleading impression of being applied. Worth removing separately.🤖 Generated with Claude Code
https://claude.ai/code/session_01LQQDPHFAGVU67bEXrdboRS