Hi Gerald,
Citando "VanBaren, Gerald (AGRE)" Gerald.VanBaren@smiths-aerospace.com:
This looks like you are getting bitten by the horrible HRCW IMMR configuration choice that Mot/Freescale/EST/WindRiver (I don't know who was first :-) made.
If you boot using the BCSR to source the HRCW (see the 826x User's Manual on the HRCW, probably Chapter 5), Mot sets the initial IMMR memory area to be at 0x0f000000. This is incompatible with linux, so the u-boot initialization (the code you've highlighted) writes to the IMMR register to change it to 0xf0000000.
Your BDI config file probably does this as well.
The problem is, the BDI and the actual code get confused about where the IMMR memory region is and one (or both :-O) of them accesses the wrong memory region, causing a bus fault which results in the reset you see.
My guess is your BDI config file remaps the IMMR and, when you step through the code, the code's writing of the IMMR screws up. I don't know how clever the BDI is in terms of examining the instructions it is executing; it is possible that it catches the IMMR write and tries to Do The Right Thing[tm] when it sees the IMMR write attempt but it screws up.
I think you have guessed ok. I have checked my config file, and it sets the IMMR to 0x04700000, which is the value it has in the user manual for the board (i got the config file from Abatron)
Your best bet is to use a flash-based HRCW and set the IMMR in the right(!!!) location out of reset. (I also would recommend switching to "boot low", in which case you can have one u-boot copy booting high via the BCSR and one copy booting low via the flash HRCW. By doing this, you can test using the flash HRCW and, when you screw up, you can recover by booting high and loading a fixed u-boot in the low spot). I have this change configured in my local (at home) copy and intend to submit it to Wolfgang Real Soon Now[tm].
OK, but as a fast test before doing that, if I remove the IMMR lines from my config file, then there wouldn't be any inconsistency, so I would be able to debug this lines of uboot. Am I wrong?.
And, why does it works when I do the RESET RUN? Should I guess than in this case the BDI2000 restarts the board without doing any special initialization?
While we are on the subject of patching this, my only reason for not submitting the patch yet is because I want to configure the link control file so that it automatically knows to link at 0xfff00000 for the "boot high" option and 0xfe800000 for the "boot low" option. I have that hard-coded presently and have not had time to figure out how to do it using a configuration selection. Hints would be welcome :-).
gvb
However, all this stuff doesn't explain or solves the other problem ... why the -DDEBUG flag doesn't works?
Thanks for your reply,
Alex