wb7, wb8: pstore/ramoops panic-log persistence (kernel side)

[evgeny-boger]

Persist kernel panic logs across the reboot that follows a crash, on Wiren Board 7 (Allwinner R40/A40i) and Wiren Board 8 (Allwinner H616/T507).

pstore/ramoops keeps a crash log in a reserved DRAM region, but that is only useful if the region address is stable across boots and the reboot preserves DRAM. This adds both, plus a guard against crash loops.

Changes

• Config — enable pstore/ramoops in the WB7 and WB8 kernel configs.
• Device tree — ship a fixed ramoops reserved-memory node at 0x43800000 (1 MiB, no-map) in both SoCs' DTBs, so the region is stable across boots and registers without a kernel command line.
• Driver (drivers/soc/sunxi/wb-ramoops-panic-reset.c):
  • On panic, if ramoops holds unharvested records, arm the SoC watchdog for a ~6 s warm reset that preserves DRAM. The log stays in the region and systemd-pstore harvests it on the next boot.
  • Panic-loop breaker — stamp a breadcrumb in an always-on RTC scratch register (H616 0x0700010c, R40 0x01c20500) that survives a warm reset but is cleared by a full power cycle. On a repeated panic the driver declines to re-arm and lets the board escalate to a power cut, breaking the loop. The breadcrumb is cleared once the system stays up long enough to be considered healthy.
• wbec MFD — recognise the newer EC power-on-reason codes.

Region address

0x43800000 sits below the kernel decompression buffer and above the relocated kernel and small-DRAM fixup loads, is non-power-of-two (dodging DDR size-scan midpoints), and fits a 128 MiB board.

Scope

This is the kernel side. On these boards a wedged controller is recovered by a full power cycle, not just a warm reset; the U-Boot bootloader parks the region across that cycle and the EC performs it, so a log survives even a hard power-cut. Validated end to end on WB7, WB8/LPDDR4 and WB8/DDR3: a crash log survives a real power cycle and is harvested on the next boot.

[evgeny-boger]

Added FIXED-address ramoops DT node + panic-loop-breaker

Two changes on top of the earlier commits:

1. Fixed reserved-memory ramoops node at 0x46000000 in the WB7 (sun8i-r40) and WB8 (sun50i-h616) family DTs (84x/85x, 72x/74x; 73x inherits via 72x). Matches U-Boot WB_RAMOOPS_BASE. This is what gives a kernel-only update value: the node is present regardless of U-Boot, so panic logs survive a warm reset and the kernel harvests them with no shuttle. Hardware-proven: on a 4 GiB WB8 with stock no-fixup U-Boot, ramoops probes at 0x46000000 from the DTB alone, and a panic → warm reset → kernel self-harvest captured 40 KB dmesg + console.

2. Panic-loop-breaker in the notifier. There's no hardware reset-cause latch on these SoCs (watchdog status is interrupt-mode, clears on reset), so I use the RTC general-purpose register documented "for storing power-off information" (GP reg 3, 0x0700010c): it survives a warm reset and is wiped by the EC's hard 5V cycle — exactly the reset-reason signal needed. The panic handler stamps it before arming; a boot that comes up still stamped declines to re-arm (letting the EC watchdog hard-cycle to break the loop); a 60 s healthy-uptime delayed-work clears it so ordinary panics always warm-reset. Bench-confirmed: came back from a panic warm reset; holding off re-arm → healthy, panic warm-reset re-armed at +60 s. H616 only for now (R40 RTC wipe-on-hard-cycle unverified; R40 keeps arming unconditionally).

Also validated: the full 6.18 kernel boots on a real WB8.4.3 (6.8→6.18 jump), ramoops at 0x46000000, and the full shuttle chain (with new U-Boot) reaches poweron_reason=9 + harvest.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EVPkc2g2yir6SGyrED6uNT