Tests, tests, and more tests.

[Djhg2000]

How do power state changes work, anyway? Does the software issue a special instruction or write some specific value to a particular register and the SoC does the rest? Or does the software have to handle some management around it, too?

Back in the day when I messed around with PIC16f, pretty much all of the power related stuff was implemented with magic registers. For instance, changing the clock rate was writing a divider value to an oscillator configuration register and 1 (or 2, I can't remember what the manual said off the top of my head) clock cycles later the processor was using the new frequency. If you needed precise timing then you would calculate the time it took to reconfigure the oscillator by using the old frequency. When I went through a PIC class one of our first tasks was to make a cycle-accurate delay function, which involved looking up and verifying the precise execution time of every instruction we used (including setup and execution of function calls).

Now an ARM is far more complex than a PIC, but they both have roots in old RISC designs so it's not impossible the same workflow simply got inherited from the existing designs.

 

[levi]

The ARM design was heavily influenced by the 6502, so thing like video controller registers always used to be memory mapped on those old 8-bit machines. I suspect that's the simplest way to add things to an ARM core via customising the MMU rather than adding registers into an already compact and tightly laid out core.

 

[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.