[U-Boot-Users] Custom MPC8347 Board can't access cache
Hello All,
I am trying to bring up a custom MPC8347 board with source based off of 1.3-rc1, unfortunately, I am not making it to board_init_f.
Using an abatron bdi, I've discovered the offending instruction is on cpu/mpc83xx/start.S:752 -
752 mtmsr r5 /* r5 is 0x3072 */
Has anyone else seen this issue?
For reference, here are some configuration settings that may be of value:
#define CFG_INIT_RAM_ADDR 0x20000000 /* Initial RAM address */ #define CFG_INIT_RAM_END 0x1000 /* End of used area in RAM*/ #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)
Does anyone have any insight? Thanks for the help, Sam Sparks
Sparks, Sam wrote:
Hello All,
I am trying to bring up a custom MPC8347 board with source based off of 1.3-rc1, unfortunately, I am not making it to board_init_f.
Using an abatron bdi, I've discovered the offending instruction is on cpu/mpc83xx/start.S:752 -
752 mtmsr r5 /* r5 is 0x3072 */
Has anyone else seen this issue?
For reference, here are some configuration settings that may be of value:
#define CFG_INIT_RAM_ADDR 0x20000000 /* Initial RAM address */ #define CFG_INIT_RAM_END 0x1000 /* End of used area in RAM*/ #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)
Does anyone have any insight? Thanks for the help, Sam Sparks
If you decode the value of r5 (assuming your comment is correct - DON'T ASSUME THAT, verify it!!!), the mtmsr is enabling caching. My deduction is that caching is messing you up.
If you disable caching, does your board boot (albeit slowly)?
If so, you have two possibilities: 1) Misconfigured hardware 1a) Memory map, BATs, etc. - look for things that should not be cached like I/O but are cached inadvertently. 1b) Your SDRAM is initialized improperly.
READ THIS PAGE!!! http://www.denx.de/wiki/DULG/UBootCrashAfterRelocation
2) You have a hardware (board layout) problem.
The good news is, odds are pretty good that your problem is 1b). If it isn't 1b, the odds are pretty good that it is 1a).
Good luck, gvb
From: Jerry Van Baren [mailto:gerald.vanbaren@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
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@lists.sourceforge.net Subject: RE: [U-Boot-Users] Custom MPC8347 Board can't access cache
From: Jerry Van Baren [mailto:gerald.vanbaren@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
In message BAF8B1E0BB28024A90895E746A3B610D1B5311@twx-exch01.twacs.local you wrote:
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:
Hmm... do you know the hardware details of your board, *and* those of the TQM834x module and the STK85xx evaluation board? Without such knowledge it will be difficult for you to judje if the TQM834x is really a good choice to compare against, and you will not know what to take and what to change...
Best regards,
Wolfgang Denk
Wolfgang Denk wrote: Hmm... do you know the hardware details of your board, *and* those of the TQM834x module and the STK85xx evaluation board? Without such knowledge it will be difficult for you to judje if the TQM834x is really a good choice to compare against, and you will not know what
I'm using the TQM834X (and the MPC8349ITX/EMDS) boards as a baseline configuration for my board. Specifically with regards to the processor's internal cache, I think these are a good choice, as all four boards have processors in the same family.
Feel free to correct me if I'm wrong. I may be missing something.
Thanks, Sam
participants (3)
-
Jerry Van Baren -
Sparks, Sam -
Wolfgang Denk