[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