This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM816x DDR3 SW leveling and EZSDK u-boot code updates



Hi all,

 

as you know, the wiki shows the DM816x SW leveling procedure

http://processors.wiki.ti.com/index.php/DM816x_C6A816x_AM389x_DDR3_Init

 

However with DM816x EZSDK 5.03 and 5.04 the u-boot code does not match up with the wiki anymore. Essentially I am trying to understand two things about how to modify u-boot with values from the CCS executable:

(1) The CCS program gives separate values for EMIF0 and EMIF1. How are EMIF0 and EMIF1 values entered into the u-boot code?

(2) The CCS program gives separate values for indvidual byte lanes. How are these separate byte lane values added into the u-boot code?

 

Here is what comes out of the CCS program for either EMIF0 or EMIF1

*********************************************************
Byte level Slave Ratio Search Program Values
*********************************************************
                      BYTE3   BYTE2  BYTE1   BYTE0
*********************************************************
Read DQS MAX           5d      60      78      77
Read DQS MIN            8       8       4       8
Read DQS OPT           32      34      31      38
*********************************************************
Read DQS GATE MAX     1ec     1d1     1b5     1a0
Read DQS GATE MIN      8f      7c      63      41
Read DQS GATE OPT     13d     126     10c      f0
*********************************************************
Write DQS MAX          97      a3      8c      8b
Write DQS MIN           0       0       0       0
Write DQS OPT          4b      51      46      45
*********************************************************

 

Here is SDK 5.03. It looks like each byte lane gets the same value. It is also unclear how to enter EMIF0 vs EMIF1

#if defined(CONFIG_TI816X_DDR3_SW_LEVELING)
/* These values are obtained from the CCS app */
#define RD_DQS_GATE 0x1B3
#define RD_DQS  0x35
#define WR_DQS  0x93

#endif

#endif /* CONFIG_TI816X_DDR_796 */


#if defined(CONFIG_TI816X_DDR3_SW_LEVELING)
#define WR_DQS_RATIO_BYTE_LANE3 ((WR_DQS << 10) | WR_DQS)
#define WR_DQS_RATIO_BYTE_LANE2 ((WR_DQS << 10) | WR_DQS)
#define WR_DQS_RATIO_BYTE_LANE1 ((WR_DQS << 10) | WR_DQS)
#define WR_DQS_RATIO_BYTE_LANE0 ((WR_DQS << 10) | WR_DQS)

#define WR_DATA_RATIO_BYTE_LANE3 (((WR_DQS + 0x40) << 10) | (WR_DQS + 0x40))
#define WR_DATA_RATIO_BYTE_LANE2 (((WR_DQS + 0x40) << 10) | (WR_DQS + 0x40))
#define WR_DATA_RATIO_BYTE_LANE1 (((WR_DQS + 0x40) << 10) | (WR_DQS + 0x40))
#define WR_DATA_RATIO_BYTE_LANE0 (((WR_DQS + 0x40) << 10) | (WR_DQS + 0x40))

#define RD_DQS_RATIO   ((RD_DQS << 10) | RD_DQS)

#define DQS_GATE_BYTE_LANE0  ((RD_DQS_GATE << 10) | RD_DQS_GATE)
#define DQS_GATE_BYTE_LANE1  ((RD_DQS_GATE << 10) | RD_DQS_GATE)
#define DQS_GATE_BYTE_LANE2  ((RD_DQS_GATE << 10) | RD_DQS_GATE)
#define DQS_GATE_BYTE_LANE3  ((RD_DQS_GATE << 10) | RD_DQS_GATE)

#endif /* CONFIG_TI816X_DDR3_SW_LEVELING */

 

Here is SDK5.04. I am thinking the first piece of code separates EMIF0 from EMIF1 (please confirm), but the second piece of code still enters the same values for each byte lane.

#if defined(CONFIG_TI816X_DDR3_SW_LEVELING)
/* These values are obtained from the CCS app */
#define RD_DQS_GATE ((emif == 0) ? 0x1B3 : 0x1B3)
#define RD_DQS  ((emif == 0) ? 0x35 : 0x35)
#define WR_DQS  ((emif == 0) ? 0x93 : 0x93)

