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

[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 <hdegoede at 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 <henrik at henriknordstrom.net>
>> Signed-off-by: Stefan Roese <sr at denx.de>
>> Signed-off-by: Hans de Goede <hdegoede at 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 0000000..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 heavy time-to-market pressure.
> 
> Now this patch is just taking these obviously incorrect settings and
> putting them into the mainline u-boot. Sure, these settings can't be
> completely unreliable, because they are used in production on a huge
> number of commercially sold devices. The DRAM controller and the DDR3
> chips have some safety headroom in practice and may tolerate a bit of
> abuse before failing. However all these settings have to be eventually
> formally validated in some way (ensure that the supported boards at
> least do not obviously fail the https://github.com/ssvb/lima-memtester
> test). And IMHO this preferably should be done before the v2014.10
> release.

I don't think we will have time to fix these for v2014.10, regardless
I don't think that validating is a real option, since we have to small
a sample of each board to do anything statistically meaningful, and
most of us also don't have the time to run many tests either.

So I think that the best way forward with this, is now that we know
what the all the magic values actually do, to tweak the settings
to be inside the relevant DRAM specs for the speed we're operating the
RAM at on each board. AFAIK making things (somewhat) slower should
always be safe / not lead to regressions, so this seems like the
safe thing to do.

Regards,

Hans