[U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards

[Siarhei Siamashka]

On Sun, 28 Sep 2014 17:58:41 +0200
Hans de Goede <hdegoede at redhat.com> wrote:

> Hi,
> 
> On 09/18/2014 06:07 PM, Siarhei Siamashka wrote:
> > On Sun, 27 Jul 2014 23:25:21 +0200
> > Hans de Goede <hdegoede at redhat.com> wrote:
> > 
> > Which revision of A10-OLinuXino-LIME do you have? Revision A is known
> > to have troubles running stable at 1008MHz CPU clock speed, as confirmed
> > on a sample set of two boards (mine and Oliver Schinagl's):
> >     https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html
> 
> I have a revision A board.
> 
> > A bunch of revision C boards were all fine in Oliver's tests. And
> > nobody has ever tested revision B so far, so we have no idea whether
> > it is stable or not. A mysterious thing is that the Olimex
> > representatives on IRC were not aware of any fixes of this kind
> > applied to the PCB.
> > 
> > My understanding is that the revision A was just a small pre-production
> > batch, donated by OLIMEX to a number of open source developers. Some of
> > these boards were distributed at FOSDEM. I'm not sure if we should
> > really worry about the reliability of the revision A, because none of
> > the 'normal' customers probably have such boards. We only need to
> > clarify the status of revision B.
> > 
> > But if we want to support the revision A too, then it probably needs
> > its own config, which would somehow restrict the CPU clock speed.
> 
> My revision A was actually ordered normally, a couple of days before
> the first batch sold-out. So it is likely that the entire first batch
> was revision A.
> 
> Do you have any easy step-by-step document (or ready to use sdcard
> image to download) to do some stress tests on my revision A ?

The easy step-by-step document was there since the beginning of May:
    https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html

If you don't mind to download random binaries from the Internet, there
was also a link to the static djpeg binary if you are unsure about the
one used in your distro and don't want to waste time compiling
libjpeg-turbo yourself.

Also it looks like now we need to try a little bit harder with the
mainline kernel, so I have posted some updates in my reply to
Arnd Gronenberg:
    http://lists.denx.de/pipermail/u-boot/2014-September/190061.html

Taking all of this into account and with the use of the djpeg static
binary download, it's just a few lines to type in the console:


cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg
wget http://people.freedesktop.org/~siamashka/files/20140504/djpeg-static
chmod +x djpeg-static while true ; do ./djpeg-static A10-LIME.jpg |
md5sum ; done


If identical hashes show up in each line of the output, then everything
is fine. If some hashes end up to be different, then there is data
corruption happening during JPEG decoding, which indicates hardware
reliability issues.

> Maybe the first couple handed out to developers where hand soldered
> or some such ? Either way it would be good to either confirm that
> my revision A has the same issues, or not :)

My board looks fine (without any visible soldering problems). As
discussed months ago on the linux-sunxi mailing list, we are suspecting
that the root cause is some significant voltage drop on the dcdc2 power
line between the PMIC and the SoC. So that if the current is high
(under high CPU usage) then the SoC actually gets a substantially
reduced voltage compared to the requested 1.4V from the PMIC.

Newer revisions of the A10-Lime PCB might just have a beefier power
line with reduced resistance, but that's only a speculation.

By the way, it looks like the Banana Pi might suffer from the very
same problem. Somebody has just submitted a FEX file update (FEX serves
a similar purpose as DTS in the sunxi-3.4 kernel):
    https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg07629.html
The commit message only says "Fix the unstable problem caused by dvfs
table" without going into any details. The change that they are
introducing is in fact moving the highest cpufreq operating point from
"912MHz at 1.4V" to "912MHz at 1.425V". Supposedly to fix some
reliability problems reproduced on some undisclosed use case. Now if we
are trying to use the mainline kernel, then it does not have cpufreq
support and the CPU clock frequency/voltage settings are inherited
from u-boot. And u-boot currently configures them to, surprise
surprise, "912MHz at 1.4V" which is expected to be unstable according
to that FEX update submitter. This raises an obvious red flag.

The libjpeg-turbo decoding test appears to be sensitive to the CPU
clock frequency/voltage (at least for Cortex-A8), so somebody might
want to give it a try also on the Banana Pi. Or if the libjpeg-turbo
test does not reveal anything interesting, then we might want to ask
the Banana Pi FEX update submitter to find out how the reliability
problem is supposed to be reproduced.

-- 
Best regards,
Siarhei Siamashka