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