Am Tue, 19 Sep 2017 11:05:40 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Well, it already tells us there's no general problem with using Samsung memory, our timings should be correct (well, we are sticking to JEDEC, so these should work).
So the main guess would be noise right now - though we have no idea why it works when DLL is set to off.
Maybe the DLL within the memory chip is more responsive to noise than the signal integrity, etc.?
That would be an explanation.
If we can get the RAM to work 100% fine without any issues with DLL off, I'm fine with that for the first 500 CPU boards... but nevertheless, we should look for the reason what's going wrong.
We don't a bad surprise in the future if a different batch of RAM chips won't work anymore even with the DLL off.
First results from powering up the reworked CPU boards:
- Samsung K4B4G works equally well with the same 2GB EMIF setup we
use for the IMG 2GB boards.
- IM 8G16 board does not boot - but there is a short circuit on
VSYS :( I.e. rework has damaged the board and we can't evaluate the memory chips yet.
I'll check if we can get that repaired (swapping Palmas for example could help, or transplanting the memory chips to yet another CPU board).
Unfortunately, this doesn't help us much.
BR, Nikolaus
Am 19.09.2017 um 01:19 schrieb Michael Mrozek EvilDragon@openpandora.org:
On Mo, 2017-09-18 at 21:11 +0200, Matthijs van Duin wrote:
Well, sure, it wouldn't be the solution, but might be interesting to see if it works.
I still find it weird though that it probably works with DLL off but full speed :O
What happens if you back it off 5% from the bin edge and run the clock at 507 MHz or so?
The memory is binned for CL=7 @ 533 MHz, which means the manufacturer guarantees those timings. I'm also fairly sure that CL is only relevant for timing closure internal to the memory, hence increasing it won't fix issues with the interfacing between memory and omap.
Of course lowering the clock frequency could nevertheless be beneficial since gives all nets (both signal and power) more time to stabilize again after a transition. Doing so however would require lowering the frequency of the core PLL and thereby all clocks that derive from it (which include all interconnects and the GPU), which would be annoying from a performance point of view.
Matthijs _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel