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

[AngeloGioacchino Del Regno]

On 9/15/26 14:12, Martino Dell'Ambrogio wrote:
> 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 zone sizes (record-size=8 KiB, console-size=32 KiB, ftrace-size=8 KiB,
> pmsg-size=8 KiB) consume the full 64 KiB carve-out. The requested ecc-size=16
> reserves a small Reed-Solomon parity block from each zone's own allocation
> in persistent_ram_new(), which 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 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@xxxxxxxx>
> ---
> Changes in v5:
>   - Restore this board's own carve-out. v4 carried the BPI-R4 values by
>     mistake - 1 MiB at 0x42f00000 with 128/256/64/64 KiB zones - while the
>     commit message still described the BPI-R3 layout. That would have reserved
>     1 MiB instead of 64 KiB on a 2 GiB board and contradicted its own message.
>     Back to 64 KiB at 0x42ff0000 with 8/32/8/8 KiB, as in v3. Thanks to the
>     Sashiko review for catching it; entirely my error in regenerating the patch.
>   - No other change: the plain reserved-memory node from v4 is kept.
>
> The BPI-R4 patch is unaffected - its values were correct in v4 and it needs no
> resend:
> https://lore.kernel.org/all/20260915135722.566918-1-tillo@xxxxxxxx/

You forgot to send the 7988a bpi-r4 patch :-)

Cheers,
Angelo