[U-Boot] U-Boot configuration and latter Linux MMU init failures
Hi,
From your experience, can some incomplete/incorrect U-Boot configuration
lead to MMU init failures inside Linux ?
Particularly, my Linux kernel fails during the first Data Cache Block Store instruction (dcbst) of the MMU init and I ask myself if this cannot be linked to my cache initialization inside U-Boot (HID0 for my MPC8270 board).
See http://ozlabs.org/pipermail/linuxppc-embedded/2008-September/031398.html for more details.
Regards, Rémi
Remi Lefevre wrote:
Hi,
From your experience, can some incomplete/incorrect U-Boot configuration lead to MMU init failures inside Linux ?
Particularly, my Linux kernel fails during the first Data Cache Block Store instruction (dcbst) of the MMU init and I ask myself if this cannot be linked to my cache initialization inside U-Boot (HID0 for my MPC8270 board).
See http://ozlabs.org/pipermail/linuxppc-embedded/2008-September/031398.html for more details.
Regards, Rémi
Hi Rémi,
I don't have much advice, sorry.
The linux MMU setup code is the #1 most delicate operation in starting linux. It is extremely easy to get something wrong and extremely hard to debug (as you found out).
Questions that may help: 1) Are you enabling dcache? icache? in u-boot? 2) Does linux boot if you don't enable dcache/icache? 3) (really 1a) How are you setting up and/or using cache that is different from other 82xx boards? 4) (really 1b?) How are you using DBATs (and IBATs)? Is it compatible with linux's start up code? Is linux changing your DBATs, for instance, causing memory (un)mapping side effects? IIRC (been a while, may have changed), linux uses 3 of the 4 DBATs during start up.
Interestingly enough, dcbst is a *data* cache store, run in the *icache* flush routine. I assume this is intended to flush out any instructions that are stuck in the dcache due to writes (self modifying code and/or loaded/copied code). I would *speculate* that the address of the stuff in your dcache no longer points to valid memory.
HTH, gvb
Dear Jerry Van Baren,
In message 48DA3124.8000409@ge.com you wrote:
Interestingly enough, dcbst is a *data* cache store, run in the *icache* flush routine. I assume this is intended to flush out any instructions that are stuck in the dcache due to writes (self modifying code and/or loaded/copied code). I would *speculate* that the address of the stuff in your dcache no longer points to valid memory.
Also let's keep in mind that cache flushing means accessing the RAM in burst mode, so have a look at FAQ # 1.
Best regards,
Wolfgang Denk
Hi,
In message 48DA3124.8000409@ge.com you wrote:
Interestingly enough, dcbst is a *data* cache store, run in the *icache* flush routine. I assume this is intended to flush out any instructions that are stuck in the dcache due to writes (self modifying code and/or loaded/copied code). I would *speculate* that the address of the stuff in your dcache no longer points to valid memory.
Also let's keep in mind that cache flushing means accessing the RAM in burst mode, so have a look at FAQ # 1.
1. You were right Wolfgang, I still had issue with my SDRAM. It seems that I misunderstand the DR field of BR SDRAM register as setting it produces "random" failures in MMU init. I'm however using ECC, therefore I will have to understand exactly why it is not needed... SDRAM init is really unforgiving !
2. I forgot to add appropriate #define CONFIG_OF_BOARD_SETUP and custom RAM size code settings for my custom board, therefore the RAM size in Linux fdt was set to 0... Not good at all and hangs very early without much details.
With this, my kernel completes its init (and hangs in NFS mount, but this is another story...).
At last, I have some doubt about the fdt "timebase-frequency" value. It seems to be set to (bus_clk / 4) on mpc8260, but I cannot find in the mpc8270 (mpc8280) user manual any confirmation. Does this value only depends on cpu or could the board have any influence on it ? I know this is related to the decrementer register but I miss some basic understanding here.
Anyway, thanks for your advices.
Regards, Rémi
Remi Lefevre wrote:
At last, I have some doubt about the fdt "timebase-frequency" value. It seems to be set to (bus_clk / 4) on mpc8260, but I cannot find in the mpc8270 (mpc8280) user manual any confirmation. Does this value only depends on cpu or could the board have any influence on it ? I know this is related to the decrementer register but I miss some basic understanding here.
It is not board-specific. See section 1.1.8.2 of the G2 core reference manual.
-Scott
participants (4)
-
Jerry Van Baren -
Remi Lefevre -
Scott Wood -
Wolfgang Denk