at91sam9: watchdog: period

at91sam9: watchdog: period

[Jiří Prchal]

Hi all,
I'm trying to discover what's wrong with watchdog on my board. I didn't find anything about it on internet so I would 
ask you for help.
I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors to GND. Frequency seems to be good since 
hwclock (RTC) runs pretty precisely powered from backup and main power too (no NTP). But watchdog time to reset is still 
61s regardless default (16s) or 4s heartbeat setting. No change to WDT_MR in bootstrap, so in Linux should work.
Here is dump:
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10 
PREEMPT Thu May 14 15:20:24 CEST 2015
[    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine model: AKsignal CDU9G25_v6
[    0.000000] Memory policy: Data cache writeback
[    0.000000] AT91: Detected soc type: at91sam9x5
[    0.000000] AT91: Detected soc subtype: at91sam9g25
...
[    4.669669] AT91: Starting after watchdog reset
[    4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1)
...

/ # killall watchdog
[ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped!
/ # [ 1821.123123] watchdog watchdog0: watchdog did not stop!
[ 1882.294294] at91sam9_wdt: I will reset your machine !

Thanks for any help.
Jiri

at91sam9: watchdog: period

[Bryan Evenson]

Jiri,

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Jir? Prchal
> Sent: Friday, May 15, 2015 3:17 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Boris Brezillon; Jean-Christophe Plagniol-Villard; Nicolas Ferre
> Subject: at91sam9: watchdog: period
> 
> Hi all,
> I'm trying to discover what's wrong with watchdog on my board. I didn't find
> anything about it on internet so I would ask you for help.
> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors
> to GND. Frequency seems to be good since hwclock (RTC) runs pretty
> precisely powered from backup and main power too (no NTP). But watchdog
> time to reset is still 61s regardless default (16s) or 4s heartbeat setting. No
> change to WDT_MR in bootstrap, so in Linux should work.

I have the same hardware setup and the watchdog timeout is 15 seconds for me.  For my kernel, I am using the Atmel fork at github.com/linux4sam/linux-at91, master branch at commit 5d5b332821753d616e65da6237f0a3330e59b98f.  Even though this is based upon the 3.10 kernel, there isn't much that has changed with regard to the RTC or watchdog between 3.10 and 4.03; Atmel has been good on backporting their changes to their fork.  Maybe try an older kernel and see if the problem goes away?


Regards,
Bryan

> Here is dump:
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3
> (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10
> PREEMPT Thu May 14 15:20:24 CEST 2015
> [    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ),
> cr=0005317f
> [    0.000000] CPU: VIVT data cache, VIVT instruction cache
> [    0.000000] Machine model: AKsignal CDU9G25_v6
> [    0.000000] Memory policy: Data cache writeback
> [    0.000000] AT91: Detected soc type: at91sam9x5
> [    0.000000] AT91: Detected soc subtype: at91sam9g25
> ...
> [    4.669669] AT91: Starting after watchdog reset
> [    4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1)
> ...
> 
> / # killall watchdog
> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being
> stopped!
> / # [ 1821.123123] watchdog watchdog0: watchdog did not stop!
> [ 1882.294294] at91sam9_wdt: I will reset your machine !
> 
> Thanks for any help.
> Jiri
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

at91sam9: watchdog: period

[Nicolas Ferre]

Le 15/05/2015 15:59, Bryan Evenson a ?crit :
> Jiri,
> 
>> -----Original Message-----
>> From: linux-arm-kernel [mailto:linux-arm-kernel-
>> bounces at lists.infradead.org] On Behalf Of Jir? Prchal
>> Sent: Friday, May 15, 2015 3:17 AM
>> To: linux-arm-kernel at lists.infradead.org
>> Cc: Boris Brezillon; Jean-Christophe Plagniol-Villard; Nicolas Ferre
>> Subject: at91sam9: watchdog: period
>>
>> Hi all,
>> I'm trying to discover what's wrong with watchdog on my board. I didn't find
>> anything about it on internet so I would ask you for help.
>> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors
>> to GND. Frequency seems to be good since hwclock (RTC) runs pretty
>> precisely powered from backup and main power too (no NTP). But watchdog
>> time to reset is still 61s regardless default (16s) or 4s heartbeat setting. No
>> change to WDT_MR in bootstrap, so in Linux should work.
> 
> I have the same hardware setup and the watchdog timeout is 15
> seconds for me. For my kernel, I am using the Atmel fork at
> github.com/linux4sam/linux-at91, master branch at commit
> 5d5b332821753d616e65da6237f0a3330e59b98f.

FYI, I've just moved the master branch of our github to the newer
3.18-based branch: linux-3.18-at91.

Bye,


> Even though this is based upon
> the 3.10 kernel, there isn't much that has changed with regard to the
> RTC or watchdog between 3.10 and 4.03; Atmel has been good on
> backporting their changes to their fork. Maybe try an older kernel and
> see if the problem goes away?
> 
> 
> Regards,
> Bryan
> 
>> Here is dump:
>> [    0.000000] Booting Linux on physical CPU 0x0
>> [    0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3
>> (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10
>> PREEMPT Thu May 14 15:20:24 CEST 2015
>> [    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ),
>> cr=0005317f
>> [    0.000000] CPU: VIVT data cache, VIVT instruction cache
>> [    0.000000] Machine model: AKsignal CDU9G25_v6
>> [    0.000000] Memory policy: Data cache writeback
>> [    0.000000] AT91: Detected soc type: at91sam9x5
>> [    0.000000] AT91: Detected soc subtype: at91sam9g25
>> ...
>> [    4.669669] AT91: Starting after watchdog reset
>> [    4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1)
>> ...
>>
>> / # killall watchdog
>> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being
>> stopped!
>> / # [ 1821.123123] watchdog watchdog0: watchdog did not stop!
>> [ 1882.294294] at91sam9_wdt: I will reset your machine !
>>
>> Thanks for any help.
>> Jiri
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 


-- 
Nicolas Ferre

at91sam9: watchdog: period

[Boris Brezillon]

Hi Jiri,

On Fri, 15 May 2015 09:16:37 +0200
Ji?? Prchal <jiri.prchal@aksignal.cz> wrote:

> Hi all,
> I'm trying to discover what's wrong with watchdog on my board. I didn't find anything about it on internet so I would 
> ask you for help.
> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors to GND. Frequency seems to be good since 
> hwclock (RTC) runs pretty precisely powered from backup and main power too (no NTP). But watchdog time to reset is still 
> 61s regardless default (16s) or 4s heartbeat setting. No change to WDT_MR in bootstrap, so in Linux should work.
> Here is dump:
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10 
> PREEMPT Thu May 14 15:20:24 CEST 2015
> [    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> [    0.000000] CPU: VIVT data cache, VIVT instruction cache
> [    0.000000] Machine model: AKsignal CDU9G25_v6
> [    0.000000] Memory policy: Data cache writeback
> [    0.000000] AT91: Detected soc type: at91sam9x5
> [    0.000000] AT91: Detected soc subtype: at91sam9g25
> ...
> [    4.669669] AT91: Starting after watchdog reset
> [    4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1)
> ...
> 
> / # killall watchdog
> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped!
> / # [ 1821.123123] watchdog watchdog0: watchdog did not stop!
> [ 1882.294294] at91sam9_wdt: I will reset your machine !

Is this file present on your board ?
/proc/device-tree/ahb/apb/watchdog at fffffe40/atmel,idle-halt

If it is then you should patch your DT to remove the property.

Best Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

at91sam9: watchdog: period

[Jiří Prchal]

On 15.5.2015 16:19, Nicolas Ferre wrote:
>> I have the same hardware setup and the watchdog timeout is 15
>> seconds for me. For my kernel, I am using the Atmel fork at
>> github.com/linux4sam/linux-at91, master branch at commit
>> 5d5b332821753d616e65da6237f0a3330e59b98f.
>
> FYI, I've just moved the master branch of our github to the newer
> 3.18-based branch: linux-3.18-at91.
>
> Bye,

Since this files at91sam9_wdt.c and at91sam9_wdt.h are without changes between git 3.18 and 4.0.3 I think the problem is 
somewhere else. Later I can try whole git 3.18 kernel, now I don't have time for it.

Bye

at91sam9: watchdog: period

[Jiří Prchal]

On 15.5.2015 17:25, Boris Brezillon wrote:
> Is this file present on your board ?
> /proc/device-tree/ahb/apb/watchdog at fffffe40/atmel,idle-halt
>
> If it is then you should patch your DT to remove the property.
>
> Best Regards,
>
> Boris
>
>
No, there is only:
drwxrwxr-x    2 root     root             0 May 18 06:12 .
drwxrwxr-x   35 root     root             0 May 18 06:12 ..
-r--rw-r--    1 root     root             0 May 18 06:12 atmel,dbg-halt
-r--rw-r--    1 root     root             4 May 18 06:12 atmel,reset-type
-r--rw-r--    1 root     root             9 May 18 06:12 atmel,watchdog-type
-r--rw-r--    1 root     root            22 May 18 06:12 compatible
-r--rw-r--    1 root     root            12 May 18 06:12 interrupts
-r--rw-r--    1 root     root             9 May 18 06:12 name
-r--rw-r--    1 root     root             8 May 18 06:12 reg
-r--rw-r--    1 root     root             5 May 18 06:12 status
-r--rw-r--    1 root     root             4 May 18 06:12 timeout-sec

at91sam9: watchdog: period

[Boris Brezillon]

On Mon, 18 May 2015 08:27:43 +0200
Ji?? Prchal <jiri.prchal@aksignal.cz> wrote:

> 
> 
> On 15.5.2015 17:25, Boris Brezillon wrote:
> > Is this file present on your board ?
> > /proc/device-tree/ahb/apb/watchdog at fffffe40/atmel,idle-halt
> >
> > If it is then you should patch your DT to remove the property.
> >
> > Best Regards,
> >
> > Boris
> >
> >
> No, there is only:
> drwxrwxr-x    2 root     root             0 May 18 06:12 .
> drwxrwxr-x   35 root     root             0 May 18 06:12 ..
> -r--rw-r--    1 root     root             0 May 18 06:12 atmel,dbg-halt
> -r--rw-r--    1 root     root             4 May 18 06:12 atmel,reset-type
> -r--rw-r--    1 root     root             9 May 18 06:12 atmel,watchdog-type
> -r--rw-r--    1 root     root            22 May 18 06:12 compatible
> -r--rw-r--    1 root     root            12 May 18 06:12 interrupts
> -r--rw-r--    1 root     root             9 May 18 06:12 name
> -r--rw-r--    1 root     root             8 May 18 06:12 reg
> -r--rw-r--    1 root     root             5 May 18 06:12 status
> -r--rw-r--    1 root     root             4 May 18 06:12 timeout-sec
> 

Can you dump watchdog registers (using devmem) ?


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

at91sam9: watchdog: period

[Jiří Prchal]

On 18.5.2015 09:27, Boris Brezillon wrote:
>
> Can you dump watchdog registers (using devmem) ?

/ # devmem 0xfffffe40
0x00000000
/ # devmem 0xfffffe44
0x1FFF2FFF
/ # devmem 0xfffffe48
0x00000000

at91sam9: watchdog: period

[Yang, Wenyou]

On 2015/5/18 16:17, Ji?? Prchal wrote:
>
>
> On 18.5.2015 09:27, Boris Brezillon wrote:
>>
>> Can you dump watchdog registers (using devmem) ?
>
> / # devmem 0xfffffe40
> 0x00000000
> / # devmem 0xfffffe44
> 0x1FFF2FFF
> / # devmem 0xfffffe48
> 0x00000000
>
The register value is right.

I tested the Linux-3.18-at91-linux4sam_4.7 on the at91sam9g35ek. It 
reset the system in the 16s after removing atmel,idle-halt property.

Best Regards,
Wenyou Yang

at91sam9: watchdog: period

[Boris Brezillon]

On Mon, 18 May 2015 08:27:43 +0200
Ji?? Prchal <jiri.prchal@aksignal.cz> wrote:

> 
> 
> On 15.5.2015 17:25, Boris Brezillon wrote:
> > Is this file present on your board ?
> > /proc/device-tree/ahb/apb/watchdog at fffffe40/atmel,idle-halt
> >
> > If it is then you should patch your DT to remove the property.
> >
> > Best Regards,
> >
> > Boris
> >
> >
> No, there is only:
> drwxrwxr-x    2 root     root             0 May 18 06:12 .
> drwxrwxr-x   35 root     root             0 May 18 06:12 ..
> -r--rw-r--    1 root     root             0 May 18 06:12 atmel,dbg-halt

Are you debugging your platform with a JTAG (if that's the case and you
still want the watchdog to expire in 16 seconds, then you should remove
the dbg-halt property).

> -r--rw-r--    1 root     root             4 May 18 06:12 atmel,reset-type
> -r--rw-r--    1 root     root             9 May 18 06:12 atmel,watchdog-type
> -r--rw-r--    1 root     root            22 May 18 06:12 compatible
> -r--rw-r--    1 root     root            12 May 18 06:12 interrupts
> -r--rw-r--    1 root     root             9 May 18 06:12 name
> -r--rw-r--    1 root     root             8 May 18 06:12 reg
> -r--rw-r--    1 root     root             5 May 18 06:12 status
> -r--rw-r--    1 root     root             4 May 18 06:12 timeout-sec
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

at91sam9: watchdog: period

[Boris Brezillon]

On Tue, 19 May 2015 11:07:29 +0800
"Yang, Wenyou" <wenyou.yang@atmel.com> wrote:

> 
> 
> On 2015/5/18 16:17, Ji?? Prchal wrote:
> >
> >
> > On 18.5.2015 09:27, Boris Brezillon wrote:
> >>
> >> Can you dump watchdog registers (using devmem) ?
> >
> > / # devmem 0xfffffe40
> > 0x00000000
> > / # devmem 0xfffffe44
> > 0x1FFF2FFF
> > / # devmem 0xfffffe48
> > 0x00000000
> >
> The register value is right.

It seems correct to me too.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

at91sam9: watchdog: period

[Jiří Prchal]

On 19.5.2015 09:12, Boris Brezillon wrote:
>
> Are you debugging your platform with a JTAG (if that's the case and you
> still want the watchdog to expire in 16 seconds, then you should remove
> the dbg-halt property).
>
No, not debugging.

at91sam9: watchdog: period

[Jiří Prchal]

On 19.5.2015 09:14, Boris Brezillon wrote:
> On Tue, 19 May 2015 11:07:29 +0800
> "Yang, Wenyou" <wenyou.yang@atmel.com> wrote:
>
>>
>>
>> On 2015/5/18 16:17, Ji?? Prchal wrote:
>>>
>>>
>>> On 18.5.2015 09:27, Boris Brezillon wrote:
>>>>
>>>> Can you dump watchdog registers (using devmem) ?
>>>
>>> / # devmem 0xfffffe40
>>> 0x00000000
>>> / # devmem 0xfffffe44
>>> 0x1FFF2FFF
>>> / # devmem 0xfffffe48
>>> 0x00000000
>>>
>> The register value is right.
>
> It seems correct to me too.
>
Not to me, I want 4s:
[    4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1)

at91sam9: watchdog: period

[Boris Brezillon]

On Tue, 19 May 2015 11:01:49 +0200
Ji?? Prchal <jiri.prchal@aksignal.cz> wrote:

> 
> 
> On 19.5.2015 09:14, Boris Brezillon wrote:
> > On Tue, 19 May 2015 11:07:29 +0800
> > "Yang, Wenyou" <wenyou.yang@atmel.com> wrote:
> >
> >>
> >>
> >> On 2015/5/18 16:17, Ji?? Prchal wrote:
> >>>
> >>>
> >>> On 18.5.2015 09:27, Boris Brezillon wrote:
> >>>>
> >>>> Can you dump watchdog registers (using devmem) ?
> >>>
> >>> / # devmem 0xfffffe40
> >>> 0x00000000
> >>> / # devmem 0xfffffe44
> >>> 0x1FFF2FFF
> >>> / # devmem 0xfffffe48
> >>> 0x00000000
> >>>
> >> The register value is right.
> >
> > It seems correct to me too.
> >
> Not to me, I want 4s:
> [    4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1)

There's a difference between your heartbeat (the frequency you
refresh/reset your watchdog) and the watchdog expiration time (here set
to 16 secs).
We usually set the heartbeat to 1/2 or 1/4 the expiration time, so that
we're (almost) sure we can reset the watchdog before its expiration.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

at91sam9: watchdog: period

[Jiří Prchal]

On 19.5.2015 11:14, Boris Brezillon wrote:
>
> There's a difference between your heartbeat (the frequency you
> refresh/reset your watchdog) and the watchdog expiration time (here set
> to 16 secs).
> We usually set the heartbeat to 1/2 or 1/4 the expiration time, so that
> we're (almost) sure we can reset the watchdog before its expiration.
>
>
I'm confused. Why need kernel to know the time in witch userspace process will reset watchdog?
And how to change watchdog expiration time?

at91sam9: watchdog: period

[Boris Brezillon]

On Tue, 19 May 2015 11:52:16 +0200
Ji?? Prchal <jiri.prchal@aksignal.cz> wrote:

> 
> 
> On 19.5.2015 11:14, Boris Brezillon wrote:
> >
> > There's a difference between your heartbeat (the frequency you
> > refresh/reset your watchdog) and the watchdog expiration time (here set
> > to 16 secs).
> > We usually set the heartbeat to 1/2 or 1/4 the expiration time, so that
> > we're (almost) sure we can reset the watchdog before its expiration.
> >
> >
> I'm confused. Why need kernel to know the time in witch userspace process will reset watchdog?

This time is not exposed to userspace, it's the internal heartbeat used
by the driver to refresh the watchdog.

> And how to change watchdog expiration time?

With the atmel,max-heartbeat-sec property.

Anyway, that does not explain why your system takes 61 secs to trigger
a reset (instead of 16 secs).
Can you try to revert this commit [1] ?


[1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/watchdog/at91sam9_wdt.c?id=d677772e1358924bf487cd833bdc4d50f3f6f64d
-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

at91sam9: watchdog: period

[Jiří Prchal]

On 19.5.2015 12:04, Boris Brezillon wrote:
>> I'm confused. Why need kernel to know the time in witch userspace process will reset watchdog?
>
> This time is not exposed to userspace, it's the internal heartbeat used
> by the driver to refresh the watchdog.

Kernel driver does refresh? For what is utility "watchdog" in busybox?
When I stop this util then it will reboot.

>
>> And how to change watchdog expiration time?
>
> With the atmel,max-heartbeat-sec property.

No effect on it, still 61s.

>
> Anyway, that does not explain why your system takes 61 secs to trigger
> a reset (instead of 16 secs).
> Can you try to revert this commit [1] ?

Because of our company internet policy I can't clone git so I tried kernel 3.18.13.
No change, still 61s.

>
>
> [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/watchdog/at91sam9_wdt.c?id=d677772e1358924bf487cd833bdc4d50f3f6f64d
>

at91sam9: watchdog: period

[Jiří Prchal]

On 19.5.2015 12:04, Boris Brezillon wrote:
>
> Anyway, that does not explain why your system takes 61 secs to trigger
> a reset (instead of 16 secs).
> Can you try to revert this commit [1] ?
>
>
> [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/watchdog/at91sam9_wdt.c?id=d677772e1358924bf487cd833bdc4d50f3f6f64d

I reverted this commit: still 61s.
By the way, between
# [  109.117117] at91sam9_wdt: I will reset your machine !
and
RomBOOT
is another 27s.
Whole watchdog reboot sequence is about 90s!
Slow clock is measured by counter as 32786Hz.

at91sam9: watchdog: period

[Jiří Prchal]

On 21.5.2015 14:41, Ji?? Prchal wrote:
> On 19.5.2015 12:04, Boris Brezillon wrote:
>>
>> Anyway, that does not explain why your system takes 61 secs to trigger
>> a reset (instead of 16 secs).
>> Can you try to revert this commit [1] ?
>>
>>
>> [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/watchdog/at91sam9_wdt.c?id=d677772e1358924bf487cd833bdc4d50f3f6f64d
>>
>
> I reverted this commit: still 61s.
> By the way, between
> # [  109.117117] at91sam9_wdt: I will reset your machine !
> and
> RomBOOT
> is another 27s.
> Whole watchdog reboot sequence is about 90s!
> Slow clock is measured by counter as 32786Hz.

Is something new?

at91sam9: watchdog: period

[Jiří Prchal]

Again hi to all,
is something new about watchdog period?  I just tried kernel 4.3-rc3 with same result. There must be some hw error seems 
to me.

On 15.5.2015 09:16, Ji?? Prchal wrote:
> Hi all,
> I'm trying to discover what's wrong with watchdog on my board. I didn't find anything about it on internet so I would
> ask you for help.
> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors to GND. Frequency seems to be good since
> hwclock (RTC) runs pretty precisely powered from backup and main power too (no NTP). But watchdog time to reset is still
> 61s regardless default (16s) or 4s heartbeat setting. No change to WDT_MR in bootstrap, so in Linux should work.
> Here is dump:
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10
> PREEMPT Thu May 14 15:20:24 CEST 2015
> [    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> [    0.000000] CPU: VIVT data cache, VIVT instruction cache
> [    0.000000] Machine model: AKsignal CDU9G25_v6
> [    0.000000] Memory policy: Data cache writeback
> [    0.000000] AT91: Detected soc type: at91sam9x5
> [    0.000000] AT91: Detected soc subtype: at91sam9g25
> ...
> [    4.669669] AT91: Starting after watchdog reset
> [    4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1)
> ...
>
> / # killall watchdog
> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped!
> / # [ 1821.123123] watchdog watchdog0: watchdog did not stop!
> [ 1882.294294] at91sam9_wdt: I will reset your machine !
>
> Thanks for any help.
> Jiri

at91sam9: watchdog: period

[Sylvain Rochet]

Hi Ji??,

On Fri, May 15, 2015 at 09:16:37AM +0200, Ji?? Prchal wrote:
> Hi all,
> I'm trying to discover what's wrong with watchdog on my board. I didn't find
> anything about it on internet so I would ask you for help.
> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors
> to GND. Frequency seems to be good since hwclock (RTC) runs pretty precisely
> powered from backup and main power too (no NTP). But watchdog time to reset
> is still 61s regardless default (16s) or 4s heartbeat setting. No change to
> WDT_MR in bootstrap, so in Linux should work.

I'm a bit late here but it looks like there is a misunderstanding about 
the watchdog stack involved here:

userland
------- /dev/watchdog0 ------
watchdog0
  -> userland wanted reset time value
  -> userland wanted ping time value
------- internal kernel watchdog interface ------
atmel,at91sam9260-wdt
  -> atmel,min-heartbeat-sec
  -> atmel,max-heartbeat-sec

watchdog0 is the software interface, controlled by your userland, is it 
always on top of the hardware watchdog and it calls the watchdog_ops 
hooks, like watchdog_ops->start(), watchdog_ops->stop(), or 
watchdog_ops->set_timeout() for this driver depending on the userland 
willingness to (re)start, stop the watchdog or change the hardware 
timeout value.

watchdog0 have two configurable values, reset time and ping time, the 
default is 60s for timeout and 30s for ping (the 61s you are 
seeing is the default timeout value).

For example, the watchdog binary from BusyBox allows you to set the 
watchdog0 reset and ping time using -T and -t arguments:
    -T N    Reboot after N seconds if not reset (default 60)
    -t N    Reset every N seconds (default 30)

The -T value is sent to the hardware driver using the 
watchdog_ops->set_timeout() hook. The -t value is how often you want the 
watchdog to be (re)started using the watchdog_ops->start() hook.

In a perfect world, the watchdog_ops->set_timeout() hook should be able 
to precisely set the hardware timeout you want, but there is two 
problems here:

  - 60 secs timeout is more than supported by this hardware watchdog, 
which have a maximum timeout value of 16 secs. The driver is able to 
return to userland that wanted values are not acceptable, but it would 
means the default watchdog values wouldn't work.

  - This hardware watchdog is a bit special: its period cannot be 
changed once started, usually the hardware timeout follows the watchdog0 
timeout value wanted by userspace but that's not possible here. That's 
why this driver is using its own heartbeat software timer to reset the 
hardware watchdog more often than actually asked by userland. Thus, 
because we are resetting on your own the hardware watchdog it means that 
once the software watchdog embedded into this driver expire there is 
still the hardware watchdog to expire.

We try to reset the watchdog counter 4 or 2 times more often than 
actually requested, in order to avoid spurious watchdog reset. For the 4 
times case (the default), we get a hardware timeout between 12 and 16 
secs.

Conclusion, if you want a fast reset, you have to use a lower 
atmel,max-heartbeat-sec value as well as using low values for the 
timeouts values passed to kernel through the watchdog interface 
"watchdog -T -t".

I wonder if we should substract from the watchdog_ops->set_timeout() 
new_timeout argument value the previously set hardware timeout period, 
this way we would have a "60 - 16 + 12~16" instead of a "60 + 12~16" 
watchdog timeout. If someone agree I will propose a patch to do that.


> / # killall watchdog
> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped!
> [ 1821.123123] watchdog watchdog0: watchdog did not stop!

60 seconds software timeout, this is the default set by userland tools.

> [ 1882.294294] at91sam9_wdt: I will reset your machine !

Then 12 to 16 seconds timeout, this is the hardware timeout.


Sylvain

at91sam9: watchdog: period

[Jiří Prchal]

Thanks Sylvain,
good explanation, now it's clear for me.
It works!
The problem is SOLVED!

On 6.10.2015 20:03, Sylvain Rochet wrote:
> Hi Ji??,
>
> On Fri, May 15, 2015 at 09:16:37AM +0200, Ji?? Prchal wrote:
>> Hi all,
>> I'm trying to discover what's wrong with watchdog on my board. I didn't find
>> anything about it on internet so I would ask you for help.
>> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors
>> to GND. Frequency seems to be good since hwclock (RTC) runs pretty precisely
>> powered from backup and main power too (no NTP). But watchdog time to reset
>> is still 61s regardless default (16s) or 4s heartbeat setting. No change to
>> WDT_MR in bootstrap, so in Linux should work.
>
> I'm a bit late here but it looks like there is a misunderstanding about
> the watchdog stack involved here:
>
> userland
> ------- /dev/watchdog0 ------
> watchdog0
>    -> userland wanted reset time value
>    -> userland wanted ping time value
> ------- internal kernel watchdog interface ------
> atmel,at91sam9260-wdt
>    -> atmel,min-heartbeat-sec
>    -> atmel,max-heartbeat-sec
>
> watchdog0 is the software interface, controlled by your userland, is it
> always on top of the hardware watchdog and it calls the watchdog_ops
> hooks, like watchdog_ops->start(), watchdog_ops->stop(), or
> watchdog_ops->set_timeout() for this driver depending on the userland
> willingness to (re)start, stop the watchdog or change the hardware
> timeout value.
>
> watchdog0 have two configurable values, reset time and ping time, the
> default is 60s for timeout and 30s for ping (the 61s you are
> seeing is the default timeout value).
>
> For example, the watchdog binary from BusyBox allows you to set the
> watchdog0 reset and ping time using -T and -t arguments:
>      -T N    Reboot after N seconds if not reset (default 60)
>      -t N    Reset every N seconds (default 30)
>
> The -T value is sent to the hardware driver using the
> watchdog_ops->set_timeout() hook. The -t value is how often you want the
> watchdog to be (re)started using the watchdog_ops->start() hook.
>
> In a perfect world, the watchdog_ops->set_timeout() hook should be able
> to precisely set the hardware timeout you want, but there is two
> problems here:
>
>    - 60 secs timeout is more than supported by this hardware watchdog,
> which have a maximum timeout value of 16 secs. The driver is able to
> return to userland that wanted values are not acceptable, but it would
> means the default watchdog values wouldn't work.
>
>    - This hardware watchdog is a bit special: its period cannot be
> changed once started, usually the hardware timeout follows the watchdog0
> timeout value wanted by userspace but that's not possible here. That's
> why this driver is using its own heartbeat software timer to reset the
> hardware watchdog more often than actually asked by userland. Thus,
> because we are resetting on your own the hardware watchdog it means that
> once the software watchdog embedded into this driver expire there is
> still the hardware watchdog to expire.
>
> We try to reset the watchdog counter 4 or 2 times more often than
> actually requested, in order to avoid spurious watchdog reset. For the 4
> times case (the default), we get a hardware timeout between 12 and 16
> secs.
>
> Conclusion, if you want a fast reset, you have to use a lower
> atmel,max-heartbeat-sec value as well as using low values for the
> timeouts values passed to kernel through the watchdog interface
> "watchdog -T -t".
>
> I wonder if we should substract from the watchdog_ops->set_timeout()
> new_timeout argument value the previously set hardware timeout period,
> this way we would have a "60 - 16 + 12~16" instead of a "60 + 12~16"
> watchdog timeout. If someone agree I will propose a patch to do that.
>
>
>> / # killall watchdog
>> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped!
>> [ 1821.123123] watchdog watchdog0: watchdog did not stop!
>
> 60 seconds software timeout, this is the default set by userland tools.
>
>> [ 1882.294294] at91sam9_wdt: I will reset your machine !
>
> Then 12 to 16 seconds timeout, this is the hardware timeout.
>
>
> Sylvain
>

at91sam9: watchdog: period

[Sylvain Rochet]

Hi,

On Tue, Oct 06, 2015 at 08:03:43PM +0200, Sylvain Rochet wrote:
> 
> I wonder if we should substract from the watchdog_ops->set_timeout() 
> new_timeout argument value the previously set hardware timeout period, 
> this way we would have a "60 - 16 + 12~16" instead of a "60 + 12~16" 
> watchdog timeout. If someone agree I will propose a patch to do that.

A night of thinking later, it may sounds appealing but this is a stupid 
idea. We have an overlap hard to deal with if user chooses a ping time 
close to the timeout (e.g.: 60s timeout, 55s ping time), it sounds 
stupid to do so but we can't prevent nor check that. So let's keep it 
simple.

Sylvain