System crash on boot_e500.S on 2.4Kernel

System crash on boot_e500.S on 2.4Kernel

[mike zheng]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

  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

[-- Attachment #2: Type: text/html, Size: 4027 bytes --]

Re: System crash on boot_e500.S on 2.4Kernel

[Andy Fleming]

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

Re: System crash on boot_e500.S on 2.4Kernel

[mike zheng]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

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 <afleming@freescale.com> wrote:
>
>
> 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
>

[-- Attachment #2: Type: text/html, Size: 2532 bytes --]

Re: System crash on boot_e500.S on 2.4Kernel

[Becky Bruce]

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 <afleming@freescale.com> wrote:
> 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
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: System crash on boot_e500.S on 2.4Kernel

[mike zheng]

[-- Attachment #1: Type: text/plain, Size: 3482 bytes --]

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 <becky.bruce@freescale.com> wrote:
>
>
> 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 <afleming@freescale.com> wrote:
> > 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
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>

[-- Attachment #2: Type: text/html, Size: 6346 bytes --]

Re: System crash on boot_e500.S on 2.4Kernel

[Andy Fleming]

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

Re: System crash on boot_e500.S on 2.4Kernel

[mike zheng]

[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]

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 <afleming@freescale.com> wrote:
>
>
> 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.


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
>

[-- Attachment #2: Type: text/html, Size: 5917 bytes --]

Re: System crash on boot_e500.S on 2.4Kernel

[Andy Fleming]

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

Re: System crash on boot_e500.S on 2.4Kernel

[mike zheng]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On 8/15/07, Andy Fleming <afleming@freescale.com> wrote:
>
>
> 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.


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
>

[-- Attachment #2: Type: text/html, Size: 1401 bytes --]