On Sun, 25 May 2014 00:34:14 +0200 Olliver Schinagl <[email protected]> wrote:
> Hey all, > > I am just venting here mostly as I don't have much time to test things > really just yet. > > As you know I am writing a book based on the A10/A20 stuff and wanted to > double-check/upgrade the Fedora 19 chapter to F20. After an hour of > figuring out why it kept crashing (I thought it was a power thing) and > trying various u-boots (supplied in the f20 image and from our current > git) I suddenly remembered that a FAST_MBUS setting does not work on my > cubietruck. And indeed, removing FAST_MBUS from the boards.cfg made the > board sprung to life. > > TL:DR; > We should really drop FAST_MBUS on all boards as a default, since we > want the repo to contain safe defaults. Once we get the whole memory > tweaking done more reliable, then sure, but until then, only users who > can and want to play with this setting should. > > Also, the F20 image should really be rebuilt with u-boots without FAST_MBUS. > Hans, I'm not sure if you know or could talk to the current fedora > maintainer for the Allwinner stuff, but I do feel it is somewhat > important that at least the image works for everyone 'out of the box', > right? So maybe publish an updated or r2 image? Olliver, until you try https://github.com/ssvb/lima-memtester/ and report the results, what you are saying is just a speculation and bullshitting. I know that you have deliberately ignored me at least *four* times (twice in the IRC and twice in the mailing list) since this whole ordeal started. And this prevents all of *us* from getting any clue about what is *really* going on with your hardware. You hardware is very clearly an odd ball, exhibiting the behaviour not seen by anyone else so far. This makes it very important to double check everything before jumping to any conclusions. We have seen a number of users, who had reported unstable behaviour and rare crashes/lockups with their cubieboard2/cubietruck. As far as I know, all of them could knock down their system with the lima-memtester test in a matter of a few seconds (!) or a few minutes. And then search for the real root cause. BTW, in one case it turned out to be just a bad USB cable, which was used to power the board: http://irclog.whitequark.org/cubieboard/2014-05-15#9034663; Anyway, in all other cases, just increasing the dcdc3 voltage to 1.3V (via the fex file tweak) helped to resolve all the issues. One more thing. The CubieTech people have quite a number of their boards with FAST_MBUS settings some time ago and apparently had no problems with them: https://groups.google.com/forum/#!topic/linux-sunxi/rhOUJXJu0Jg Though they did not bother to comment on my question about dcdc3 voltage they used for testing. TL:DR; Please spend a couple of *minutes* of your precious time to run the lima-memtester *after* you have disabled FAST_MBUS in your u-boot. If the test still fails, then you can't blame FAST_MBUS alone for all the problems. And if you decide to cooperate after all, I have one more idea about what could be potentially the root cause of problems on your hardware. The automatic hardware DQS gate training has a relatively low resolution (plus/minus 90 degrees phase) to select the initial approximation, which is nevertheless usable for low dram clock speeds. You could have a butterfly effect, with FAST_MBUS settings just causing the DQS training to flip to a different initial approximation with severe reliability implications. Anyway, please ping me on IRC if you want to debug the problem in real time. The "it ain't work for me, so it should be disabled" reports are not really helping much. If you have time to write posts to the mailing list, then you should also have time to run some basic tests. Please do it. -- 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.
