watchdog vs inflate in zlib

Povolotsky, Alexander Alexander.Povolotsky at marconi.com
Thu Jan 6 02:28:54 EST 2005


I just have found while searching the web the old Linux 2.4 posting by Jan
Roelens ... and 
I am experiencing (but on newer Linux 2.6) exactly the same problem (on PPC
880) as he has mentioned:

> the linux statup code encounters
> a watchdog timeout (and thus a reset), somewhere when it is decompressing
> the ramdisk image.

I got confirmation from my board "vendor" that:
"The watch dog is enabled by the boot monitor, so it must be handled by the
loader and by the kernel too."

Also I just got addional info from my  "vendor" that: "The  timeout period
of the watchdog is 800msec."
The "vendor" also suggested that "to be sure", the watchdog should be reset
each 100msec ...

The boot monitor used is custom modified (by the board "vendor") pSOS
bootloader for which I do not have the code.
The compressed kernel image for Linux 2.6 is considerably larger than for
Linux 2.4 (which works fine with several watch dog reset calls put into
"while" loops within zlib decompression functions) - perhaps I need to put
more watch dog resets into zlib code ... ? - Any advise on where to put
those extra resets, etc. ?

Could I use the fix, posted - see below - by Jan Rowlens - have anyone tried
it on Linux 2.6 ?
What are suggested modifications I need to do to bring this fix to 2.6 ?

Thanks,
Best Regards,
I will Highly Appreciate replies,
Alex
********************************************************

FROM: Jan Roelens
DATE: 07/26/2001 11:06:54
SUBJECT: RE:  [Ppcboot-users] Can we use watchdog timer with Linux? 

The following code changes to the kernel work:

arch/ppc/kernel/m8xx-setup.c:

+/* added this function, called from arch/ppc/kernel/time.c*/
+void m8xx_reset_watchdog(void)
+{
+        ((volatile immap_t *)IMAP_ADDR)->im_siu_conf.sc_swsr = 0x556c;
+        ((volatile immap_t *)IMAP_ADDR)->im_siu_conf.sc_swsr = 0xaa39;
+}

in m8xx_init():

        ppc_md.time_init      = NULL;
        ppc_md.set_rtc_time   = m8xx_set_rtc_time;
        ppc_md.get_rtc_time   = m8xx_get_rtc_time;
        ppc_md.calibrate_decr = m8xx_calibrate_decr;
+        ppc_md.reset_watchdog = m8xx_reset_watchdog;

arch/ppc/kernel/time.c:

+unsigned long sched_watchdog_counter = 0;

void timer_interrupt(struct pt_regs * regs)
{
        int dval, d;
        unsigned long cpu = smp_processor_id();
.
.
.


+   if ((++sched_watchdog_counter&0x3F)==0) /*every 640msec */
+      ppc_md.reset_watchdog();

        hardirq_exit(cpu);
}

in include/asm-ppc/machdep.h:

struct machdep_calls {
        void            (*setup_arch)(unsigned long * memory_start_p,
                                unsigned long * memory_end_p);
        /* Optional, may be NULL. */
        int             (*setup_residual)(char *buffer);
        /* Optional, may be NULL. */
        int             (*get_cpuinfo)(char *buffer);
        /* Optional, may be NULL. */
        unsigned int    (*irq_cannonicalize)(unsigned int irq);
        void            (*init_IRQ)(void);
        void            (*do_IRQ)(struct pt_regs *regs, int cpu, int
isfake);

        /* A general init function, called by ppc_init in init/main.c.
           May be NULL. */
        void            (*init)(void);

        void            (*restart)(char *cmd);
        void            (*power_off)(void);
        void            (*halt)(void);

