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

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

[Joakim Tjernlund]

Still trying to wrap my head around the P2010 cpu and its boot sequence(NOR)
We can run the full u-boot it we use the BDI emulator but without emulator it
won't boot.
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.

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?

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.

2) RDB has its CCSRBAR defined to 0xffe00000 which is not the default ccsrbar(0xff700000)
   this looks like a typo, and if it is, does u-boot work on RDB boards if changed
   to the default? I suspect RDB could end up in the same trap we are stuck in.

 Jocke

[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

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

[Joakim Tjernlund]

Scott Wood <scottwood@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.

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

[Scott Wood]

On 05/02/2012 03:09 PM, Joakim Tjernlund wrote:
> Scott Wood <scottwood@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

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

[Schneider, Kolja]

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

Easily done, just throw out everything in the [init] section. Or is this really just
about BDI presence, as Scott suggested?

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

Have you checked your board's law.c and the corresponding flash-related 
#defines, i.e. CONFIG_SYS_FLASH_BASE_PHYS, and the LAW size?

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

Do you really need this? Why not just use the last 512k for u-boot?

> > > 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 changed it to 0xff70000 again due to some special board-specific 
black magic hack we had to perform around here, works fine on P1022.

:-) Kolja

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

[Joakim Tjernlund]

"Schneider, Kolja" <Kolja.Schneider@men.de> wrote on 2012/05/03 10:46:55:
>
> > > 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.
> >
>
> Easily done, just throw out everything in the [init] section. Or is this really just
> about BDI presence, as Scott suggested?

I found the problem, u-boot is somewhat flawed, it requires CONFIG_SYS_MONITOR_BASE
to be "base 2 even", must land on a 256K or 512K or 1024K address. I had
it to be 400K as I don't want burn >112 KB padding each time we burn an image, debugging
takes time as it is. Will be extra fun when u-boot size is bigger than 512K :(

Being able to separate the bootpg and the rest is one step to avoid burning
useless padding.

It is this this code:
#if !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SECURE_BOOT)
	/* create a temp mapping in AS=1 to the 4M boot window */
	lis     r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@h
	ori     r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@l

	lis     r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, (MAS2_I|MAS2_G))@h
	ori     r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, (MAS2_I|MAS2_G))@l

	/* The 85xx has the default boot window 0xff800000 - 0xffffffff */
	lis     r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@h
	ori     r9,r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l

Notice the hardcoded 0xffc00000, that is the culprit here.

On a related matter, I believe that one should be able to have a minimal emulator
config that allows you to both program flash efficiently and debug u-boot
via BDI/gdb.
I have always managed to do this before with our earlier freescale CPUs but now
seems hard(impossible?) with the current u-boot design. It is a major
pain to change emul config each time you do the burn flash/debug cycle.

 Jocke

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

[Joakim Tjernlund]

>
> "Schneider, Kolja" <Kolja.Schneider@men.de> wrote on 2012/05/03 10:46:55:
> >
> > > > 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.
> > >
> >
> > Easily done, just throw out everything in the [init] section. Or is this really just
> > about BDI presence, as Scott suggested?
>
> I found the problem, u-boot is somewhat flawed, it requires CONFIG_SYS_MONITOR_BASE
> to be "base 2 even", must land on a 256K or 512K or 1024K address. I had
> it to be 400K as I don't want burn >112 KB padding each time we burn an image, debugging
> takes time as it is. Will be extra fun when u-boot size is bigger than 512K :(

ehh, that should be on a 4MB boundary instead, meaning that
CONFIG_SYS_MONITOR_BASE 0xeff80000 works but 0xeff8c000 don't

>
> Being able to separate the bootpg and the rest is one step to avoid burning
> useless padding.
>
> It is this this code:
> #if !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SECURE_BOOT)
>    /* create a temp mapping in AS=1 to the 4M boot window */
>    lis     r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@h
>    ori     r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@l
>
>    lis     r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, (MAS2_I|MAS2_G))@h
>    ori     r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE, (MAS2_I|MAS2_G))@l
>
>    /* The 85xx has the default boot window 0xff800000 - 0xffffffff */
>    lis     r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@h
>    ori     r9,r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l
>
> Notice the hardcoded 0xffc00000, that is the culprit here.
>
> On a related matter, I believe that one should be able to have a minimal emulator
> config that allows you to both program flash efficiently and debug u-boot
> via BDI/gdb.
> I have always managed to do this before with our earlier freescale CPUs but now
> seems hard(impossible?) with the current u-boot design. It is a major
> pain to change emul config each time you do the burn flash/debug cycle.
>
>  Jocke
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Joakim,

In message <OF35057017.5788F889-ONC12579F3.00427B35-C12579F3.0044277A@transmode.se> you wrote:
>
> I found the problem, u-boot is somewhat flawed, it requires CONFIG_SYS_MONITOR_BASE
> to be "base 2 even", must land on a 256K or 512K or 1024K address. I had

This is not a generic U-Boot problem, just one oif the 85xx
implementation.

> On a related matter, I believe that one should be able to have a minimal emulator
> config that allows you to both program flash efficiently and debug u-boot
> via BDI/gdb.
> I have always managed to do this before with our earlier freescale CPUs but now
> seems hard(impossible?) with the current u-boot design. It is a major
> pain to change emul config each time you do the burn flash/debug cycle.

I agree with you - but again, this is "only" a 85xx issue, not a
generic U-Boot design problem.


I know, this doesn't help you much...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"If anything can go wrong, it will."                   - Edsel Murphy

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

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 2012/05/03 15:11:33:
>
> Dear Joakim,
>
> In message <OF35057017.5788F889-ONC12579F3.00427B35-C12579F3.0044277A@transmode.se> you wrote:
> >
> > I found the problem, u-boot is somewhat flawed, it requires CONFIG_SYS_MONITOR_BASE
> > to be "base 2 even", must land on a 256K or 512K or 1024K address. I had
>
> This is not a generic U-Boot problem, just one oif the 85xx
> implementation.
>
> > On a related matter, I believe that one should be able to have a minimal emulator
> > config that allows you to both program flash efficiently and debug u-boot
> > via BDI/gdb.
> > I have always managed to do this before with our earlier freescale CPUs but now
> > seems hard(impossible?) with the current u-boot design. It is a major
> > pain to change emul config each time you do the burn flash/debug cycle.
>
> I agree with you - but again, this is "only" a 85xx issue, not a
> generic U-Boot design problem.

Yes, should have been more specific.

 Jocke