[U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
Siarhei Siamashka
siarhei.siamashka at gmail.com
Mon Sep 29 00:09:55 CEST 2014
On Sun, 28 Sep 2014 21:34:57 +0200
Arnd Gronenberg <arnd at gronenberg.com> wrote:
>
> On 09/28/2014 05:58 PM, Hans de Goede wrote:
> > [...]
> >
> > On 09/18/2014 06:07 PM, Siarhei Siamashka 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.
>
> My Olimex A10 OLinuXino Lime is also labelled "Rev. A"... It is running
> stable at 1008MHz and I just tried Olivers djpeg test without any problems.
>
> I'm running Hans' u-boot-sunxi 2014.10-rc1-g7190869 and Linux mainline
> 3.17.0-rc1-00158-g451fd72.
Thanks for trying the test and sharing the results. You are extending
our sample set from 2 boards to 3 (by the whole 50%) :-)
But could you please check whether you really have libjpeg-turbo
(with NEON optimizations) and not libjpeg from IJG? I did mention
libjpeg-turbo a few times in my original e-mail, however somehow failed
to communicate that it is strictly required to reproduce the problem.
Sorry about this. One of the commenters in the old discussion thread
already fell into this trap :-( Later I provided a script for automating
everything by using a ruby script. The script performs downloading and
compiling the "right" libjpeg-turbo and then runs tests for all cpufreq
operating points. But since the mainline kernel does not have cpufreq
support yet, this script will not help us here (and is not really
needed).
Anyway, please check whether you have libjpeg-turbo by running
"djpeg -v" command. If your distro happens to have IJG libjpeg instead
of libjpeg-turbo, then you can download and compile libjpeg-turbo from
sources (it is quite a small package and does not require any
dependencies). After that, you can run the test as demonstrated in
the examples below.
My results from A10-Lime revision A with the sunxi-3.4 kernel and
u-boot v2014.10-rc2:
$ djpeg -v
libjpeg-turbo version 1.3.0 (build 20130811)
$ cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg
$ while true ; do djpeg A10-LIME.jpg | md5sum ; done
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
6047ca65e1412dd3f53b250239e4558b -
bf66d2bd1a88c5720b0dc8d8ece43099 -
9d8eb11018cca04f70883c6ed9ddb9c6 -
7d2a4baa11e7015e2b8ae5717fce699b -
513bd48bcd3a67705324ec8658646e7d -
f61c7c8f42b86ede28d48dfb350efd64 -
50a3b1ea14994d19a66238f2414d9f5c -
674f968fe8d7c79b2f7116c94b2fb02c -
bf66d2bd1a88c5720b0dc8d8ece43099 -
b57efa7bb81263a93f69fcbbbd06d590 -
d1627d8fd02f54e0154fcced72be637b -
ab92721819073d0fb4dd2a7a67afb0fc -
79cf9706c29c19b9325d3e04f34b5059 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
9ba81185fd5ed48277cc590fdb323955 -
d43cdb0215bae6de33b7921b20c5545f -
d1ef0584fdff38c84a7d24a32fde4de9 -
1cef1e0202605a93870279f23d93287f -
f7fd0ae6b3beda26f61c2be566224ac3 -
c346e833833f9b35093be336cadbcbc2 -
02c6e7e19882f438e5a9123a0d3e7ea2 -
b9d788d94a469b3bad20a997a039ce88 -
8545180d6384a6319fbf672052d61549 -
455b8da5c39b21b5104c12b6d02e9ff8 -
670df0c3bf6becf5e4378e336d193f45 -
07e922c9510d9d75f701317ada24d1f9 -
8cdae0aa48061da5c45ac81159bdac53 -
4f3b47ad5603f7253c0a4b13a61987a5 -
02f6175d5fb8672e69c7e433451b5dbc -
1440adb6576c6d02cf05c31b3c2c2b7c -
618a736628096581dfd2d5421e061235 -
2a791022a39f7e8d57efa50cd801007b -
44d2e8dd4a205d3aadcfc25a446fe06e -
72e2d96eb5e0ea987763cfaa1f3ca0a5 -
4f4c11e23f09f2923f925e6bb0a88deb -
f6ce3826e0e91ca75fbca378f21a6a72 -
6d2c6ac6eb8c96cad5b19e3287192802 -
8db6a3c5fb031317eb352110261e23fd -
And results with the mainline kernel and u-boot v2014.10-rc2:
$ djpeg -v
libjpeg-turbo version 1.3.0 (build 20130811)
$ cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg
$ while true ; do djpeg A10-LIME.jpg | md5sum ; done
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
ee013e5796bbfed7dcae4b7bae195fd7 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
b4303763c2e1f4f6e47f85a18e310ee4 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
871133f440be61b966974908552d50c5 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
ab958001b12fbb6f893a2f49ecb81806 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
bf66d2bd1a88c5720b0dc8d8ece43099 -
ba88dffa992908c37dc7be23ffaf7f4e -
e040c99fbeaf8a2f12b3a72fc867a9fb -
bf66d2bd1a88c5720b0dc8d8ece43099 -
It looks like the problem is actually somewhat more difficult to
reproduce with the mainline kernel. Maybe the L2 cache latency tweaks
from the sunxi-3.4 kernel affect something after all?
https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-v3.4.86-r0/arch/arm/mm/proc-v7.S#L248
Or maybe there is some other place in the sunxi-3.4 kernel with
similar tweaks, which I have overlooked? Also the problem may
be additionally CPU temperature dependent and more likely to show
up after running longer.
In any case, please keep it running for a while (maybe 100-1000
rounds) to see if you eventually get at least one corrupted JPEG
decoding result.
Thanks again. And sorry for asking you to do a little bit more work for
additional confirmation.
If anyone else has A10-Lime board revision A or B, feel free to
report your results too. And the final reminder just in case:
using specifically the NEON optimized libjpeg-turbo package is
really important!
> >> 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.
> >> I also ha
> > 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 ?
> >
> > 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 :)
> I bought my revision A from a German distributor (exp-tech.de) and it
> doesn't look hand soldered (except for the through hole parts :-) ).
So some number of revision A boards actually got into the hands of
"normal" people. That's good to know.
> If I correctly compared the schematics for revision A,B and C, there is
> only one change in regard to the DRAM: R8 (connected to ZQ) has a
> different value:
> - Revision A: 237 Ohm / 1%
> - Revision B: 430 Ohm / 1%
> - Revision C: 330 Ohm / 1%
>
> I checked R8 on my revision A's PCB: It is a 330 Ohm / 1%, therefore the
> value specified in the revision C schematic. So it may make sense to
> check R8 on the problematic revision A boards and replace it by a 330
> Ohm resistor. The DRAM data sheet specifies this resistor with 240 Ohm /
> 1%...
Yes, the ever changing RZQ resistor nominals in different revisions
of OLIMEX boards is a major PITA for us if we want to try finding
optimal DRAM configuration. Because we can't rely on having the
same ZQ calibration results on different revisions of OLIMEX boards,
fine tuning the 'zq'/'odt_en'/'emr1' parameters in the 'dram_para'
struct is problematic :-(
But this is a separate problem, which is very likely not directly
related to the data corruption in libjpeg-turbo. In the case
of libjpeg-turbo, the data corruption shows up when overclocking
the CPU. AFAIK, all A10 boards (not just A10-Lime) fail this test
with the processors overclocked to 1.2GHz and the unmodified
voltage in the sunxi-3.4 cpufreq table. This makes the CPU and
CPU caches the primary culprits instead of DRAM.
> >> [...]
> >>
> >> Either way, these settings are outside of the valid range when running
> >> at 480MHz (which would be something like DDR3-960 in our case).
> >>
> >> [...]
> The current (probably incorrect) values work fine with my board (even
> though they may be out of spec), but the value of R8 may have some
> impact here.
To get a bit more confidence that they really work fine and are not
just borderline unstable, you can compile and run
https://github.com/ssvb/lima-memtester/
with the sunxi-3.4 kernel.
Unfortunately we don't have any git branch with the mali kernel driver
patch applied to the mainline kernel yet, and this introduces some
inconveniences. If anyone needs some assistance compiling the sunxi-3.4
kernel and booting it with u-boot v2014.10, please drop me a line.
PS. I don't expect any major problems here, because I had run this
test myself on my A10-Lime board. But having more confirmations is
always useful.
--
Best regards,
Siarhei Siamashka
More information about the U-Boot
mailing list