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

2014-09-29 Thread Arnd Gronenberg 


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.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  -

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

2014-09-28 Thread Hans de Goede 
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:
 
 Add support for boards which I own and which already have a dts file in the
 upstream kernel.
 
 Hi Hans,
 
 It's good to know that you have all this hardware and can take care of
 maintaining it.

With maintaining being the key word here, I don't have the time to
extensively test things on all these different boards, but I do have
them around to test things if some board specific issues pop up.

 
 Signed-off-by: Henrik Nordstrom hen...@henriknordstrom.net
 Signed-off-by: Stefan Roese s...@denx.de
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  board/sunxi/Makefile|  6 ++
  board/sunxi/dram_a10_olinuxino_l.c  | 31 +++
  board/sunxi/dram_sun4i_360_1024_iow16.c | 31 +++
  board/sunxi/dram_sun4i_360_1024_iow8.c  | 31 +++
  board/sunxi/dram_sun4i_360_512.c| 31 +++
  board/sunxi/dram_sun4i_384_1024_iow8.c  | 31 +++
  boards.cfg  |  6 ++
  7 files changed, 167 insertions(+)
  create mode 100644 board/sunxi/dram_a10_olinuxino_l.c
  create mode 100644 board/sunxi/dram_sun4i_360_1024_iow16.c
  create mode 100644 board/sunxi/dram_sun4i_360_1024_iow8.c
  create mode 100644 board/sunxi/dram_sun4i_360_512.c
  create mode 100644 board/sunxi/dram_sun4i_384_1024_iow8.c

 diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
 index 03f55cc..b1db5d9 100644
 --- a/board/sunxi/Makefile
 +++ b/board/sunxi/Makefile
 @@ -11,8 +11,14 @@
  obj-y   += board.o
  obj-$(CONFIG_SUNXI_GMAC)+= gmac.o
  obj-$(CONFIG_SUNXI_AHCI)+= ahci.o
 +obj-$(CONFIG_A10_OLINUXINO_L)   += dram_a10_olinuxino_l.o
 
 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 ?

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 :)


 
  obj-$(CONFIG_A13_OLINUXINOM)+= dram_a13_oli_micro.o
 +obj-$(CONFIG_BA10_TV_BOX)   += dram_sun4i_384_1024_iow8.o
  obj-$(CONFIG_CUBIEBOARD)+= dram_cubieboard.o
  obj-$(CONFIG_CUBIEBOARD2)   += dram_cubieboard2.o
  obj-$(CONFIG_CUBIETRUCK)+= dram_cubietruck.o
 +obj-$(CONFIG_MELE_A1000)+= dram_sun4i_360_512.o
 +obj-$(CONFIG_MELE_A1000G)   += dram_sun4i_360_1024_iow8.o
 +obj-$(CONFIG_MINI_X)+= dram_sun4i_360_512.o
 +obj-$(CONFIG_MINI_X_1GB)+= dram_sun4i_360_1024_iow16.o
  obj-$(CONFIG_R7DONGLE)  += dram_r7dongle.o
 diff --git a/board/sunxi/dram_a10_olinuxino_l.c 
 b/board/sunxi/dram_a10_olinuxino_l.c
 new file mode 100644
 index 000..24a1bd9
 --- /dev/null
 +++ b/board/sunxi/dram_a10_olinuxino_l.c
 @@ -0,0 +1,31 @@
 +/* this file is generated, don't edit it yourself */
 +
 +#include common.h
 +#include asm/arch/dram.h
 +
 +static struct dram_para dram_para = {
 +.clock = 480,
 +.type = 3,
 +.rank_num = 1,
 +.density = 4096,
 +.io_width = 16,
 +.bus_width = 16,
 +.cas = 6,
 
 The CAS=6 is not quite right for the 480MHz DRAM clock speed if we
 are dealing with the typical DDR3 chips, with the timings mostly
 representing the standard JEDEC speed bins.
 
 CAS=6 is good up to 400MHz. CAS=7 is good up to 533MHz. And CAS=9 is
 good up to 667MHz.
 
 +.zq = 123,
 +.odt_en = 0,
 +.size = 512,
 +.tpr0 = 0x30926692,
 +.tpr1 = 0x1090,
 +.tpr2 = 0x1a0c8,
 
 The .tpr0/.tpr1/.tpr2 settings here are simply using the default reset

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

2014-09-28 Thread Siarhei Siamashka 
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.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  -

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

2014-09-28 Thread Arnd Gronenberg 


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.

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 :-) ).


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%...

[...]

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.


Best regards, Arnd

--

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

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

2014-09-28 Thread Siarhei Siamashka 
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

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

2014-09-28 Thread Siarhei Siamashka 
On Mon, 29 Sep 2014 08:38:42 +0300
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:

 On Sun, 28 Sep 2014 17:58:41 +0200
 Hans de Goede hdego...@redhat.com wrote:
 
  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

