Thanks for all the valuable input. So this is what I have checked so far. Until now the behaviour is still exactly as described in the first post.
On Tue, 20 Apr 2010 15:30:56 +0200, Joakim Tjernlund <joakim.tjernl...@transmode.se> wrote: > Dunno, try running with any i/d cache for the DRAM. If that works > it is very likely you have misconfigured the DRAM I checked that I have valid BAT entries and tried to remove anything unused compared to the MPC8313ERDB(like PCIe , NOR Flash etc.). These are my current BAT settings, which work when I start with enabled BP as described. #define CONFIG_HIGH_BATS 1 /* High BATs supported */ /* 128 MB of DDR @ 0x00000000 */ #define CONFIG_SYS_IBAT0L (CONFIG_SYS_SDRAM_BASE | BATL_PP_10 | BATL_CACHEINHIBIT | BATL_GUARDEDSTORAGE) #define CONFIG_SYS_IBAT0U (CONFIG_SYS_SDRAM_BASE | BATU_BL_128M | BATU_VS | BATU_VP) /* IMMRBAR @ 0xE0000000 */ #define CONFIG_SYS_IBAT1L (CONFIG_SYS_IMMR | BATL_PP_10 | BATL_CACHEINHIBIT | BATL_GUARDEDSTORAGE) #define CONFIG_SYS_IBAT1U (CONFIG_SYS_IMMR | BATU_BL_256M | BATU_VS | BATU_VP) #define CONFIG_SYS_IBAT2L (0xF0000000 | BATL_PP_10 | BATL_GUARDEDSTORAGE) #define CONFIG_SYS_IBAT2U (0xF0000000 | BATU_BL_256M | BATU_VS | BATU_VP) > It sure looks like an mpc8313 problem I once looked into > for quite some time. The solution was: > http://lists.denx.de/pipermail/u-boot/2009-March/049175.html 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? 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 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) ? Best Regards -- Peter Vollmer Innominate Security Technologies AG Berlin / Germany _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
