* PLPRCR & Checkstop reset
@ 2000-06-25 21:33 Mark S. Mathews
2000-06-26 19:13 ` Dan Malek
2000-06-27 17:11 ` Dan Malek
0 siblings, 2 replies; 8+ messages in thread
From: Mark S. Mathews @ 2000-06-25 21:33 UTC (permalink / raw)
To: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PLPRCR & Checkstop reset
2000-06-25 21:33 PLPRCR & Checkstop reset Mark S. Mathews
@ 2000-06-26 19:13 ` Dan Malek
2000-06-27 17:41 ` Mark S. Mathews
2000-06-27 17:11 ` Dan Malek
1 sibling, 1 reply; 8+ messages in thread
From: Dan Malek @ 2000-06-26 19:13 UTC (permalink / raw)
To: Mark S. Mathews; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PLPRCR & Checkstop reset
2000-06-25 21:33 PLPRCR & Checkstop reset Mark S. Mathews
2000-06-26 19:13 ` Dan Malek
@ 2000-06-27 17:11 ` Dan Malek
2000-06-27 17:50 ` Dan Malek
1 sibling, 1 reply; 8+ messages in thread
From: Dan Malek @ 2000-06-27 17:11 UTC (permalink / raw)
To: Mark S. Mathews; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PLPRCR & Checkstop reset
2000-06-26 19:13 ` Dan Malek
@ 2000-06-27 17:41 ` Mark S. Mathews
0 siblings, 0 replies; 8+ messages in thread
From: Mark S. Mathews @ 2000-06-27 17:41 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
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:
>
> > 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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PLPRCR & Checkstop reset
2000-06-27 17:11 ` Dan Malek
@ 2000-06-27 17:50 ` Dan Malek
2000-06-27 18:50 ` Jerry Van Baren
0 siblings, 1 reply; 8+ messages in thread
From: Dan Malek @ 2000-06-27 17:50 UTC (permalink / raw)
To: Mark S. Mathews, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 237 bytes --]
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
[-- Attachment #2: m8xx_setup.patch --]
[-- Type: text/plain, Size: 503 bytes --]
--- linux.old/arch/ppc/kernel/m8xx_setup.c Wed Feb 16 11:43:25 2000
+++ linux/arch/ppc/kernel/m8xx_setup.c Tue Jun 27 09:47:27 2000
@@ -228,9 +240,17 @@
void
m8xx_restart(char *cmd)
{
- extern void m8xx_gorom(void);
+ extern void m8xx_gorom(uint bp, uint startaddr);
+ uint startaddr;
+
+ startaddr = 0xfff00100;
+
+ if (cmd != NULL) {
+ if (!strncmp(cmd, "startaddr=", 10))
+ startaddr = simple_strtoul(&cmd[10], NULL, 0);
+ }
- m8xx_gorom();
+ m8xx_gorom((uint)__pa(res), startaddr);
}
void
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PLPRCR & Checkstop reset
2000-06-27 17:50 ` Dan Malek
@ 2000-06-27 18:50 ` Jerry Van Baren
2000-06-27 19:16 ` Dan Malek
0 siblings, 1 reply; 8+ messages in thread
From: Jerry Van Baren @ 2000-06-27 18:50 UTC (permalink / raw)
To: linuxppc-embedded
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:
>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
>--- linux.old/arch/ppc/kernel/m8xx_setup.c Wed Feb 16 11:43:25 2000
>+++ linux/arch/ppc/kernel/m8xx_setup.c Tue Jun 27 09:47:27 2000
>@@ -228,9 +240,17 @@
> void
> m8xx_restart(char *cmd)
> {
>- extern void m8xx_gorom(void);
>+ extern void m8xx_gorom(uint bp, uint startaddr);
>+ uint startaddr;
>+
>+ startaddr = 0xfff00100;
>+
>+ if (cmd != NULL) {
>+ if (!strncmp(cmd, "startaddr=", 10))
>+ startaddr = simple_strtoul(&cmd[10], NULL, 0);
>+ }
>
>- m8xx_gorom();
>+ m8xx_gorom((uint)__pa(res), startaddr);
> }
>
> void
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PLPRCR & Checkstop reset
2000-06-27 18:50 ` Jerry Van Baren
@ 2000-06-27 19:16 ` Dan Malek
2000-06-27 19:35 ` Jerry Van Baren
0 siblings, 1 reply; 8+ messages in thread
From: Dan Malek @ 2000-06-27 19:16 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PLPRCR & Checkstop reset
2000-06-27 19:16 ` Dan Malek
@ 2000-06-27 19:35 ` Jerry Van Baren
0 siblings, 0 replies; 8+ messages in thread
From: Jerry Van Baren @ 2000-06-27 19:35 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
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:
>
> > 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/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2000-06-27 19:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-06-25 21:33 PLPRCR & Checkstop reset Mark S. Mathews
2000-06-26 19:13 ` Dan Malek
2000-06-27 17:41 ` Mark S. Mathews
2000-06-27 17:11 ` Dan Malek
2000-06-27 17:50 ` Dan Malek
2000-06-27 18:50 ` Jerry Van Baren
2000-06-27 19:16 ` Dan Malek
2000-06-27 19:35 ` Jerry Van Baren
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).