reboot on PQ2FADS board.
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 at ozlabs.org [mailto:linuxppc-embedded-bounces+daveliu=freescale.com at ozlabs.org] On Behalf Of Zhimin (Jimmy) Liu Sent: Friday, August 18, 2006 1:00 AM To: linuxppc-embedded at ozlabs.org Subject: reboot on PQ2FADS board. Did you sovlve the problem? I have same issue for the PQ2FADS board. jimmy -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060818/968e753a/attachment.htm
reboot on PQ2FADS board.
Did you sovlve the problem? I have same issue for the PQ2FADS board. jimmy -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060817/3eb9347a/attachment.htm
reboot on PQ2FADS board.
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)
uintstartaddr;
unsigned long msr;
char badval;
volatile cpm2_map_t *immap = cpm2_immr;
/* Enable CheckStop reset. */
immap-im_clkrst.car_rmr |= 0x0001;
/* 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 = 0x0440; /* this is taken from u-boot-1.1.4 */
/* Access bad address.*/
((void (*)(void)) startaddr) ();
return 1;
}
On 7/19/06, Wolfgang Denk wd at denx.de wrote:
In message 4879B0C6C249214CBE7AB04453F84E4D050B0F at
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 at 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
reboot on PQ2FADS board.
In message f9a7e7a80607192046s3f17e8a5s4cfba43f1747e9ec at mail.gmail.com you wrote: m8260_restart(char * cmd) ... startaddr = 0x0440; /* 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 at 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 at csnews.cs.colorado.edu
reboot on PQ2FADS board.
This way maybe can not work. when the MMU turn off,
the next instructions maybe can not be fetched if these instructions
didn't exist cache.
so it is possible these instruction can not executed.
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));
Now the MMU trun off, is real address mode. But the PC still is
0xC00.. It is old effective address.
dummy = ((immap_t *)IMAP_ADDR)-im_clkrst.res[0];
These instructions will locate on the real address space.. It is
0xC00- KERNELBASE
printk(Restart failed\n);
for (;;);
}
reboot on PQ2FADS board.
-Original Message- From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of Lei Sun Sent: Tuesday, July 18, 2006 11:41 AM To: linuxppc-embedded at ozlabs.org Subject: reboot on PQ2FADS board. 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? Thanks lei ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
reboot on PQ2FADS board.
In message 4879B0C6C249214CBE7AB04453F84E4D050B0F at
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 at 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
reboot on PQ2FADS board.
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 at denx.de wrote:
In message 4879B0C6C249214CBE7AB04453F84E4D050B0F at
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 at 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
reboot on PQ2FADS board.
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
reboot on PQ2FADS board.
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