#endif

#endif /* CONFIG_TI816X_DDR_796 */


#if defined(CONFIG_TI816X_DDR3_SW_LEVELING)
#define WR_DQS_RATIO_BYTE_LANE3 ((WR_DQS << 10) | WR_DQS)
#define WR_DQS_RATIO_BYTE_LANE2 ((WR_DQS << 10) | WR_DQS)
#define WR_DQS_RATIO_BYTE_LANE1 ((WR_DQS << 10) | WR_DQS)
#define WR_DQS_RATIO_BYTE_LANE0 ((WR_DQS << 10) | WR_DQS)

#define WR_DATA_RATIO_BYTE_LANE3 (((WR_DQS + 0x40) << 10) | (WR_DQS + 0x40))
#define WR_DATA_RATIO_BYTE_LANE2 (((WR_DQS + 0x40) << 10) | (WR_DQS + 0x40))
#define WR_DATA_RATIO_BYTE_LANE1 (((WR_DQS + 0x40) << 10) | (WR_DQS + 0x40))
#define WR_DATA_RATIO_BYTE_LANE0 (((WR_DQS + 0x40) << 10) | (WR_DQS + 0x40))

#define RD_DQS_RATIO   ((RD_DQS << 10) | RD_DQS)

#define DQS_GATE_BYTE_LANE0  ((RD_DQS_GATE << 10) | RD_DQS_GATE)
#define DQS_GATE_BYTE_LANE1  ((RD_DQS_GATE << 10) | RD_DQS_GATE)
#define DQS_GATE_BYTE_LANE2  ((RD_DQS_GATE << 10) | RD_DQS_GATE)
#define DQS_GATE_BYTE_LANE3  ((RD_DQS_GATE << 10) | RD_DQS_GATE)

#endif /* CONFIG_TI816X_DDR3_SW_LEVELING */

#endif /* CONFIG_TI816X_EVM_DDR3 */

 

 

Could you clarify how to enter the values from the CCS program into uboot?

Could someone also update the wiki with that information?

 

Thanks,

--Gunter

  • Hi all,

     

    do you have an update on this issue?

    Additionally, Since a lot of customers are now on EZSDK 5.04, the wiki is getting more and more outdated, because the u-boot code has moved since the older PSPs. We would need someone to update this wiki to have proven step for SDK5.04 users

     

    Specifically there are certain patches required, but I believe with the newer PSP04.04 these patches are no longer needed.

    Prerequisites 

    1. Excel spreadsheet for obtaining the seed values which is the input to the CCS based app File:RatioSeed.zip
    2. CCS based program DDR3_SlaveRatio_ByteWiseSearch_TI816x.out which generates the static values for the software leveling process File:DDR3 SlaveRatio ByteWiseSearch TI816x.zip
    3. TI816X GEL File File:TI816x ddr3.zip
    4. TI816x U-Boot source code based on PSP release 04.00.00.07
    5. U-Boot-DDR3.patch File:U-Boot-DDR3.zip for adding support for DDR3 in the U-Boot. This needs to be applied on top of the PSP release 04.00.00.07
    6. Asymmetric-DDR3-memory-inteface.patch File:Asymmetric DDR3 interface.zip for adding support for Asymmetric DDR3 memory interface with PSP Release 04.00.00.13
    7. U-Boot User Guide which is a part of the PSP release

     

    It would be great if we could go exhaustively through the steps and update them for SDK5.04.

     

    Regards,

    --Gunter

     

     

  • Gunter

    I have some question when I try to fill the CLK trace, for the 16bit DDR3, I think  the CK trace should be the same length on byte0 and byte1, why is there 0.55 inch difference on TI's exmaple?

    CLK trace 3.65 3.1 2.55 2

    thanks

    jeffery

  • Jeffrey,

    Have you checked the latest u-boot?

    http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=shortlog;h=refs/heads/ti81xx-master

  • Hi Renjith,

     

    we see the latest u-boot patch for byte wise leveling at

    http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=blobdiff;f=arch/arm/include/asm/arch-ti81xx/ddr_defs_ti816x.h;h=e36e3f28d506c7280f78d7577026419997919477;hp=b6cbe608ca7ec5893023968890c572f969448bf9;hb=eab0c13a2fd49d12100f19a5ca785e0eed1c2d6a;hpb=a5fbec30ebdbe5002e221ae9d87c9f6a60a446f5

    and the code shows a reversal of the byte lanes

    +#define WR_DQS_RATIO_BYTE_LANE0                WR_DQS_LANE3
    +#define WR_DQS_RATIO_BYTE_LANE1                WR_DQS_LANE2
    +#define WR_DQS_RATIO_BYTE_LANE2                WR_DQS_LANE1
    +#define WR_DQS_RATIO_BYTE_LANE3                WR_DQS_LANE0
    +
    +#define WR_DATA_RATIO_BYTE_LANE0       WR_DATA_LANE3
    +#define WR_DATA_RATIO_BYTE_LANE1       WR_DATA_LANE2
    +#define WR_DATA_RATIO_BYTE_LANE2       WR_DATA_LANE1
    +#define WR_DATA_RATIO_BYTE_LANE3       WR_DATA_LANE0
    +
    +#define RD_DQS_RATIO_BYTE_LANE0                RD_DQS_LANE3
    +#define RD_DQS_RATIO_BYTE_LANE1                RD_DQS_LANE2
    +#define RD_DQS_RATIO_BYTE_LANE2                RD_DQS_LANE1
    +#define RD_DQS_RATIO_BYTE_LANE3                RD_DQS_LANE0
    +
    +#define RD_DQS_GATE_BYTE_LANE0         RD_DQS_GATE_LANE3
    +#define RD_DQS_GATE_BYTE_LANE1         RD_DQS_GATE_LANE2
    +#define RD_DQS_GATE_BYTE_LANE2         RD_DQS_GATE_LANE1
    +#define RD_DQS_GATE_BYTE_LANE3         RD_DQS_GATE_LANE0
     
    This is interesting and we see that it is truly the case that changing the WR_DQS_RATIO_BYTE_LANE3 for example changes the delay on the Lane 0. Knowing this we are now uncertain of how exactly the CCS app generates values for the byte lanes. The wiki shows the following example outputs and we need to confirm how to EXACTLY transfer values into the new u-boot code, so there is no ambiguity:
     
    *********************************************************
    Byte level Slave Ratio Search Program Values
    *********************************************************                      
    BYTE3   BYTE2  BYTE1   BYTE0
    *********************************************************
    Read DQS MAX           5d      60      78      77
    Read DQS MIN            8       8       4       8
    Read DQS OPT           32      34      31      38
    *********************************************************
    Read DQS GATE MAX     1ec     1d1     1b5     1a0
    Read DQS GATE MIN      8f      7c      63      41
    Read DQS GATE OPT     13d     126     10c      f0
    *********************************************************
    Write DQS MAX          97      a3      8c      8b
    Write DQS MIN           0       0       0       0
    Write DQS OPT          4b      51      46      45
    *********************************************************
     
    Can we put in writing how the values are mapped to the u-boot code? Can we also update the wiki to reflect that?
     
     
    Thanks,
    --Gunter
  • Gunter,

    I'm not really sure though whether its integrated to latest arago project or not. But there is a u-boot change available, where the DDR leveling algorithm is completely integrated to u-boot. The patch you've shared is just having the macros carrying the optimal values. But this patch will calculate it at run time using the trace lengths info and generate the values. Also it does leveling every time it reboots. 

  • Hi Renjith,

     

    that would be the best option to have all software leveling embedded into u-boot. Could you point me to this patch?

     

    Secondly, could someone confirm that the latest DDR3 bytewise leveling patch for u-boot on arago-project.org is the approved code that customers should use now?

     

    Thanks,

    --Gunter

  • Hi Gunter,

    I have emailed you the patch. 

  • Renjith,

    Would you mind sending me the patch you were referring to?

    Thanks in advance,

    Tate

  • Tate,

    I'm sorry I can't do that as these patches are developed for a customer.