Re: [U-Boot-Users] MPC8540 mtest "hang" with 1GByte memory module
It seems that a prolonged sequence of accesses is required to cause the
problem.
Heating problem? It can cause strange problems.
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.
Best Regards
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
participants (2)
-
Jerry Van Baren -
Joao, Nuno (ext)