[U-Boot] ppc44x - watchdog timers reboots during the image loading
On my 460ex board, i've tried to add CONFIG_WATCHDOG to the config and it appears to work until the board tries to boot. At that point I can count down about 10 seconds and the reboot happens. The 10s correlates with what I think the watchdog is being set to. I've inserted some WATCHDOG_RESET() invocations wrapping memmove_wd (which admittedly should not be needed), but it does not have an effect. The last message I see is ...
Verifying Checksum ... OK ## Flattened Device Tree blob at ff3e0000 Booting using the fdt blob at 0xff3e0000 Uncompressing Kernel Image ... OK Loading Device Tree to 007fa000, end 007ffd2f ... OK Loading Ramdisk to 1ec58000, end 1efffc0c ... OK
Then it instantly resets. If I remove CONFIG_WATCHDOG the board works and boots correctly. My u-boot is circa early 2009. From looking at the current u-boot it does not have the tcr and tsr registers "converted to uppercase", so I don't think it builds yet. I've verified the addresses of the spr and they look correct.
Any thoughts or help are appreciated. I did notice the comments in cpu-init.c that my tcr is setup with 0xF0000000, I *think* this is actually 10s on a 800MHz board. Not sure where the 2.684 numbers originates as stated in the comments. I also changed the acknowledge of the watchdog to the following, though neither my changes nor the original have any effect. I've also verified that the code is getting included and built. Not sure what to try next.
void reset_4xx_watchdog(void) { /* * Clear TSR(WIS) bit */ mtspr(tsr, 0xC0000000); } #endif /* CONFIG_WATCHDOG */
On Thu, Sep 30, 2010 at 3:15 PM, ame ayman@phx1-ss-2-lb.cnet.com wrote:
On my 460ex board, i've tried to add CONFIG_WATCHDOG to the config and it appears to work until the board tries to boot. At that point I can count down about 10 seconds and the reboot happens. The 10s correlates with what I think the watchdog is being set to. I've inserted some WATCHDOG_RESET() invocations wrapping memmove_wd (which admittedly should not be needed), but it does not have an effect.
Looks to me like your implementation of WATCHDOG_RESET() is broken. It's not actually resetting the watchdog. That's what you should debug.
On Thu, Sep 30, 2010 at 03:48:36PM -0500, Timur Tabi wrote:
On Thu, Sep 30, 2010 at 3:15 PM, ame ayman@phx1-ss-2-lb.cnet.com wrote:
On my 460ex board, i've tried to add CONFIG_WATCHDOG to the config and it appears to work until the board tries to boot. ?At that point I can count down about 10 seconds and the reboot happens. ?The 10s correlates with what I think the watchdog is being set to. ?I've inserted some WATCHDOG_RESET() invocations wrapping memmove_wd (which admittedly should not be needed), but it does not have an effect.
Looks to me like your implementation of WATCHDOG_RESET() is broken. It's not actually resetting the watchdog. That's what you should debug.
I suspect that that is the case, but trawling through the u-boot code it appears that WATCHDOG_RESET is a macro that eventually does one of two things: a) if asm, bl watchdog_reset b) if c, watchdog_reset()
watchdog_reset in turn saves the interrupt state, disables interrupts, invokes reset_4xx_watchdog, then restores the interrupt state.
Finally reset_4xx_watchdog does mtspr(tsr, 0xc0000000) where tsr is 0x150 IIRC.
All of this is in the u-boot source, mostly in cpu.c and watchdog.h (i.e. none of this is custom for my board, it is part of the ppc44x code).
I've dumped the binary to make sure the methods are actually in the code, manipulating the spr, and getting called.
ame
ame wrote:
Finally reset_4xx_watchdog does mtspr(tsr, 0xc0000000) where tsr is 0x150 IIRC.
My guess is that this code doesn't actually reset the watchdog. Perhaps your value of TSR is wrong, or 0xc0000000 is wrong, or perhaps there's some other watchdog active that you're ignoring.
On Thursday 30 September 2010 22:15:04 ame wrote:
On my 460ex board, i've tried to add CONFIG_WATCHDOG to the config and it appears to work until the board tries to boot. At that point I can count down about 10 seconds and the reboot happens. The 10s correlates with what I think the watchdog is being set to. I've inserted some WATCHDOG_RESET() invocations wrapping memmove_wd (which admittedly should not be needed), but it does not have an effect. The last message I see is ...
Verifying Checksum ... OK ## Flattened Device Tree blob at ff3e0000 Booting using the fdt blob at 0xff3e0000 Uncompressing Kernel Image ... OK Loading Device Tree to 007fa000, end 007ffd2f ... OK Loading Ramdisk to 1ec58000, end 1efffc0c ... OK
Then it instantly resets. If I remove CONFIG_WATCHDOG the board works and boots correctly. My u-boot is circa early 2009. From looking at the current u-boot it does not have the tcr and tsr registers "converted to uppercase", so I don't think it builds yet. I've verified the addresses of the spr and they look correct.
Please check again. Here the current source:
arch/powerpc/cpu/ppc4xx/cpu.c:
... void reset_4xx_watchdog(void) { /* * Clear TSR(WIS) bit */ mtspr(SPRN_TSR, 0x40000000); } ...
Definitely upper-case here.
Any thoughts or help are appreciated. I did notice the comments in cpu-init.c that my tcr is setup with 0xF0000000, I *think* this is actually 10s on a 800MHz board. Not sure where the 2.684 numbers originates as stated in the comments. I also changed the acknowledge of the watchdog to the following, though neither my changes nor the original have any effect. I've also verified that the code is getting included and built. Not sure what to try next.
Note that you need to enable the watchdog support in the Linux kernel as well. Otherwise Linux will of course reset once the watchdog timer times out. Did you enable the book-e watchdog timer in Linux?
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
On Fri, Oct 01, 2010 at 03:35:14PM +0200, Stefan Roese wrote:
On Thursday 30 September 2010 22:15:04 ame wrote:
On my 460ex board, i've tried to add CONFIG_WATCHDOG to the config and it appears to work until the board tries to boot. At that point I can count down about 10 seconds and the reboot happens. The 10s correlates with what I think the watchdog is being set to. I've inserted some WATCHDOG_RESET() invocations wrapping memmove_wd (which admittedly should not be needed), but it does not have an effect. The last message I see is ...
Verifying Checksum ... OK ## Flattened Device Tree blob at ff3e0000 Booting using the fdt blob at 0xff3e0000 Uncompressing Kernel Image ... OK Loading Device Tree to 007fa000, end 007ffd2f ... OK Loading Ramdisk to 1ec58000, end 1efffc0c ... OK
Then it instantly resets. If I remove CONFIG_WATCHDOG the board works and boots correctly. My u-boot is circa early 2009. From looking at the current u-boot it does not have the tcr and tsr registers "converted to uppercase", so I don't think it builds yet. I've verified the addresses of the spr and they look correct.
Please check again. Here the current source:
arch/powerpc/cpu/ppc4xx/cpu.c:
... void reset_4xx_watchdog(void) { /* * Clear TSR(WIS) bit */ mtspr(SPRN_TSR, 0x40000000); } ...
Definitely upper-case here.
Ok, confirmed the new one has it in there. sorry about that. The logic is the same as the one that is in the old code though.
Any thoughts or help are appreciated. I did notice the comments in cpu-init.c that my tcr is setup with 0xF0000000, I *think* this is actually 10s on a 800MHz board. Not sure where the 2.684 numbers originates as stated in the comments. I also changed the acknowledge of the watchdog to the following, though neither my changes nor the original have any effect. I've also verified that the code is getting included and built. Not sure what to try next.
Note that you need to enable the watchdog support in the Linux kernel as well. Otherwise Linux will of course reset once the watchdog timer times out. Did you enable the book-e watchdog timer in Linux?
Yes, that is enabled. But from the looks of the boot trace up above, am I correct in saying that it never even made it to Linux? Isn't u-boot still in control at the point that it loads the ramdisk into ram?
Thanks ayman
On Friday 01 October 2010 16:37:55 ame wrote:
void reset_4xx_watchdog(void) {
/*
* Clear TSR(WIS) bit */mtspr(SPRN_TSR, 0x40000000);
} ...
Definitely upper-case here.
Ok, confirmed the new one has it in there. sorry about that. The logic is the same as the one that is in the old code though.
Sure.
Any thoughts or help are appreciated. I did notice the comments in cpu-init.c that my tcr is setup with 0xF0000000, I *think* this is actually 10s on a 800MHz board. Not sure where the 2.684 numbers originates as stated in the comments. I also changed the acknowledge of the watchdog to the following, though neither my changes nor the original have any effect. I've also verified that the code is getting included and built. Not sure what to try next.
Note that you need to enable the watchdog support in the Linux kernel as well. Otherwise Linux will of course reset once the watchdog timer times out. Did you enable the book-e watchdog timer in Linux?
Yes, that is enabled. But from the looks of the boot trace up above, am I correct in saying that it never even made it to Linux? Isn't u-boot still in control at the point that it loads the ramdisk into ram?
Sure, while loading/copying the ramdisk control is still under U-Boot. But from your first email I read:
The last message I see is ...
Verifying Checksum ... OK
## Flattened Device Tree blob at ff3e0000
Booting using the fdt blob at 0xff3e0000 Uncompressing Kernel Image ... OK Loading Device Tree to 007fa000, end 007ffd2f ... OK Loading Ramdisk to 1ec58000, end 1efffc0c ... OK
So the ramdisk is already copied. Or do I miss something here? Please check the code (add some printf's etc) to see if you are still in U-Boot or not.
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
On Fri, Oct 01, 2010 at 09:37:55AM -0500, ame wrote:
On Fri, Oct 01, 2010 at 03:35:14PM +0200, Stefan Roese wrote:
On Thursday 30 September 2010 22:15:04 ame wrote:
On my 460ex board, i've tried to add CONFIG_WATCHDOG to the config and it appears to work until the board tries to boot. At that point I can count down about 10 seconds and the reboot happens. The 10s correlates with what I think the watchdog is being set to. I've inserted some WATCHDOG_RESET() invocations wrapping memmove_wd (which admittedly should not be needed), but it does not have an effect. The last message I see is ...
Verifying Checksum ... OK ## Flattened Device Tree blob at ff3e0000 Booting using the fdt blob at 0xff3e0000 Uncompressing Kernel Image ... OK Loading Device Tree to 007fa000, end 007ffd2f ... OK Loading Ramdisk to 1ec58000, end 1efffc0c ... OK
Then it instantly resets. If I remove CONFIG_WATCHDOG the board works and boots correctly. My u-boot is circa early 2009. From looking at the current u-boot it does not have the tcr and tsr registers "converted to uppercase", so I don't think it builds yet. I've verified the addresses of the spr and they look correct.
Please check again. Here the current source:
arch/powerpc/cpu/ppc4xx/cpu.c:
... void reset_4xx_watchdog(void) { /* * Clear TSR(WIS) bit */ mtspr(SPRN_TSR, 0x40000000); } ...
Definitely upper-case here.
Ok, confirmed the new one has it in there. sorry about that. The logic is the same as the one that is in the old code though.
Well, ok, kind of. cpu.c is correct, cpu_init.c that actually sets up the watchdog timer is not though. It still has the lower case register names.
#if defined(CONFIG_WATCHDOG) val = mfspr(tcr); ... mtspr(tcr, val);
val = mfspr(tsr); val |= 0x80000000; /* enable watchdog timer */ mtspr(tsr, val); ... #endif /* CONFIG_WATCHDOG */
I've added some prints and turned on debug and find that it makes it all the way to the jump to the kernel. So it must be an issue with the setup or config of the kernel. Does the device tree require any changes to work with the watchdog? Thanks for your help.
ame
Hi ame,
On Friday 01 October 2010 17:36:39 ame wrote:
Ok, confirmed the new one has it in there. sorry about that. The logic is the same as the one that is in the old code though.
Well, ok, kind of. cpu.c is correct, cpu_init.c that actually sets up the watchdog timer is not though. It still has the lower case register names.
#if defined(CONFIG_WATCHDOG) val = mfspr(tcr); ... mtspr(tcr, val);
val = mfspr(tsr); val |= 0x80000000; /* enable watchdog timer */ mtspr(tsr, val);... #endif /* CONFIG_WATCHDOG */
Ah, correct. I missed those. I'll fix it soon. Thanks for pointing out.
I've added some prints and turned on debug and find that it makes it all the way to the jump to the kernel. So it must be an issue with the setup or config of the kernel. Does the device tree require any changes to work with the watchdog? Thanks for your help.
Depends on the watchdog device driver. The Book-E driver doesn't seem to need anything here, AFAIK. I suggest you enable the debug early-printk feature and/or look the __log_buf to see how far Linux really comes. This is not U- Boot realted any more though. So further questions/mails should be moved to linuxppc-dev.
Cheers, Stefan
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
participants (4)
-
ame -
ame -
Stefan Roese -
Timur Tabi