[U-Boot] mpc8313 SPL, relocate_code, large page NAND
Peter Vollmer
pvollmer-u-boot at innominate.com
Tue Apr 20 19:02:53 CEST 2010
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.tjernlund at 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
<nvbolhuis at 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
More information about the U-Boot
mailing list