Watchdog on MPC82xx

Watchdog on MPC82xx

[Bastos Fernandez Alexandre]

Hi list,

I am trying to use the on-chip watchdog timer in the MPC8248 to
recover from system hangs.

I have been following the guidelines from the changes I have found
from Compulab.

In u-boot, the watchdog is activated and works fine. The changes in
the kernel are, basically, assigning the ppd_md.heartbeat to a function
which resets the watchdog. This is supposed to start reseting the wdt
after ppc_md.setup_arch is invoked, but this is not working, and the
kernel keeps rebooting during startup.

I have tried to catch the point when this happens to force a WD service
sequence before that, but I had no success.

So, can anyone give me some guidelines for this job? I have seen from
freescale docs that MPC83xx watchdog may be the same than MPC82xx one.
So, could I use the same approach than used on MPC83xx boards?

http://patchwork.ozlabs.org/linuxppc//patch?id=4118


Thanks in advance

Alex

Re: Watchdog on MPC82xx

[Bastos Fernandez Alexandre]

> So, can anyone give me some guidelines for this job? I have seen from
> freescale docs that MPC83xx watchdog may be the same than MPC82xx one.
> So, could I use the same approach than used on MPC83xx boards?
>
> http://patchwork.ozlabs.org/linuxppc//patch?id=4118
>

Though Freescales doc for MPC83xx says:

• Functional and programming compatibility with MPC8260 watchdog timer

further reading shows that there is a "little" difference. MPC83xx can
come out of reset with WDT disabled, while MPC82xx can't. So the approach
for MPC83xx is not possible on those other systems.

So, any other idea? Is the WDT on MPC8248 usable at all?

Thanks,

Alex

Re: Watchdog on MPC82xx

[Mike Rapoport]

Bastos Fernandez Alexandre wrote:

>
>So, any other idea? Is the WDT on MPC8248 usable at all?
>  
>
I used the watchdog timer on mpc8247 and mpc8271. The mpc8248 watchdog 
should be the same. I used ppc_md.heartbeat to write to the watchdog 
registers and it worked fine. Also, I've added WATCHDOG_RESET()  to 
common/cmd_bootm.c in U-Boot just before the jump to kernel.

>Thanks,
>
>Alex
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>  
>


-- 
Sincerely yours,
Mike Rapoport
-----------------------------------------------------------------
CompuLab Ltd.
Web: http://www.compulab.co.il

RE: Watchdog on MPC82xx

[Bastos Fernandez Alexandre]

Mike,

I tested several times last week but it didn't work for me.
I had made the changes in U-boot as you say, but it keeped
reseting at the time. In fact, in the log_buf I can see
several printk's after setup_arch (where ppc_md.heartbeat)
is assigned, but the watchdog counter is not reloaded.

Which could be the difference? I am using ramdisk,
and a MPC8248 clocked at 100MHz, but I don't think
this will be the reason.

Now, someone has proposed me to try reloading WDT in
printk calls. I will test.

Best regards,

Alex



> Bastos Fernandez Alexandre wrote:
> 
> >
> >So, any other idea? Is the WDT on MPC8248 usable at all?
> >  
> >
> I used the watchdog timer on mpc8247 and mpc8271. The mpc8248 watchdog 
> should be the same. I used ppc_md.heartbeat to write to the watchdog 
> registers and it worked fine. Also, I've added WATCHDOG_RESET()  to 
> common/cmd_bootm.c in U-Boot just before the jump to kernel.
> 
> >Thanks,
> >
> >Alex
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
> >  
> >
> 
> 
> -- 
> Sincerely yours,
> Mike Rapoport
> -----------------------------------------------------------------
> CompuLab Ltd.
> Web: http://www.compulab.co.il

Re: Watchdog on MPC82xx

[Bastos Fernandez Alexandre]

Well,

I have tested two different approaches which has been confirmed
to be already working on MPC82xx boards.

One, from Paul Bilke, is based on modifiying printk to service
the WDT and reload the counter during boot time.
So I have modified kernel/printk.c and tested with this:

asmlinkage int printk(const char *fmt, ...)
{
    va_list args;
    int r;

    force_wdt_reload();
    [...]
}

