[U-Boot] Default LAWBAR mapping at reset for mpc85xx?

[Scott Wood]

On 05/02/2012 02:04 PM, Joakim Tjernlund wrote:
> 
> Still trying to wrap my head around the P2010 cpu and its boot sequence(NOR)

Yeah, it's a bit convoluted.

> We can run the full u-boot it we use the BDI emulator but without emulator it
> won't boot.

I'm not sure what "BDI emulator but without emulator" means.

If you mean the BDI is trying to initialize things rather than leave the
system in its default state, don't do that.

> We have 64 MB NOR flash and have based out design on the P1020RDB and we boot from NOR.
> Using the emulator but with minimal config we cannot get past the switch_as part in start.S
> if we define a LAWBAR for our flash space in the emulator, u-boot will boot correctly.

Given the issues with e500v2 hardware debug that Prabhakar has been
trying to work around, I'd try debugging with serial output instead
during that phase of the boot, at least to see how far you get in the
absence of breakpoints or single stepping.

> We don't understand how the initial routing of addresses to CS0 work without an
> LAWBAR mapping(all LAWBARS are invalid at reset). Is there some HW default at work
> here we have yet to see?

There's a boot translation window that acts like a LAW.  This is
described in section 4.3.1.3 ("Boot Page Translation") of the manual.

> Other observations
> 1) why not map initial stack to L2SRAM instead of cache? That would make early debugging
>    much simpler as the memory would stay when stepping with gdb.

You could do that, but then you'd have to have separate handling for
e500mc where the CPC (L3) is what can be used for SRAM -- and are there
any 85xx that don't have L2?

It would be nice to not need special hacks in simulators that don't
normally model cache (but could more easily model SRAM).

> 2) RDB has its CCSRBAR defined to 0xffe00000 which is not the default ccsrbar(0xff700000)
>    this looks like a typo,

It's not a typo.  We do this on all the 85xx boards.  At this point
you'll probably need a time machine to find out why (probably just fit
into software's intended memory map better), but we're not going to
change it now.

> and if it is, does u-boot work on RDB boards if changed
>    to the default?

I would not expect U-Boot to break if you change the CCSRBAR setting
(but of course I can't guarantee that), but you will need to update the
device tree to match, and other OSes may have this hardcoded.

> I suspect RDB could end up in the same trap we are stuck in.

What sort of trap?

-Scott