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

[robert lazarski]

On 9/26/07, Andy Fleming <afleming at gmail.com> wrote:
> On 9/26/07, robert lazarski <robertlazarski at gmail.com> wrote:
> > On 9/26/07, Jerry Van Baren <gerald.vanbaren at smiths-aerospace.com> wrote:
> > > robert lazarski wrote:
> > >
> >         .long TLB1_MAS0(0, 0, 0)
> >         .long TLB1_MAS1(1, 0, 0, 0, 0)
> >         .long TLB1_MAS2(E500_TLB_EPN(CFG_CCSRBAR_DEFAULT), 0,0,0,0,1,0,1,0)
> >         .long TLB1_MAS3(E500_TLB_RPN(CFG_CCSRBAR_DEFAULT), 0,0,0,0,0,1,0,1,0,1)
>
>
> You might not need this entry.  I think you're covering it with the
> Flash mapping.  This is probably true for some other boards, and I
> don't think it's your problem, but having two mappings for the same
> virtual address space is technically a programming error.  It just
> happens that there's no negative side effect on e500.

I tried removing it, but I still get the same error.

>
> >          * These entries end up at TLB0 Indicies 0x10, 0x14, 0x18 and 0x1c,
> >          * and must not collide with other TLB0 entries.
> >          */
> >         .long TLB1_MAS0(0, 0, 0)
> >         .long TLB1_MAS1(1, 0, 0, 0, 0)
> >         .long TLB1_MAS2(E500_TLB_EPN(CFG_INIT_RAM_ADDR),
> >                         0,0,0,0,0,0,1,0)
> >         .long TLB1_MAS3(E500_TLB_RPN(CFG_INIT_RAM_ADDR),
> >                         0,0,0,0,0,1,0,1,0,1)
>
> What did you set CFG_INIT_RAM_ADDR to?

0xe4010000 . Seems like a lot of boards do that - what is the
significance of this address? This gets used only after relocation, is
that correct? I only have DDR2. This is actually TLB0 if I understand
correctly, TLB1 processing is actually where my code seems to die,
right?

>
> >         /*
> >          * TLB 0, 1:    128M    Non-cacheable, guarded
> >          * 0xf8000000   128M    FLASH
> >          * Out of reset this entry is only 4K.
> >          */
> >         .long TLB1_MAS0(1, 1, 0)
> >         .long TLB1_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_64M)
> >         .long TLB1_MAS2(E500_TLB_EPN(CFG_FLASH_BASE), 0,0,0,0,1,0,1,0)
> >         .long TLB1_MAS3(E500_TLB_RPN(CFG_FLASH_BASE), 0,0,0,0,0,1,0,1,0,1)
> >         .long TLB1_MAS0(1, 0, 0)
> >         .long TLB1_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_64M)
> >         .long TLB1_MAS2(E500_TLB_EPN(CFG_FLASH_BASE+0x4000000), 0,0,0,0,1,0,1,0)
> >         .long TLB1_MAS3(E500_TLB_RPN(CFG_FLASH_BASE+0x4000000), 0,0,0,0,0,1,0,1,0,1)
>
>
> Try reordering these entries so that TLB1, entry 0 is initialized
> before TLB1, entry 1.  I'm fighting a cold right now, so I'm not
> thinking of any good reason why this is necessary, but I know that's
> how I did it on the 8568 MDS board.

Tried that, seemingly no help. I really am thinking my flash is the
culprit here though - its the first thing parsed through the loop in
start.S right?. I tried both locking and unlocking my flash in the bdi
config file, but I seen no change. With my 128MB of flash unlocked vi
the bdi config, I can write to the beginning as shown here:

ATUM>erase 0xF8000000 0x4000 0x20
Erasing flash at 0xf8000000
...
ATUM>mmh 0xf8000000 0xcafe
ATUM>mdh 0xf8000000 1
0_f8000000 : 0xcafe  -13570  ..

Is there anything I can do further to see if my flash is the cause of
my problems?
>
> Another possibility to consider is that the BDI's config that you are
> using is creating its own bad mappings.
>
> Andy
>

I've looked at the bdi config a lot today. I think I get the 'core is
stopped'  issue because of my IVOR15 is bad. I'm hoping if I can fix
that I might be able to get better clues on what is wrong. Abatron
support tells me:

"As mentioned in the manual, debugging works only if the Debug Interrupt
(IVOR15) points to a valid, mapped and therefore executable opcode. If
not then the core will crash!"

Any suggestions on what that needs to be when debugging before
relocation? This doesn't seem to be working for me - I'm not using a
workspace:

WSPR    63          0xffff0000  ;IVPR to boot core
WSPR    415         0x0000f000  ;IVOR15 : Debug exception

Another thing: I seemingly can skip IVOR15 all together by using GDB -
so says arbartron:

One way to debug code where the above conditions are not meet, is to use
"BREAKMODE LOOP" and then use GDB to debug.
Use always "run to cursor" or make sure that you remove the breakpoint
that triggers before you continue, this to prevent GDB to do any single
stepping.

I started the bdi in BREAKMODE LOOP, but the gdb part if not working
for me. I can connect to the bdi, and I can hit the beginning of
start.S. Anything after that appears to be dying on me - still working
on it.

Thanks all,
Robert