Warm reboot on 826x targets

Warm reboot on 826x targets

[Paul Gortmaker]

I've been trying to get a WRS 8265 to do a warm reboot, and found some
things that I am wondering about.

Firstly, is anyone having success on having "reboot" restart the machine
on a similar platform?

Secondly, the default BOOTROM_RESTART_ADDR is 0x40000104 (sbc82xx.h) and I
was wondering if this matches any platforms out there.  On this board, the
place where U-Boot lives is 0xFFF00104 -- and I've verified this by typing
"g fff00104" at the U-Boot prompt which causes U-Boot to simply restart.

I've changed the value in sbc82xx.h and now at the reboot, instead of a
register dump, it simply hangs.  Looking at m8260_gorom (in kernel/head.S)
it clears the MSR_EE (ext int. enable) bit in the MSR before jumping --
but I was wondering if there are other bits in MSR that need to be
cleared; e.g. instruction relocation enable and data relocation enable
(MSR_IR and MSR_DR). The register bits are on p76 of MPCFPE32B.pdf from
Freescale.

I guess if somebody even said "it works for me" then I'd have a better
feeling thinking that what is done to the MSR currently is sufficient.

Paul.


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/

Re: Warm reboot on 826x targets

[Eugene Surovegin]

On Tue, Apr 12, 2005 at 11:14:35AM -0700, Paul Gortmaker wrote:
> I've been trying to get a WRS 8265 to do a warm reboot, and found some
> things that I am wondering about.
> 
> Firstly, is anyone having success on having "reboot" restart the machine
> on a similar platform?
> 
> Secondly, the default BOOTROM_RESTART_ADDR is 0x40000104 (sbc82xx.h) and I
> was wondering if this matches any platforms out there.  On this board, the
> place where U-Boot lives is 0xFFF00104 -- and I've verified this by typing
> "g fff00104" at the U-Boot prompt which causes U-Boot to simply restart.
> 
> I've changed the value in sbc82xx.h and now at the reboot, instead of a
> register dump, it simply hangs.  Looking at m8260_gorom (in kernel/head.S)
> it clears the MSR_EE (ext int. enable) bit in the MSR before jumping --
> but I was wondering if there are other bits in MSR that need to be
> cleared; e.g. instruction relocation enable and data relocation enable
> (MSR_IR and MSR_DR). The register bits are on p76 of MPCFPE32B.pdf from
> Freescale.
> 
> I guess if somebody even said "it works for me" then I'd have a better
> feeling thinking that what is done to the MSR currently is sufficient.

I don't have any problems using reboot() on 8248 based board. 
Kernel.org-based 2.4.29 tree.

I have U-Boot at 0xfe00'0000, and I use 0xfe00'0104 as a second 
parameter for m8260_gorom. Also make sure that first parameter is also 
correct:

	m8260_gorom(__pa(__res), 0xfe000104);

-- 
Eugene

Re: Warm reboot on 826x targets

[Frank]

--- Paul Gortmaker <p_gortmaker@yahoo.com> wrote:
> I've been trying to get a WRS 8265 to do a warm reboot, and
> found some
> things that I am wondering about.
> 
> Firstly, is anyone having success on having "reboot" restart
> the machine
> on a similar platform?
> 
> Secondly, the default BOOTROM_RESTART_ADDR is 0x40000104
> (sbc82xx.h) and I
> was wondering if this matches any platforms out there.  On
> this board, the
> place where U-Boot lives is 0xFFF00104 -- and I've verified
> this by typing
> "g fff00104" at the U-Boot prompt which causes U-Boot to
> simply restart.
> 
> I've changed the value in sbc82xx.h and now at the reboot,
> instead of a
> register dump, it simply hangs.  Looking at m8260_gorom (in
> kernel/head.S)
> it clears the MSR_EE (ext int. enable) bit in the MSR before
> jumping --
> but I was wondering if there are other bits in MSR that need
> to be
> cleared; e.g. instruction relocation enable and data
> relocation enable
> (MSR_IR and MSR_DR). The register bits are on p76 of
> MPCFPE32B.pdf from
> Freescale.
> 
> I guess if somebody even said "it works for me" then I'd have
> a better
> feeling thinking that what is done to the MSR currently is
> sufficient.
> 
> Paul.
> 
I'm working on the exact same problem with u-boot (trying to do
warm reboot from the VxWorks shell). I modified romInit.S to
pass control to u-boot (at 0xfe000000) and that works just fine.
But after I boot VxWorks from u-boot (go 0xfff00100) and invoke
reboot from the VxWorks shell, it just hangs. If I boot VxWorks
without invoking u-boot first, it works fine. If you find the
problem befor me, let me know and I'll do tha same...

> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/

Re: Warm reboot on 826x targets

[Paul Gortmaker]

I should have asked what version of U-Boot you were using.  I've had
U-Boot 1.1.1 on this thing from the beginning, but I've heard that some
people are sticking with 1.0 on production stuff.

I've found that I can't use the watchdog timer for a reboot, since it is
"write once" (SYCPR) and I'm guessing U-Boot writes to it at boot.

