On Sun, 28 Sep 2014 17:58:41 +0200 Hans de Goede <hdego...@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 <hdego...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
