Hi Siarhei, On 11/11/15 04:40, Siarhei Siamashka wrote: > On Thu, 22 Oct 2015 13:52:38 +0200 > Jens Kuske <jensku...@gmail.com> wrote: > >> >> On 22/10/15 10:49, Hans de Goede wrote: >>> Hi, >>> >>> On 22-10-15 09:49, Jens Kuske wrote: >> [..] >>>> >>>> I don't plan to work on USB soon, my next step would have been Ethernet >>>> and finishing the basic u-boot support. You know my u-boot H3 wip tree I >>>> hope? Before we duplicate our work there too... >>>> https://github.com/jemk/u-boot-sunxi/tree/sunxi/h3 >>> >>> I was not aware of that work, at a first glance it looks good. Can you >>> rebase >>> this on top of current u-boot/master (or v2015.10) and then submit it >>> upstream ? >> >> I will, after fixing some more things (like your question 2). > > FYI, this branch works mostly OK on my freshly bought Orange Pi PC > board. I only had to reduce the DRAM clock speed from 672MHz to 480MHz > to prevent the kernel from oopsing. > > But when the DRAM is initialized by boot0, 672MHz seems to work without > obviously visible problems. > > I will try to debug this problem and compare the configuration in the > DRAM controller hardware registers. The FEX files seem to imply that > the DRAM settings should be the same on all H3 based Orange boards, > but there might be still some deliberate difference in the configuration > or a subtle bug in your code.
I'd guess it's the ZQ calibration that doesn't work correctly, see below why. But since I have removed a lot of other code that wasn't used I might accidentally destroyed something else too, but I have been very careful. > >>> 2 questions which come to mind immediately: >>> >>> 1) Where does the dram init logic come from, AFAIK Allwinner has not >>> provided >>> any H3 dram init code ? >> >> It's from the Draco H3 TV Stick SDK: >> >> http://www.cnx-software.com/2015/06/14/tronsmart-draco-h3-tv-stick-firmware-and-sdk-released/ > > Could you please provide a bit more details about the location of this > code? I tried to download the SDK and looked around a bit. There are > some directories with the DRAM initialization code: > > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_a13 > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_a20 > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_a31 > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_a39 > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_a50 > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_a67 > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_a73 > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_a77 > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_a81 > H3_SDK_20150601_lichee/brandy/basic_loader/bsp_for_i20 > > The names are a bit strange and nothing obviously looks like H3. > A quick search for some of the relatively unique magic constants > used in your code also was not very successful, but I did not try > too hard yet. 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. 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... 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"); } 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]); } I don't have the time to add more information now, but we can discuss this later. > >>> 2) I see no pmic code in there. I know these boards do not use an axp pmic, >>> but according to my info at least the Orange Pi 2 (which I have) uses a >>> sy8106a pmic, it is not entirely clear to me yet if this one needs any >>> init though, I've mailed the Orange Pi people about this. >> >> Correct, the CPU voltage is provided by a i2c controllable regulator >> (sy8106a) >> without any datasheet. I've found how to set the voltage in above SDK, but I >> first want test this carefully. >> >> There's also the problem that we have to use the OpenRISC core for power >> management (especially poweroff), since there is no external PMIC. This can >> be done later of course, but we should think about how to do it. > > There was a SY8106A datasheet posted later in the mailing list. It > looks like at least on the Orange Pi PC the default voltage supplied > by SY8106A (and configured via a pair of resistors) is 1.2V which > seems to be safe for the CPU clock frequencies up to 1008MHz according > to the comments in the FEX file. I added some notes to the wiki page: > > https://linux-sunxi.org/Orange_Pi_PC > > Moreover, people in the Orange Pi forums seem to be complaining about > the SoC easily overheating without a heatsink. It means that enabling > the highest CPU clock speed may be not the brightest idea I think, based on the FEX file comments, everything above 1.2GHz is overclocking, so we might shouldn't do this anyway. > without > adding support for the temperature sensor first. So it looks like > configuring SY8106A is not the most important feature for the initial > H3 support in U-Boot and it can be postponed until a later date. I came to this conclusion in the meantime too, especially since I can't really figure out how to write to this i2c bus in u-boot :D Regards, 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.
