Re: [PATCH v1] watchdog: sama5d4_wdt: Reset delay on start

From: Guenter Roeck
Date: Fri Mar 04 2016 - 08:09:13 EST


On 03/04/2016 01:06 AM, Romain Izard wrote:
Hi Wenyou, Guenter,

2016-03-04 6:23 GMT+01:00 Guenter Roeck <linux@xxxxxxxxxxxx>:
On 03/03/2016 05:35 PM, Yang, Wenyou wrote:
On 2016/3/3 18:29, Romain Izard wrote:

If the internal counter is not refreshed when the watchdog is
started for the first time, the watchdog will trigger very rapidly.
For example, opening /dev/watchdog without writing in it will
immediately trigger a reboot, instead of waiting for the delay to
expire.

To avoid this problem, reload the timer on opening the watchdog
device.

Command: "while sleep 5; do echo 1; done > /dev/watchdog" Before:
system reset After: the watchdog runs correctly

I didn't reproduce your issue on my side,

run the your commands as follows, it works fine, the system reset
doesn't happen.

I've just verified with the factory image provided on the SAMA5D2
Xplained board. It does not display this behaviour.

But the difference is that in the case without the issue, I'm using the
AT91bootstrap SPL, U-Boot, and the kernel from the QSPI chip. When I
have the issue, I have a U-Boot based SPL, U-Boot itself and the kernel
that come from the FAT partition of an SD-Card.

Userspace does not seem to be involved in the issue, as I can reproduce
it both with my buildroot environment, and the Yocto environment from
the factory image.

Different chip revision ? Different chip type ? Different chip
initialization by ROMMON ?

Can we get exact chip revisions and types for both cases (working and
not working), and (if it might be relevant) a dump of all associated
chip registers ?


I also check the WDT_MR register before and after enabling watchdog,
the WDV and WDD fields are correct.

Can you check it again? thank you.

Working case:
MR on kernel startup: 0x3fffafff
MR after watchdog init: 0x0fffafff
MR after start: 0x0fff2fff

Problem case:
MR on kernel startup: 0x00008000
MR after watchdog init: 0x0fffafff
MR after start: 0x0fff2fff

So this means that the counter reload does not seem to work very well if
WDD/WDV have been set to 0 in the past. The other question is why does
U-Boot (from the Atmel branch based on 2015.1) put this stange value in
this register.


Can you check the value of AT91_WDT_SR ? Maybe it tells us something.

Also, in the error case, can you check if the watchdog times out at all
after you applied your patch ?

Thanks,
Guenter

Best regards,