reboot on PQ2FADS board.

reboot on PQ2FADS board.

[Lei Sun]

Hi:
    I have linux 2.4.30 runnning on this board, the "reboot -f"
command cause machine check and kernel ooops.  The problem seems in
the "m8260_gorom" in head.S.  The restart() function in m8260_setup.c
passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
the warm start address,  I changed it to 0xFF800100, that's where the
u-boot's _start_warm lives, I have verified that address by typing "g
ff800100" in u-boot console, which cause the board reset.
    I assume the m8260_gorom  has been heavily tested for other
boards. I wonder if anyone got a PQ2FADS-VR board that has the similar
problem?  I am not familar with the assembly code for PPC.  Any
suggestions?

Thanks
lei

RE: reboot on PQ2FADS board.

[Li Yang-r58472]

> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of Lei Sun
> Sent: Tuesday, July 18, 2006 11:41 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: reboot on PQ2FADS board.
>=20
> Hi:
>     I have linux 2.4.30 runnning on this board, the "reboot -f"
> command cause machine check and kernel ooops.  The problem seems in
> the "m8260_gorom" in head.S.  The restart() function in m8260_setup.c
> passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
> the warm start address,  I changed it to 0xFF800100, that's where the
> u-boot's _start_warm lives, I have verified that address by typing "g
> ff800100" in u-boot console, which cause the board reset.

Are you sure ff800100 is _start_warm lives?  In latest u-boot
_start_warm is at
EXC_OFF_SYS_RESET + 0x10.  In your case, that will be 0xff800110.
Please try
with the correct address.

>     I assume the m8260_gorom  has been heavily tested for other
> boards. I wonder if anyone got a PQ2FADS-VR board that has the similar
> problem?  I am not familar with the assembly code for PPC.  Any
> suggestions?
>=20
> Thanks
> lei
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: reboot on PQ2FADS board.

[Wolfgang Denk]

In message <4879B0C6C249214CBE7AB04453F84E4D050B0F@zch01exm20.fsl.freescale.net> you wrote:
>
> > command cause machine check and kernel ooops.  The problem seems in
> > the "m8260_gorom" in head.S.  The restart() function in m8260_setup.c
> > passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
> > the warm start address,  I changed it to 0xFF800100, that's where the
> > u-boot's _start_warm lives, I have verified that address by typing "g
> > ff800100" in u-boot console, which cause the board reset.
> 
> Are you sure ff800100 is _start_warm lives?  In latest u-boot

Trying to jump to some boot rom address is IMHO always a bad approach
to reboot a system. You should always try to cause a reset  condition
for  the CPU, and thus for all the associated hardware. On 8xx / 8260
systems this is usually done by going through  a  machine  check.  We
have  the  following code in our linuxppc_2_4_devel tree, which works
on ALL 8260 systems, no matter whioch boot loder they use:

static void
m8260_restart(char *cmd)
{   
        __volatile__ unsigned char dummy;
        ulong msr;
    
        cli();
        volatile immap_t *immap = (immap_t *) IMAP_ADDR;
    
        immap->im_clkrst.car_rmr = 1;    /* Checkstop Reset enable */
    
        /* Interrupts and MMU off */
        __asm__ __volatile__ ("mfmsr    %0":"=r" (msr):);
    
        msr &= ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
        __asm__ __volatile__ ("mtmsr    %0"::"r" (msr)); 
    
        dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
    
        printk("Restart failed\n");
        for (;;);
}   


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If a group of N persons implements a COBOL compiler,  there  will  be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham

Re: reboot on PQ2FADS board.

[Lei Sun]

Hi :
  I  tried your approach last ight, (in fact I copied part of the
do_reboot() code from u-boot and put it in m8260_restart() function in
the kernel).  The only difference is the first line,
     volatile immap_t *immap = (immap_t *) IMAP_ADDR;
in my case it is
     volatile immap_t * immap = cpm2_immr;
I am using different source tree.
it simply hangs, rather then reset.

On 7/19/06, Wolfgang Denk <wd@denx.de> wrote:
> In message <4879B0C6C249214CBE7AB04453F84E4D050B0F@zch01exm20.fsl.freescale.net> you wrote:
> >
> > > command cause machine check and kernel ooops.  The problem seems in
> > > the "m8260_gorom" in head.S.  The restart() function in m8260_setup.c
> > > passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
> > > the warm start address,  I changed it to 0xFF800100, that's where the
> > > u-boot's _start_warm lives, I have verified that address by typing "g
> > > ff800100" in u-boot console, which cause the board reset.
> >
> > Are you sure ff800100 is _start_warm lives?  In latest u-boot
>
> Trying to jump to some boot rom address is IMHO always a bad approach
> to reboot a system. You should always try to cause a reset  condition
> for  the CPU, and thus for all the associated hardware. On 8xx / 8260
> systems this is usually done by going through  a  machine  check.  We
> have  the  following code in our linuxppc_2_4_devel tree, which works
> on ALL 8260 systems, no matter whioch boot loder they use:
>
> static void
> m8260_restart(char *cmd)
> {
>        __volatile__ unsigned char dummy;
>        ulong msr;
>
>        cli();
>        volatile immap_t *immap = (immap_t *) IMAP_ADDR;
>
>        immap->im_clkrst.car_rmr = 1;    /* Checkstop Reset enable */
>
>        /* Interrupts and MMU off */
>        __asm__ __volatile__ ("mfmsr    %0":"=r" (msr):);
>
>        msr &= ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
>        __asm__ __volatile__ ("mtmsr    %0"::"r" (msr));
>
>        dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
>
>        printk("Restart failed\n");
>        for (;;);
> }
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> If a group of N persons implements a COBOL compiler,  there  will  be
> N-1 passes. Someone in the group has to be the manager. - T. Cheatham
>