#define SWSR_ADDR (CPM_MAP_ADDR + 0x1000E)

void force_wdt_reload(void)
{
    unsigned short *swsr_ptr = (unsigned short *)ioremap(SWSR_ADDR,0x2);

    (*swsr_ptr) = (unsigned short) 0x556c;
    (*swsr_ptr) = (unsigned short) 0xaa39;
}

Paul has reported changing printk works for him on several MPC82xx boards.

Second one is from Mike Rapoport from Compulab. Is the heartbeat
method. I have added and additional call in m82xx_board_setup()
which should reset the WDT for the first time in setup_arch():

static __inline__ void reset_8260_watchdog(void)
{
    cpm2_immr->im_siu_conf.siu_82xx.sc_swsr = 0x556c;
    cpm2_immr->im_siu_conf.siu_82xx.sc_swsr = 0xaa39;
}

void __init
m82xx_board_setup(void)
{
    volatile cpm2_map_t *immap = cpm2_immr;

    reset_8260_watchdog();

    ppc_md.heartbeat = m82xx_heartbeat;
    ppc_md.heartbeat_reset = HZ/2;
    ppc_md.heartbeat_count = 1;

}

Mike has reported the heartbeat method is working for him
on MPC8247 and MPC8271 boards with kernel 2.6.12.3.


I have tested both in a MCP8248 based board, with kernel
2.6.15 and u-boot 1.1.4 and I have no success. I can see
the __log_buf after the reset caused by de WDT and there
are several printk's done. I have put printk's to the
reset_8260_watchdog(), and I can see them also, so I
should suppose it is executed, but the board keeps reseting.
Furthermore, u-boot is doing OK the WDT job (with changes done
from Compulab).

I have dissasambled that, and for example:

c01c93b8 <m82xx_board_setup>:
c01c93b8: 3d 40 c0 1e     lis     r10,-16354
c01c93bc: 38 00 55 6c     li      r0,21868
c01c93c0: 81 2a 81 8c     lwz     r9,-32372(r10)
c01c93c4: 3d 09 00 01     addis   r8,r9,1
c01c93c8: b0 08 00 0e     sth     r0,14(r8)
c01c93cc: 81 68 0d 50     lwz     r11,3408(r8)
c01c93d0: 81 2a 81 8c     lwz     r9,-32372(r10)
c01c93d4: 75 60 08 00     andis.  r0,r11,2048
c01c93d8: 38 00 aa 39     li      r0,-21959
c01c93dc: 3d 29 00 01     addis   r9,r9,1
c01c93e0: b0 09 00 0e     sth     r0,14(r9)
c01c93e4: 41 82 00 44     beq-    c01c9428 <m82xx_board_setup+0x70>

[...]

which looks OK for me (but I am not an expert).

So, could someone give me some guideline about what could
be happening?. Should I downgrade to 2.6.12.3 and test?
Is the WDT being reloaded at least one time and then
failing to reset? Some idea on how to debug that?

Thanks


Alex BASTOS

