[PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Wolfram Sang]

SparrowHawk may run without ATF but with U-Boot SPL which does not
reserve the SWDT. Remove the default "reserved" marking.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---

Tested it by using the SWDT on my board.

 arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
index 161c083241f9..1da8e476b219 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
@@ -942,8 +942,3 @@ &sensor_thermal_cr52 {
 &sensor_thermal_ddr1 {
 	critical-action = "shutdown";
 };
-
-/* Firmware should reserve it but sadly doesn't */
-&swdt {
-	status = "reserved";
-};
-- 
2.47.2

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Marek Vasut]

On 10/17/25 1:51 PM, Wolfram Sang wrote:
> SparrowHawk may run without ATF

Nitpick: It is abbreviated "TFA" now.

Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Geert Uytterhoeven]

Hi Wolfram,

Thanks for your patch!

On Fri, 17 Oct 2025 at 13:51, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> SparrowHawk may run without ATF but with U-Boot SPL which does not
> reserve the SWDT. Remove the default "reserved" marking.

The same is true for other boards (e.g. my SPL-enabled White Hawk)...

> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
> @@ -942,8 +942,3 @@ &sensor_thermal_cr52 {
>  &sensor_thermal_ddr1 {
>         critical-action = "shutdown";
>  };
> -
> -/* Firmware should reserve it but sadly doesn't */
> -&swdt {
> -       status = "reserved";
> -};

As commit c38c85613ba2b7e9 ("arm64: dts: renesas: sparrow/white-hawk:
Mark SWDT as reserved") is not yet in soc/for-next, I can still fold
this fix into the original commit.

Or better: drop all these swdt = reserved commits?
TBH, I always had my doubts about making them reserved in the upstream
DTS, and there does not seem to be much gain in doing so...

Thoughts?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]


> Or better: drop all these swdt = reserved commits?

Maybe. Since Marek is maybe interested in fixing FW...

> TBH, I always had my doubts about making them reserved in the upstream
> DTS, and there does not seem to be much gain in doing so...

No strong opinion here. With "reserved" I think I followed your
suggestion but I personally don't mind.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Geert Uytterhoeven]

Hi Wolfram,

On Mon, 20 Oct 2025 at 21:48, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > Or better: drop all these swdt = reserved commits?
>
> Maybe. Since Marek is maybe interested in fixing FW...
>
> > TBH, I always had my doubts about making them reserved in the upstream
> > DTS, and there does not seem to be much gain in doing so...
>
> No strong opinion here. With "reserved" I think I followed your
> suggestion but I personally don't mind.

Well, the proper mechanism would be that firmware using SWDT would
override the status to reserved, preventing the user from using it if
it was enabled in the DTB passed by the user.  But (a) the current
firmware doesn't do that, and (b) we currently do not have a use-case
for enabling SWDT in the DTB.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Marek Vasut]

On 10/21/25 9:09 AM, Geert Uytterhoeven wrote:

Hello everyone,

> On Mon, 20 Oct 2025 at 21:48, Wolfram Sang
> <wsa+renesas@sang-engineering.com> wrote:
>>> Or better: drop all these swdt = reserved commits?
>>
>> Maybe. Since Marek is maybe interested in fixing FW...
>>
>>> TBH, I always had my doubts about making them reserved in the upstream
>>> DTS, and there does not seem to be much gain in doing so...
>>
>> No strong opinion here. With "reserved" I think I followed your
>> suggestion but I personally don't mind.
> 
> Well, the proper mechanism would be that firmware using SWDT would
> override the status to reserved, preventing the user from using it if
> it was enabled in the DTB passed by the user.  But (a) the current
> firmware doesn't do that, and (b) we currently do not have a use-case
> for enabling SWDT in the DTB.

Upstream TFA does enable SWDT for R-Car Gen3, but not for Gen4.

I can pass SWDT node from upstream TFA to next stage on Gen3 if you 
would like that ?

-- 
Best regards,
Marek Vasut

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Geert Uytterhoeven]

Hi Marek,

