> > Yes, but that isn't the problem. > > > Could anyone familiar with that workaround listed below verify > > that > > this could be causing the CPU to freeze/crash? > > I've been there and done it. The CCSRBAR can't be changing while you > are using the BDI2000 for debug. The debug registers the BDI2000 is > trying to access are in this space. If you move the space without the > BDI2000 knowing (i.e. in your code), the BDI2000 doesn't seem to be > able to track those changes and continues to try and access the > debug registers in the last known space. > > > So, what you have to do is (simply :-) ensure the CCSRBAR isn't > changing when you are debugging the software.
That leaves me with one question. When I don't do anything in the init section of the bdi2000 except one command which is to remove the L2SRAM from the initial MMU page and then I proceed with booting the board boots fine. If I halt the board examine the CCSRBAR it has moved from the default location. I must be missing something, any ideas? Thanks -- Matthew S. McClintock <mattsm at arlut.utexas.edu> ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
