[U-Boot] Default LAWBAR mapping at reset for mpc85xx?
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
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
- 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).
- 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
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
- 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).
- 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.
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.
- 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
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?
- 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
"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
"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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
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
participants (4)
-
Joakim Tjernlund -
Schneider, Kolja -
Scott Wood -
Wolfgang Denk