From: mike zheng <hidden> Date: 2007-08-14 20:21:59
Hi All,
I am trying to bring up MPC8548 CDS board on 2.4 kernel. I have problem in
the head_e500.S. The "mtspr SRR0, r7; mtspr SRR1 r6" does not work for me.
The content of R7 and R6 are not moved to SRR0 and SRR1. I am using the
tool-chain from Freescale for 2.6 kernel.
Any idea on this issue?
Thanks,
Mike
Code of head_e500.S:
slwi r6,r6,5 /* setup new context with other address space */
bl 1f /* Find our address */
1: mflr r9
rlwimi r7,r9,0,20,31
addi r7,r7,24
mtspr SRR0,r7 ........No change in SRR0
mtspr SRR1,r6 ........No change in SRR1
rfi ........System crash
/* 4. Clear out PIDs & Search info */ l
li r6,0
mtspr SPRN_PID0,r6
mtspr SPRN_PID1,r6
mtspr SPRN_PID2,r6
mtspr SPRN_MAS6,r6
From: Andy Fleming <hidden> Date: 2007-08-14 20:39:06
On Aug 14, 2007, at 15:21, mike zheng wrote:
Hi All,
I am trying to bring up MPC8548 CDS board on 2.4 kernel. I have
problem in the head_e500.S. The "mtspr SRR0, r7; mtspr SRR1 r6"
does not work for me. The content of R7 and R6 are not moved to
SRR0 and SRR1. I am using the tool-chain from Freescale for 2.6
kernel.
Any idea on this issue?
Just to check...how do you know it doesn't work?
Andy
From: mike zheng <hidden> Date: 2007-08-15 13:59:43
I use BDI to debug these two instructions. And here are the output of BDI
just before the "rfi". The content of R6, R7 is different from SRR0(SPR26)
and SRR1(SPR27).
cds8548>res run
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- JTAG exists check passed
- IDCODE is 0x0003901D
- SVR is 0x80390011
- PVR is 0x80210010
- CCSRBAR is 0x0_ff700000
- BDI removes HRESET
- TARGET: Target PVR is 0x80210010
- TARGET: resetting target passed
cds8548>halt
Target CPU : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : COP halt
Current PC : 0xfff82560
Current CR : 0x88000042
Current MSR : 0x00021200
Current LR : 0xfff8aa4c
Current CCSRBAR : 0x0_e0000000
cds8548>ci
cds8548>bi 0x0000015c
Breakpoint identification is 0
cds8548>go
- TARGET: stopped
cds8548>rd
GPR00: 00000000 0ffabd20 00000200 00000008
GPR04: 00000000 00000001 00000020 00000160
GPR08: 1f8b0808 00000148 0ffabace 0ffe08b0
GPR12: 00000006 764deddb 10000300 007fff00
GPR16: 00000001 ffffffff 007fff25 0ffff9d8
GPR20: 007ffeb0 00000000 0fffaa3c 0ffae490
GPR24: 00000000 00000003 02000040 007fff25
GPR28: 007fff00 0ffab3b8 0fcd6000 007ffeb0
CR : 24024022 MSR: 00021200
cds8548>rdspr 26
SPR 26 : 0xfff81300 - 519424
cds8548>rdspr 27
SPR 27 : 0x00001000 4096
cds8548>
On 8/14/07, Andy Fleming [off-list ref] wrote:
On Aug 14, 2007, at 15:21, mike zheng wrote:
quoted
Hi All,
I am trying to bring up MPC8548 CDS board on 2.4 kernel. I have
problem in the head_e500.S. The "mtspr SRR0, r7; mtspr SRR1 r6"
does not work for me. The content of R7 and R6 are not moved to
SRR0 and SRR1. I am using the tool-chain from Freescale for 2.6
kernel.
Any idea on this issue?
Just to check...how do you know it doesn't work?
Andy
From: Becky Bruce <hidden> Date: 2007-08-15 16:17:04
On Aug 15, 2007, at 8:59 AM, mike zheng wrote:
I use BDI to debug these two instructions. And here are the output
of BDI just before the "rfi". The content of R6, R7 is different
from SRR0(SPR26) and SRR1(SPR27).
I see you have not printed the pc/nia once you stop. Are you sure
you're stopped where you think? Please check this.
-B
cds8548>res run
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- JTAG exists check passed
- IDCODE is 0x0003901D
- SVR is 0x80390011
- PVR is 0x80210010
- CCSRBAR is 0x0_ff700000
- BDI removes HRESET
- TARGET: Target PVR is 0x80210010
- TARGET: resetting target passed
cds8548>halt
Target CPU : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : COP halt
Current PC : 0xfff82560
Current CR : 0x88000042
Current MSR : 0x00021200
Current LR : 0xfff8aa4c
Current CCSRBAR : 0x0_e0000000
cds8548>ci
cds8548>bi 0x0000015c
Breakpoint identification is 0
cds8548>go
- TARGET: stopped
cds8548>rd
GPR00: 00000000 0ffabd20 00000200 00000008
GPR04: 00000000 00000001 00000020 00000160
GPR08: 1f8b0808 00000148 0ffabace 0ffe08b0
GPR12: 00000006 764deddb 10000300 007fff00
GPR16: 00000001 ffffffff 007fff25 0ffff9d8
GPR20: 007ffeb0 00000000 0fffaa3c 0ffae490
GPR24: 00000000 00000003 02000040 007fff25
GPR28: 007fff00 0ffab3b8 0fcd6000 007ffeb0
CR : 24024022 MSR: 00021200
cds8548>rdspr 26
SPR 26 : 0xfff81300 - 519424
cds8548>rdspr 27
SPR 27 : 0x00001000 4096
cds8548>
On 8/14/07, Andy Fleming [off-list ref] wrote:
On Aug 14, 2007, at 15:21, mike zheng wrote:
quoted
Hi All,
I am trying to bring up MPC8548 CDS board on 2.4 kernel. I have
problem in the head_e500.S. The "mtspr SRR0, r7; mtspr SRR1 r6"
does not work for me. The content of R7 and R6 are not moved to
SRR0 and SRR1. I am using the tool-chain from Freescale for 2.6
kernel.
Any idea on this issue?
Just to check...how do you know it doesn't work?
Andy
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
From: mike zheng <hidden> Date: 2007-08-15 21:12:42
Here is the PC value before the rfi:
cds8458>halt
Target CPU: : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : instruction breakpoint
Current PC : 0x0000015c
Current CR : 0x24024022
Current MSR : 0x00012100
Current LR :0x00000148
Current CCSRBAR :0x0_e000000
After the rfi:
#step timeout defected
cds8458>halt
Target CPU: : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : COP halt
Current PC : 0xfff81300
Current CR : 0x24024022
Current MSR : 0x00001000
Current LR :0x00000148
Current CCSRBAR :0x0_e000000
On 8/15/07, Becky Bruce [off-list ref] wrote:
On Aug 15, 2007, at 8:59 AM, mike zheng wrote:
quoted
I use BDI to debug these two instructions. And here are the output
of BDI just before the "rfi". The content of R6, R7 is different
from SRR0(SPR26) and SRR1(SPR27).
I see you have not printed the pc/nia once you stop. Are you sure
you're stopped where you think? Please check this.
-B
quoted
cds8548>res run
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- JTAG exists check passed
- IDCODE is 0x0003901D
- SVR is 0x80390011
- PVR is 0x80210010
- CCSRBAR is 0x0_ff700000
- BDI removes HRESET
- TARGET: Target PVR is 0x80210010
- TARGET: resetting target passed
cds8548>halt
Target CPU : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : COP halt
Current PC : 0xfff82560
Current CR : 0x88000042
Current MSR : 0x00021200
Current LR : 0xfff8aa4c
Current CCSRBAR : 0x0_e0000000
cds8548>ci
cds8548>bi 0x0000015c
Breakpoint identification is 0
cds8548>go
- TARGET: stopped
cds8548>rd
GPR00: 00000000 0ffabd20 00000200 00000008
GPR04: 00000000 00000001 00000020 00000160
GPR08: 1f8b0808 00000148 0ffabace 0ffe08b0
GPR12: 00000006 764deddb 10000300 007fff00
GPR16: 00000001 ffffffff 007fff25 0ffff9d8
GPR20: 007ffeb0 00000000 0fffaa3c 0ffae490
GPR24: 00000000 00000003 02000040 007fff25
GPR28: 007fff00 0ffab3b8 0fcd6000 007ffeb0
CR : 24024022 MSR: 00021200
cds8548>rdspr 26
SPR 26 : 0xfff81300 - 519424
cds8548>rdspr 27
SPR 27 : 0x00001000 4096
cds8548>
On 8/14/07, Andy Fleming [off-list ref] wrote:
On Aug 14, 2007, at 15:21, mike zheng wrote:
quoted
Hi All,
I am trying to bring up MPC8548 CDS board on 2.4 kernel. I have
problem in the head_e500.S. The "mtspr SRR0, r7; mtspr SRR1 r6"
does not work for me. The content of R7 and R6 are not moved to
SRR0 and SRR1. I am using the tool-chain from Freescale for 2.6
kernel.
Any idea on this issue?
Just to check...how do you know it doesn't work?
Andy
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
From: Andy Fleming <hidden> Date: 2007-08-15 22:06:19
On Aug 15, 2007, at 16:12, mike zheng wrote:
Here is the PC value before the rfi:
cds8458>halt
Target CPU: : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : instruction breakpoint
Current PC : 0x0000015c
Current CR : 0x24024022
Current MSR : 0x00012100
Current LR :0x00000148
Current CCSRBAR :0x0_e000000
After the rfi:
#step timeout defected
cds8458>halt
Target CPU: : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : COP halt
Current PC : 0xfff81300
Current CR : 0x24024022
Current MSR : 0x00001000
Current LR :0x00000148
Current CCSRBAR :0x0_e000000
Ok, I'm sure your problem isn't that SRR0 isn't getting updated
properly. I suspect something is going wrong during the rfi.
Possibly something in your TLBs. However, what is happening is most
likely that you have hit an exception, and SRR0 and SRR1 have been
updated. I'm a little confused by the addresses where you first
invoke "halt". It looks like you're in the middle of flash, which is
an odd place in u-boot to be.
And if you look at your PC, it doesn't seem like you step. It looks
like something goes wrong with the debugging. My suggestion is to
check your TLB setup and your IVOR setup. Find out if the IVORs are
pointing at an exception at fff81300.
Andy
From: mike zheng <hidden> Date: 2007-08-15 22:46:27
Hi Andy,
Here is BDI output of the register value after line 212. The value of R6, R7
is 0x20, 0x160. However the value of SRR0(SPR26), SRR1(SPR27) is 0xfff81300
and 0x00001000. Why are they different from r7 and r6? We just did the
mtspr, the value should be the same. The rfi jump to 0xfff81300 is because
of the value in SRR0.
211 mtspr SRR0, r7
212 mtspr SRR1, r6
213 rfi
214
215 /*4. Clear out PIDs & Search info */
216 li r6, 0
BDI output:
cds8548>bi 0x0000015c
Breakpoint identification is 0
cds8548>go
- TARGET: stopped
cds8548>rd
GPR00: 00000000 0ffabd20 00000200 00000008
GPR04: 00000000 00000001 00000020 00000160
GPR08: 1f8b0808 00000148 0ffabace 0ffe08b0
GPR12: 00000006 764deddb 10000300 007fff00
GPR16: 00000001 ffffffff 007fff25 0ffff9d8
GPR20: 007ffeb0 00000000 0fffaa3c 0ffae490
GPR24: 00000000 00000003 02000040 007fff25
GPR28: 007fff00 0ffab3b8 0fcd6000 007ffeb0
CR : 24024022 MSR: 00021200
cds8548>rdspr 26
SPR 26 : 0xfff81300 - 519424
cds8548>rdspr 27
SPR 27 : 0x00001000 4096
cds8548>
On 8/15/07, Andy Fleming [off-list ref] wrote:
On Aug 15, 2007, at 16:12, mike zheng wrote:
quoted
Here is the PC value before the rfi:
cds8458>halt
Target CPU: : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : instruction breakpoint
Current PC : 0x0000015c
Current CR : 0x24024022
Current MSR : 0x00012100
Current LR :0x00000148
Current CCSRBAR :0x0_e000000
After the rfi:
#step timeout defected
cds8458>halt
Target CPU: : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : COP halt
Current PC : 0xfff81300
Current CR : 0x24024022
Current MSR : 0x00001000
Current LR :0x00000148
Current CCSRBAR :0x0_e000000
Ok, I'm sure your problem isn't that SRR0 isn't getting updated
properly. I suspect something is going wrong during the rfi.
Possibly something in your TLBs. However, what is happening is most
likely that you have hit an exception, and SRR0 and SRR1 have been
updated. I'm a little confused by the addresses where you first
invoke "halt". It looks like you're in the middle of flash, which is
an odd place in u-boot to be.
The first halt is at 0x0000015c, which is the break point I set after line
212. It is in the memory, not flash.
And if you look at your PC, it doesn't seem like you step. It looks
like something goes wrong with the debugging. My suggestion is to
check your TLB setup and your IVOR setup. Find out if the IVORs are
pointing at an exception at fff81300.
All the TLB and IVOR setup is from Uboot, the kernel haven't touched them
yet.
Andy
From: Andy Fleming <hidden> Date: 2007-08-16 01:16:49
On Aug 15, 2007, at 17:46, mike zheng wrote:
Hi Andy,
Here is BDI output of the register value after line 212. The value
of R6, R7 is 0x20, 0x160. However the value of SRR0(SPR26), SRR1
(SPR27) is 0xfff81300 and 0x00001000. Why are they different from
r7 and r6? We just did the mtspr, the value should be the same. The
rfi jump to 0xfff81300 is because of the value in SRR0.
Yes, it's very strange. But it's also pretty much impossible for the
mtspr to just fail like that. A more likely scenario is that the BDI
is getting bad information. Could you take a look at your IVORs?
I'm very curious to see if fff81300 is an interrupt vector.
Andy
From: mike zheng <hidden> Date: 2007-08-16 14:37:49
On 8/15/07, Andy Fleming [off-list ref] wrote:
On Aug 15, 2007, at 17:46, mike zheng wrote:
quoted
Hi Andy,
Here is BDI output of the register value after line 212. The value
of R6, R7 is 0x20, 0x160. However the value of SRR0(SPR26), SRR1
(SPR27) is 0xfff81300 and 0x00001000. Why are they different from
r7 and r6? We just did the mtspr, the value should be the same. The
rfi jump to 0xfff81300 is because of the value in SRR0.
Yes, it's very strange. But it's also pretty much impossible for the
mtspr to just fail like that. A more likely scenario is that the BDI
is getting bad information. Could you take a look at your IVORs?
I'm very curious to see if fff81300 is an interrupt vector.
Now I know the BDI need debug vector to be set properly. I manually change
the IVPR and IVOR15 for BDI, and will update you the progress.
Andy