Re: reboot on PQ2FADS board.

[Mathieu Deschamps]

Hi,

On Wednesday 19 July 2006 16:12, Lei Sun wrote:
> Hi :
>   I  tried your approach last ight, (in fact I copied part of the
> do_reboot() code from u-boot and put it in m8260_restart() function in
> the kernel).  The only difference is the first line,
>      volatile immap_t *immap = (immap_t *) IMAP_ADDR;
> in my case it is
>      volatile immap_t * immap = cpm2_immr;
> I am using different source tree.
> it simply hangs, rather then reset.
>
[...]

Give a try to :
	startaddr = 0xff000104;



-- 
Mathieu Deschamps
Com2gether Design Center
Electronic and Embedded Engineering Services
www.com2gether.net 

Re: reboot on PQ2FADS board.

[Lei Sun]

On 7/19/06, Mathieu Deschamps <mathieu.deschamps@com2gether.net> wrote:
> Hi,
>
> On Wednesday 19 July 2006 16:12, Lei Sun wrote:
> > Hi :
> >   I  tried your approach last ight, (in fact I copied part of the
> > do_reboot() code from u-boot and put it in m8260_restart() function in
> > the kernel).  The only difference is the first line,
> >      volatile immap_t *immap = (immap_t *) IMAP_ADDR;
> > in my case it is
> >      volatile immap_t * immap = cpm2_immr;
> > I am using different source tree.
> > it simply hangs, rather then reset.
> >
> [...]
>
> Give a try to :
>         startaddr = 0xff000104;

That address was in the code before for warm-reset. It didn't work, I
tried the CheckStop approach, it didn't work either.

thanks
lei

Re: reboot on PQ2FADS board.

[Lei Sun]

Hi :
  The following is the version I am using, it's pretty much same as
do_reset() code in u-boot -1.1.4 for m8260 target. However the machine
just hangs.
  I wonder if there are any difference between Power on Reset and Hard
reset?  in my case maybe the machine did get reset, but the u-boot
didn't get executed correctly in the case of hard reset ?  It doesn't
explain the fact that i can run "reset" in u-boot console though.

Any comments are highly appreciated! I am stucked in here now.

m8260_restart(char * cmd)
        uint    startaddr;
        unsigned long msr;
        char badval;
        volatile cpm2_map_t *immap = cpm2_immr;

        /* Enable CheckStop reset. */
        immap->im_clkrst.car_rmr |= 0x00000001;
        /* Interrupts and MMU off */
        __asm__ __volatile__("mfmsr %0":"=r" (msr):);
        msr &= ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
        __asm__ __volatile__("mtmsr %0":: "r" (msr));
        startaddr = 0x04400000; /* this is taken from u-boot-1.1.4 */
        /* Access bad address.*/
        ((void (*)(void)) startaddr) ();
        return 1;
}

On 7/19/06, Wolfgang Denk <wd@denx.de> wrote:
> In message <4879B0C6C249214CBE7AB04453F84E4D050B0F@zch01exm20.fsl.freescale.net> you wrote:
> >
> > > command cause machine check and kernel ooops.  The problem seems in
> > > the "m8260_gorom" in head.S.  The restart() function in m8260_setup.c
> > > passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
> > > the warm start address,  I changed it to 0xFF800100, that's where the
> > > u-boot's _start_warm lives, I have verified that address by typing "g
> > > ff800100" in u-boot console, which cause the board reset.
> >
> > Are you sure ff800100 is _start_warm lives?  In latest u-boot
>
> Trying to jump to some boot rom address is IMHO always a bad approach
> to reboot a system. You should always try to cause a reset  condition
> for  the CPU, and thus for all the associated hardware. On 8xx / 8260
> systems this is usually done by going through  a  machine  check.  We
> have  the  following code in our linuxppc_2_4_devel tree, which works
> on ALL 8260 systems, no matter whioch boot loder they use:
>
> static void
> m8260_restart(char *cmd)
> {
>         __volatile__ unsigned char dummy;
>         ulong msr;
>
>         cli();
>         volatile immap_t *immap = (immap_t *) IMAP_ADDR;
>
>         immap->im_clkrst.car_rmr = 1;    /* Checkstop Reset enable */
>
>         /* Interrupts and MMU off */
>         __asm__ __volatile__ ("mfmsr    %0":"=r" (msr):);
>
>         msr &= ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
>         __asm__ __volatile__ ("mtmsr    %0"::"r" (msr));
>
>         dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
>
>         printk("Restart failed\n");
>         for (;;);
> }
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> If a group of N persons implements a COBOL compiler,  there  will  be
> N-1 passes. Someone in the group has to be the manager. - T. Cheatham
>

