Watchdog on MPC82xx
Rune Torgersen
runet at innovsys.com
Thu Apr 20 00:29:09 EST 2006
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.
> -----Original Message-----
> From: linuxppc-embedded-bounces+runet=innovsys.com at ozlabs.org
> [mailto:linuxppc-embedded-bounces+runet=innovsys.com at 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
>
> 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 ................
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
More information about the Linuxppc-embedded
mailing list