[U-Boot] [PATCH 11/14] sunxi: Fill memory before comparing it when doing dram init on sun6i

[Siarhei Siamashka]

On Fri, 19 Dec 2014 17:56:40 +0100
Hans de Goede <hdegoede at redhat.com> wrote:

> Hi,
> 
> On 19-12-14 11:08, Siarhei Siamashka wrote:
> > On Thu, 18 Dec 2014 19:12:13 +0000
> > Ian Campbell <ijc at hellion.org.uk> wrote:
> >
> >> On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote:
> >>> The sun8i boot0 code fills the DRAM with a "random" pattern before comparing
> >>> it at different offsets to do columns, etc. detection. The sun6i boot0 code
> >>> does not do it, but it seems like a good idea to do this regardless.
> >>
> >> Is this the right way round? The existing sun6i code (which you are
> >> moving here) seems to _rely_ on something having written a useful
> >> pattern, which I would have assumed to have been boot0. Or else how does
> >> it work now? Chance?
> >
> > It appears that this code is just trying to find the first address line,
> > which is not connected anywhere. If the address line is not connected,
> > then having the corresponding bit set or clear in the memory address
> > does not matter and we are effectively accessing the same location.
> 
> Correct.
> 
> > Both sun6i and sun8i code is incorrect and only works because of relying
> > on luck.
> >
> > The sun6i code is incorrect because it is just reading memory without
> > initializing it at all. Probably relying on having some unique garbage
> > there in a natural way.
> >
> > The newer sun8i code is still incorrect because it is not safeguarding
> > against accidentally encountering the same test pattern at an unrelated
> > memory location. Yes, the probability is extremely low, but still not
> > zero.
> 
> The probability is so low that it really does not matter, so I've no intention
> to fix this.

"If anything bad can happen, it probably will" :-)

There are many real life examples, when something supposedly almost
impossible has in fact happened. Like the following story:
    http://ixbtlabs.com/articles2/magia-chisel/
In a nutshell, the designers of some old CD/CD-RW drives just did not
bother to ensure that the written user data can be never confused
with the service information (sync headers) on disk. The probability
of encountering something that resembles a sync header was considered
to be way too low. Well, until somebody has encountered a hardware
glitch and a sync header fragment got mistakenly read from the drive
as part of some file. Now this corrupted file can wreak havoc if
written to a CD disk, because the false sync header in it is getting
interpreted as an actual sync header. Oops.

Anyway, this is a bug in the sun6i/sun8i dram code. And the submitted
patch appears to be only a partial/incomplete fix. A strong NAK from
me.

-- 
Best regards,
Siarhei Siamashka