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
