From: Clemens Koller <hidden> Date: 2007-11-16 15:27:36
Hello, Robert!
robert lazarski schrieb:
> Hi all, on my custom 85xx board I can't do a soft reset. I'm using
> u-boot 1.3rc3 that has the latest cpu/mpc85xx/cpu.c patch to fix some
> type of reset problem. When I press the software reset button on my
> board after my nfs kernel panic, I get this:
Please define "software reset button" in your case. :-)
I consider a "button" clearly as hardware.
In my case (my button) asserts the HRESET# CPU pin low.
As far as I understood the details (not verified again):
To trigger a hard reset via software, the CPU (8540 at least)
should assert the HRESET_REQ# (Pin AG20) low (which needs
to be triggered in software, somehow).
Some external glue logic should then issue the HRESET#
(pin AH16) low to reset the CPU (hard, Power On Reset).
The SRESET# (pin AF20) is the soft reset input, causes
an mcp assertion to the core.... (RTFM)
So, the detailed explanation seems to be implementation
specific (if HRESET_REQ# can get triggered and if HRESET_REQ#
assertion is glued to assert HRESET# from the HW guys).
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
> Rebooting in 10 seconds..Machine check in kernel mode.
> Caused by (from MCSR=80000000): Machine Check Signal
> Oops: Machine check, sig: 7 [#1]
> MPC85xx CDS
> NIP: c00131f8 LR: c0014060 CTR: c00230dc
> REGS: c0289f50 TRAP: 0202 Not tainted (2.6.24-rc2-ge6a5c27f-dirty)
> MSR: 00021000 <ME> CR: 24000028 XER: 20000000
> TASK = c1020000[1] 'swapper' THREAD: c1022000
> GPR00: 00000002 c1023e30 c1020000 00000000 00000686 00000047 c1023e38 00000000
> GPR08: 7e58da6f f10000b0 003d0900 c0281ec8 44000088 7fffa7e3 3ffefb00 00800000
> GPR16: ffffffff 00000000 007fff00 c0220000 c0260000 c0260000 00000000 3ffeb254
> GPR24: c0260000 00000000 c0280000 c0219f84 c0290000 00002710 c0260000 00000000
> NIP [c00131f8] fsl_rstcr_restart+0x20/0x24
> LR [c0014060] mpc85xx_cds_restart+0x78/0x8c
> Call Trace:
> [c1023e30] [c0014008] mpc85xx_cds_restart+0x20/0x8c (unreliable)
> [c1023e50] [c000c894] machine_restart+0x34/0x48
> [c1023e60] [c0031f9c] emergency_restart+0x14/0x24
> [c1023e70] [c00234e8] panic+0x134/0x174
> [c1023f00] [c0242d5c] mount_block_root+0x108/0x24c
> [c1023f50] [c02431c0] prepare_namespace+0xd0/0x210
> [c1023f70] [c0242938] kernel_init+0x170/0x290
> [c1023ff0] [c000d2dc] kernel_thread+0x44/0x60
> Instruction dump:
> 80010014 38210010 7c0803a6 4e800020 7c000146 3d20c029 8129821c 2f890000
> 419e0010 38000002 7c0004ac 90090000 <48000000> 81230044 8009003c 70090008
> Kernel panic - not syncing: Attempted to kill init!
> Rebooting in 10 seconds..
>
> I believe Clemens recently confirmed the same issue. Any ideas?
> Robert
Not really. I just can confirm that the a $shutdown -r now doesn't
reboot my board anymore whereas 2.6.21-rc4 did.
IIRC, I've seen a patch which changed some instructions in some reboot()
function some time ago.
(Please note, I'm using the mpc8540_ads which might be slightly different
from the *_cds.)
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
From: robert lazarski <hidden> Date: 2007-11-16 20:44:22
On Nov 16, 2007 10:27 AM, Clemens Koller [off-list ref] wrote:
Hello, Robert!
robert lazarski schrieb:
> Hi all, on my custom 85xx board I can't do a soft reset. I'm using
> u-boot 1.3rc3 that has the latest cpu/mpc85xx/cpu.c patch to fix some
> type of reset problem. When I press the software reset button on my
> board after my nfs kernel panic, I get this:
Please define "software reset button" in your case. :-)
I consider a "button" clearly as hardware.
I mean a hardware button that calls SRESET , ie, Soft reset machine check.
<snip>
The SRESET# (pin AF20) is the soft reset input, causes
an mcp assertion to the core.... (RTFM)
That's what we are doing. The 85xx docs say "Soft reset. Causes a
machine check interrupt to the e500 core. Note that if the e500 core
is not configured to process machine check interrupts, the assertion
of SRESET causes a core checkstop. SRESET need not be asserted during
a hard reset."
Is the 85xx kernel "not configured to process machine check
interrupts" ? Do I need to do that myself in my boards restart
function via the special registers? Is there code already for this?
Robert
From: robert lazarski <hidden> Date: 2007-11-16 21:28:16
On Nov 16, 2007 3:44 PM, robert lazarski [off-list ref] wrote:
On Nov 16, 2007 10:27 AM, Clemens Koller [off-list ref] wrote:
quoted
The SRESET# (pin AF20) is the soft reset input, causes
an mcp assertion to the core.... (RTFM)
That's what we are doing. The 85xx docs say "Soft reset. Causes a
machine check interrupt to the e500 core. Note that if the e500 core
is not configured to process machine check interrupts, the assertion
of SRESET causes a core checkstop. SRESET need not be asserted during
a hard reset."
Sorry for replying to myself, but thought I'd mention SRESET works
fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
doesn't work for me on 2.6.24rc2 .
Robert
From: Kumar Gala <hidden> Date: 2007-11-16 21:46:47
On Nov 16, 2007, at 3:28 PM, robert lazarski wrote:
On Nov 16, 2007 3:44 PM, robert lazarski [off-list ref]
wrote:
quoted
On Nov 16, 2007 10:27 AM, Clemens Koller
[off-list ref] wrote:
quoted
The SRESET# (pin AF20) is the soft reset input, causes
an mcp assertion to the core.... (RTFM)
That's what we are doing. The 85xx docs say "Soft reset. Causes a
machine check interrupt to the e500 core. Note that if the e500 core
is not configured to process machine check interrupts, the assertion
of SRESET causes a core checkstop. SRESET need not be asserted during
a hard reset."
Sorry for replying to myself, but thought I'd mention SRESET works
fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
doesn't work for me on 2.6.24rc2 .
From: robert lazarski <hidden> Date: 2007-11-16 22:01:35
On Nov 16, 2007 4:46 PM, Kumar Gala [off-list ref] wrote:
On Nov 16, 2007, at 3:28 PM, robert lazarski wrote:
quoted
On Nov 16, 2007 3:44 PM, robert lazarski [off-list ref]
wrote:
quoted
On Nov 16, 2007 10:27 AM, Clemens Koller
[off-list ref] wrote:
quoted
The SRESET# (pin AF20) is the soft reset input, causes
an mcp assertion to the core.... (RTFM)
That's what we are doing. The 85xx docs say "Soft reset. Causes a
machine check interrupt to the e500 core. Note that if the e500 core
is not configured to process machine check interrupts, the assertion
of SRESET causes a core checkstop. SRESET need not be asserted during
a hard reset."
Sorry for replying to myself, but thought I'd mention SRESET works
fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
doesn't work for me on 2.6.24rc2 .
What actual 85xx are you using?
- k
Custom 8548 board. I'm using the cds 85xx code for a reference and I
calling the same reset functions.
Robert
From: Kumar Gala <hidden> Date: 2007-11-17 19:53:08
On Nov 16, 2007, at 4:01 PM, robert lazarski wrote:
On Nov 16, 2007 4:46 PM, Kumar Gala [off-list ref] wrote:
quoted
On Nov 16, 2007, at 3:28 PM, robert lazarski wrote:
quoted
On Nov 16, 2007 3:44 PM, robert lazarski [off-list ref]
wrote:
quoted
On Nov 16, 2007 10:27 AM, Clemens Koller
[off-list ref] wrote:
quoted
The SRESET# (pin AF20) is the soft reset input, causes
an mcp assertion to the core.... (RTFM)
That's what we are doing. The 85xx docs say "Soft reset. Causes a
machine check interrupt to the e500 core. Note that if the e500
core
is not configured to process machine check interrupts, the
assertion
of SRESET causes a core checkstop. SRESET need not be asserted
during
a hard reset."
Sorry for replying to myself, but thought I'd mention SRESET works
fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
doesn't work for me on 2.6.24rc2 .
What actual 85xx are you using?
- k
Custom 8548 board. I'm using the cds 85xx code for a reference and I
calling the same reset functions.
1. do you have the following in your dts:
global-utilities@e0000 { //global utilities reg
compatible = "fsl,mpc8548-guts";
reg = <e0000 1000>;
fsl,has-rstcr;
};
2. in your platform code are you using fsl_rstcr_restart in
define_machine()
- k
From: robert lazarski <hidden> Date: 2007-11-26 17:41:39
Hi Kumar, I finally got time to get back to this:
On Nov 17, 2007 2:52 PM, Kumar Gala [off-list ref] wrote:
On Nov 16, 2007, at 4:01 PM, robert lazarski wrote:
quoted
quoted
quoted
Sorry for replying to myself, but thought I'd mention SRESET works
fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
doesn't work for me on 2.6.24rc2 .
What actual 85xx are you using?
- k
Custom 8548 board. I'm using the cds 85xx code for a reference and I
calling the same reset functions.
1. do you have the following in your dts:
global-utilities@e0000 { //global utilities reg
compatible = "fsl,mpc8548-guts";
reg = <e0000 1000>;
fsl,has-rstcr;
};
Yes.
2. in your platform code are you using fsl_rstcr_restart in
define_machine()
- k
Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
calling 'reboot' in the shell, it just hangs. Using the same dts and
resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
someone who does should be able to confirm whether the issue exists or
not by just attempting to reboot via bash.
Robert
From: Clemens Koller <hidden> Date: 2007-11-26 20:20:17
Hi, Robert, Hi, Kumar!
robert lazarski schrieb:
Hi Kumar, I finally got time to get back to this:
On Nov 17, 2007 2:52 PM, Kumar Gala [off-list ref] wrote:
quoted
On Nov 16, 2007, at 4:01 PM, robert lazarski wrote:
quoted
quoted
quoted
Sorry for replying to myself, but thought I'd mention SRESET works
fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
doesn't work for me on 2.6.24rc2 .
What actual 85xx are you using?
- k
Custom 8548 board. I'm using the cds 85xx code for a reference and I
calling the same reset functions.
1. do you have the following in your dts:
global-utilities@e0000 { //global utilities reg
compatible = "fsl,mpc8548-guts";
reg = <e0000 1000>;
fsl,has-rstcr;
};
Yes.
quoted
2. in your platform code are you using fsl_rstcr_restart in
define_machine()
- k
Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
calling 'reboot' in the shell, it just hangs. Using the same dts and
resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
someone who does should be able to confirm whether the issue exists or
not by just attempting to reboot via bash.
ACK. Exactly the same over here (mpc8540ads compatible).
I added the global-utilities today as well, but reboot fails.
Why is the guts stuff missing i.e. in most of the shipped
mpc85xx*.dts? Does it depend on some hardware connections
external to the CPU?
Regards,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19
From: Kumar Gala <hidden> Date: 2007-11-27 07:38:33
quoted
Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
calling 'reboot' in the shell, it just hangs. Using the same dts and
resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
someone who does should be able to confirm whether the issue exists
or
not by just attempting to reboot via bash.
Can someone do a git-bisect and find the patch that breaks things?
quoted
ACK. Exactly the same over here (mpc8540ads compatible).
I added the global-utilities today as well, but reboot fails.
if you are on a 8540 GUTS doesn't support hreset_req (8548 or newer).
Why is the guts stuff missing i.e. in most of the shipped
mpc85xx*.dts? Does it depend on some hardware connections
external to the CPU?
Only the 8548 or newer CPUs have the GUTS HRESET_REQ ability that we
use to reset. (8540, 8560, 8541, 8555 do not).
- k
Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
calling 'reboot' in the shell, it just hangs. Using the same dts and
resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
someone who does should be able to confirm whether the issue exists
or
not by just attempting to reboot via bash.
Can someone do a git-bisect and find the patch that breaks things?
I'll see if I can reproduce it on my 8548cds. If so, I'll then git-bisect.
-Dale
Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
calling 'reboot' in the shell, it just hangs. Using the same dts and
resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
someone who does should be able to confirm whether the issue exists
or
not by just attempting to reboot via bash.
Can someone do a git-bisect and find the patch that breaks things?
I'll see if I can reproduce it on my 8548cds. If so, I'll then git-bisect.
I tried this with the current powerpc.git tree on my mpc8548cds, and
the reboot command works for me. The system rebooted just fine.
-Dale
From: Kumar Gala <hidden> Date: 2007-11-27 17:45:43
On Nov 27, 2007, at 8:54 AM, Dale Farnsworth wrote:
I wrote:
quoted
Kumar Gala wrote:
quoted
quoted
quoted
Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or
when
calling 'reboot' in the shell, it just hangs. Using the same dts
and
resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
someone who does should be able to confirm whether the issue
exists
or
not by just attempting to reboot via bash.
Can someone do a git-bisect and find the patch that breaks things?
I'll see if I can reproduce it on my 8548cds. If so, I'll then git-
bisect.
I tried this with the current powerpc.git tree on my mpc8548cds, and
the reboot command works for me. The system rebooted just fine.
I'm wondering if there is an issue rebooting if we are in an oops.
- k
On Tue, Nov 27, 2007 at 10:26:59AM -0600, Kumar Gala wrote:
On Nov 27, 2007, at 8:54 AM, Dale Farnsworth wrote:
quoted
I wrote:
quoted
Kumar Gala wrote:
quoted
quoted
quoted
Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or
when
calling 'reboot' in the shell, it just hangs. Using the same dts
and
resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
someone who does should be able to confirm whether the issue
exists
or
not by just attempting to reboot via bash.
Can someone do a git-bisect and find the patch that breaks things?
I'll see if I can reproduce it on my 8548cds. If so, I'll then git-
bisect.
I tried this with the current powerpc.git tree on my mpc8548cds, and
the reboot command works for me. The system rebooted just fine.
I'm wondering if there is an issue rebooting if we are in an oops.
I still can't reproduce it. Current powerpc.git reboots OK after an
oops on my 8548cds. As long as I make it to "Rebooting in 180 seconds..",
it resets 3 minutes later. It may be hw-dependent as well as
sw-dependent.
-Dale