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:
>>> Thanks for the explanations. I finally got lima-memtester up and
>>> running on H3 hardware (not that it was difficult, but just the amount
>>> of unnecessary compatibility breaks in the H3 SDK kernel was a bit
>>> unexpected and really discouraging, they are really doing almost
>>> *everything* in a different way compared to A10/A20 SDK kernel just
>>> for the sake of making things different):
>>>
>>>
>>> https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test
>>>
>>> Currently U-Boot v2016.01-rc2 fails the lima-memtester check unless
>>> the DRAM clock speed is reduced to 456 MHz on my Orange Pi PC. But
>>> if I use the boot0 bootloader to boot the same kernel image
>>> (uImage-3.4-sun8i-h3-lima-memtester), then the test works fine.
>>> This means that there must be still something wrong with the H3
>>> DRAM init code in U-Boot, or maybe some clocks are wrong
>>>
>>
>> I tried to compare boot0 and the SDK source again and actually
>> found another difference.
>
> Did you dump the DRAM controller registers to find this difference
> between U-Boot and boot0?
In this case, yes. But also by reviewing the disassembled boot0 again.
>
>> 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...
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.
>
> 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.
>
> 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.
Regards,
Jens
--
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.
