Hi Brad and Sricharan, 2013/10/17 Sricharan R <r.sricha...@ti.com>: > Hi Brad, > > On Thursday 17 October 2013 08:05 AM, Griffis, Brad wrote: >> First, Sricharan, thanks for putting together these patches and getting them >> posted so quickly. I approve of the code but wanted to comment on the >> commit message. Our previous (internal) thread had a hodge podge of issues, >> so I think there was some confusion there. In particular this comment was >> not 100% accurate: >> >>> 1) The first change from 0x64656465 to 0x64646464 removes the weak pull >>> on the DQ lines. Otherwise the DQ line was not staying at Vref when >>> IDLE (retreats >>> to ground) and because of this there were extra transitions and noise. >> It removes the weak pullup, yes. However, the DQ line not staying at VREF >> during IDLE was a different thing altogether and is not affected by this >> change. That's actually something that is hard-coded as part of the >> integration of the PHY into the SoC and is not configurable... >> >> This particular pullup affects both DQS and nDQS. We don't want to pull >> differential signals in the same direction. So, bottom line, disabling that >> weak pullup will improve the signal integrity. (I think I would leave the >> commit message at that.) >> >>> 2) The second change was to enable internal VREF_DQ_OUT which otherwise >>> was at 0V. >> The above description is entirely accurate and I would agree is suitable for >> the commit message. Here's a bit more detail for the archives... >> >> On the uEVM there are 4 DDR3 devices. The VREF for 2 of the devices is >> powered by the OMAP's VREF_CA_OUT pins. The VREF on the other 2 devices is >> powered by the OMAP's VREF_DQ_OUT pins. So the net effect here is that only >> half of the DDR3 devices were being supplied a VREF! This was clearly a >> mistake. This patch improves the robustness of the interface and was >> specifically seen to cure corruption observed at high temperatures on some >> boards. > Thanks for the accurate explanation, i will reword it with your suggestions > above. > > Regards, > Sricharan >
Unfortunately, either, without your patch and with your patch applied on top of u-boot master, I'm still having issues with the memory on my uEVM. The board seems is working ok, It boots and I can use it normally without unexpected results, but doing a memtester I'm getting errors like this: # memtester 1500M 1 memtester version 4.2.2 (32-bit) Copyright (C) 2010 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffff000 want 1500MB (1572864000 bytes) got 1500MB (1572864000 bytes), trying mlock ...locked. Loop 1/1: Stuck Address : ok Random Value : FAILURE: 0x6ff35305 != 0x7ff35305 at offset 0x1dc1f2f0. FAILURE: 0x5b5f1d04 != 0x4b5f1d04 at offset 0x1df90aec. FAILURE: 0x7afb1b21 != 0x6afb1b21 at offset 0x1ee50aec. FAILURE: 0x6fbf70f6 != 0x7fbf70f6 at offset 0x1f15f2f0. FAILURE: 0xbffa76f0 != 0xaffa76f0 at offset 0x1f710aec. FAILURE: 0x8ff2323b != 0x9ff2323b at offset 0x2321f2f0. FAILURE: 0xf5ff18e7 != 0xe5ff18e7 at offset 0x259b0aec. FAILURE: 0x6bf988f2 != 0x7bf988f2 at offset 0x26bdf2f0. FAILURE: 0x9c069130 != 0x8c069130 at offset 0x1dc1f2f0. FAILURE: 0xa8aadf31 != 0xb8aadf31 at offset 0x1df90aec. FAILURE: 0x890ed914 != 0x990ed914 at offset 0x1ee50aec. FAILURE: 0x9c4ab2c3 != 0x8c4ab2c3 at offset 0x1f15f2f0. FAILURE: 0x4c0fb4c5 != 0x5c0fb4c5 at offset 0x1f710aec. FAILURE: 0x7c07f00e != 0x6c07f00e at offset 0x2321f2f0. FAILURE: 0x060adad2 != 0x160adad2 at offset 0x259b0aec. FAILURE: 0x980c4ac7 != 0x880c4ac7 at offset 0x26bdf2f0. Compare XOR : FAILURE: 0xcc2794e6 != 0xbc2794e6 at offset 0x1dc1f2f0. FAILURE: 0xd8cbe2e7 != 0xe8cbe2e7 at offset 0x1df90aec. FAILURE: 0xb92fdcca != 0xc92fdcca at offset 0x1ee50aec. FAILURE: 0xcc6bb679 != 0xbc6bb679 at offset 0x1f15f2f0. FAILURE: 0x7c30b87b != 0x8c30b87b at offset 0x1f710aec. FAILURE: 0xac28f3c4 != 0x9c28f3c4 at offset 0x2321f2f0. FAILURE: 0x362bde88 != 0x462bde88 at offset 0x259b0aec. FAILURE: 0xc82d4e7d != 0xb82d4e7d at offset 0x26bdf2f0. Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : testing 60 FAILURE: 0xefffffff != 0xffffffff at offset 0x184bf2f0. Block Sequential : testing 59 FAILURE: 0x3b3b3b3b != 0x2b3b3b3b at offset 0x1b6ffaec. Checkerboard : testing 0 FAILURE: 0x45555555 != 0x55555555 at offset 0x0507f2f0. Bit Spread : testing 0 FAILURE: 0xfffffffa != 0xeffffffa at offset 0x21b10aec. FAILURE: 0xfffffffa != 0xeffffffa at offset 0x2cbd0aec. Bit Flip : testing 2 FAILURE: 0xeffffffe != 0xfffffffe at offset 0x24d7f2f0. FAILURE: 0xeffffffe != 0xfffffffe at offset 0x2c05f2f0. Walking Ones : testing 0 FAILURE: 0xeffffffe != 0xfffffffe at offset 0x078df2f0. FAILURE: 0xeffffffe != 0xfffffffe at offset 0x0815f2f0. FAILURE: 0xfffffffe != 0xeffffffe at offset 0x089dfaec. FAILURE: 0xeffffffe != 0xfffffffe at offset 0x0dedf2f0. FAILURE: 0xeffffffe != 0xfffffffe at offset 0x0ef3f2f0. FAILURE: 0xeffffffe != 0xfffffffe at offset 0x1723f2f0. Walking Zeroes : ok 8-bit Writes : FAILURE: 0xec7f21ba != 0xfc7f21ba at offset 0x1825f2f0. FAILURE: 0xfedeee2c != 0xeedeee2c at offset 0x1aebfaec. 16-bit Writes : ok Looks like something is still wrong in DDR3 configuration. Any advice what could be the problem ? Cheers, Enric _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot