[PATCH] arm64: dts: mediatek: mt7986a-bananapi-bpi-r3: add ramoops region

[PATCH] arm64: dts: mediatek: mt7986a-bananapi-bpi-r3: add ramoops region

[Martino Dell'Ambrogio]

Reserve 64 KiB of RAM just below the ARM Trusted Firmware secmon region
(0x42ff0000-0x43000000) for persistent kernel log storage via pstore/ramoops,
allowing post-panic console output and oops dumps to be recovered after a
warm reset. Without it, kernel crash logs on this board are lost when the
SoC reboots.

The carve-out is divided into 8 KiB kmsg records, a 32 KiB rolling console,
8 KiB ftrace, and 8 KiB pmsg, leaving the remainder for the per-record
Reed-Solomon ECC parity (ecc-size=16) which significantly improves dump
readability when the panic path truncates writes mid-record.

The region sits immediately below the ATF block already declared at
0x43000000 in mt7986a.dtsi, so no other reserved-memory child is moved or
resized. BPI-R3 ships with 2 GiB of DRAM starting at 0x40000000, well above
0x43000000, so the region is always within installed memory.

For the carve-out to actually preserve content across a reset, the boot
loader must avoid touching this region on warm reset; on standard BPI-R3
boards with the stock OpenWrt U-Boot fork this already holds.

Signed-off-by: Martino Dell'Ambrogio <tillo@tillo.ch>
---
 .../boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts    | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
index 19f538d..31ee189 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
@@ -140,6 +140,18 @@ sfp2: sfp-2 {
 	};
 };
 
+&{/reserved-memory} {
+	ramoops@42ff0000 {
+		compatible = "ramoops";
+		reg = <0 0x42ff0000 0 0x10000>;
+		record-size = <0x2000>;
+		console-size = <0x8000>;
+		ftrace-size = <0x2000>;
+		pmsg-size = <0x2000>;
+		ecc-size = <16>;
+	};
+};
+
 &cpu_thermal {
 	cooling-maps {
 		map-cpu-active-high {
-- 
2.47.3

Re: [PATCH] arm64: dts: mediatek: mt7986a-bananapi-bpi-r3: add ramoops region

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `ramoops` reserved-memory node is missing the `no-map` property, leading to initialization failure and preventing the driver from loading.
- [Low] The commit message mathematically miscalculates the memory layout and fundamentally misrepresents how `ramoops` allocates space for ECC parity.
--

commit b448b96b8ca8171732f9a19b1cb33fbb0c73f34d
Author: Martino Dell'Ambrogio <tillo@tillo.ch>

arm64: dts: mediatek: mt7986a-bananapi-bpi-r3: add ramoops region

This patch reserves a 64 KiB memory region for pstore/ramoops on the
BPI-R3 board. The carve-out is intended to store kernel log data to
persist across warm resets.

> The carve-out is divided into 8 KiB kmsg records, a 32 KiB rolling console,
> 8 KiB ftrace, and 8 KiB pmsg, leaving the remainder for the per-record
> Reed-Solomon ECC parity (ecc-size=16) which significantly improves dump
> readability when the panic path truncates writes mid-record.

[Severity: Low]
Is this description of the ECC parity location accurate?

With 32 KiB for the console, 8 KiB for ftrace, 8 KiB for pmsg, and two 8 KiB
kmsg records, the allocations sum to exactly 64 KiB, leaving 0 bytes of
remainder.

It appears the ramoops driver implements ECC by carving the ecc-size
directly out of the payload capacity of each individual zoned region, rather
than placing it in a separate remainder pool.

Could the commit message be updated to clarify how the ECC parity is actually
allocated within the zones?

> diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
> index 19f538d160ab5..31ee189dedc73 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts

[ ... ]

> +&{/reserved-memory} {
> +	ramoops@42ff0000 {
> +		compatible = "ramoops";
> +		reg = <0 0x42ff0000 0 0x10000>;
> +		record-size = <0x2000>;
> +		console-size = <0x8000>;
> +		ftrace-size = <0x2000>;
> +		pmsg-size = <0x2000>;
> +		ecc-size = <16>;
> +	};
> +};

[Severity: High]
Does this reserved memory node need the no-map property to function correctly?

Since this region sits within the system DRAM starting at 0x40000000,
without no-map the OS will incorporate it into the kernel's linear mapping
as Normal Cacheable memory.

When the pstore/ramoops driver attempts to map this region using ioremap_wc(),
will ioremap_prot() on ARM64 detect the attempt to remap active RAM with
different memory attributes and trigger an aliasing violation warning,
returning NULL and preventing the driver from loading?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260528093038.1945245-1-tillo@tillo.ch?part=1

[PATCH v2] arm64: dts: mediatek: mt7988a-bananapi-bpi-r4: add ramoops region

[Martino Dell'Ambrogio]

Reserve 1 MiB of RAM just below the ARM Trusted Firmware secmon region
(0x42f00000-0x43000000) for persistent kernel log storage via pstore/ramoops,
allowing post-panic console output and oops dumps to be recovered after a
reboot. Without it, kernel crash logs on this board are lost when the SoC
warm-resets and the on-chip console buffer is reinitialised.

With record-size=128 KiB, console-size=256 KiB, ftrace-size=64 KiB and
pmsg-size=64 KiB, ramoops_probe() carves the post-console remainder
(640 KiB) into five 128 KiB kmsg records, with the requested ecc-size=16
reserving a small Reed-Solomon parity block from each zone's own
allocation (per persistent_ram_new()). The ECC lets pstore recover dumps
even when the panic path truncates writes mid-record.

The no-map property is required so the reserved region is kept out of the
kernel linear map. ramoops remaps the carve-out write-combine via
ioremap_wc(); on arm64, leaving the same physical RAM mapped cacheable in
the linear map at the same time is an attribute-mismatch and risks losing
panic data to dirty cache evictions from the linear alias.

The carve-out sits immediately below the ATF region already declared at
0x43000000 in mt7988a.dtsi, so no other reserved-memory child is moved or
resized. BPI-R4 ships with at least 4 GiB of DRAM starting at 0x40000000,
so the region is well within installed memory on every variant.

For the carve-out to actually preserve content across a reset, the boot
loader must also avoid touching this region on warm reset; on standard
BPI-R4 boards with the stock OpenWrt U-Boot fork this already holds.

Signed-off-by: Martino Dell'Ambrogio <tillo@tillo.ch>
---
Changes in v2:
 - Add no-map; to keep the carve-out out of the kernel linear map and
   avoid the cacheable/write-combine attribute mismatch on arm64.
   (sashiko-bot, gemini-3.1-pro)
 - Rewrite the ECC paragraph in the commit log: ramoops carves ecc-size
   from each zone's own allocation in persistent_ram_new() and the
   post-console remainder is split into record-size'd kmsg records, not
   one record plus a separate ECC pool. (sashiko-bot, gemini-3.1-pro)

v1: https://lore.kernel.org/all/20260528093038.1945245-1-tillo@tillo.ch/

 .../boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi   | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
index 0ff69da..f7d4944 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
@@ -80,6 +80,19 @@ sfp1: sfp1 {
 	};
 };

+&{/reserved-memory} {
+	ramoops@42f00000 {
+		compatible = "ramoops";
+		reg = <0 0x42f00000 0 0x100000>;
+		no-map;
+		record-size = <0x20000>;
+		console-size = <0x40000>;
+		ftrace-size = <0x10000>;
+		pmsg-size = <0x10000>;
+		ecc-size = <16>;
+	};
+};
+
 &cci {
 	proc-supply = <&rt5190_buck3>;
 };
--
2.47.3