[U-Boot-Users] Need help understanding cpu/mpc85xx/start.S

[Jerry Van Baren]

robert lazarski wrote:
> Hi all,
> 
> My custom 85xx board code off of the latest u-boot git repo is dying -
> or locking up the bdi somehow - and I've spent the last few days
> trying to understand the code and how the bdi can tell me what the
> registers are doing.
> 
> Starting with the basics: R1 has a 4K stack from 0xfffff000-0xffffffff
> and the stack grows down?
> 
> Here's the part of the code I'm crashing in and which I trying to
> understand, shown here from vim with lines enabled:
> 
>  158         bl      tlb1_entry
>  159         mr      r5,r0
>  160         lwzu    r4,0(r5)        /* how many TLB1 entries we actually use */
>  161         mtctr   r4
>  162
>  163 0:      lwzu    r6,4(r5)
>  164         lwzu    r7,4(r5)
>  165         lwzu    r8,4(r5)
>  166         lwzu    r9,4(r5)
>  167         mtspr   MAS0,r6
>  168         mtspr   MAS1,r7
>  169         mtspr   MAS2,r8
>  170         mtspr   MAS3,r9
>  171         isync
>  172         msync
>  173         tlbwe
>  174         isync
>  175         bdnz    0b
>  176
>  177 1:
> 
> Are lines 158-171 setting up the TLB's as defined by 'bl      tlb1_entry'  ?

Sounds like a good guess.

Here is my guess: you should go through tlb1_entry() with a fine tooth 
comb and see exactly what it is doing with the TLBs and why that is 
messing you up.

Where the processor "crashes" is very likely a delayed reaction to a tlb 
screwup.  What happens is that some instructions remain in the 
processor's prefetch queue so the processor will continue to execute for 
a little while.  Playing with MMUs (TLBs) is like playing with 
grenades... they don't go off immediately when you pull the pin. 
DAMHIKT  ;-)

When I have a crash in perfectly valid code, I look upstream a few 
instructions.

> Line 160 is disassembled to be address fffff0b8 , which I can set a
> breakpoint to and analyze as follows:
> 
> ATUM>bi 0xfffff0b8
> Breakpoint identification is 0
> ATUM>go
> - TARGET: stopped
> ATUM>info
>     Target CPU        : MPC85xx (e500v2 rev.2)
>     Target state      : halted
>     Debug entry cause : instruction breakpoint
>     Current PC        : 0xfffff0b8
>     Current CR        : 0x00000000
>     Current MSR       : 0x00000200
>     Current LR        : 0xfffff0b4
>     Current CCSRBAR   : 0x0_e0000000
> ATUM>rd
> GPR00: fffff210 fffff0b4 00010001 00000000
> GPR04: 00000000 fffff210 00000000 00000000
> GPR08: 00000000 00000000 00000000 00000000
> GPR12: 00000000 00000000 00000000 00000000
> GPR16: 00000000 00000000 00000000 00000000
> GPR20: 00000000 00000000 00000000 00000000
> GPR24: 00000000 00000000 00000000 00000000
> GPR28: 00000000 00000000 00000000 00000000
> CR   : 00000000     MSR: 00000200
> ATUM>mdh 0xfffff210 2
> 0_fffff210 : 0x0000       0  ..
> 0_fffff212 : 0x000b      11  ..
>
> I read the above to say that the 'rd' command shows all Rx registers
> as zero based, and R5 is  fffff210.

Yes.

> Line 160's 'lwzu    r4,0(r5)' will
> read a 16bit word of a value of 'b' and assign it to R4, confirmed by
> the next 'ti' :

No, 32 bit word.  Time to crack your PPC opcode manual.  The lwzu 
instruction reads the *32 bit* value pointed to by r5 with a zero 
offset, and updates r5 with r5+offset.  Since the offset is zero in this 
case, r5 still points to 0xfffff210.

The "z" in the lwzu opcode means the upper 32 bits would be zeroed if r4 
had 64 bits (lhzu zeros the upper 16 bits, lbzu zeros the upper 24 
bits).  Since your processor is 32 bits, the "z" is meaningless.

When you get into the loop, however, the offset is 4:
     163 0:      lwzu    r6,4(r5)
so r6 (in this case will be loaded from 0xfffff210+4) and r5 will be 
"updated" to be 0xfffff214.  Thus r5 steps through the table.

As discussed above, however, I *strongly* suspect you have a messed up 
TLB and the grenade only goes off here in the middle of innocent 
instructions.

> Any clues please?
> Robert

Good luck,
gvb