[U-Boot] U-Boot configuration and latter Linux MMU init failures

[U-Boot] U-Boot configuration and latter Linux MMU init failures

[Remi Lefevre]

Hi,

[U-Boot] U-Boot configuration and latter Linux MMU init failures

[Jerry Van Baren]

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

[U-Boot] U-Boot configuration and latter Linux MMU init failures

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Save yourself!  Reboot in 5 seconds!

[U-Boot] U-Boot configuration and latter Linux MMU init failures

[Remi Lefevre]

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

[U-Boot] U-Boot configuration and latter Linux MMU init failures

[Scott Wood]

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