On Tue, Apr 20, 2010 at 07:02:53PM +0200, Peter Vollmer wrote: > I worked through that thread, but as it seems I have no unguarded memory > range left. Each BAT entry has BATL_GUARDEDSTORAGE set. > By using the BATL_CACHEINHIBIT for the RAM bock I suppose I have the > dcache disabled, right?
Hmm, how is lock_ram_in_cache going to work then? > On Tue, 20 Apr 2010 14:44:10 +0200, Norbert van Bolhuis > <nvbolh...@aimvalley.nl> wrote: > > It could also be your DDR RAM not properly functioning. You > > can let u-boot test it with the POST MEM test (which happens > > before relocation). > > I checked RAM using mtest in the CLI (I'll also let the memory test run > through the night). The board has 128MB, so I did "mtest 0x3000 > 0x03e97000" , and no problems so far. If I start u-boot through the right > breakpoint, I can see no issues with DDR or NAND whatsoever. > > Is it possible to enable the exception handlers (maybe at least > MachineCheckException) in the SPL loader You could try to get some custom code in there maybe, but there's no room for the standard exception code. > or how can I get the sytem into a > defined state when the problem happens ? Currently I'm even unsure where > the core is jumping to, so maybe that would be a good start. If the > exception happens while still running in the high BMS, would the > MachineCheckException hit address 0xfff00200 , or would it already try to > jump to 0x00000200 (with a potentially uninitialised DDR RAM) ? Depends on what the value of MSR[IP] is at that point. It looks like MSR[IP] will not be cleared in the NAND SPL. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
