| Message ID | 1381918210-6176-1-git-send-email-r.sricharan@ti.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
Hi Sricharan, 2013/10/16 Sricharan R <r.sricharan@ti.com>: > Changing the IO settings to turn on VREF_DQ and > disable weak pullup for DQS/nDQS. > > Signed-off-by: Sricharan R <r.sricharan@ti.com> > --- > arch/arm/include/asm/arch-omap5/omap.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h > index 414d37a..3c2306f 100644 > --- a/arch/arm/include/asm/arch-omap5/omap.h > +++ b/arch/arm/include/asm/arch-omap5/omap.h > @@ -145,9 +145,9 @@ struct s32ktimer { > #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0 > > #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C > -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465 > +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464 > #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631 > -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8 > +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC > #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x84210000 > > #define EFUSE_1 0x45145100 > -- > 1.7.9.5 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Sorry for my ignorance, I just want to know more ... What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ? Improves ? Thanks in advance, Enric
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/16/2013 07:34 AM, Enric Balletbo Serra wrote: > Hi Sricharan, > > 2013/10/16 Sricharan R <r.sricharan@ti.com>: >> Changing the IO settings to turn on VREF_DQ and >> disable weak pullup for DQS/nDQS. >> >> Signed-off-by: Sricharan R <r.sricharan@ti.com> >> --- >> arch/arm/include/asm/arch-omap5/omap.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h >> index 414d37a..3c2306f 100644 >> --- a/arch/arm/include/asm/arch-omap5/omap.h >> +++ b/arch/arm/include/asm/arch-omap5/omap.h >> @@ -145,9 +145,9 @@ struct s32ktimer { >> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0 >> >> #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C >> -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465 >> +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464 >> #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631 >> -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8 >> +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC >> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x84210000 >> >> #define EFUSE_1 0x45145100 > > Sorry for my ignorance, I just want to know more ... > > What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ? Improves ? I suspect I know what this is about, but can we please have a more verbose commit message here? - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSXoefAAoJENk4IS6UOR1WbcUP/0BlIP5NY4KU47JRfUn3CbxP zS2m38hrHsmwiO7RO1OocI5wZm4jTFKfoTkxenuYdfyoJycSKaD0qWOCgYHobMHy uxZ4qTkMrBVquRgiUuMjlII8tHMAX+ce8sVehnGXmG3EMYK4H5OAzvrKWsW7Cyx8 PbNQzZxNghenMJ2UHme2GhWp5OJtHerVoj7j7DMNUVFgeOs/x9MxRQyvIc/dOJ9r 0M1UOLK15R3GjHw6ClrYvsa8wPoobbdhALU7Nem7EuQZlmYtBl8RIQa3EghjVfB+ yX9IxbFMoWgEDCSYkzK/oAm5rjcqGJxfTsOYancEBd8l3L2eSTsYUuK2BVPBCkYP GoHz1Mm7f+TwzVZfyAS4cGkFg7LRymj9M5vIhKg9mZp5a0MxKw/2DsiVEKlCJU/t TZHaBzQ8jmwmZ296qvPh8n3XnEzO7zn3hutowghux3LLfkuyaBC346haMS5GA77D D3TjWsYIr8XEaJ87DI7H3Ll1leSxRcDu3V3naR7/s/+gVIcXe8Iv4QApnp0bP5+2 8HT5bQtIJTEu58ZP7taWzhkrpD/FWTBUNt18X6koaRSMjG7Za37VnG6IRlKW1MbG CdsfWbTv1n46Ee4Qr/g1d5t0g92fay5dlpuJHdMafQR7p6WqA88QkxhWBSUv7mnn ZTONa00kbM3+npFlIZfZ =cIsK -----END PGP SIGNATURE-----
Hi, On Wednesday 16 October 2013 06:03 PM, Tom Rini wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/16/2013 07:34 AM, Enric Balletbo Serra wrote: >> Hi Sricharan, >> >> 2013/10/16 Sricharan R <r.sricharan@ti.com>: >>> Changing the IO settings to turn on VREF_DQ and >>> disable weak pullup for DQS/nDQS. >>> >>> Signed-off-by: Sricharan R <r.sricharan@ti.com> >>> --- >>> arch/arm/include/asm/arch-omap5/omap.h | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h >>> index 414d37a..3c2306f 100644 >>> --- a/arch/arm/include/asm/arch-omap5/omap.h >>> +++ b/arch/arm/include/asm/arch-omap5/omap.h >>> @@ -145,9 +145,9 @@ struct s32ktimer { >>> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0 >>> >>> #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C >>> -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465 >>> +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464 >>> #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631 >>> -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8 >>> +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC >>> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x84210000 >>> >>> #define EFUSE_1 0x45145100 >> Sorry for my ignorance, I just want to know more ... >> >> What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ? Improves ? > I suspect I know what this is about, but can we please have a more > verbose commit message here? Above the two changes improved DDR3 stability at extended temperature ranges above 83C. 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. 2) The second change was to enable internal VREF_DQ_OUT which otherwise was at 0V. Hope this helps. BTW, i will repost with a better commit log. Sorry. Regards, Sricharan
Hi Sricharan, 2013/10/16 Sricharan R <r.sricharan@ti.com>: > Hi, > > On Wednesday 16 October 2013 06:03 PM, Tom Rini wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10/16/2013 07:34 AM, Enric Balletbo Serra wrote: >>> Hi Sricharan, >>> >>> 2013/10/16 Sricharan R <r.sricharan@ti.com>: >>>> Changing the IO settings to turn on VREF_DQ and >>>> disable weak pullup for DQS/nDQS. >>>> >>>> Signed-off-by: Sricharan R <r.sricharan@ti.com> >>>> --- >>>> arch/arm/include/asm/arch-omap5/omap.h | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h >>>> index 414d37a..3c2306f 100644 >>>> --- a/arch/arm/include/asm/arch-omap5/omap.h >>>> +++ b/arch/arm/include/asm/arch-omap5/omap.h >>>> @@ -145,9 +145,9 @@ struct s32ktimer { >>>> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0 >>>> >>>> #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C >>>> -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465 >>>> +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464 >>>> #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631 >>>> -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8 >>>> +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC >>>> #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x84210000 >>>> >>>> #define EFUSE_1 0x45145100 >>> Sorry for my ignorance, I just want to know more ... >>> >>> What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ? Improves ? >> I suspect I know what this is about, but can we please have a more >> verbose commit message here? > > Above the two changes improved DDR3 stability at extended temperature > ranges above 83C. > > 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. > > 2) The second change was to enable internal VREF_DQ_OUT which otherwise was at 0V. > > Hope this helps. BTW, i will repost with a better commit log. Sorry. > > Regards, > Sricharan > Many thanks for the explanation. Best regards, Enric
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
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: >> >>> 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
diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h index 414d37a..3c2306f 100644 --- a/arch/arm/include/asm/arch-omap5/omap.h +++ b/arch/arm/include/asm/arch-omap5/omap.h @@ -145,9 +145,9 @@ struct s32ktimer { #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0 #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465 +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464 #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631 -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8 +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x84210000 #define EFUSE_1 0x45145100
Changing the IO settings to turn on VREF_DQ and disable weak pullup for DQS/nDQS. Signed-off-by: Sricharan R <r.sricharan@ti.com> --- arch/arm/include/asm/arch-omap5/omap.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)