PLPRCR & Checkstop reset

Hi Folks,

We're using the mvista 2.2.13-3 kernel sources and I'd like to add a
software reboot capability.  I've figured out that I need to add an enable
of CheckstopReset and generate a MachineCheck in head.S.  Before I go
muddling through the assembly (I'm pretty clueless there), I was wondering if
someone had a snippet to share that would force the hard reset I'm looking
for.

Thanks,
-Mark

Mark S. Mathews

AbsoluteValue Systems      Web:    http://www.linux-wlan.com
P.O. Box 941149            e-mail: mark@linux-wlan.com
Maitland, FL 32794-1149    Phone:  407.644.8582
USA                        Fax:    407.539.1294


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Mark S. Mathews wrote:

We're using the mvista 2.2.13-3 kernel sources and I'd like to add a
software reboot capability.

How do you actually want to reboot?  At one time, I had modified
the kernel "gorom()" function to simply jump into the boot rom as
if a reset occurred.  I should make this work again for many reasons.

If you really want the hard reset, which in some cases on some
designs will reset some external hardware sometimes, then the
checkstop reset will do the trick.  This is often confused with
performing a hard reset function, which really isn't the same thing.

I will dig up the code for both cases.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Mark S. Mathews wrote:

We're using the mvista 2.2.13-3 kernel sources and I'd like to add a
software reboot capability.

Here is the first installment.  It will allow commands that use
the reboot system call (like 'reboot') to properly jump into the
system reset vector.  If you want to write some custom programs
to execute code somewhere else, you can call reboot with a
starting address parameter.  I use this to use Linux to load a
new Linux kernel.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Hmmm.  I'm not exactly sure which 'kind' of reset I should be using.

What I'm trying to accomplish is getting "init 6" or "reboot" to work as
expected.  I.e. JLAPC (Just like a PC  ;-)

I'd like the reset to result a reset to the RPXU2 which restarts my kernel
via 'autoboot'.  Since the 'reset' command in the RPXU and U2 used the
checkstop thing, I figured it would would work OK for me.

I haven't yet studied the reset part of the 823 manual close enough to
figure out all of the available reset modes.

I'll defer to your expertise the selection of the 'right way' to do this.
;-)

Thanks,
-Mark

On Mon, 26 Jun 2000, Dan Malek wrote:

Mark S. Mathews wrote:

quoted

We're using the mvista 2.2.13-3 kernel sources and I'd like to add a
software reboot capability.

How do you actually want to reboot?  At one time, I had modified
the kernel "gorom()" function to simply jump into the boot rom as
if a reset occurred.  I should make this work again for many reasons.

If you really want the hard reset, which in some cases on some
designs will reset some external hardware sometimes, then the
checkstop reset will do the trick.  This is often confused with
performing a hard reset function, which really isn't the same thing.

I will dig up the code for both cases.


	-- Dan

Mark S. Mathews

AbsoluteValue Systems      Web:    http://www.linux-wlan.com
P.O. Box 941149            e-mail: mark@linux-wlan.com
Maitland, FL 32794-1149    Phone:  407.644.8582
USA                        Fax:    407.539.1294


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Dan Malek wrote:

Here is the first installment.

Let's try this again.......I will actually attach something
this time.  I am travelling and don't have access to a system
or enought documentation to attempt checkstop/reset.



	-- Dan

It would be better to not jump to the reset vector on a warm
start.  Often there is hardware configuration issues with rerunning all
the reset code - the primary one is that the IMMR quite likely is in a
different location than the power up default value.

I've seen two conventions.  The one I've seen more often is to jump to
the 4th byte after the reset vector (0xFFF00004).  In this case, the
first reset location is a branch to the coldstart location.

I checked LiMon 1.1 and it uses the (reserved) zeroth vector
(0xFFF00000) for its warmstart location.

gvb


At 01:50 PM 6/27/00 -0400, Dan Malek wrote:

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Jerry Van Baren wrote:

It would be better to not jump to the reset vector on a warm
start.

Yes, but there isn't any standard among the 8xx boot roms.

This seems to work on all of the boards I have ever tested.  If
it doesn't work for you, let's discuss it and find something that
does.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

It is unfortunate that there apparently is no standard.  The only item
that I'm concerned with at the moment is the 8260 IMMR which is
readable but only if you know where it is first, in which case there is
no need to read it. :-(

Due to (a) laziness and (b) heredity (the board's, not mine), the power
up IMMR value on the systems I'm using is not the proper value for
running linux so we change it as part of our custom startup.  This code
cannot be re-run on a warm start because the IMMR is already moved.  If
there is no standard way to distinguish a warm start from a cold start
(e.g. different entry points), we will have to stash a special flag in
RAM that, if it is set to a magic number, tells us not to mess with the
IMMR because it is already correct.

gvb


At 03:16 PM 6/27/00 -0400, Dan Malek wrote:

Jerry Van Baren wrote:

quoted

It would be better to not jump to the reset vector on a warm
start.

Yes, but there isn't any standard among the 8xx boot roms.

This seems to work on all of the boards I have ever tested.  If
it doesn't work for you, let's discuss it and find something that
does.



        -- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/