[PATCH 0/2] rockchip: odroid-m1s/rk3566 watchdog support

[Andreas Zdziarstek]

Hi Quentin,

Am Di., 23. Juni 2026 um 11:10 Uhr schrieb Quentin Schulz
<quentin.schulz at cherry.de>:

> > Unfortunately, the TRM is rather tight-lipped about what each one really
> > does. Per experimentation: Setting it to the "first" global reset fixes
>
> As per TRM (2.8.4 Global Software Reset):
>
> """
> glb_srstn_1 resets almost all logic except some registers just
> supporting hardware reset.
> glb_srstn_2 resets almost all logic except GRFs and GPIOs.
> """
>
> which is similarly worded in PX30 TRM for example.
>

Yep, it certainly sounds like srstn_1 is the more "complete" reset but that's
mostly just a guess from the wording

> > the hang and makes the watchdog work as expected in U-Boot. This is the
> > first patch. As the PX30 does the same thing in its arch_cpu_init(), I
> > believe this to be the way to go but I am curious to hear if anybody has
> > more technical insight on this.
> >
>
> I'm not sure there's much more we can know (would debugging this with
> JTAG help? I've never used it so don't know). But it's been a pain point
> on various Rockchip SoCs already, I'm quite surprised the default is
> still global reset 1 and not global reset 2.

It seemed to me that the default is just "don't touch the register bit". The
hardware initialization value is 0 which triggers srstn_2. The question is if
srstn_2 might be the correct choice for some boards? As you say this has
been a problem on other SoCs already, I would guess "not likely".

I have a little prior JTAG Debugging experience but no usable hardware in
my private posession. (Don't think the Odroid has the relevant pins even
broken out). However, I doubt we could do much more with it than confirm
if srst_2 locks up the SoC or if it hangs for some other reason.

Cheers,
Andreas