On Sun, 12 Oct 2014 14:32:01 +0200 Olliver Schinagl <[email protected]> wrote:
> On 05/30/2014 06:24 PM, Siarhei Siamashka wrote: > > On Sun, 25 May 2014 11:43:52 +0200 > > Hans de Goede <[email protected]> wrote: > > > >> Hi, > >> > >> On 05/25/2014 12:34 AM, Olliver Schinagl 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? > >> > >> I've suggested a couple of times already to run of FAST_MBUS, but > >> others did not like the idea. > >> > >> And TBH they have a point, your board is the only one which has > >> stability issues which seem to be caused by FAST_MBUS. > >> > >> Can you please work with Siarhei Siamashka to properly root > >> cause this ? If it really is FAST_MBUS I'm all for disabling it,' > >> but first lets make sure. > > > > A status update. Olliver was kind enough to spend several hours of > > his time running various DRAM tests a few days ago: > > http://irclog.whitequark.org/linux-sunxi/2014-05-26#9139352; > > > > These tests seem to have confirmed my earlier suspicions about > > the unreliable hardware DQS gate training being at fault. On my > > Cubietruck, the results of performing the DQS gate training > > are the following, no matter whether FAST_MBUS is used or not: > > rslr0=00000249, rdgr0=000000AA > > Or we can represent them as a bit more readable artificial > > 'dqs_gating_delay' variable, where each byte specifies the > > DQS gating delay (measured in quarter cycles) for each of > > the four DDR3 byte lanes (or in other words, the delay for > > each of the 4 memory chips used in the Cubietruck): > > dqs_gating_delay=0x06060606 > > > > But Olliver got the following results on his Cubietruck: > > dqs_gating_delay=0x05060606 (without FAST_MBUS) > > dqs_gating_delay=0x05060605 (with FAST_MBUS) > > > > This basically means that enabling FAST_MBUS indeed behaves very > > much like the http://en.wikipedia.org/wiki/Butterfly_effect > > The hardware DQS training apparently has difficulties to decide > > between 5 and 6 quarter cycle delay for one of the lanes, and > > the FAST_MBUS configuration makes it flip to 5 (making the system > > so unreliable, that it even fails to boot). We would assume that > > in the case of doubt, both of these settings should be more or > > less equally good or bad, but apparently the hardware DQS gate > > training also has a bias towards the lower values (probably > > caused by rounding down instead of rounding to the nearest). > > If anybody is interested in more details about how this all > > works, it is possible to find the relevant information in the > > "data training" section of the RK30XX manual. > > > > In any case, Olliver tried to override this unreliable autodetection > > and use the rslr0/rdgr0 settings obtained from my board. This seemed > > to have resolved the reliability problems. > > > > Now about the next steps. On IRC I kept asking Olliver two days > > in a row to check if his Cubietruck can work with a higher DRAM > > clock frequency than the lowly default 432MHz. If his board is > > anything like mine or Jens Kuske's, then it should be bootable > > with DRAM clocked at 600MHz, and pass lima-memtester tests at > > around 528MHz or 540MHz (with dram_tpr3=0x7222 and dcdc3_vol=1300). > > Knowing the DRAM clock speed limit on the Oliver's board and > > comparing it with the other boards would allow us to know if it > > is just the hardware DQS training block broken and everything > > else is the same, or something else is also different. We are > > still missing this information. > a few months later, > > do you still want me to run these tests? :) Yes, sure. If you have time for this. Your Cubietruck is very unusual, and maybe even somewhat defective. I'm not sure if I can provide any good step by step instructions. First of all, we need to be sure that the DRAM controller can be successfully initialized. This requires performing some steps in the right order with the right delays. A number of problems in the DRAM initialization sequence have been corrected in the mainline u-boot v2014.10 If you get some fatal problems right in the u-boot (DRAM size gets detected as 0), then it makes sense debugging it a bit to see, which step is failing. If the system boots but is unreliable, then the lima-memtester is the right tool to use. Try to tweak the dcdc3 voltage (both in u-boot and in fex) and dram/mbus clock frequencies until you can boot the system and pass the lima-memtester test. Then report the results. Some information about how the DRAM controller works on A10/A13/A20 and how it gets configured is available at: http://linux-sunxi.org/A10_DRAM_Controller_Calibration Feel free to ping me on IRC, because this is the fastest communication method. > If you can supply me with a pached u-boot version that does everything > you want, i can run those lima and cpuburn tests :) Here is the u-boot branch that I have been offering to people, who expressed interest in running memory tests on their hardware: https://github.com/ssvb/u-boot-sunxi-dram/commits/highspeedtruck-sunxi-3.4-v2 Just revert the two last commits there to get the 'stock' v2014.10 dram setup for the cubietruck. I would assume that first we want to have dram at least working reliable on your board before moving to something like 600MHz. Also u-boot v2014.10 has been finally released. So a more up to date u-boot branch with sunxi-3.4 kernel support will be available in a matter of a few days. -- 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.