Re: reboot on PQ2FADS board.

[Wolfgang Denk]

In message <f9a7e7a80607192046s3f17e8a5s4cfba43f1747e9ec@mail.gmail.com> you wrote:
>
> m8260_restart(char * cmd)
...
>         startaddr = 0x04400000; /* this is taken from u-boot-1.1.4 */

This is a random address which  happens  to  be  not  mapped  in  the
specific  board  (MPC8260ADS.h).  The approach taken here is strongly
deprecated - it is juat an examp[le of a badly maintained board.  In-
stead, I recommend to use an addrress which causes a checkstop on all
boards,  idependently of the cspecific memory map. This is what we do
here:

> >         dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];

In the end, the effect is the same.

And I have no idea why it would not work  on  your  board.  Attach  a
debugger and find out where exactly the code is hanging.

Ummm... and if you run under a debugger, *detach*  it  and  check  if
reset starts to work...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It's certainly  convenient  the  way  the  crime  (or  condition)  of
stupidity   carries   with   it  its  own  punishment,  automatically
admisistered without remorse, pity, or prejudice. :-)
         -- Tom Christiansen in <559seq$ag1$1@csnews.cs.colorado.edu>

RE: reboot on PQ2FADS board.

[Liu Dave-r63238]

This way maybe can not work. when the MMU turn off,=20
the next instructions maybe can not be fetched if these instructions
didn't exist cache.=20
so it is possible these instruction can not executed. =20

>=20
> Trying to jump to some boot rom address is IMHO always a bad=20
> approach to reboot a system. You should always try to cause a=20
> reset  condition for  the CPU, and thus for all the=20
> associated hardware. On 8xx / 8260 systems this is usually=20
> done by going through  a  machine  check.  We have  the =20
> following code in our linuxppc_2_4_devel tree, which works on=20
> ALL 8260 systems, no matter whioch boot loder they use:
>=20
> static void
> m8260_restart(char *cmd)
> {  =20
>         __volatile__ unsigned char dummy;
>         ulong msr;
>    =20
>         cli();
>         volatile immap_t *immap =3D (immap_t *) IMAP_ADDR;
>    =20
>         immap->im_clkrst.car_rmr =3D 1;    /* Checkstop Reset enable =
*/
>    =20
>         /* Interrupts and MMU off */
>         __asm__ __volatile__ ("mfmsr    %0":"=3Dr" (msr):);
>    =20
>         msr &=3D ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
>         __asm__ __volatile__ ("mtmsr    %0"::"r" (msr));=20
>    =20
Now the MMU trun off, is real address mode. But the PC still is
0xC00xxxx.. It is old effective address.

>         dummy =3D ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
These instructions will locate on the real address space...... It is
0xC00xxxx- KERNELBASE
>    =20
>         printk("Restart failed\n");
>         for (;;);
> }  =20
>=20

reboot on PQ2FADS board.

[Zhimin (Jimmy) Liu]

[-- Attachment #1: Type: text/plain, Size: 80 bytes --]

Did you sovlve the problem? I have same issue for the  PQ2FADS board.

jimmy

[-- Attachment #2: Type: text/html, Size: 502 bytes --]

RE: reboot on PQ2FADS board.

[Liu Dave-r63238]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

Hi Liu,
 
please try this..
 
     u32 msr;
     
     volatile immap_t *immap = (immap_t *) IMAP_ADDR;
     
     
     /* Interrupts and MachineCheck off */
     __asm__ __volatile__ ("mfmsr    %0":"=r" (msr):);
     
     msr &= ~(MSR_ME | MSR_EE);
     __asm__ __volatile__ ("mtmsr    %0"::"r" (msr)); 
     
     immap->im_clkrst.car_rmr = 1;    /* Checkstop Reset enable */

     immap->resxxx = 0;        /* please find one immap illegal address
                                   access it, trig reset */
     for (;;);



________________________________

	From: linuxppc-embedded-bounces+daveliu=freescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+daveliu=freescale.com@ozlabs.org] On
Behalf Of Zhimin (Jimmy) Liu
	Sent: Friday, August 18, 2006 1:00 AM
	To: linuxppc-embedded@ozlabs.org
	Subject: reboot on PQ2FADS board.
	
	

	Did you sovlve the problem? I have same issue for the  PQ2FADS
board. 

	jimmy 


[-- Attachment #2: Type: text/html, Size: 3257 bytes --]