On 6/23/26 11:42 AM, Andreas Zdziarstek wrote:
Hi Quentin,
Am Di., 23. Juni 2026 um 11:10 Uhr schrieb Quentin Schulz
<[email protected]>:
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