P.S. The __log_buf
 3c353e4c 696e7578 20766572 73696f6e    <5>Linux version
 20322e36 2e313520 28616c65 62617340     2.6.15 (alebas@
 54523339 32292028 67636320 76657273    xxxx) (gcc vers
 696f6e20 332e332e 32292023 33392050    ion 3.3.2) #39 P
 5245454d 50542054 75652041 70722031    REEMPT Tue Apr 1
 38203135 3a32353a 33392043 45535420    8 15:25:39 CEST
 32303036 0a3c363e 54656c65 76657320    2006.<6>Televes
 446f4338 32343820 436f6d70 75746572    XXX8248 Computer
 2d6f6e2d 4d6f6475 6c652070 6f72740a    -on-Module port.
 3c373e4f 6e206e6f 64652030 20746f74    <7>On node 0 tot
 616c7061 6765733a 20313633 38340a3c    alpages: 16384.<
 373e2020 444d4120 7a6f6e65 3a203136    7>  DMA zone: 16
 33383420 70616765 732c204c 49464f20    384 pages, LIFO
 62617463 683a330a 3c373e20 20444d41    batch:3.<7>  DMA
 3332207a 6f6e653a 20302070 61676573    32 zone: 0 pages
 2c204c49 464f2062 61746368 3a300a3c    , LIFO batch:0.<
 373e2020 4e6f726d 616c207a 6f6e653a    7>  Normal zone:
 20302070 61676573 2c204c49 464f2062     0 pages, LIFO b
 61746368 3a300a3c 373e2020 48696768    atch:0.<7>  High
 4d656d20 7a6f6e65 3a203020 70616765    Mem zone: 0 page
 732c204c 49464f20 62617463 683a300a    s, LIFO batch:0.
 3c343e42 75696c74 2031207a 6f6e656c    <4>Built 1 zonel
 69737473 0a3c353e 4b65726e 656c2063    ists.<5>Kernel c
 6f6d6d61 6e64206c 696e653a 20726f6f    ommand line: roo
 743d2f64 65762f72 616d3020 72772063    t=/dev/ram0 rw c
 6f6e736f 6c653d74 74794350 4d0a3c35    onsole=ttyCPM.<5
 3e596f75 20617265 20617420 4f6e650a    >You are at One.
 3c343e50 49442068 61736820 7461626c    <4>PID hash tabl
 6520656e 74726965 733a2035 31322028    e entries: 512 (
 6f726465 723a2039 2c203831 00000000    order: 9, 81....
 00000000 00000000 00000000 00000000    ................

RE: Watchdog on MPC82xx

[Rune Torgersen]

On our 8265/8280 board, the max timeout of the watchdog timer was ~1.3
seconds, so it kept resetting before the heartbeat function got called
on boot.

I had to add a watchdog reset to time_init() because it woud pause there
for about 2 secondfs trying to see if there was a realtime clock.=20

> -----Original Message-----
> From: linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.or
> g] On Behalf Of Bastos Fernandez Alexandre
> Sent: Wednesday, April 19, 2006 06:14
> To: linuxppc-embedded list
> Subject: Re: Watchdog on MPC82xx
>=20
> Well,
>=20
> I have tested two different approaches which has been confirmed
> to be already working on MPC82xx boards.
>=20
> One, from Paul Bilke, is based on modifiying printk to service
> the WDT and reload the counter during boot time.
> So I have modified kernel/printk.c and tested with this:
>=20
> asmlinkage int printk(const char *fmt, ...)
> {
>     va_list args;
>     int r;
>=20
>     force_wdt_reload();
>     [...]
> }
>=20
> #define SWSR_ADDR (CPM_MAP_ADDR + 0x1000E)
>=20
> void force_wdt_reload(void)
> {
>     unsigned short *swsr_ptr =3D (unsigned short=20
> *)ioremap(SWSR_ADDR,0x2);
>=20
>     (*swsr_ptr) =3D (unsigned short) 0x556c;
>     (*swsr_ptr) =3D (unsigned short) 0xaa39;
> }
>=20
> Paul has reported changing printk works for him on several=20
> MPC82xx boards.
>=20
> Second one is from Mike Rapoport from Compulab. Is the heartbeat
> method. I have added and additional call in m82xx_board_setup()
> which should reset the WDT for the first time in setup_arch():
>=20
> static __inline__ void reset_8260_watchdog(void)
> {
>     cpm2_immr->im_siu_conf.siu_82xx.sc_swsr =3D 0x556c;
>     cpm2_immr->im_siu_conf.siu_82xx.sc_swsr =3D 0xaa39;
> }
>=20
> void __init
> m82xx_board_setup(void)
> {
>     volatile cpm2_map_t *immap =3D cpm2_immr;
>=20
>     reset_8260_watchdog();
>=20
>     ppc_md.heartbeat =3D m82xx_heartbeat;
>     ppc_md.heartbeat_reset =3D HZ/2;
>     ppc_md.heartbeat_count =3D 1;
>=20
> }
>=20
> Mike has reported the heartbeat method is working for him
> on MPC8247 and MPC8271 boards with kernel 2.6.12.3.
>=20
>=20
> I have tested both in a MCP8248 based board, with kernel
> 2.6.15 and u-boot 1.1.4 and I have no success. I can see
> the __log_buf after the reset caused by de WDT and there
> are several printk's done. I have put printk's to the
> reset_8260_watchdog(), and I can see them also, so I
> should suppose it is executed, but the board keeps reseting.
> Furthermore, u-boot is doing OK the WDT job (with changes done
> from Compulab).
>=20
> I have dissasambled that, and for example:
>=20
> c01c93b8 <m82xx_board_setup>:
> c01c93b8: 3d 40 c0 1e     lis     r10,-16354
> c01c93bc: 38 00 55 6c     li      r0,21868
> c01c93c0: 81 2a 81 8c     lwz     r9,-32372(r10)
> c01c93c4: 3d 09 00 01     addis   r8,r9,1
> c01c93c8: b0 08 00 0e     sth     r0,14(r8)
> c01c93cc: 81 68 0d 50     lwz     r11,3408(r8)
> c01c93d0: 81 2a 81 8c     lwz     r9,-32372(r10)
> c01c93d4: 75 60 08 00     andis.  r0,r11,2048
> c01c93d8: 38 00 aa 39     li      r0,-21959
> c01c93dc: 3d 29 00 01     addis   r9,r9,1
> c01c93e0: b0 09 00 0e     sth     r0,14(r9)
> c01c93e4: 41 82 00 44     beq-    c01c9428 <m82xx_board_setup+0x70>
>=20
> [...]
>=20
> which looks OK for me (but I am not an expert).
>=20
> So, could someone give me some guideline about what could
> be happening?. Should I downgrade to 2.6.12.3 and test?
> Is the WDT being reloaded at least one time and then
> failing to reset? Some idea on how to debug that?
>=20
> Thanks
>=20
>=20
> Alex BASTOS
>=20
> P.S. The __log_buf
>  3c353e4c 696e7578 20766572 73696f6e    <5>Linux version
>  20322e36 2e313520 28616c65 62617340     2.6.15 (alebas@
>  54523339 32292028 67636320 76657273    xxxx) (gcc vers
>  696f6e20 332e332e 32292023 33392050    ion 3.3.2) #39 P
>  5245454d 50542054 75652041 70722031    REEMPT Tue Apr 1
>  38203135 3a32353a 33392043 45535420    8 15:25:39 CEST
>  32303036 0a3c363e 54656c65 76657320    2006.<6>Televes
>  446f4338 32343820 436f6d70 75746572    XXX8248 Computer
>  2d6f6e2d 4d6f6475 6c652070 6f72740a    -on-Module port.
>  3c373e4f 6e206e6f 64652030 20746f74    <7>On node 0 tot
>  616c7061 6765733a 20313633 38340a3c    alpages: 16384.<
>  373e2020 444d4120 7a6f6e65 3a203136    7>  DMA zone: 16
>  33383420 70616765 732c204c 49464f20    384 pages, LIFO
>  62617463 683a330a 3c373e20 20444d41    batch:3.<7>  DMA
>  3332207a 6f6e653a 20302070 61676573    32 zone: 0 pages
>  2c204c49 464f2062 61746368 3a300a3c    , LIFO batch:0.<
>  373e2020 4e6f726d 616c207a 6f6e653a    7>  Normal zone:
>  20302070 61676573 2c204c49 464f2062     0 pages, LIFO b
>  61746368 3a300a3c 373e2020 48696768    atch:0.<7>  High
>  4d656d20 7a6f6e65 3a203020 70616765    Mem zone: 0 page
>  732c204c 49464f20 62617463 683a300a    s, LIFO batch:0.
>  3c343e42 75696c74 2031207a 6f6e656c    <4>Built 1 zonel
>  69737473 0a3c353e 4b65726e 656c2063    ists.<5>Kernel c
>  6f6d6d61 6e64206c 696e653a 20726f6f    ommand line: roo
>  743d2f64 65762f72 616d3020 72772063    t=3D/dev/ram0 rw c
>  6f6e736f 6c653d74 74794350 4d0a3c35    onsole=3DttyCPM.<5
>  3e596f75 20617265 20617420 4f6e650a    >You are at One.
>  3c343e50 49442068 61736820 7461626c    <4>PID hash tabl
>  6520656e 74726965 733a2035 31322028    e entries: 512 (
>  6f726465 723a2039 2c203831 00000000    order: 9, 81....
>  00000000 00000000 00000000 00000000    ................
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20

Re: Watchdog on MPC82xx

[Bastos Fernandez Alexandre]

Mark,

>
> I haven't been following this closely, but are you sure it's a WDT
> reset?  You can tell from the Reset Status Register (RSR).
> u-boot prints out a decode of this register, which also clears the
> bits, so you have to go by the printout when u-boot starts to see
> why the last reset occurred.

U-boot is reporting the Watchdog reset. You can see:

U-Boot 1.1.4 (Apr 11 2006 - 14:39:01)

MPC8272 Reset Status: Software Watchdog, External Soft, External Hard

MPC8272 Clock Configuration
 - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq  25-75 , Core Freq 100-300
 - dfbrg 1, corecnf 0x1a, busdf 3, cpmdf 1, plldf 0, pllmf 3
 - vco_out  400000000, scc_clk  100000000, brg_clk   25000000
 - cpu_clk  400000000, cpm_clk  200000000, bus_clk  100000000
 - pci_clk   66666666

CPU:   MPC8272 (HiP7 Rev 14, Mask 1.0 1K50M) at 400 MHz
Board: Televes XXX8248
       Watchdog enabled


>
> Just trying to help brainstorm...
>
> Mark Chambers
>

Thanks,

Alex Bastos

RE: Watchdog on MPC82xx

[Pelton, Dave]

Alex,

I have recently been trying to get the internal watchdog timer working
with 2.6.15 on a MPC8247 custom board (@ 266MHz), and hence I have been
following this thread with great interest.

I tried the heartbeat method (setting ppc_md.heartbeat to kick the
watchdog) and I was unable to get it to work correctly.  To help things
I tried sprinkling a few kicks of the watchdog through the early layers
of init code but this seemed to make no difference.

I also tried porting the mpc8xx watchdog driver to the mpc82xx
architecture (i.e. kicking the watchdog using the PIT interrupt).  This
seemed to fail in the same way.  I would see about 8 or 10 characters of
the initial start-up message (where it dumps the Linux version and the
build time) and then the watchdog would kick the card back to u-boot.

As a last resort I tried kicking the watchdog in the printk call (in
essentially the same way that you do below), and I found that this
worked correctly when used in conjunction with the ported version of the
mpc8xx watchdog driver.  I suspect it would work equally well with the
heartbeat method.

I don't understand why kicking the watchdog from printk fixes things,
and it really seems like an ugly way to fix this problem.  I did the
quick math to figure out how long it will take the watchdog to trigger,
and at my clock rate of 266MHz, the watchdog fires in about 0.5 seconds,
which means that anything that runs for longer than 0.25 seconds could
cause a watchdog trigger.  My best guess is that within printk there is
something that exceeds this margin, but looking in the code I can not
see what that would be (unless draining the printk console output over
the ttyCPM0 serial port somehow takes a long time).


Perhaps some of the wise ones on the list could provide some suggestions
on why printk seems to be the sticking point for the watchdog.


- David Pelton.


-----Original Message-----
Sent: Wednesday, April 19, 2006 7:14 AM
To: linuxppc-embedded list
Subject: Re: Watchdog on MPC82xx

Well,

I have tested two different approaches which has been confirmed to be
already working on MPC82xx boards.

One, from Paul Bilke, is based on modifiying printk to service the WDT
and reload the counter during boot time.
So I have modified kernel/printk.c and tested with this:

asmlinkage int printk(const char *fmt, ...) {
    va_list args;
    int r;

    force_wdt_reload();
    [...]
}


<< snip >>

RE: Watchdog on MPC82xx

[Bastos Fernandez Alexandre]

Rune,

> On our 8265/8280 board, the max timeout of the watchdog timer was ~1.3
> seconds, so it kept resetting before the heartbeat function got called
> on boot.
>
> I had to add a watchdog reset to time_init() because it woud pause there
> for about 2 secondfs trying to see if there was a realtime clock.
>

I think that you are OK. Using the while(1) test suggested by Paul Bilke,
I could verify that time_init() is the cause for the reset. In fact, I have
no RTC on my board (so I suppose the delay looking for it will be maximum).

Thanks

Alex Bastos