[U-Boot-Users] Custom MPC8347 Board can't access cache

[Sparks, Sam]

Ok, new problem.

I've trying to configure internal cache at 0x20000000 (based off of
TQM834x), and U-Boot is failing to access the memory space as indicated
by my debug session:

(gdb) b board.c:479
Breakpoint 9 at 0xfff06b54: file board.c, line 479.
(gdb) c
Continuing.

Breakpoint 8, board_init_f (bootflag=Cannot access memory at address
0x20000ed0
) at board.c:479
479             addr_sp -= sizeof (gd_t);
(gdb)

I've verified I cannot access the memory space via the BDI either. Does
anyone see a problem with my configuration?
#define CFG_SDRAM_BASE     0x00000000
#define CFG_INIT_RAM_ADDR  0x20000000
#define CFG_IMMR     0xE0000000
#define CFG_FLASH_BASE     0xF8000000

/* DDR 0 - 512M */
#define CFG_IBAT0L   (CFG_SDRAM_BASE | BATL_PP_10 | BATL_MEMCOHERENCE)
#define CFG_IBAT0U   (CFG_SDRAM_BASE | BATU_BL_256M | BATU_VS | BATU_VP)
#define CFG_IBAT1L   (CFG_SDRAM_BASE + 0x10000000 | BATL_PP_10 |
BATL_MEMCOHERENCE)
#define CFG_IBAT1U   (CFG_SDRAM_BASE + 0x10000000 | BATU_BL_256M |
BATU_VS | BATU_VP)

/* stack in DCACHE @ 512M (no backing mem) */
#define CFG_IBAT2L   (CFG_INIT_RAM_ADDR | BATL_PP_10 |
BATL_MEMCOHERENCE)
#define CFG_IBAT2U   (CFG_INIT_RAM_ADDR | BATU_BL_128K | BATU_VS |
BATU_VP)

/* IMMRBAR */
#define CFG_IBAT3L   (CFG_IMMR | BATL_PP_10 | BATL_CACHEINHIBIT |
BATL_GUARDEDSTORAGE)
#define CFG_IBAT3U   (CFG_IMMR | BATU_BL_2M | BATU_VS | BATU_VP)

/* FLASH */
#define CFG_IBAT4L   (CFG_FLASH_BASE | BATL_PP_10 | BATL_CACHEINHIBIT |
BATL_GUARDEDSTORAGE)
#define CFG_IBAT4U   (CFG_FLASH_BASE | BATU_BL_128M | BATU_VS | BATU_VP)

Thanks for the help,
Sam 

>-----Original Message-----
>From: Sparks, Sam 
>Sent: Tuesday, October 16, 2007 11:03 AM
>To: Jerry Van Baren
>Cc: u-boot-users at lists.sourceforge.net
>Subject: RE: [U-Boot-Users] Custom MPC8347 Board can't access cache
>
>>From: Jerry Van Baren [mailto:gerald.vanbaren at ge.com] 
>>Sparks, Sam wrote:
>>> Does anyone have any insight? Thanks for the help,
>>> Sam Sparks
>>
>>Good luck,
>>gvb
>>
>
>The problem turned out to be how I was configuring the DBATs 
>and IBATS. I had missed a critical mapping and was accessing 
>invalid memory.
>
>Thanks,
>Sam