On Fri, Sep 30, 2016 at 6:20 PM, Jens Kuske <jensku...@gmail.com> wrote: > 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?
This code is detecting H3 rev.A chip, correct? I'm thinking we need to detect the H3(0x1680) first and check for rev.A for safety. Can you point me where it documented, unable to find the same. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
