Tests, tests, and more tests.

[Grench]

I'm waiting for Nikolaus to compile me the updated version so I can test it on my unit.

https://xkcd.com/303/

Sorry - had to be done.

 

[WizardStan]

DLL in this sense means Delay Locked Loop, not the crap Windows libraries. It's memory timings and what not.

Ah yes, of course. To prevent a lock you must add a loop to delay it.

 

[Silent-Hunter]

I hope this is really it, and the issue is fixed!

 

[notaz]

With that patch my pyra has clocked over 3h (and counting), something I could ever reach only with memtest before. I'll see if it survives overnight.

I remember @zmatt saying DDR_DISABLE_DLL is not supposed to be ever set. I wonder what the repercussions are because nobody else seem to set it.

 

[EvilDragon]

I remember @zmatt saying DDR_DISABLE_DLL is not supposed to be ever set. I wonder what the repercussions are because nobody else seem to set it.

Well, seeing how Tony wrote in the mailing list:

Well for the idle freezing issue, curiously the old "disable internal dll" trick seems to work.

, it seems this is not the first time someone has done that (or at least he did that).

And further from his post:

If that works for the idle system problem, then we probably have some DLL timing related value misconfigured.

This makes it sound to me that the solution is not simply to enable that for production use, but rather that this just seems to be a way to test whether the DLL timings are correctly configured.

So if I understood him correctly, is simply tells us WHAT the problem is (wrong DLL timings), it's not the fix.

 

[notaz]

Well, seeing how Tony wrote in the mailing list:

Well for the idle freezing issue, curiously the old "disable internal dll" trick seems to work.

, it seems this is not the first time someone has done that (or at least he did that).

It was actually us, after the first 4GB boards were made and had problems, setting that bit had positive effects. I don't remember who came up with setting that bit back then, zmatt maybe.

 

[Silent-Hunter]

Well at least now you know what it (hopefully) is.

 

[Linux-SWAT]

Starting tomorrow, I'll stay next to my post box the whole day.

 

[rSl]

I hope this is really it, and the issue is fixed!

++++1

 

[fusion_power]

That compared little software pieces/commands can cause such massive hardware issues...scary...

 

[FBnil]

++++1

 

[comradekingu]

How does SPD settings work on ARM?

etutorials.org/Linux+systems/embedded+linux+systems/Chapter+9.+Setting+Up+the+Bootloader/9.5+U-Boot/
was interesting.

Is "clocks_in_mhz" 1 or 0 in uboot?

Since it seems a bit random, maybe it is a scaling issue? Changing the multiplier, FSB/bclk or voltage could be problematic.

Then again I dont know how an OMAP5 overclocks.

 

[Bosbeetle]

Looks like the tangled ball of yarn is unravalling a bit, whoop!

 

[Linux-SWAT]

For DDR4, too bad :^)
https://www.phoronix.com/scan.php?page=news_item&px=Linux-DDR4-SPD-Driver-EE1004

 

[Bosbeetle]

Just noticed: Clock rate and data rate are different.

For example, for the IMGTech memory, the website says:

Data Rate: DDR3-1333
Clock Rate: 667MHz

And the Samsung Data sheet says:

400 MHz f CK for 800Mb/sec/pin, 533MHz f CK for 1066Mb/sec/pin,
667MHz f CK for 1333Mb/sec/pin, 800MHz f CK for 1600Mb/sec/pin,
933MHz f CK for 1866Mb/sec/pin,

So 533MHz should be fine.

So we "have" 1600 DDR3L --> how should than 533 be okay? Since it not a multiple of 533. If it is 1600 Mb over 4 pins it should be at 400MHz... if it's 1600 over 2 pins it should be 800MHz. Should setting it to 400 MHz be an option.

If 532 is the max for OMAP5 400MHz would be a safe bet

 

[EvilDragon]

So we "have" 1600 DDR3L --> how should than 533 be okay?

The 1600 supports DDR3-800, DDR3-1066, DDR3-1333, DDR3-1600.

The DDR3-1866 supports all these but additionally DDR3-1866 (so it's a bit faster, if your SoC supports it).

They always support slower frequencies, just not higher ones.

 

[Silent-Hunter]

The 1600 supports DDR3-800, DDR3-1066, DDR3-1333, DDR3-1600.

The DDR3-1866 supports all these but additionally DDR3-1866 (so it's a bit faster, if your SoC supports it).

They always support slower frequencies, just not higher ones.

If the lowest it supports is DDR3-800, doesn't that mean it needs to be 800 MHz?

 

[Letalis Sonus]

If the lowest it supports is DDR3-800, doesn't that mean it needs to be 800 MHz?

There's the effective clock, there's the interface clock and there's the memory clock.

JEDEC specifies DDR3-1600 with an I/O clock of 400MHz and a memory clock of 200 MHz, which results in an effective clock of 1600 MHz. DDR3 performs 4 transactions per clock, resulting in 8x prefetch.

Fun fact: DDR-400 already had a memory clock of 200 MHz, there was no significant increase in memory clock until DDR4.

Edit: Brainfart, I/O clock is 800 MHz. The DDR3 I/O clock is always 4x memory clock.

 

[Silent-Hunter]

I see! That's interesting. So perhaps 400 should be tried then?

 

[Bosbeetle]

The 1600 supports DDR3-800, DDR3-1066, DDR3-1333, DDR3-1600.

The DDR3-1866 supports all these but additionally DDR3-1866 (so it's a bit faster, if your SoC supports it).

They always support slower frequencies, just not higher ones.

Ah thats clear thanks..
[doublepost=1539028608,1539028430][/doublepost]

I see! That's interesting. So perhaps 400 should be tried then?

Well they also reported running to slow could lead to faults... but I guess 400 and 533 could be tried... still strange OMAP5 spec is 532