On Tue, 21 Oct 2025 at 15:14, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 10/21/25 9:09 AM, Geert Uytterhoeven wrote:
> > On Mon, 20 Oct 2025 at 21:48, Wolfram Sang
> > <wsa+renesas@sang-engineering.com> wrote:
> >>> Or better: drop all these swdt = reserved commits?
> >>
> >> Maybe. Since Marek is maybe interested in fixing FW...
> >>
> >>> TBH, I always had my doubts about making them reserved in the upstream
> >>> DTS, and there does not seem to be much gain in doing so...
> >>
> >> No strong opinion here. With "reserved" I think I followed your
> >> suggestion but I personally don't mind.
> >
> > Well, the proper mechanism would be that firmware using SWDT would
> > override the status to reserved, preventing the user from using it if
> > it was enabled in the DTB passed by the user.  But (a) the current
> > firmware doesn't do that, and (b) we currently do not have a use-case
> > for enabling SWDT in the DTB.
>
> Upstream TFA does enable SWDT for R-Car Gen3, but not for Gen4.

Oh, so this is a "generic" R-Car Gen4 issue?
Does that mean we can use SWDT in Linux on R-Car Gen4 with TF-A,
or does TF-A still block access to it?

> I can pass SWDT node from upstream TFA to next stage on Gen3 if you
> would like that ?

I guess that would be a good thing to do.  But I am afraid it is a bit
late in the product life cycle.  Ideally, everything that is used by
firmware should be marked reserved...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Marek Vasut]

On 10/21/25 3:22 PM, Geert Uytterhoeven wrote:

Hello Geert,

> On Tue, 21 Oct 2025 at 15:14, Marek Vasut <marek.vasut@mailbox.org> wrote:
>> On 10/21/25 9:09 AM, Geert Uytterhoeven wrote:
>>> On Mon, 20 Oct 2025 at 21:48, Wolfram Sang
>>> <wsa+renesas@sang-engineering.com> wrote:
>>>>> Or better: drop all these swdt = reserved commits?
>>>>
>>>> Maybe. Since Marek is maybe interested in fixing FW...
>>>>
>>>>> TBH, I always had my doubts about making them reserved in the upstream
>>>>> DTS, and there does not seem to be much gain in doing so...
>>>>
>>>> No strong opinion here. With "reserved" I think I followed your
>>>> suggestion but I personally don't mind.
>>>
>>> Well, the proper mechanism would be that firmware using SWDT would
>>> override the status to reserved, preventing the user from using it if
>>> it was enabled in the DTB passed by the user.  But (a) the current
>>> firmware doesn't do that, and (b) we currently do not have a use-case
>>> for enabling SWDT in the DTB.
>>
>> Upstream TFA does enable SWDT for R-Car Gen3, but not for Gen4.
> 
> Oh, so this is a "generic" R-Car Gen4 issue?
> Does that mean we can use SWDT in Linux on R-Car Gen4 with TF-A,
> or does TF-A still block access to it?

I think this can be tested on Sparrow Hawk easily , with and without 
TFA. Wolfram, how do I test the SWDT ?

>> I can pass SWDT node from upstream TFA to next stage on Gen3 if you
>> would like that ?
> 
> I guess that would be a good thing to do.  But I am afraid it is a bit
> late in the product life cycle.  Ideally, everything that is used by
> firmware should be marked reserved...

It seems SWDT is not used by upstream TFA, but maybe it is used by 
downstream one (or downstream loader). I can enable SWDT in either TFA 
or U-Boot if that would be preferable, or leave it available for Linux.

-- 
Best regards,
Marek Vasut

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Wolfram Sang]

[-- Attachment #1.1: Type: text/plain, Size: 731 bytes --]

Hi Marek,

sorry for the late reply. I am on holiday this week with only limited
time for work and net access.

> I think this can be tested on Sparrow Hawk easily , with and without TFA.
> Wolfram, how do I test the SWDT ?

1) enable the node in DT
2) apply the patch "[PATCH] soc: renesas: rcar-rst: keep RESBAR2S in default state"
3) apply the diff attached to this mail (untested but quite sure that's
   what i did a few days ago) which allows SWDT to reset
4) access it like any other watchdog. IIRC I did this to enforce a reset
   # watchdog -T1 -t3 /dev/watchdog1
   (with busybox watchdog)

I think that's it. It uses the same driver as the RWDT, so you probably
have this activated already.

Happy hacking,

   Wolfram


[-- Attachment #1.2: v4h_allow_swdt_to_reset.diff --]
[-- Type: text/x-diff, Size: 903 bytes --]

diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
index 0541990901fc..a78ea77dba16 100644
--- a/drivers/soc/renesas/rcar-rst.c
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -12,7 +12,7 @@
 
 #define WDTRSTCR_RESET		0xA55A0002
 #define WDTRSTCR		0x0054
-#define GEN4_WDTRSTCR_RESET	0xA55A8002
+#define GEN4_WDTRSTCR_RESET	0xA55A8000
 #define GEN4_WDTRSTCR		0x0010
 
 #define CR7BAR			0x0070
@@ -117,7 +117,7 @@ static const struct of_device_id rcar_rst_matches[] __initconst = {
 	/* R-Car Gen4 */
 	{ .compatible = "renesas,r8a779a0-rst", .data = &rcar_rst_v3u },
 	{ .compatible = "renesas,r8a779f0-rst", .data = &rcar_rst_gen4 },
-	{ .compatible = "renesas,r8a779g0-rst", .data = &rcar_rst_gen4 },
+	{ .compatible = "renesas,r8a779g0-rst", .data = &rcar_rst_v3u },
 	{ .compatible = "renesas,r8a779h0-rst", .data = &rcar_rst_gen4 },
 	{ /* sentinel */ }
 };

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Geert Uytterhoeven]

Hi Marek,

On Tue, 21 Oct 2025 at 18:07, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 10/21/25 3:22 PM, Geert Uytterhoeven wrote:
> > On Tue, 21 Oct 2025 at 15:14, Marek Vasut <marek.vasut@mailbox.org> wrote:
> >> On 10/21/25 9:09 AM, Geert Uytterhoeven wrote:
> >>> On Mon, 20 Oct 2025 at 21:48, Wolfram Sang
> >>> <wsa+renesas@sang-engineering.com> wrote:
> >>>>> Or better: drop all these swdt = reserved commits?
> >>>>
> >>>> Maybe. Since Marek is maybe interested in fixing FW...
> >>>>
> >>>>> TBH, I always had my doubts about making them reserved in the upstream
> >>>>> DTS, and there does not seem to be much gain in doing so...
> >>>>
> >>>> No strong opinion here. With "reserved" I think I followed your
> >>>> suggestion but I personally don't mind.
> >>>
> >>> Well, the proper mechanism would be that firmware using SWDT would
> >>> override the status to reserved, preventing the user from using it if
> >>> it was enabled in the DTB passed by the user.  But (a) the current
> >>> firmware doesn't do that, and (b) we currently do not have a use-case
> >>> for enabling SWDT in the DTB.
> >>
> >> Upstream TFA does enable SWDT for R-Car Gen3, but not for Gen4.
> >
> > Oh, so this is a "generic" R-Car Gen4 issue?
> > Does that mean we can use SWDT in Linux on R-Car Gen4 with TF-A,
> > or does TF-A still block access to it?
>
> I think this can be tested on Sparrow Hawk easily , with and without
> TFA. Wolfram, how do I test the SWDT ?
>
> >> I can pass SWDT node from upstream TFA to next stage on Gen3 if you
> >> would like that ?
> >
> > I guess that would be a good thing to do.  But I am afraid it is a bit
> > late in the product life cycle.  Ideally, everything that is used by
> > firmware should be marked reserved...
>
> It seems SWDT is not used by upstream TFA, but maybe it is used by
> downstream one (or downstream loader). I can enable SWDT in either TFA
> or U-Boot if that would be preferable, or leave it available for Linux.

My Gray Hawk Single still has downstream firmware, and I can modify the
SWDT registers from U-Boot (unlike on Salvator-XS with R-Car H3 ES2),
so access is not blocked.
Hence I plan to drop the SWDT patches for all R-Car Gen4 boards.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [PATCH] arm64: dts: renesas: sparrow-hawk: don't reserve SWDT

[Marek Vasut]

On 10/27/25 11:09 AM, Geert Uytterhoeven wrote:

Hello Geert,

> My Gray Hawk Single still has downstream firmware, and I can modify the
> SWDT registers from U-Boot (unlike on Salvator-XS with R-Car H3 ES2),
> so access is not blocked.
> Hence I plan to drop the SWDT patches for all R-Car Gen4 boards.

Thank you for testing. You can also flip the DIP switches on WhiteHawk 
to boot the original firmware on it, it is left unmodified . Then we 
would know whether even the WH is unaffected, but I suspect it likely is.

-- 
Best regards,
Marek Vasut