Hi,
On 11/13/2015 01:36 PM, Siarhei Siamashka wrote:
On Wed, 11 Nov 2015 18:26:54 +0100
Jens Kuske <[email protected]> wrote:
Based on some guessing and comparing with the parts I initially started
disassembling (before this SDK appeared), I think it's I20. The I20 dram
init code matched the disassembled parts exactly, except the ZQ
calibration part...
So, looks like it might not be correct to assume I20 == H3.
The magic constants in mctl_set_master_priority() seem to be a bit
different too. This explains why I could not find the matching code
in the SDK.
This is the ZQ calibration function I got by disassembling, but I dropped
it since the SDK version worked well too. Maybe I should have done the
opposite and drop the SDK...
Agreed, it's safer to prefer the variant of code that is actually
used in production on real devices.
It looks a bit strange, like if they are always calibrating the
first channel and then copying to the others, maybe there is some
hardware bug they work around.
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];
u32 reg_val, val;
mctl_dbg("ZQ calibration... ");
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);
writel(PIR_CLRSR, &mctl_ctl->pir);
mctl_phy_init(PIR_ZCAL);
val = readl(&mctl_ctl->zqdr[0]) & 0xff;
writel((val << 24) | (val << 16) | (val << 8) | (val << 0),
&mctl_ctl->zqdr[2]);
writel(PIR_CLRSR, &mctl_ctl->pir);
mctl_phy_init(PIR_ZCAL);
zq_val[i] = val | (bin_to_mgray(mgray_to_bin(readl(&mctl_ctl->zqdr[0])
>> 24) - 1) << 8);
}
writel((zq_val[1] << 16) | zq_val[0], &mctl_ctl->zqdr[0]);
writel((zq_val[3] << 16) | zq_val[2], &mctl_ctl->zqdr[1]);
writel((zq_val[5] << 16) | zq_val[4], &mctl_ctl->zqdr[2]);
mctl_dbg((mctl_ctl->zqsr & (1 << 30)) ? "ERROR\n" : "DONE\n");
}
Thanks, using this implementation fixes the reliability problems at
672MHz on my Orange Pi PC board.
Cool, note I've added Jens' (preliminary) patches to my
github/jwrdegoede/u-boot-sunxi/sunxi-wip branch, as having upstream u-boot
makes testing the kernel a lot easier.
I've replaced the mctl_zq_calibration function there with this one,
as well as did some other small fixes (to properly disable pmic
support with upstream u-boot master).
Thanks for taking care of U-Boot, it works great so far.
Seconded, thanks a lot for this work Jens, and it works great for
me too.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.