"Peter Vollmer" <pvollmer-u-b...@innominate.com> wrote on 2010/04/20 14:12:41: > > On Tue, 20 Apr 2010 11:57:09 +0200, Joakim Tjernlund > <joakim.tjernl...@transmode.se> wrote: > > Probably a BDI2000 issue. If memory serves right BDI2000 flushes the > > cache when it hits a BP. > > > > Try this addin this to your BDI .cfg file: > > TSZ4 0xe6000000 0xe60001100 ; init stack space for cache > > ; needs a 'sap 0' in BDI > > > > Then reboot BDI 2000, telnet to it and enter "sap 0" at the cmd prompt. > > Start debugging. > > Ok, but my problem is that it works with the BP enabled, so I can step
Oh, didn't read that carfully. > through the whole relocate_code function, or simply continue, without a > problem. It however does not work without the BP, or with the BP set too > late, or if the board runs standalone without the emulator. So I guess I > need to fix something in u-boot, not in the emulator configuration ... Then I suspect that your DRAM isn't configured properly, perhaps burst access is unreliable. > > But the bit about the BDI flushing the cache when a breakpoint gets hit, > could that indicate that I have to flush the cache prior to entering the > relocate_code loop? In case of a cache problem, wouldn't I just have to > expect bogus data copied into RAM? > Instead, the core is frozen, with the PC at 0xfff00ab0 , and it refuses to > step any further afterwards. Would it maybe help to try to include the > exception traps in the spl bootloader ? Dunno, try running with any i/d cache for the DRAM. If that works it is very likely you have misconfigured the DRAM _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
