Re: [U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings
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:
- 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.)
- 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
Hi Brad and Sricharan,
2013/10/17 Sricharan R r.sricharan@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:
- 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.)
- 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
participants (2)
-
Enric Balletbo Serra -
Sricharan R