On 09/29/2014 12:09 AM, Siarhei Siamashka wrote:
On Sun, 28 Sep 2014 21:34:57 +0200 Arnd Gronenberg <a...@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.htmlI 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.
Well... I should thank this community for all the work on Allwinner support :-)Thanks again. And sorry for asking you to do a little bit more work for additional confirmation.
As mentioned above, I'll compile a current 3.4 kernel and try lima-memtester on my A10 OLinuXino LIME later today.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.
-- Arnd Gronenberg, a...@gronenberg.com, DJ9PZ / AB2QP
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