As a different twist, I tried doing a reset like the m8xx does, as shown
below, but that just caused a hang as well, so I'm wondering if the
problem is more low level (board isn't set up properly, etc.)

Paul.

/*
 *This is a tweaked version of the m8xx_restart.
 */
static void
sbc82xx_restart(char *cmd)
{
        __volatile__ unsigned char dummy;
        unsigned long msr;

        volatile car_cpm2_t *cc = &cpm2_immr->im_clkrst;

        msr = mfmsr();
        mtmsr(msr & ~MSR_EE);
        __asm__ __volatile__("": : :"memory");

        /* Checkstop reset enable -- Sec. 5.3 of MPC8260UM.pdf */
        cc->car_rmr = 0x80000000;

        msr = mfmsr();
        mtmsr(msr & ~MSR_ME);

        dummy = cc->res[0];
        BUG();
}



--- Eugene Surovegin <ebs@ebshome.net> wrote:
> On Tue, Apr 12, 2005 at 11:14:35AM -0700, Paul Gortmaker wrote:
> > I've been trying to get a WRS 8265 to do a warm reboot, and found some
> > things that I am wondering about.
> > 
> > Firstly, is anyone having success on having "reboot" restart the
> machine
> > on a similar platform?
> > 
> > Secondly, the default BOOTROM_RESTART_ADDR is 0x40000104 (sbc82xx.h)
> and I
> > was wondering if this matches any platforms out there.  On this board,
> the
> > place where U-Boot lives is 0xFFF00104 -- and I've verified this by
> typing
> > "g fff00104" at the U-Boot prompt which causes U-Boot to simply
> restart.
> > 
> > I've changed the value in sbc82xx.h and now at the reboot, instead of
> a
> > register dump, it simply hangs.  Looking at m8260_gorom (in
> kernel/head.S)
> > it clears the MSR_EE (ext int. enable) bit in the MSR before jumping
> --
> > but I was wondering if there are other bits in MSR that need to be
> > cleared; e.g. instruction relocation enable and data relocation enable
> > (MSR_IR and MSR_DR). The register bits are on p76 of MPCFPE32B.pdf
> from
> > Freescale.
> > 
> > I guess if somebody even said "it works for me" then I'd have a better
> > feeling thinking that what is done to the MSR currently is sufficient.
> 
> I don't have any problems using reboot() on 8248 based board. 
> Kernel.org-based 2.4.29 tree.
> 
> I have U-Boot at 0xfe00'0000, and I use 0xfe00'0104 as a second 
> parameter for m8260_gorom. Also make sure that first parameter is also 
> correct:
> 
> 	m8260_gorom(__pa(__res), 0xfe000104);
> 
> -- 
> Eugene
> 
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Warm reboot on 826x targets

[Eugene Surovegin]

On Fri, Apr 22, 2005 at 12:46:38PM -0700, Paul Gortmaker wrote:
> I should have asked what version of U-Boot you were using. 

This is not relevant, because Linux doesn't use this "checkstop" 
trick. It directly just jumps to U-Boot warm-reboot entry point.

-- 
Eugene

Re: Warm reboot on 826x targets

[Wolfgang Denk]

In message <20050422210610.GA9158@gate.ebshome.net> you wrote:
> 
> This is not relevant, because Linux doesn't use this "checkstop" 
> trick. It directly just jumps to U-Boot warm-reboot entry point.

Which is a bad design desicion, IMHO. If you want to reset  a  board,
you  should  really  RESET  it  (and  give all attached peripherals a
chance to get reset, too), instead of just assuming everything is  in
good shape an it's sufficient to just jump into some boot loader code
again.

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
"Language shapes the way we think, and determines what we  can  think
about."                                                 - B. L. Whorf

Re: Warm reboot on 826x targets

[Eugene Surovegin]

On Sat, Apr 23, 2005 at 12:25:56AM +0200, Wolfgang Denk wrote:
> In message <20050422210610.GA9158@gate.ebshome.net> you wrote:
> > 
> > This is not relevant, because Linux doesn't use this "checkstop" 
> > trick. It directly just jumps to U-Boot warm-reboot entry point.
> 
> Which is a bad design desicion, IMHO. If you want to reset  a  board,
> you  should  really  RESET  it  (and  give all attached peripherals a
> chance to get reset, too), instead of just assuming everything is  in
> good shape an it's sufficient to just jump into some boot loader code
> again.

Sure, but tell me then, _WHY_ U-Boot has this warm-reboot entry?

IMHO, Motorola should have implemented normal reset facility, which 
doesn't require any tricks.

-- 
Eugene

Re: Warm reboot on 826x targets

[Wolfgang Denk]

In message <20050422222925.GB9158@gate.ebshome.net> you wrote:
>
> Sure, but tell me then, _WHY_ U-Boot has this warm-reboot entry?

Because a customer payed for it, and it does not hurt (as long as you
don't use it).

> IMHO, Motorola should have implemented normal reset facility, which 
> doesn't require any tricks.

Only machines that are supposed to  run  M$  software  need  a  reset
facility :-)

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
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie