From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 06 Jul 2006 11:08:15 -0400 Subject: [U-Boot-Users] MPC8540 mtest "hang" with 1GByte memory module In-Reply-To: References: Message-ID: <44AD275F.5070805@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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