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