Repository navigation
arm: dts: mediatek: mt6589-lenovo-blade: move ramoops into 1 MiB of DRAM - #87
Conversation
|
looks good |
The SoC dtsi puts ramoops in 7 KiB of on-chip SRAM with 1 KiB records. That cannot hold a single oops: every panic ended with "pstore: backend (ramoops) writing error (-28)", and the record kept only the first lines of the trace. Reserve 1 MiB of DRAM right below LK's framebuffer instead (0xbf500000, next to framebuffer_reserved): 32 KiB dump records, 256 KiB of console, and ECC to tell a damaged record. LK and the kernel leave this memory alone across a warm reset. Tested on the Lenovo B8000-H (MT8389): after a forced panic and the watchdog reboot, /sys/fs/pstore held the whole oops. Not checked on the B8000-F or B6000, whose LK may use this range differently. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Mikhail Nevskiy <trudenboy0@gmail.com>
6531e35 to
b26835a
Compare
fmm |
|
The pstore scans every record slot at probe and checks the ECC of whatever was in DRAM before; a slot that has never held a record reads as garbage and is reported as uncorrectable. The messages stop once the region has valid records. Checked on the B8000-H with the same node (1 MiB @ 0xbf500000, 32 KiB records, ECC 16): after a forced panic |
The SoC dtsi puts ramoops in 7 KiB of on-chip SRAM with 1 KiB records. That cannot hold one oops: our panics all ended with
pstore: backend (ramoops) writing error (-28), with only the first lines of the trace stored.This moves ramoops, for the blade boards, into 1 MiB of DRAM right below LK's framebuffer:
0xbf500000, next toframebuffer_reserved;The SoC node is deleted in
mt6589-lenovo-blade.dtsi, so other MT6589 boards keep theirs.Tested: Lenovo B8000-H (MT8389), our kernel with the same node. After a forced panic and the watchdog reboot,
/sys/fs/pstoreheld the whole oops. Where each record lives and when to clear it:docs/crash-evidence.md(Russian).Not checked: the B8000-F and B6000. Their LK may use this range differently. The node sits in the shared blade dtsi only because
framebuffer_reservedis there too.In daily use on our tree (blade/v7.1 @ 7dd2454 + our patches) since October; rebased and build-tested on current blade/v7.1, not yet booted on this base.
Assisted-by: Claude:claude-opus-5-5