On Thu, 10 Dec 2015 10:29:52 +0100 Jens Kuske <[email protected]> wrote:
> On 10/12/15 03:13, Siarhei Siamashka wrote: > > Hello, > > > > On Wed, 9 Dec 2015 19:29:49 +0100 > > Jens Kuske <[email protected]> wrote: > > > >> On 09/12/15 09:40, Siarhei Siamashka wrote: > >> The read delays (except for dqs) are doubled in boot0 before > >> writing them to the registers. Looks like they suddenly needed > >> higher values than possible with 4 bit. The register seems to > >> take 6 bit wide values. > > > > Well, we can always change the layout of data in this struct and > > allocate 8 bits per each delay value instead of 4 bits: > > > > struct dram_para para = { > > .read_delays = 0x00007979, > > .write_delays = 0x6aaa0000, > > .dual_rank = 0, > > .bus_width = 32, > > .row_bits = 15, > > .page_size = 4096, > > }; > > > > Are they originally the 'tpr11' and 'tpr12' parameters from FEX? > > Yes, they are. I just gave them meaningful names. > Each nibble represents delay of one byte lane, the lower 4 for the DQ > lines, the upper 4 for the DQS/DQS# lines. > > > Maybe they belong in Kconfig, with a comment about how to do all > > the needed conversion from FEX (multiplication by 2)? > > If it turns out that they should be different between boards, sure. But > all FEX files I checked had the same values. Maybe the board vendors > don't even know about these, Allwinner provided these somewhat strange > numbers (why does lane 4 have a much shorter dqs write delay) and they > adopted them... It looks like exactly the same story as with A10/A13/A20. All the device vendors are using the same set of settings, while these settings are not necessarily optimal (or even good) specifically for their hardware. > Maybe something like this would be a good idea: > > CONFIG_DRAM_DQ_READ_DELAY = 0x0e120e12 > CONFIG_DRAM_DQS_READ_DELAY = 0x00000000 > CONFIG_DRAM_DQ_WRITE_DELAY = 0x00000000 > CONFIG_DRAM_DQS_WRITE_DELAY = 0x060a0a0a > > Or we find values that work well on all boards. This may be tricky. H3 still needs some automation. Because just randomly trying different settings in a manual way is not a very productive use of anyone's time. Also active users engagement is critical, or we have no chance to collect enough statistics from different board samples. Fortunately Orange Pi PC seems to be quite popular, so it is likely to be one of the best supported and well configured boards. Another alternative is the board manufacturer's engagement. > > BTW, do these delays serve a somewhat similar purpose as the 'tpr3' > > parameter in A10/A13/A20? Later we could adapt the a10-tpr3-scan > > script and make a h3 variant of it for bruteforce searching optimal > > values of these delays. > > I think they are comparable with tpr3. The hardware would even support > individual delays for each bit, but the combinations get endless then. Yes, A10/A13/A20 also had many configuration knobs. Some configuration knobs appear to be more important than the others in practice. This needs to be figured out in an experimental way. The Orange Pi PC has DDR3L-1600 memory chips. If the H3 DRAM controller configuration is the only limiting factor, then there may be potentially a way up to clock DRAM up to 800 MHz. And there is never too much memory bandwidth for graphics and multimedia :-) Still the first priority is of course trying to ensure reliable operation at the specified/advertised ~667 MHz. But I'm not sure if I want to do any work on this myself, unless enough people register their interest and at least promise to participate in testing. > > > > With the lima-memtester test failures, we have already discovered > > in an experimental way that correctly configuring these delays > > apparently affects reliability :-) > > > >> After fixing that, lima-memtester doesn't fail at 672 MHz anymore > >> on my Orange Pi Plus. Before it failed at 552 and higher. > >> Patch below. > > > > Thanks. With this U-Boot patch, lima-memtester does not fail anymore > > at 672 MHz on my Orange Pi PC board too. That's a major improvement > > over what is in U-boot 2016.01-rc2. If you are going to submit this > > patch to U-Boot, you can have my > > > > Tested-by: Siarhei Siamashka <[email protected]> > > Should I submit it as a fix? I mean, it seems it doesn't really fix it > at least on some Orange Pi PCs, but only improves the situation. > My OPi Plus now passes 744 MHz too (maybe even higher, didn't try), so > there are definitely differences between the boards. We can always have this patch and also reduce the DRAM clock speed to a safer level. -- 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.
