Mihály Snajder

Subject: Fix for eMMC Internal State Deadlock / Power-Loss Recovery Failure on Allwinner (sunxi) platforms (Banana Pi P2 Zero) Hi Armbian and sunxi developers, I would like to share an industrial-grade diagnostic report and a 100% verified solution regarding a severe, reproducible boot deadlock on Allwinner H2+/H3 platforms (specifically tested on Banana Pi P2 Zero) utilizing onboard eMMC. === 1. SYMPTOM === During rigorous power-cycling stress tests (hard power-off during random kernel init/write phases), the system randomly bricks on subsequent boots, showing a "dropping to shell" (initramfs / BusyBox prompt) or failing completely during the U-Boot phase with a non-existent MMC device error. A severe "vicious cycle" (degrading cycle count) was observed: initially, the failure occurred around the 11th cycle. After optimization, it pushed to the 78th/93rd cycle, but eventually dropped down to a catastrophic failure after just 12 cycles, locking the eMMC in an unbootable state. === 2. ROOT CAUSE ANALYSES === We discovered a multi-layered hardware/software deadlock (a conceptual deadlock between the eMMC firmware and the Linux kernel/U-Boot drivers): A) eMMC Internal State Hang: Sudden power loss during write operations forces the eMMC controller's FTL (Flash Translation Layer) into an internal Power Loss Recovery routine upon next boot. It flags this state in its internal NVRAM. B) Aggressive Host Initialization: While the eMMC controller is busy performing its background recovery, the U-Boot and Linux Kernel drivers immediately flood the MMC bus with high-frequency initialization sequences and commands (e.g., trying to shift to high-speed modes like HS200 or DDR at 1.8V). C) Runtime Power Management Interruption: The eMMC controller, overwhelmed by background recovery and high-speed host commands, responds with a timeout. The `sunxi-mmc` driver interprets this timeout as a fatal hardware failure and immediately triggers Runtime PM, disabling the MMC clock (CLK) to save power. D) The Deadlock: Disabling the CLK freezes the eMMC internal microcontroller mid-flight. Without a host clock, the eMMC cannot finish its internal Power Loss Recovery. The corrupt state remains burned into the NVRAM flag. Subsequent cold resets wake up the eMMC with the exact same corrupt flag, trapping the board in an permanent boot hivel. === 3. VERIFIED SOLUTION (320+ Cycles Success) === To break this deadlock, we had to apply a 5-step cross-layer configuration (U-Boot, Device Tree, and Filesystem). After applying these fixes, the device successfully passed a brutal 5-hour stress test, completing 320 consecutive aggressive power-cycles without a single warm-boot or failure. Here is the exact production-ready recipe: 1) Limit eMMC Frequency & Disable High-Speed Modes (DTB) Prevent the kernel from driving the chip into unstable timing states during the sensitive boot phase. Limit the bus to a stable, industrial 52 MHz clock. In the device tree, target the exact eMMC controller node (mmc@1c1f000 for mmc2 on BPi-P2Z): &mmc2 { max-frequency = <52000000>; /delete-property/ mmc-hs200-1_8v; /delete-property/ mmc-ddr-1_8v; }; 2) Disable MMC Runtime Power Management & Enforce Continuous Clock (DTB) Force the host to maintain a constant clock signal on the MMC bus, allowing the eMMC microcontroller to finish its internal recovery routines even if a timeout occurs. &mmc2 { non-removable; keep-power-in-suspend; no-mmc-runtime-pm; status = "okay"; }; 3) Enforce U-Boot Level eMMC Bus Reset and Nagging Clean-up (boot.cmd / boot.scr) Clear the internal state-machine of the eMMC controller *before* U-Boot attempts to read large kernel files from the ext4 root partition. Add these exact lines to the very beginning of your /boot/boot.cmd before compiling it to boot.scr: # Force MMC2 bus reset and NVRAM buffer flush mmc dev 2 mmc rescan # Provide a 2-second silent window for the eMMC FTL to safely finish house-keeping sleep 2 4) Register-Level Hardware Watchdog Activation in U-Boot (boot.cmd / boot.scr) Ensure a hardware-level warm-boot safety net in case the eMMC hangs during early bootloader stages before the kernel can initialize its own watchdog. Add this at the top of /boot/boot.cmd: # Enable Allwinner H3 belső Watchdog (16-second threshold) mw.l 0x01c20c90 0x00000000 mw.l 0x01c20c94 0x00000b03 5) Mitigate Write Stress on Filesystem (/etc/fstab) Reduce the probability of power-loss catching the eMMC during a critical metadata/journal write phase. Modify the root partition mount options in /etc/fstab: UUID=your-uuid-here / ext4 defaults,noatime,nodiratime,commit=60,barrier=0 0 1 === CONCLUSION === By combining a U-Boot level `mmc rescan` + `sleep 2` (which clears the FTL buffers) with the Device Tree `no-mmc-runtime-pm` (which guarantees uninterrupted host clock), we permanently fixed this elusive hardware/software race condition. I highly recommend incorporating these MMC stability flags into the standard Armbian dts targets for Allwinner boards deployed in mission-critical or unstable power environments. Best regards, mihint