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

[robert lazarski]

On 9/28/07, robert lazarski <robertlazarski at gmail.com> wrote:
> On 9/26/07, Andy Fleming <afleming at gmail.com> wrote:
> > 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.
> >
>
> Can I get clarification on one point in particular here please? Before
> the TLB's get processed, IVPR is set to the TEXT_BASE - 0xfff80000 -
> and then IVOR15 is set to 0x0f00, ie 'Debug' interrupt type is mapped
> to 0xfff80f00 . If that is correct, isn't 0xfff80f00 unmapped, since
> only the last page 0xfffff000-0xffffffff is mapped?
>
> I ask because for bdi, debugging works only if the Debug Interrupt
> (IVOR15) points to a valid, mapped and therefore executable opcode. If
> not then the core crashes. I ask because I may have a TLB issue and
> I'm having a hard finding it. Or maybe the bdi core is crashing simply
> because IVOR15 is not an executable opcode ?
>
> Thanks all, I hope I'm asking valid questions that are of general interest,
> Robert
>

I know its poor form to keep replying to myself, but I believe I
narrowed my problem down to be IVOR + IVOR15 for sure and _not_ the
tlb1 entries, ie, the bdi is crashing and its not because of a bad tlb
at this point. After looking at code and debugging best I could, these
lines in start.S:

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)

At least the first time through and where the bdi crashes have so far
_only_ processed in my init.S :

 53 #define entry_start \
 54         mflr    r1      ;       \
 55         bl      0f      ;
 56
 57 #define entry_end \
 58 0:      mflr    r0      ;       \
 59         mtlr    r1      ;       \
 60         blr             ;
 61
 62
 63         .section        .bootpg, "ax"
 64         .globl  tlb1_entry
 65 tlb1_entry:
 66         entry_start
 67
 68         /*
 69          * Number of TLB0 and TLB1 entries in the following table
 70          */
 71         .long (2f-1f)/16

That code is standard on all 85xx boards, ie, AFAIK only the number of
TLB's are known at this stage and a 'bl 1f' where the TLB0 and TLB1
are actually processed haven't been executed yet. Make sense? If so,
that leaves me with (a) figuring out how to get IVOR + IVO15 to have a
mapped and executable opcode (b) debugging this part of the code
without the bdi and without a serial port (c) using the new bdi
firmware which Abatron tells me can , via gdb,  debug without IVOR +
IVO15 .

Best regards,
Robert