In our previous discussion, Why devmem2 is a Loaded Gun, we explored how mmreg prevents RCU stalls by acting as a Software Address Decoder. By validating addresses against /proc/iomem and the Device Tree before touching the bus, mmreg ensures that you aren’t firing a “Read/Write” request into a total vacuum.
This solves 99% of accidental system hangs. But if you are a developer working on high-performance SoCs like the Zynq UltraScale+ MPSoC, there is a final 1% that is even more deceptive: The “Zombie” Hardware State.
A “Zombie” state occurs when the kernel’s “blueprint” (the Device Tree) says a device is present and initialized, but the physical hardware gate remains locked. In these cases, even mmreg’s validation might pass, but the resulting bus access could still trigger a hardware stall. To achieve greater than 99% safety, we must understand the “Gatekeepers” that sit between the Kernel Resource Map and the physical AXI wires.
The Illusion of Presence: When Blueprints Lie
mmreg is brilliant because it provides Informed Consent. It checks if the kernel has “claimed” the memory range. However, the Linux kernel is an optimistic bookkeeper. When a Device Tree Overlay (DTBO) is loaded, the kernel updates its Resource Map immediately. It assumes that if the driver is probed, the hardware is alive.
But in the world of FPGAs and complex Power Domains, “Registered” does not mean “Responsive.”
The Gatekeeper of Logic: The DONE Bit
The most common “Zombie” state happens right after an FPGA reconfiguration. The Linux fpga_manager might report a status of operating, and mmreg will see the associated address ranges in /sys/bus/platform/devices/.
However, if the bitstream was corrupted or had a clock-domain mismatch, the FPGA’s internal DONE signal might never have toggled. The kernel thinks the PL (Programmable Logic) is ready, but the AXI interconnect inside the PL is still in reset.
The Gatekeeper of the Bridge: PS-PL Isolation
The ZynqMP architecture features physical isolation gates between the Processor System (PS) and the Programmable Logic (PL). These gates are designed to protect the system from glitches during power-up.
Usually, the First Stage Bootloader (FSBL) or the FPGA manager handles these. But if a developer manually resets the PL or a power-management event occurs, these gates can “slam shut” without the kernel’s Resource Map being updated.
To the kernel (and thus to mmreg), the device at 0xA0000000 is still “Legit.” But the physical bridge will swallow the AXI request and never return a response.
The Generic Safety Check: Clock Gating
Unlike vendor-specific isolation registers, Clock Validation is a generic Linux kernel concept that can be integrated into mmreg natively. In modern SoCs, the kernel may gate the clock to an IP core to save power if no active driver has explicitly requested it.
If you use mmreg to probe a register on a gated clock domain, the CPU enters the Absolute Deadlock. The AXI logic in the peripheral literally cannot toggle its handshake signals without a running clock.
Preflight checks
UIO and DTS overlays
If you’re using custom overlays, ensure your Device Tree overlay is correctly applied. You can inspect loaded overlays via
dmesg | grep fpgaFPGA Status
This is a special case only valid for FPGA based SoCs.
The best course of action is to probe the internal status registers of that Processor which are defined for status of FPGA but available in PS (Processor System).
For example, let’s look at the pcap_status register as defined in UG1087 which deals with Zynq UltraScale+.
Some embedded operating systems may have a dedicated fpga_manager, one can also check its status before proceeding to probe newly created memory mapped Addresses.
cat /sys/class/fpga_manager/fpga0/stateIf it returns operating, all is good. If not, it is a clear indication that the bitstream is not loaded and the FPGA is not configured.
Xilinx provides Python-based utility libraries called xmutil and fpgautil, which can also be used to get more properties of the FPGA. There might be different tools from different vendors.
sudo xmutil platformstats
# Provides performance metrics like CPU/RAM usage, temperatures, and power.Other checks that one may perform:
- Power Domain Status: Many SoCs (including ZynqMP) have fine-grained power domains controlled by PMU firmware. Even if a device is mapped in the kernel, its domain may be powered down.
cat /sys/devices/platform/firmware/pmu/power/*/status- Reset Controller State: Devices may be held in reset by the SoC’s reset controller.
cat /sys/kernel/debug/reset/summaryChecking Clocks
If you are aware of the name of the clock used for the AXI bus, just grab the summary.
For example, if the intended clock is named pl1_ref:
sudo grep -i "pl1_ref" /sys/kernel/debug/clk/clk_summaryIf the enable count is 0, the clock has not been started yet. Reading and writing on any address related to this clock will surely end in a deadlock. Do check the design, bitstream, and more importantly, the device tree before probing registers.
Informed Consent is Just the Beginning
mmreg has fundamentally changed the safety profile of embedded Linux development and testing. By moving the “Address Decoding” from the blind hardware bus to the informed software kernel, it has effectively removed the “Loaded Gun” from the developer’s hand.
However, a tool is only as good as the information it has. In the “Last Mile” of hardware bring-up, the kernel’s information can be outdated. By combining mmreg with a robust, declarative understanding of hardware gatekeepers—Clocks, Isolation, and Power—developers can finally treat direct memory access as a professional, predictable workflow rather than a gamble.
If the kernel can’t see it, mmreg won’t touch it. But if the hardware isn’t powered or clocked, new validation hooks ensure you never enter the deadlock.