Re: [PATCH v2] arm64: dts: renesas: ironhide: Describe inline ECC carveouts

[Geert Uytterhoeven]

Hi Marek,

On Fri, 10 Jul 2026 at 18:05, Marek Vasut
<marek.vasut+renesas@xxxxxxxxxxx> wrote:
> The DBSC5 DRAM controller protects DRAM content using inline ECC.
> The inline ECC utilizes areas of DRAM for its operation, which are
> in the DRAM address range, but must not be accessed or modified.
> Describe the inline ECC carveout areas used by the DBSC5 controller
> on this hardware as reserved-memory, which must not be accessed.
> Include DRAM areas which are unprotected by ECC as well, those are
> parts of the DRAM which directly precede the ECC carveout.
>
> In case of high DRAM utilization, unless the inline ECC carveouts
> are properly reserved, Linux may use and corrupt the memory used
> by the DBSC5 DRAM controller for inline ECC, which would lead to
> the system becoming unstable.
>
> Fixes: ad142a4ef710 ("arm64: dts: renesas: r8a78000: Add initial Ironhide board support")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Marek Vasut <marek.vasut+renesas@xxxxxxxxxxx>

> V2: Include the unprotected data areas as well

Thanks for the update!

With the ECC carveouts, Ironhide survives booting with "earlycon
memtest=17".

> --- a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
> @@ -107,6 +107,47 @@ tee@8c400000 {
>                         reg = <0x0 0x8c400000 0x0 0x02000000>;
>                         no-map;
>                 };
> +
> +               /* DRAM controller inline ECC areas */
> +               ecc@10cccc0000 {
> +                       reg = <0x10 0xcccc0000 0x0 0x33340000>;
> +                       no-map;
> +               };
> +
> +               ecc@12cccc0000 {
> +                       reg = <0x12 0xcccc0000 0x0 0x33340000>;
> +                       no-map;
> +               };
> +
> +               ecc@14cccc0000 {
> +                       reg = <0x14 0xcccc0000 0x0 0x33340000>;
> +                       no-map;
> +               };
> +
> +               ecc@16cccc0000 {
> +                       reg = <0x16 0xcccc0000 0x0 0x33340000>;
> +                       no-map;
> +               };
> +
> +               ecc@18cccc0000 {
> +                       reg = <0x18 0xcccc0000 0x0 0x33340000>;
> +                       no-map;
> +               };
> +
> +               ecc@1a66660000 {
> +                       reg = <0x1a 0x66660000 0x0 0x999a0000>;
> +                       no-map;
> +               };
> +
> +               ecc@1c66660000 {
> +                       reg = <0x1c 0x66660000 0x0 0x999a0000>;
> +                       no-map;
> +               };
> +
> +               ecc@1e66660000 {
> +                       reg = <0x1e 0x66660000 0x0 0x999a0000>;
> +                       no-map;
> +               };

Given all DB[0-7]FSDRAMECCAREA00 registers on Ironhide contain
0x0000cccc (md.l e98[0-3][7f]450 1), I think the last 3 regions should
start at offset 0xcccc0000 instead of 0x66660000, too.
As a bonus, we get 4.8 GiB back ;-)

>         };
>  };
>

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds