Blocked using CodeWarrior; problem with hardware breakpoints

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Blocked using CodeWarrior; problem with hardware breakpoints

Jump to solution
1,114 Views
FRANCOIST
Contributor II

We are debugging u-boot using CodeWarrior on our new processor board with an MPC8572E.

 

We are currently blocked in our development. We are having problems with CodeWarrior

hardware breakpoints, and we are at a point in our investigation where we need Freescale support.

 

Here the situation:

 

We understand that in order to get hardware breakpoints to work we need:

1- A valid address with a valid instruction at IPVR (IVOR15),

2- DE bit enable in MSR register, and

3- To avoid problems; always set breakpoints before or after code which accesses SRR0 and SRR1, and never step through such code.

 

We are trying to get hw breakpoints to work directly after a processor hard reset.

The processor starts with the default POR processor config, plus the changes done as per our CodeWarrior init script.

 

Initially HW breakpoint works, but in u-boot we change IVPR from 0x0000_0000 (set to 0 in our init script) to 0xEFF8_0000.

0xEFF8_0000 is not valid at this point. Shortly after setting the interrupt vectors, we create a 4M TLB entry in AS1 for 0xEFF8_0000.

 

We do this as follow:

 

        /* create a temp mapping in AS1 to the 4M boot window (15) */

        lis     r6,FSL_BOOKE_MAS0(TLB_1, CONFIG_SYS_TLBN_FLASH, 0)@h                  --- > CONFIG_SYS_TLBN_FLASH is 15

        ori     r6,r6,FSL_BOOKE_MAS0(TLB_1, CONFIG_SYS_TLBN_FLASH, 0)@l

 

        lis     r7,FSL_BOOKE_MAS1(1, 1, 0, AS1, BOOKE_PAGESZ_4M)@h

        ori     r7,r7,FSL_BOOKE_MAS1(1, 1, 0, AS1, BOOKE_PAGESZ_4M)@l

 

        lis     r8,FSL_BOOKE_MAS2(TEXT_BASE & 0xffc00000, (MAS2_I|MAS2_G))@h          ----> TEXT_BASE is 0xEFF8_0000

        ori     r8,r8,FSL_BOOKE_MAS2(TEXT_BASE & 0xffc00000, (MAS2_I|MAS2_G))@l

 

        /* The 85xx has the default boot window 0xff800000 - 0xffffffff */

        lis     r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@h

        ori     r9,r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l

 

        mtspr   MAS0,r6

        mtspr   MAS1,r7

        mtspr   MAS2,r8

        mtspr   MAS3,r9

        isync

        msync

        tlbwe

 

After this point 0xEFF8_0000 should be valid and H/W breakpoint should work… it does not.

 

We have also verify that:

  • Address Space is 1 (MSR IS and DS are both set to 1),
  • Debug interrupt is enable (MSR DE is 1), and
  • The effect of the TLB update is visible (rfi instruction should cause this to occur).

 

Some code is actually doing this shortly after setting the TLB entry above…

 

        lis     r6,MSR_CE|MSR_ME|MSR_DE|MSR_IS|MSR_DS@h

        ori     r6,r6,MSR_CE|MSR_ME|MSR_DE|MSR_IS|MSR_DS@l

        lis     r7,switch_as@h

        ori     r7,r7,switch_as@l

 

        mtspr   SPRN_SRR0,r7

        mtspr   SPRN_SRR1,r6

        rfi

 

Still does not work!!

 

After doing all this, and looking into the forums and documentations, we are still puzzled why hardware breakpoint does not work.

 

Is our understanding correct? What else should we verify?

 

We have captured the content of few registers right after the hard reset, in case this info is needed;

IVPR:            0x0000_0000

TLB0CFG:         0x0411_0200

TLB1CFG:         0x101B_C010

PORBMSR:        0x8737_0000

BPTR:           0x0000_0000

CCSRBAR:        0x000E_0000

LAWBAR3:        0x000F_0000

LAWAR3: 0x8040_001B

Other LAW regs, all 0.

 

Thank you,

Francois

Labels (1)
0 Kudos
1 Solution
276 Views
FRANCOIST
Contributor II

FYI... problem is solved.

We cleaned-up our cfg file and H/W breakpoints worked really well after that.

 

I believe the explaination above is quite correct.

 

Other things to check are more obvious... i.e. overlapping TLB entries.

 

 

View solution in original post

0 Kudos
1 Reply
277 Views
FRANCOIST
Contributor II

FYI... problem is solved.

We cleaned-up our cfg file and H/W breakpoints worked really well after that.

 

I believe the explaination above is quite correct.

 

Other things to check are more obvious... i.e. overlapping TLB entries.

 

 

0 Kudos