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

[Andy Fleming]

On 9/26/07, robert lazarski <robertlazarski at gmail.com> wrote:
> Hi all,
>
>
> Starting with the basics: R1 has a 4K stack from 0xfffff000-0xffffffff
> and the stack grows down?

It better not.  r1 will eventually have a stack somewhere.  Initially,
we put it in unmapped memory space which allows us to use the cache as
memory.  0xfffff000-0xffffffff is the last page in memory, and that is
a) in Flash, and b) the boot page.  Until you execute the code you're
having a problem with below, that last page will be the only page
mapped.

>
> 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'  ?


It sets up the TLBs as you should have set up in your board's init.S
file.  When tlb1_entry returns, r0 will point to a word with the
number of TLB entries.  After that, it's an array which is fairly
straightforward:

MAS0
MAS1
MAS2
MAS3

>
> Here's the part where my code or the bdi is crashing, line 163 which
> is mapped as fffff0c0 :
>
> 163 0:      lwzu    r6,4(r5)
>

> 'lwzu    r6,4(r5)' as I read it says: load a word from R5 + 4 bytes,
> ie, address fffff214:
>
> ATUM>mdh 0xfffff214 2
> 0_fffff214 : 0x0000       0  ..
> 0_fffff216 : 0x0000       0  ..


Ok, but that's what you would expect, if you look in init.S.  The
first entry is:

TLB1_MAS0(0,0,0)

The TLB1 part is misleading (one day, I will change all of those
macros), but it sets up MAS0 to point at TLB0, entry 0.


> Is my problem is that I am assigning zero here? I'm confused since the
> CDS code seems to work the same way. The result of single stepping
> consistently results in:


I can assure that's not the problem.


>
> ATUM>info
>     Target CPU        : MPC85xx (e500v2 rev.2)
>     Target state      : halted
>     Debug entry cause : instruction breakpoint
>     Current PC        : 0xfffff0c0
>     Current CR        : 0x00000000
>     Current MSR       : 0x00000200
>     Current LR        : 0xfffff0b4
>     Current CCSRBAR   : 0x0_e0000000
> ATUM>ti
> - Core status is 0x0041
> *** Core is stopped, no debugging possible
> # PPC: timeout while waiting for halt
> ATUM>    Target CPU        : MPC85xx (e500v2 rev.2)
>     Target state      : running
> # Step timeout detected
>
> I sent a question to Abatron technical support about this in the case
> its a bdi issue - still waiting to see what they say.
>
> Any clues please?
> Robert


Well, there's nothing wrong with the code you've shown us so far.
Does the CDS show the same problem when single-stepping?  Are you sure
you're single-stepping?  My first guess would be that you've set up
TLB1, entry 0 with something that's not Flash, and that what you are
seeing is the result of unmapping your Flash while executing out of
it.

What does your init.S look like?

Andy