[PATCH] rk3328: request that SoC resets use the first reset

[Simonas Kazlauskas]

Matteo Martelli wrote:
>
>Hi Simonas,
>
>On Thu, 26 Dec 2024 00:23:13 +0200, Simonas Kazlauskas <linux-rockchip at kazlauskas.me> wrote:
>> On my test board (Radxa RockPiE)/setup the second reset does not appear
>> to be working at all - requesting second reset even as early as inside
>> the U-Boot will entirely hang the CPU with the only way to recover from
>> it being to pull physical RST pin to ground or to power cycle the
>> device. While there may be ways to set up the second reset such that it
>> would work correctly, it is pretty clear to me that at least Linux
>> doesn't do that currently.
>>
>> SOC reset sources (watchdog timer in particular) defaults to using the
>> second type of reset, so any attempts to use the feature on my board are
>> unsuccessful. Instead of the SoC reset, a hang occurs.
>
>I have encountered exactly the same issue on my rock64 board. The SoC hangs
>when the watchdog tries to reset the board. I haven't tested your patch (yet)
>but I followed the example in your cover letter and by setting the first global
>reset in u-boot the watchdog can reset the board properly:
>
>mw ff440090 3a98c064    # CRU_GLB_CNT_TH: set first global reset for WDT and TSADC
>mw ff1a0000 b           # enable watchdog
>
>This resets the board. Then by writing back to CRU_GLB_CNT_TH to its default value
>3a980064 (so second global reset), and enabling the watchdog the board does not
>reset but it hangs instead.
>
>>
>> This change makes a request that SoC reset sources use the first reset;
>> the same one as the regular reset that occurs as part of a regular
>> reboot.
>>
>> Context: The second type of reset is supposed to preserve GPIO and GRF
>> state, which to me sounds undesirable, especially for WDT use: what if
>> the GPIO/GRF state was exactly the part that led to WDT elapse?
>
>I agree that the hardware default seems undesirable and having the driver
>setting it to the first global reset seems a more reasonable default to me.
>However if it should be configurable I'm not sure what would be the best way.
>Did you receive any feedback on this? Adding Heiko to the cc list who hopefully
>might be interested in this patch and provide some insights.
>
>On a side note I'm also thinking that a similar patch could be submitted to
>u-boot, since the watchdog might be enabled by the bootloader as well.

Hey Matteo,

Haven’t received any responses/reviews/reactions to my patch, no. Your’s is the 
first.

I even reached out to some engineers on their forums/chat (don't remember 
exactly which channels at this point, though.) I've been successfully patching 
my kernel during the nixos system image build, so there was little reason for 
me to keep following up after I got thoroughly ignored the first time around.

If you can find somebody willing to take a look, it would be greatly 
appreciated!

Cheers,
S.

P.S. Added the mailing list back to `To`.

>Best regards,
>Matteo Martelli