On Fr, 2018-10-12 at 02:41 +0300, Grazvydas Ignotas wrote:
Hi,
wow, thanks a lot for that!
Too bad it doesn't help much - but at least we can get the boards reliable to work.
It seems like a problem with some TI-processors. Here is a VERY similar sounding issue: https://e2e.ti.com/support/processors/f/791/t/588807?Linux-AM3352-DDR3-self-...
Micron has an interesting guide about self-refresh modes: https://www.micron.com/products/datasheets/%7B2ADCEEB1-307F-4B37-99C9-7302CA...
Not sure if our memory behaves the same, but it has some information about the requirements to enter self-refresh mode. Not sure if these requirements / procedure is being done by the OMAP5 alone or whether this is controlled by the kernel though.
Do you know if disabling self-refresh has any negative side effects? Would it increase power consumption a lot or probably not really noticeable?
I've gone through all of them, and the ones that are programmable are correctly programmed already. There were minor mistakes (patches sent) but fixing them has no effect on the hang issue. Things I tried:
- higher cl values
- more relaxed / higher other timings that are programmable
- dumping registers from Linux and confirming everything is
programmed as it should be
- overclocking to 533.7MHz (not sure if exact 533 can be achieved
because of how omap's dpll works)
- other things I forgot
Among things not tried are strange registers like CONTROL_DDR3CH2_0 CONTROL_EMIF1_SDRAM_CONFIG_EXT - it's hard to understand what they do and how they could help with our issue.
The only thing that helps besides DLL disable is disabling self-refresh. I think the RAMs are incompatible with how OMAP5 does power saving, that's all there is to it. We'll have to choose one of those workarounds. Probably disabling self-refresh makes the most sense since unlike the DLL option it's not against any specs or requirements.
Gražvydas