Book-E watchdog driver questions
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Mike Nuss
Hi,
I have a PPC440EPx and I am testing out the builtin watchdog. I have a couple of questions:
Is there a reason that
booke_wdt.cdoes not specify aMODULE_LICENSE?Quoted 1 line
From the copyright notice at the top it appears to be GPL. As written,
it taints the kernel.
Odd, no reason. I'll submit a patch for that.
Quoted 2 lines
Also, if I test out the driver by killing my process that's doing the pinging, I get a kernel panic:
Its been a while since i've tried this. I'll try it out and see what happens.
- k
Quoted 5 lines
Quoted 4 lines
Is there a reason that
booke_wdt.cdoes not specify aMODULE_LICENSE?Quoted 2 lines
From the copyright notice at the top it appears to be GPL. As written,
it taints the kernel.
Quoted 7 lines
Odd, no reason. I'll submit a patch for that.
Quoted 2 lines
Also, if I test out the driver by killing my process that's doing the pinging, I get a kernel panic:
Its been a while since i've tried this. I'll try it out and see what happens.
I also found that GETBOOTSTATUS returns 0 after the reboot. Looking at the source code I found the comment "XXX: something is clearing TSR" - I take that to mean that the register is being cleared by something before the module tries to read it? In my case U-Boot may be clearing that - I can take a look.
Mike
Quoted 5 lines · Mike Nuss
Quoted 5 lines
Quoted 4 lines
Is there a reason that
booke_wdt.cdoes not specify aMODULE_LICENSE?Quoted 2 lines
From the copyright notice at the top it appears to be GPL. As written,
it taints the kernel.
Quoted 7 lines
Quoted 7 lines
Odd, no reason. I'll submit a patch for that.
Quoted 2 lines
Also, if I test out the driver by killing my process that's doing the pinging, I get a kernel panic:
Its been a while since i've tried this. I'll try it out and see what happens.
The kernel panic was caused because TCR: WIE was set. This bit should not be set, because it causes the timer to generate an interrupt that the kernel does not handle.
Quoted 6 lines
I also found that GETBOOTSTATUS returns 0 after the reboot. Looking at the source code I found the comment "XXX: something is clearing TSR" - I take that to mean that the register is being cleared by something before the module tries to read it? In my case U-Boot may be clearing that - I can take a look.
It turns out that the status bits in TSR are undefined at poweron reset. Boards require external logic to detect POR - this is described in AMCC's app note for the WDT. Because of this, U-Boot clears TSR early on in the standard 4xx firmware (in start.S). To use TSR to detect a watchdog reset, U-Boot must be modified to check that logic and only clear the bits at POR. Those bits will be preserved until the kernel driver looks at them, or until the system is powered off. So the driver is correct here, but the comment should be updated to explain why the GETBOOTSTATUS value may not be meaningful - it requires additional hardware and firmware support.
I can submit a patch for these issues if you like.
Mike