From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Gronenberg Date: Mon, 29 Sep 2014 10:31:45 +0200 Subject: [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards In-Reply-To: <20140929010955.1b6c8c2b@i7> References: <1406496323-13093-1-git-send-email-hdegoede@redhat.com> <1406496323-13093-5-git-send-email-hdegoede@redhat.com> <20140918190753.14734b9b@i7> <54283031.5080700@redhat.com> <542862E1.50908@gronenberg.com> <20140929010955.1b6c8c2b@i7> Message-ID: <542918F1.7020500@gronenberg.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09/29/2014 12:09 AM, Siarhei Siamashka wrote: > On Sun, 28 Sep 2014 21:34:57 +0200 > Arnd Gronenberg 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 at 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: