On Mon, 12 May 2014 10:45:44 +0200 Olliver Schinagl <[email protected]> wrote:
> > On 12-05-14 09:54, Siarhei Siamashka wrote: > > On Sun, 11 May 2014 22:47:03 +0200 > > Hans de Goede <[email protected]> wrote: > > > >> Hi, > >> > >> On 05/11/2014 12:31 PM, Siarhei Siamashka wrote: > >>> On Sun, 11 May 2014 10:36:25 +0200 > >>> Hans de Goede <[email protected]> wrote: > >>> > >>>> We've several bug reports indicating that this causes stability issues, > >>>> so lets just drop it. > So not just me? jikes ... > >>> I'm afraid that the reporters still have not done their homework > >>> properly. And suspect that the FAST_MBUS just happens to be the last > >>> straw to break the camel's back on slightly unstable systems. > FAST_MBUS isn't supposed to fix stability problems though does it? It > offers a performance/speed boost (if stable), or atleast that was my > understanding. > >> Well at least Oliver has done quite a bit of testing, with dcdc3 set > >> to 1.3V not only in u-boot but also in the fex file. > Well not quite a bit, I ran into the problem that my board became very > unstable after enabeling (and boosting the voltage). Otherwise it ran > perfectly fine (cb3 btw) > > > I don't quite trust the tests, which need tens of hours to run > > before detecting a problem. The main issue here is that we may have > > a significant variance in the problem detection time (let's say, > Tests to see if it is stable? Absolutely. In my case, the board couldn't > even reliably boot It is interesting to check if it could be something related to: https://www.mail-archive.com/[email protected]/msg04700.html I have also recently found that the Cubieboard fork of u-boot-sunxi has a similar fix, but additionally introduces a bunch of axp209_write calls: https://github.com/cubieboard/u-boot-sunxi/commit/fb357b4e1f07 > and in the rare occasion it did manage to boot, a tar > xJvf job would crash due to errors after a few minutes or had corrupted > results. I believe that lima-memtester is a much stronger dram reliability test than a tar job regardless of the MBUS setup. It would be still very interesting to check if your configuration passes the lima-memtester test after you remove FAST_MBUS and tar failures disappear. > > something between 10 and 30 hours for example). And if the person > > running the test is having some expectations (like assuming that > > lower MBUS clock provides better stability), then this person may > > stop some of the test runs prematurely and come to biased conclusions. > > > > Also we need to confirm that the fex changes have really taken effect. > > It is possible to grep the dmesg log for "buck3" string after booting > > up to find the dcdc3 voltage there. > That is a fair point, that I may not have properly tripple checked ... > > > >> Oliver, can you retest your cubietruck breakage with FAST_MBUS, with > >> the dcdc voltage traised to 1.425 V in u-boot + Siarhei's fex file > >> changes he send earlier to day, and see if your FAST_MBUS triggered > >> regression then goes away? > I can in the next week or so; I"ll try to find Siarhei's Fex changes and > run it at 1.425 v > > I don't recall if i kept the mbus in sync with the dram clock however. If you are clocking dram at just 432MHz in your Cubietruck, then your situation indeed looks very similar to: > We also had a report about some A20 device not being able to run stable > with dram clocked at 432MHz. Unless MBUS was also synchronously clocked > at 432MHz (using PLL5 instead of PLL6): > http://irclog.whitequark.org/linux-sunxi/2013-11-26#5690482 So just a random speculation. Could it be that you (and hglm) somehow have a "bad" PLL6 in your boards, which causes stability issues if used for clocking MBUS? And there is also a magic trick (discovered by jemk) to significantly improve dram overclocking potential on the Cubietruck. You can set dram_tpr3 to 0x72222 in the dram_para struct in the u-boot. But if your MBUS related problems have a different root cause, then it might not help much. In any case, you seem to be lucky to have a very unique device with interesting properties :-) Just be sure to report all your findings. -- Best regards, Siarhei Siamashka -- 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.
