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

[Quentin Schulz]

On 6/23/26 11:42 AM, Andreas Zdziarstek wrote:
> 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.
> 

For posterity, I meant the opposite :) Why did Rockchip decide on 
"partial reset is a good default"? (second global reset is the register 
reset value, and here we set first global reset). But that may be the 
reason why I cannot boot from SD card after a watchdog reset on PX30 
Ringneck from Linux then. I wonder if I revert this back to first global 
reset if the IO domain (configured in the GRF!) is kept properly 
configured and can again boot from SD card after an SoC watchdog reset! 
Will give this a try one day.

> 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.
> 

I guess we could check where the SoC is stuck? I believe Rockchip always 
expose the JTAG on the same pins as the SD card controller. But again, 
I've never used or set up JTAG on those boards so wouldn't be able to 
help here.

Cheers,
Quentin