Hi, 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.
Ok, so maybe as a first step we should add a dqs_gating_delay field to our dram parameters struct, set that to 0x06060606 for the cubietruck (and only for the cubietruck for now), and if that field is set do the override ? This is something which we could do for the current u-boot 2014.07 cycle, together with making FAST_MBUS the default everywhere. > > 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. > > As for the u-boot DRAM code, we would need to implement some sort > of a workaround or perform the DQS gate training in software. This > is not something new, because the hardware DDR3 calibration seems > to be broken in pretty much almost every SoC around (if we check > the errata lists and patches floating around) :-) > > Preferably all of this has to be resolved and tested on multiple > devices before the next u-boot merge window opens. Agreed. I have a large variety of hardware to test with (a lot of different boards, not multiple versions of one board), but I'm not sure how much time I can spend on testing :| > We are really > dependent on the users' feedback and cooperation because every > device may potentially have its own individual quirks. And I > prefer to have predictable hardware behaviour, reasonable > explanations for everything and no unresolved mysteries. Regards, Hans -- 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.