        void            (*time_init)(void); /* Optional, may be NULL */
        int             (*set_rtc_time)(unsigned long nowtime);
        unsigned long   (*get_rtc_time)(void);
        void            (*calibrate_decr)(void);
+   void        (*reset_watchdog)(void);

************************************************************************
Jan Roelens wrote:

> Hi,
>
> I'm using ppcboot-1.0.1 on a board with an MPC860.
>
> I'm loading and running Linux-2.2.14.
>
> This works fine if ppcboot disables the watchdog timer of the 860.
>
> If ppcboot enables the watchdog timer, the linux statup code encounters
> a watchdog timeout (and thus a reset), somewhere when it is decompressing
> the ramdisk image.
>
> The watchdog timeout is set to its maximum : with a 50MHz clock and a
> 2048 prescaler and a SWTC of 0xFFFF, that's a timeout of about 2.68
seconds.
>
> Can we use the watchdog timer with Linux?
>
> Thanks,
>
> --
> Jan Roelens
> <EMAIL: PROTECTED>
>
> _______________________________________________
> Ppcboot-users mailing list
> <EMAIL: PROTECTED>
> http://lists.sourceforge.net/lists/listinfo/ppcboot-users

--
Jan Roelens

-----Original Message-----
From: Povolotsky, Alexander 
Sent: Wednesday, January 05, 2005 8:58 AM
To: 'wd at denx.de'; 'Tom Rini'; 'Dan Malek'
Cc: linuxppc-embedded at ozlabs.org
Subject: watchdog vs inflate in zlib


Hi,

I got confirmation from my board "vendor" that:
"The watch dog is enabled by the boot monitor, so it must be handled by the
loader and by the kernel too."
At this point I do not know the watch dog's time out period.
The boot monitor is custom modified (by the board "vendor") pSOS bootloader
for which I do not have the code.
The compressed kernel image for Linux 2.6 is considerably larger than for
Linux 2.4 (which works fine) - perhaps I need to put more watch dog resets
into zlib code ... ? - Any advise on where to put those resets, etc. ?

Thanks,
Best Regards,
Alex
-----Original Message-----
From: wd at denx.de [mailto:wd at denx.de]
Sent: Thursday, December 30, 2004 6:09 PM
To: Povolotsky, Alexander
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: inflate returned FFFFFFFD - what does this error exactly mean ?


Hi Alex,

in message
<313680C9A886D511A06000204840E1CF0A647439 at whq-msgusr-02.pit.comms.marconi.co
m> you wrote:
> 
> After few days of wondering through debugging (and with 
> great help) I fixed (by inserting watch dog resets into 
> beginning of while loops in zlib functions) my first problem > - strange
reboot failures during decompression of

You know why I recommended U-Boot :-)

> Now I am getting "controlled" failure (during the same 
> decompression as described above):
> 
> I_BAD
> return Z_DATA_ERROR
> after zlib_inflate
> inflate returned FFFFFFFD
> exit
> 
> what does this error exactly mean ?

Most probably it means that the areas where the compressed  image  is stored
and   to  where  you  copy  the  uncompressed  code  to  are over-lapping.
Try storing the compressed image at  a  higher  address
(like 0x400000 or so).

Best regards,

Wolfgang Denk
-----Original Message-----
From: Nigel Cunningham [mailto:Nigel.Cunningham at cyclades.com]
Sent: Thursday, December 30, 2004 5:45 PM
To: Povolotsky, Alexander
Cc: linuxppc-embedded at ozlabs.org; linuxppc-embedded-bounces at ozlabs.org
Subject: Re: inflate returned FFFFFFFD - what does this error exactly mean ?

Hi.

linuxppc-embedded-bounces at ozlabs.org wrote on 31/12/2004 09:27:53:

> Hi,
>
> After few days of wondering through debugging (and with
> great help) I fixed (by inserting watch dog resets into 
> beginning of  while loops in zlib functions) my first 
> problem -strange reboot failures during decompression of
> the kernel image by the bootloader.
> However my luck expired beyond this fix so far ... ;-).
> Now I am getting "controlled" failure (during the same 
> decompression as described above):
>
> I_BAD
> return Z_DATA_ERROR
> after zlib_inflate
> inflate returned FFFFFFFD
> exit
>
> what does this error exactly mean ?

Going from include/linux/zlib.h, it is a data error: your compressed stream
has somehow been corrupted?

Regards,

Nigel
-- 



More information about the Linuxppc-embedded mailing list