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

[Scott Wood]

On 05/02/2012 03:09 PM, Joakim Tjernlund wrote:
> Scott Wood <scottwood at freescale.com> wrote on 2012/05/02 21:34:18:
>>
>> On 05/02/2012 02:04 PM, Joakim Tjernlund wrote:
>>> 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

Ah, my brain filled in the missing punctuation in the wrong place. :-)

Is the BDI doing any initialization at all, when you have it attached?
Or is the mere presence enough?

The latter case reminds me of a problem on early rev mpc8313erdb where
there was a board design error, resulting in a hang when the power
management registers were accessed in the absence of a JTAG connection.

>> 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 :(

You can do serial output in start.S, you just have to do everything
manually.

If you aren't doing serial output and don't have BDI attached, how do
you know switch_as is where it stops?

You may want to try installing usable exception handlers.

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

Why do you want to do this?  You're creating more work for yourself by
not doing it the way other 85xx boards work.

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

This is not supported.  You're supposed to put everything at the end of
flash.

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

No.  Usually on e500v2 the hardware has a default CCSR of 0x0_ff70_0000,
and we change that to 0x0_ffe0_0000 (or 0xf_ffe0_0000 in a 36-bit
address map).  It's like this on all 85xx, not just p20x0.

Either someone took the value software uses and stuck it in the hardware
manual, or (more likely) it was due to confusion with e500mc-based SoCs,
which do have a default of 0x0_fe00_0000 because their CCSR is 16 MiB
and 0x0_ff70_0000 wouldn't be properly aligned.

-Scott