On 13/11/15 13:36, Siarhei Siamashka wrote: > On Wed, 11 Nov 2015 18:26:54 +0100 > Jens Kuske <jensku...@gmail.com> 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.
Indeed, didn't remember that. > >> 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. Ok, I'll replace the SDK version then. > >> And while trying to figure out what's the reason for this I used the >> following debug function, it might help you if you want to debug ZQ cal: >> >> static void dump_zq(void) >> { >> struct sunxi_mctl_ctl_reg * const mctl_ctl = >> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE; >> >> int i; >> static const char *mod[3] = { "control", "DX0/DX1", "DX2/DX3" }; >> static const char *error[4] = { "\t", "overflow", >> "underflow", "in progress" }; >> >> printf("== ZQ calibration %s %s ==\n", >> (mctl_ctl->zqsr & (1 << 31)) ? "DONE" : "", >> (mctl_ctl->zqsr & (1 << 30)) ? "ERROR" : ""); >> >> printf("\tODT pull-up\tODT pull-down\tDRV pull-up\tDRV pull-down\n"); >> >> for (i = 0; i < 3; i++) >> printf("%s\t%2u %s\t%2u %s\t%2u %s\t%2u %s\n", mod[i], >> mgray_to_bin((mctl_ctl->zqdr[i] >> 24) & 0x1f), >> error[(mctl_ctl->zqsr >> (i * 8 + 6)) & 0x3], >> mgray_to_bin((mctl_ctl->zqdr[i] >> 16) & 0x1f), >> error[(mctl_ctl->zqsr >> (i * 8 + 4)) & 0x3], >> mgray_to_bin((mctl_ctl->zqdr[i] >> 8) & 0x1f), >> error[(mctl_ctl->zqsr >> (i * 8 + 2)) & 0x3], >> mgray_to_bin((mctl_ctl->zqdr[i] >> 0) & 0x1f), >> error[(mctl_ctl->zqsr >> (i * 8 + 0)) & 0x3]); >> } > > With your original code from github I get: > > == ZQ calibration DONE ERROR == > ODT pull-up ODT pull-down DRV pull-up DRV pull-down > control 16 underflow 16 12 underflow 12 > DX0/DX1 12 underflow 12 12 underflow 12 > DX2/DX3 12 12 12 underflow 12 > > With the implementation from your e-mail I get: > > == ZQ calibration DONE == > ODT pull-up ODT pull-down DRV pull-up DRV pull-down > control 20 17 15 13 > DX0/DX1 6 5 15 13 > DX2/DX3 6 5 15 13 > That looks *much* better :) > > I'm going to try running lima-memtester on the device and also will > do a detailed review of your code by the end of the weekend. BTW, which > boot0 binary did you use as a reference? It might help to make sure > that we are actually looking at exactly the same thing. If I remember correctly the libdram came from the SDK offered at the orange pi downloads. I roughly compared it to the preinstalled android boot0, it looked the same but had some symbols. But I dropped most unused codepaths and tried to cleaned up a lot of magic. > > And regarding the patchset itself. There are no conflicts when rebasing > it to v2015.10 and this newer version of U-Boot is preferable because > it has better FEL boot support (automatic 'boot.scr' handling). Also it > would be great to have these H3 patches posted to the U-Boot mailing > list, preferably a week ago while the merge window was still open :-) I have some more fixes waiting, but I think I can send them this weekend (without regulator support). Jens -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.