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

Arnd Gronenberg arnd at gronenberg.com
Mon Sep 29 10:31:45 CEST 2014


On 09/29/2014 12:09 AM, Siarhei Siamashka wrote:
> 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.
Output from djpeg -v
:
libjpeg-turbo version 1.3.1 (build 20140403)
Copyright (C) 1991-2012 Thomas G. Lane, Guido Vollbeding
Copyright (C) 1999-2006 MIYASAKA Masaru
Copyright (C) 2009 Pierre Ossman for Cendio AB
Copyright (C) 2009-2014 D. R. Commander
Copyright (C) 2009-2011 Nokia Corporation and/or its subsidiary(-ies)

Emulating The Independent JPEG Group's software, version 8d 15-Jan-2012

>
> 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.
I did it 1000 times (on mainline):
~/tmp> (for ((i=1;i<=1000;i++));do djpeg A10-LIME.jpg | md5sum ; done) > 
test.out
~/tmp> uniq test.out
bf66d2bd1a88c5720b0dc8d8ece43099  -
~/tmp>

I'll compile the current 3.4 kernel and test again later.
>
> Thanks again. And sorry for asking you to do a little bit more work for
> additional confirmation.
Well... I should thank this community for all the work on Allwinner 
support :-)
>
> 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!
>
>>> [...] 
>> 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.
>
As mentioned above, I'll compile a current 3.4 kernel and try 
lima-memtester on my A10 OLinuXino LIME later today.

-- 

Arnd Gronenberg, arnd at gronenberg.com, DJ9PZ / AB2QP


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2396 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140929/e7450319/attachment.bin>


More information about the U-Boot mailing list