Hi,
On 12/10/2015 10:29 AM, Jens Kuske 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:
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?
Yes please, your original version is fine for now, lets wait with
doing something more fancy until we have a good idea how something
more fancy should look like. For now I think that being able
to compare the fex file values 1:1 with our code is good.
Maybe add a comment to where you set the constants in the struct
to which tpr the settings belong, e.g. :
.read_delays = 0x00007979, /* tpr12 */
.write_delays = 0x6aaa0000, /* tpr11 */
> I mean, it seems it doesn't really fix it
at least on some Orange Pi PCs, but only improves the situation.
? if I understand things correctly your patch make lima-memtester pass
at 672 MHz (which is our current configured speed) on both your
and Siarhei's boards, to me that seems that it fixes things.
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.
