On 30.09.2016 14:24, Jagan Teki wrote:
> On Wed, Sep 21, 2016 at 11:38 PM, Jens Kuske <jensku...@gmail.com> wrote:
>> H3 seems to have a silicon bug breaking the impedance calibration.
>> This is currently worked around in software by multiple steps
>> combining the results to replace the wrong values.
>>
>> Revision A chips need a different workaround, which is present in
>> the vendor bootloader too, but got overlooked in lack of
>> information and affected boards till now.
>> This commit adds a simplified version without correction factor,
>> which would be 1.00 for all known boards anyway.
>>
>> Signed-off-by: Jens Kuske <jensku...@gmail.com>
>> ---
>>
>> Hi,
>>
>> This has been tested by an Armbian user:
>> http://forum.armbian.com/index.php/topic/872-beelink-x2-with-armbian-possible/?p=16061
>>
>> It looks like only few boards have revision A chips, probably only
>> non-development boards, otherwise we would have found this earlier.
>> The idea that these are different chip revision is based on:
>> https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/sunxi-chip.c#L341
>>
>> Regards,
>> Jens
>>
>> ---
>> arch/arm/mach-sunxi/dram_sun8i_h3.c | 64
>> +++++++++++++++++++++++++------------
>> 1 file changed, 43 insertions(+), 21 deletions(-)
>>
>> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> index 2020d75..b08b8e6 100644
>> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> @@ -217,35 +217,57 @@ static void mctl_zq_calibration(struct dram_para *para)
>> struct sunxi_mctl_ctl_reg * const mctl_ctl =
>> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>>
>> - int i;
>> - u16 zq_val[6];
>> - u8 val;
>> + if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
>> + (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {
>
> I think we can unlock before reading the sram version, do you think
> so? and lock same after.
We don't have to unlock to read this field, it's even documented in the
datasheet. Only to read the full version in bits 31:16 it has to be
unlocked. Or what did you mean?
>
>> + u32 reg_val;
>>
>> - writel(0x0a0a0a0a, &mctl_ctl->zqdr[2]);
>> -
>> - for (i = 0; i < 6; i++) {
>> - u8 zq = (CONFIG_DRAM_ZQ >> (i * 4)) & 0xf;
>> -
>> - writel((zq << 20) | (zq << 16) | (zq << 12) |
>> - (zq << 8) | (zq << 4) | (zq << 0),
>> - &mctl_ctl->zqcr);
>> + clrsetbits_le32(&mctl_ctl->zqcr, 0xffff,
>> + CONFIG_DRAM_ZQ & 0xffff);
>>
>> writel(PIR_CLRSR, &mctl_ctl->pir);
>> mctl_phy_init(PIR_ZCAL);
>>
>> - zq_val[i] = readl(&mctl_ctl->zqdr[0]) & 0xff;
>> - writel(REPEAT_BYTE(zq_val[i]), &mctl_ctl->zqdr[2]);
>> + reg_val = readl(&mctl_ctl->zqdr[0]);
>> + reg_val &= (0x1f << 16) | (0x1f << 0);
>> + reg_val |= reg_val << 8;
>> + writel(reg_val, &mctl_ctl->zqdr[0]);
>>
>> - writel(PIR_CLRSR, &mctl_ctl->pir);
>> - mctl_phy_init(PIR_ZCAL);
>> + reg_val = readl(&mctl_ctl->zqdr[1]);
>> + reg_val &= (0x1f << 16) | (0x1f << 0);
>> + reg_val |= reg_val << 8;
>> + writel(reg_val, &mctl_ctl->zqdr[1]);
>> + writel(reg_val, &mctl_ctl->zqdr[2]);
>
> Was this write call for zqdr[2] true?
Yes, it is correct, calibration for zqdr[2] doesn't work at all, so
zqdr[1] gets copied. Both are for the data lanes, so this is reasonable.
>
> thanks!
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
