Skip to content
Snippets Groups Projects
Forked from Reform / reform-boundary-uboot
Source project has a limited visibility.
  • Marek Vasut's avatar
    14eeb683
    ARM: mx6: ddr: Add write leveling correction code · 14eeb683
    Marek Vasut authored
    When the DDR calibration is enabled, a situation may happen that it
    will fail on a few select boards out of a whole production lot. In
    particular, after the first write leveling stage, the MPWLDECTRLx
    registers will contain a value 0x1nn , for nn usually being 0x7f or
    slightly lower.
    
    What this means is that the HW write leveling detected that the DQS
    rising edge on one or more bundles arrives slightly _after_ CLK and
    therefore when the DDR DRAM samples CLK on the DQS rising edge, the
    CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18).
    
    The HW write leveling then ends up adding almost an entire cycle (thus
    the 0x17f) to the DQS delay, which indeed aligns it, but also triggers
    subsequent calibration failure in DQS gating due to this massive offset.
    
    There are two observations here:
    - If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the
      DQS gating passes, the entire calibration passes as well and the
      DRAM is perfectly stable even under massive load.
    - When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so
      in MPWLDECTRx register is not there, but it is replaced by 0x0 as one
      would expect.
    
    Someone from NXP finally explains why, quoting [1]:
    
        "
        Having said all that, the DDR Stress Test does something that we
        do not advertise to the users. The Stress Test iself looks at the
        values of the MPWLDECTRL0/1 fields before reporting results, and
        if it sees any filed with a value greater than 200/256 delay
        (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR
        Stress test will reset the Write Leveling delay for this lane
        to 0x000 and not report it in the log.
    
        The reason that the DDR Stress test does this is because a delay
        of more than 78% a clock cycle means that the DQS edge is arriving
        within the JEDEC tolerence of 25% of the clock edge. In most cases,
        DQS is arriving < 5% tCK of the SDCLK edge in the early case, and
        it does not make sense to delay the DQS strobe almost a full clock
        cycle and add extra latency to each Write burst just to make the
        two edges align exactly. In this case, we are guilty of making a
        decision for the customer without telling them we are doing it so
        that we don't have to provide the above explanation to every customer.
        They don't need to know it.
        "
    
    This patch adds the correction described above, that is if the MPWLDECTRx
    value is over 0x148, the value is corrected back to 0x0.
    
    [1] https://community.nxp.com/thread/456246
    
    
    
    Signed-off-by: default avatarMarek Vasut <marex@denx.de>
    Cc: Stefano Babic <sbabic@denx.de>
    Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
    Reviewed-by: default avatarEric Nelson <eric@nelint.com>
    Reviewed-by: default avatarStefano Babic <sbabic@denx.de>
    14eeb683
    History
    ARM: mx6: ddr: Add write leveling correction code
    Marek Vasut authored
    When the DDR calibration is enabled, a situation may happen that it
    will fail on a few select boards out of a whole production lot. In
    particular, after the first write leveling stage, the MPWLDECTRLx
    registers will contain a value 0x1nn , for nn usually being 0x7f or
    slightly lower.
    
    What this means is that the HW write leveling detected that the DQS
    rising edge on one or more bundles arrives slightly _after_ CLK and
    therefore when the DDR DRAM samples CLK on the DQS rising edge, the
    CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18).
    
    The HW write leveling then ends up adding almost an entire cycle (thus
    the 0x17f) to the DQS delay, which indeed aligns it, but also triggers
    subsequent calibration failure in DQS gating due to this massive offset.
    
    There are two observations here:
    - If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the
      DQS gating passes, the entire calibration passes as well and the
      DRAM is perfectly stable even under massive load.
    - When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so
      in MPWLDECTRx register is not there, but it is replaced by 0x0 as one
      would expect.
    
    Someone from NXP finally explains why, quoting [1]:
    
        "
        Having said all that, the DDR Stress Test does something that we
        do not advertise to the users. The Stress Test iself looks at the
        values of the MPWLDECTRL0/1 fields before reporting results, and
        if it sees any filed with a value greater than 200/256 delay
        (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR
        Stress test will reset the Write Leveling delay for this lane
        to 0x000 and not report it in the log.
    
        The reason that the DDR Stress test does this is because a delay
        of more than 78% a clock cycle means that the DQS edge is arriving
        within the JEDEC tolerence of 25% of the clock edge. In most cases,
        DQS is arriving < 5% tCK of the SDCLK edge in the early case, and
        it does not make sense to delay the DQS strobe almost a full clock
        cycle and add extra latency to each Write burst just to make the
        two edges align exactly. In this case, we are guilty of making a
        decision for the customer without telling them we are doing it so
        that we don't have to provide the above explanation to every customer.
        They don't need to know it.
        "
    
    This patch adds the correction described above, that is if the MPWLDECTRx
    value is over 0x148, the value is corrected back to 0x0.
    
    [1] https://community.nxp.com/thread/456246
    
    
    
    Signed-off-by: default avatarMarek Vasut <marex@denx.de>
    Cc: Stefano Babic <sbabic@denx.de>
    Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
    Reviewed-by: default avatarEric Nelson <eric@nelint.com>
    Reviewed-by: default avatarStefano Babic <sbabic@denx.de>