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

[Joakim Tjernlund]

Scott Wood <scottwood at freescale.com> wrote on 2012/05/02 21:34:18:
>
> 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.

Yes, fully agreed. I miss the sane 0 address boot vector too.

>
> > 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.

ehh, emulator attached we can run u-boot to the fullest and without the emulator we cannot get
past start.S

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

Yes, trying to get there.

>
> > 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.

Cant' get past the asm in start.S(is fails at switch_as:) so no serial output :(

>
> > 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.

Ahh, so we have 0xff80_0000 to 0xffff_ffff to begin with.
This space will probably be too small for us as we want to relocate the
main part of the boot to beginning of flash(once the bringup is complete).
This raises another question, not the is just one u-boot.bin img with
bot the bootpg and the rest of the uboot. This img pads the space between normal u-boot
and bootpg.
Ideally one show have the option to build 2 images, one bootpg and another img
for normal u-boot so one can burn these at different locations without padding.
I cannot see any support for this but i might be missing something?

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

No idea, just getting used to our P2010 :)
It would be very valuable to run gdb in the early phase during bringup as this
can be very time consuming.

>
> 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.

I see, I think you got this value from the reference manual because it is misprinted
in there and corrected in the errata.

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

Not getting past start.S :)
It was more a debug suggestion to see if u-boot still worked.