[U-Boot] [PATCH 1/4] ARM: pxa: prevent PXA270 occasional reboot freezes

[Marek Vasut <marex@denx.de>]

On Sunday, December 15, 2013 at 12:51:44 AM, Sergei Ianovich wrote:
> On Sat, 2013-12-14 at 18:14 +0100, Marek Vasut wrote:
> > On Saturday, December 14, 2013 at 04:31:31 PM, Sergei Ianovich wrote:
> > > On Sat, 2013-12-14 at 13:29 +0100, Marek Vasut wrote:
> > > > Do you need to write this register in an endless loop ?
> > > 
> > > I didn't think this way. We need to have at least 3, but up to 5 cycles
> > > to put SDRAM in SLFRFRSH. It depends on the current state of SDRAM.
> > > There is no way to know.
> > 
> > OK, I seem to remember the uglinesses of the PXA DRAM controller, indeed
> > :(
> > 
> > > It can probably work if we write just once. But if we have another
> > > thread doing something with SDRAM in between, we will still hang.
> > 
> > U-Boot is single-threaded ;-)
> > 
> > > I am not sure how likely is the situation, though.
> > 
> > It cannot happen, really ;-)
> > 
> > BUT (!) I understand your intention. If writing the MDREFR multiple times
> > won't be a problem, I am _not_ opposed to this patch. So please only
> > make sure that's not a problem and if it's not, I won't block this
> > patch.
> 
> The relevant doc is [1, section 6.1.5.4]. Refresh rules are rather
> complex. However, clearing DRI and repeatedly writing to MDREFR should
> refresh. The refreshes should advance SDRAM state machine to
> "Self-refresh and Clock-stop". This is what we are trying to achieve.
> 
> I've run close to 1000 reboot of patched linux kernel. This mean several
> billions writes to MDREFR. If a write can cause a problem, it should
> have already shown up. So I think it is not a problem.

I saw this kernel patch, yes.

> Nevertheless, I've put a patched U-Boot with a single write to MDREFR to
> test (reset every 2 sec). After several hours, it will be clear, if a
> single write works. Let's do it the right way.

Thank you !

> 1.
> http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_de
> v_man.pdf

Best regards,
Marek Vasut