[U-Boot-Users] MPC8540 mtest "hang" with 1GByte memory module

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Joao, Nuno (ext) wrote:
>> It seems
>> that a prolonged sequence of accesses is required to cause the
> problem.
> 
> 	Heating problem? It can cause strange problems.

Long shot.  Still, it could be...

>> The following is the DRAM initialization data from Uboot:
>>
>> DRAM:  Initializing
>> DDR: number of banks = 2
>> DDR: DDR I bank density = 0x20000000
>> Number of Row Address Bits - 13
>> Number of Col Address Bits - 11
>>
>> DDR: cs0_bnds   = 0x0000001f
>> DDR: cs0_config = 0x80000103
>> (...)
>> DDR: err_sbe = 0x00ff0000
>> DDR: sdram_cfg_2  = 0x00000000
> 
> 	The configuration of the DDR is rather complex, specially
> 	the timming parameters and, of course, it depends a bit on
> 	the DDR in question. This is usually done by the hardware
> 	team, they have to give the parameters. Where I work I have
> 	a hardware collegue specialized in this kind of configuration
> 	and it took him some time to fully analyse and optimize this
> 	parameters for a MPC8541E based custom board.

My guess is that the SDRAM is initialized OK.
1) Sam claims linux boots and runs as long as he doesn't do a SDRAM test.
2) Sam indicated that the SDRAM test actually runs or appears to run to 
completion, but the UART register read (Tx ready) has stale data 
(program sees "busy", debugger sees "ready").

This would indicate that the SDRAM size (and initialization) is 
incidental to the problem - it is a way to trigger/replicate the 
problem, but is not the cause of the problem.  Also, the problem is 
"fixed" by doing an unrelated register write (*and probably read* - 
setting a LED is probably a read-modify-write operation).

Stale data in registers is very often caused by:
* Caching - reading cached values instead of the register
   * If the larger memory size changes the MMU configuration, it could
       mess up and inadvertently cache the registers
* Write posting - the write never made it to the register
   * Forgetting to do a "sync" or "EIEIO" to force proper data ordering
       (allowing the processor's BIU to reorder reads and writes)
   * Not doing a read to flush an external write posting buffer (e.g.
       PCI, PQ-III).  Your (Nuno's) previous email guessing the PQIII
       coherency module sounds very likely to me.
* Forgetting to put the "volatile" keyword on the register pointer

gvb