Sorry, my e-mail client decided to unhelpfully reshuffle line breaks.
This was supped to be:

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

-- 
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

2014-09-18 Thread Siarhei Siamashka 
On Sun, 27 Jul 2014 23:25:21 +0200
Hans de Goede hdego...@redhat.com wrote:

 Add support for boards which I own and which already have a dts file in the
 upstream kernel.

Hi Hans,

It's good to know that you have all this hardware and can take care of
maintaining it.

 Signed-off-by: Henrik Nordstrom hen...@henriknordstrom.net
 Signed-off-by: Stefan Roese s...@denx.de
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  board/sunxi/Makefile|  6 ++
  board/sunxi/dram_a10_olinuxino_l.c  | 31 +++
  board/sunxi/dram_sun4i_360_1024_iow16.c | 31 +++
  board/sunxi/dram_sun4i_360_1024_iow8.c  | 31 +++
  board/sunxi/dram_sun4i_360_512.c| 31 +++
  board/sunxi/dram_sun4i_384_1024_iow8.c  | 31 +++
  boards.cfg  |  6 ++
  7 files changed, 167 insertions(+)
  create mode 100644 board/sunxi/dram_a10_olinuxino_l.c
  create mode 100644 board/sunxi/dram_sun4i_360_1024_iow16.c
  create mode 100644 board/sunxi/dram_sun4i_360_1024_iow8.c
  create mode 100644 board/sunxi/dram_sun4i_360_512.c
  create mode 100644 board/sunxi/dram_sun4i_384_1024_iow8.c
 
 diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
 index 03f55cc..b1db5d9 100644
 --- a/board/sunxi/Makefile
 +++ b/board/sunxi/Makefile
 @@ -11,8 +11,14 @@
  obj-y+= board.o
  obj-$(CONFIG_SUNXI_GMAC) += gmac.o
  obj-$(CONFIG_SUNXI_AHCI) += ahci.o
 +obj-$(CONFIG_A10_OLINUXINO_L)+= dram_a10_olinuxino_l.o

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

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.

  obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o
 +obj-$(CONFIG_BA10_TV_BOX)+= dram_sun4i_384_1024_iow8.o
  obj-$(CONFIG_CUBIEBOARD) += dram_cubieboard.o
  obj-$(CONFIG_CUBIEBOARD2)+= dram_cubieboard2.o
  obj-$(CONFIG_CUBIETRUCK) += dram_cubietruck.o
 +obj-$(CONFIG_MELE_A1000) += dram_sun4i_360_512.o
 +obj-$(CONFIG_MELE_A1000G)+= dram_sun4i_360_1024_iow8.o
 +obj-$(CONFIG_MINI_X) += dram_sun4i_360_512.o
 +obj-$(CONFIG_MINI_X_1GB) += dram_sun4i_360_1024_iow16.o
  obj-$(CONFIG_R7DONGLE)   += dram_r7dongle.o
 diff --git a/board/sunxi/dram_a10_olinuxino_l.c 
 b/board/sunxi/dram_a10_olinuxino_l.c
 new file mode 100644
 index 000..24a1bd9
 --- /dev/null
 +++ b/board/sunxi/dram_a10_olinuxino_l.c
 @@ -0,0 +1,31 @@
 +/* this file is generated, don't edit it yourself */
 +
 +#include common.h
 +#include asm/arch/dram.h
 +
 +static struct dram_para dram_para = {
 + .clock = 480,
 + .type = 3,
 + .rank_num = 1,
 + .density = 4096,
 + .io_width = 16,
 + .bus_width = 16,
 + .cas = 6,

The CAS=6 is not quite right for the 480MHz DRAM clock speed if we
are dealing with the typical DDR3 chips, with the timings mostly
representing the standard JEDEC speed bins.

CAS=6 is good up to 400MHz. CAS=7 is good up to 533MHz. And CAS=9 is
good up to 667MHz.

 + .zq = 123,
 + .odt_en = 0,
 + .size = 512,
 + .tpr0 = 0x30926692,
 + .tpr1 = 0x1090,
 + .tpr2 = 0x1a0c8,

The .tpr0/.tpr1/.tpr2 settings here are simply using the default reset
values of the DRAM controller hardware registers. Which happen to
match the DDR2-800E speed bin, as identified by Jens Kuske:
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg03548.html

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 fundamental problem here is that u-boot-sunxi essentially trusted
the device manufacturers to pick the correct DRAM settings. However
it looks like the device manufacturers did not have any proper DRAM
documentation either. And they just ended up picking some random
settings, which seemed to kinda work (and then copy/pasted these
settings from one device to another with minor variation). Also
without doubt, they were all under a