[U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings

[U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings

[Hans de Goede]

Specific USB EHCI settings to be set for sun4i if CONFIG_USB_EHCI is enabled.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 include/configs/sun4i.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h
index 037f995..5611ecc 100644
--- a/include/configs/sun4i.h
+++ b/include/configs/sun4i.h
@@ -16,6 +16,18 @@
 
 #define CONFIG_SYS_PROMPT		"sun4i# "
 
+#ifdef CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_SUNXI
+
+#define CONFIG_USB_MAX_CONTROLLER_COUNT	2
+#ifndef CONFIG_SUNXI_USB_VBUS0_GPIO
+#define CONFIG_SUNXI_USB_VBUS0_GPIO	SUNXI_GPH(6)
+#endif
+#ifndef CONFIG_SUNXI_USB_VBUS1_GPIO
+#define CONFIG_SUNXI_USB_VBUS1_GPIO	SUNXI_GPH(3)
+#endif
+#endif
+
 /*
  * Include common sunxi configuration where most the settings are
  */
-- 
2.0.1

[U-Boot] [PATCH 2/7] sun5i: add USB EHCI settings

[Hans de Goede]

Specific USB EHCI settings to be set for sun5i if CONFIG_USB_EHCI is enabled.

Note we don't specify default VBUS gpio pins for sun5i since they vary too
much from board to board.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 include/configs/sun5i.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h
index c6138b7..6066371 100644
--- a/include/configs/sun5i.h
+++ b/include/configs/sun5i.h
@@ -16,6 +16,11 @@
 
 #define CONFIG_SYS_PROMPT		"sun5i# "
 
+#ifdef CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_SUNXI
+#define CONFIG_USB_MAX_CONTROLLER_COUNT	1
+#endif
+
 /*
  * Include common sunxi configuration where most the settings are
  */
-- 
2.0.1

[U-Boot] [PATCH 2/7] sun5i: add USB EHCI settings

[Ian Campbell]

On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
> Specific USB EHCI settings to be set for sun5i if CONFIG_USB_EHCI is enabled.
> 
> Note we don't specify default VBUS gpio pins for sun5i since they vary too
> much from board to board.

It seems to be just random chance (or more likely, copying of reference
designs?) which makes sun[^5]i more consistent, is that right?

> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Ian Campbell <ijc@hellion.org.uk>

[U-Boot] [PATCH 2/7] sun5i: add USB EHCI settings

[Hans de Goede]

Hi,

On 07/28/2014 09:42 AM, Ian Campbell wrote:
> On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
>> Specific USB EHCI settings to be set for sun5i if CONFIG_USB_EHCI is enabled.
>>
>> Note we don't specify default VBUS gpio pins for sun5i since they vary too
>> much from board to board.
> 
> It seems to be just random chance (or more likely, copying of reference
> designs?) which makes sun[^5]i more consistent, is that right?

Right, on sun4i and sun7i almost all boards use the pins from the reference
design.

> 
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> Acked-by: Ian Campbell <ijc@hellion.org.uk>

Regards,

Hans

[U-Boot] [PATCH 3/7] sunxi: Enable EHCI on various sunxi boards

[Hans de Goede]

Most sunxi boards have the EHCI controller hooked up, enable it on all
relevant boards.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 boards.cfg | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index f88eac0..48172eb 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -377,13 +377,13 @@ Active  arm         armv7          rmobile     renesas         lager
 Active  arm         armv7          s5pc1xx     samsung         goni                s5p_goni                              -                                                                                                                                 Robert Baldyga <r.baldyga@samsung.com>
 Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                              -                                                                                                                                 Minkyu Kang <mk7.kang@samsung.com>
 Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                      -                                                                                                                                 -
-Active  arm         armv7          sunxi       -               sunxi               A13-OLinuXinoM                        sun5i:A13_OLINUXINOM,SPL,CONS_INDEX=2                                                                                             Hans de Goede <hdegoede@redhat.com>
-Active  arm         armv7          sunxi       -               sunxi               Cubieboard                            sun4i:CUBIEBOARD,SPL,AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPB(8)                                                            Hans de Goede <hdegoede@redhat.com>
-Active  arm         armv7          sunxi       -               sunxi               Cubieboard2                           sun7i:CUBIEBOARD2,SPL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8)                                                           Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
-Active  arm         armv7          sunxi       -               sunxi               Cubieboard2_FEL                       sun7i:CUBIEBOARD2,SPL_FEL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8)                                                       Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               A13-OLinuXinoM                        sun5i:A13_OLINUXINOM,SPL,CONS_INDEX=2,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11)                                                 Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               Cubieboard                            sun4i:CUBIEBOARD,SPL,AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                                   Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               Cubieboard2                           sun7i:CUBIEBOARD2,SPL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                                  Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               Cubieboard2_FEL                       sun7i:CUBIEBOARD2,SPL_FEL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                              Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubietruck                            sun7i:CUBIETRUCK,SPL,AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(12),USB_EHCI                                            Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubietruck_FEL                        sun7i:CUBIETRUCK,SPL_FEL,AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(12),USB_EHCI                                        Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
-Active  arm         armv7          sunxi       -               sunxi               r7-tv-dongle                          sun5i:R7DONGLE,SPL,AXP152_POWER                                                                                                   Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               r7-tv-dongle                          sun5i:R7DONGLE,SPL,AXP152_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(13)                                                       Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          u8500       st-ericsson     snowball            snowball                              -                                                                                                                                 Mathieu Poirier <mathieu.poirier@linaro.org>
 Active  arm         armv7          u8500       st-ericsson     u8500               u8500_href                            -                                                                                                                                 -
 Active  arm         armv7          vf610       freescale       vf610twr            vf610twr                              vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg                                                                         Alison Wang <b18965@freescale.com>
-- 
2.0.1

[U-Boot] [PATCH 3/7] sunxi: Enable EHCI on various sunxi boards

[Ian Campbell]

On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
> Most sunxi boards have the EHCI controller hooked up, enable it on all
> relevant boards.

The switch to Kconfig can't come soon enough IMHO...

> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Ian Campbell <ijc@hellion.org.uk>

[U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option

[Hans de Goede]

On some boards the phy needs to be powered up through a gpio, add support for
this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 arch/arm/cpu/armv7/sunxi/board.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 8f2cef3..f2cedbb 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -129,6 +129,11 @@ int cpu_eth_init(bd_t *bis)
 {
 	__maybe_unused int rc;
 
+#ifdef CONFIG_MACPWR
+	gpio_direction_output(CONFIG_MACPWR, 1);
+	mdelay(200);
+#endif
+
 #ifdef CONFIG_SUNXI_EMAC
 	rc = sunxi_emac_initialize(bis);
 	if (rc < 0) {
-- 
2.0.1

[U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option

[Ian Campbell]

On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
> On some boards the phy needs to be powered up through a gpio, add support for
> this.

I assume from the context that this is the Ethernet PHY?

I'm a bit surprised there isn't some sort of de facto existing naming
etc for something like this, but if there is my grep's aren't finding it
so:
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Ian Campbell <ijc@hellion.org.uk>

[U-Boot] [linux-sunxi] Re: [PATCH 4/7] sunxi: Add CONFIG_MACPWR option

[Chen-Yu Tsai]

On Mon, Jul 28, 2014 at 3:48 PM, Ian Campbell <ijc@hellion.org.uk> wrote:
> On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
>> On some boards the phy needs to be powered up through a gpio, add support for
>> this.
>
> I assume from the context that this is the Ethernet PHY?
>
> I'm a bit surprised there isn't some sort of de facto existing naming
> etc for something like this, but if there is my grep's aren't finding it
> so:

My guess would be most other platforms have separate board files
for each board they support, instead of our mixed approach.

They can just put whatever GPIO poking stuff in them under one of the
standard weak symbols.

>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Acked-by: Ian Campbell <ijc@hellion.org.uk>

[U-Boot] [linux-sunxi] Re: [PATCH 4/7] sunxi: Add CONFIG_MACPWR option

[Ian Campbell]

On Mon, 2014-07-28 at 15:51 +0800, Chen-Yu Tsai wrote:
> On Mon, Jul 28, 2014 at 3:48 PM, Ian Campbell <ijc@hellion.org.uk> wrote:
> > On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
> >> On some boards the phy needs to be powered up through a gpio, add support for
> >> this.
> >
> > I assume from the context that this is the Ethernet PHY?
> >
> > I'm a bit surprised there isn't some sort of de facto existing naming
> > etc for something like this, but if there is my grep's aren't finding it
> > so:
> 
> My guess would be most other platforms have separate board files
> for each board they support, instead of our mixed approach.
> 
> They can just put whatever GPIO poking stuff in them under one of the
> standard weak symbols.

Yes, that sounds very plausible.

> 
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >
> > Acked-by: Ian Campbell <ijc@hellion.org.uk>
> 

[U-Boot] [linux-sunxi] Re: [PATCH 4/7] sunxi: Add CONFIG_MACPWR option

[Hans de Goede]

Hi,

On 07/28/2014 09:48 AM, Ian Campbell wrote:
> On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
>> On some boards the phy needs to be powered up through a gpio, add support for
>> this.
> 
> I assume from the context that this is the Ethernet PHY?

Yes, I'll amend the commit msg before pushing.

> 
> I'm a bit surprised there isn't some sort of de facto existing naming
> etc for something like this, but if there is my grep's aren't finding it
> so:
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> Acked-by: Ian Campbell <ijc@hellion.org.uk>

Regards,

Hans

[U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option

[thomas.langer at lantiq.com]

Hello Hans,

Hans de Goede wrote on?2014-07-27:
> On some boards the phy needs to be powered up through a gpio, add
> support for this.
> 

> @@ -129,6 +129,11 @@ int cpu_eth_init(bd_t *bis)
>  {
>  	__maybe_unused int rc;
> +#ifdef CONFIG_MACPWR

If this is powering a phy, maybe CONFIG_PHYPWR or similar is a better name?
Because PHY and MAC are different things!
And maybe adding GPIO to the name to indicate that the value is a GPIO number?

All of these should be part of the description in the README,
which each CONFIG_ option requires.

> +	gpio_direction_output(CONFIG_MACPWR, 1);
> +	mdelay(200);
> +#endif
> +
>  #ifdef CONFIG_SUNXI_EMAC
>  	rc = sunxi_emac_initialize(bis);
>  	if (rc < 0) {

Best Regards,
Thomas
---
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
---

[U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option

[Hans de Goede]

Hi,

On 07/28/2014 10:09 AM, thomas.langer at lantiq.com wrote:
> Hello Hans,
> 
> Hans de Goede wrote on 2014-07-27:
>> On some boards the phy needs to be powered up through a gpio, add
>> support for this.
>>
> 
>> @@ -129,6 +129,11 @@ int cpu_eth_init(bd_t *bis)
>>  {
>>  	__maybe_unused int rc;
>> +#ifdef CONFIG_MACPWR
> 
> If this is powering a phy, maybe CONFIG_PHYPWR or similar is a better name?
> Because PHY and MAC are different things!

True, but there can be many kinds of PHYs usb phys, ahci phys,
ethernet phys, etc.

> And maybe adding GPIO to the name to indicate that the value is a GPIO number?

The current name mirrors the AHCIPWR setting we already for ahci
support on sinxi boards.

> All of these should be part of the description in the README,
> which each CONFIG_ option requires.

That is a good point. We've not documented any of the sunxi specific
options as of yet. Since we've quite a few I think it
might be better to add a new doc/README.sunxi file for this. I've
put creating such a file on my todo list.

Regards,

Hans

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

[Hans de Goede]

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

Signed-off-by: Henrik Nordstrom <henrik@henriknordstrom.net>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Hans de Goede <hdegoede@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
 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,
+	.zq = 123,
+	.odt_en = 0,
+	.size = 512,
+	.tpr0 = 0x30926692,
+	.tpr1 = 0x1090,
+	.tpr2 = 0x1a0c8,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0x4,
+	.emr2 = 0,
+	.emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/board/sunxi/dram_sun4i_360_1024_iow16.c b/board/sunxi/dram_sun4i_360_1024_iow16.c
new file mode 100644
index 0000000..3763713
--- /dev/null
+++ b/board/sunxi/dram_sun4i_360_1024_iow16.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 = 360,
+	.type = 3,
+	.rank_num = 1,
+	.density = 4096,
+	.io_width = 16,
+	.bus_width = 32,
+	.cas = 6,
+	.zq = 123,
+	.odt_en = 0,
+	.size = 1024,
+	.tpr0 = 0x30926692,
+	.tpr1 = 0x1090,
+	.tpr2 = 0x1a0c8,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0,
+	.emr2 = 0,
+	.emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/board/sunxi/dram_sun4i_360_1024_iow8.c b/board/sunxi/dram_sun4i_360_1024_iow8.c
new file mode 100644
index 0000000..2a5c9ed
--- /dev/null
+++ b/board/sunxi/dram_sun4i_360_1024_iow8.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 = 360,
+	.type = 3,
+	.rank_num = 1,
+	.density = 2048,
+	.io_width = 8,
+	.bus_width = 32,
+	.cas = 6,
+	.zq = 123,
+	.odt_en = 0,
+	.size = 1024,
+	.tpr0 = 0x30926692,
+	.tpr1 = 0x1090,
+	.tpr2 = 0x1a0c8,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0,
+	.emr2 = 0,
+	.emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/board/sunxi/dram_sun4i_360_512.c b/board/sunxi/dram_sun4i_360_512.c
new file mode 100644
index 0000000..48aa6e2
--- /dev/null
+++ b/board/sunxi/dram_sun4i_360_512.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 = 360,
+	.type = 3,
+	.rank_num = 1,
+	.density = 2048,
+	.io_width = 16,
+	.bus_width = 32,
+	.cas = 6,
+	.zq = 123,
+	.odt_en = 0,
+	.size = 512,
+	.tpr0 = 0x30926692,
+	.tpr1 = 0x1090,
+	.tpr2 = 0x1a0c8,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0,
+	.emr2 = 0,
+	.emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/board/sunxi/dram_sun4i_384_1024_iow8.c b/board/sunxi/dram_sun4i_384_1024_iow8.c
new file mode 100644
index 0000000..b0fcc55
--- /dev/null
+++ b/board/sunxi/dram_sun4i_384_1024_iow8.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 = 384,
+	.type = 3,
+	.rank_num = 1,
+	.density = 2048,
+	.io_width = 8,
+	.bus_width = 32,
+	.cas = 6,
+	.zq = 123,
+	.odt_en = 0,
+	.size = 1024,
+	.tpr0 = 0x30926692,
+	.tpr1 = 0x1090,
+	.tpr2 = 0x1a0c8,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0x4,
+	.emr2 = 0,
+	.emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index 48172eb..8289c3c 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -377,12 +377,18 @@ Active  arm         armv7          rmobile     renesas         lager
 Active  arm         armv7          s5pc1xx     samsung         goni                s5p_goni                              -                                                                                                                                 Robert Baldyga <r.baldyga@samsung.com>
 Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                              -                                                                                                                                 Minkyu Kang <mk7.kang@samsung.com>
 Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                      -                                                                                                                                 -
+Active  arm         armv7          sunxi       -               sunxi               A10-OLinuXino-Lime                    sun4i:A10_OLINUXINO_L,SPL,AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI                                              Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               A13-OLinuXinoM                        sun5i:A13_OLINUXINOM,SPL,CONS_INDEX=2,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11)                                                 Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               ba10_tv_box                           sun4i:BA10_TV_BOX,SPL,AXP209_POWER,SUNXI_EMAC,USB_EHCI,SUNXI_USB_VBUS1_GPIO=SUNXI_GPH(12)                                         Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubieboard                            sun4i:CUBIEBOARD,SPL,AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                                   Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubieboard2                           sun7i:CUBIEBOARD2,SPL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                                  Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubieboard2_FEL                       sun7i:CUBIEBOARD2,SPL_FEL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                              Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubietruck                            sun7i:CUBIETRUCK,SPL,AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(12),USB_EHCI                                            Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubietruck_FEL                        sun7i:CUBIETRUCK,SPL_FEL,AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(12),USB_EHCI                                        Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               Mele_A1000                            sun4i:MELE_A1000,SPL,AXP209_POWER,SUNXI_EMAC,MACPWR=SUNXI_GPH(15),AHCI,USB_EHCI                                                   Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               Mele_A1000G                           sun4i:MELE_A1000G,SPL,AXP209_POWER,SUNXI_EMAC,MACPWR=SUNXI_GPH(15),AHCI,USB_EHCI                                                  Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               Mini-X                                sun4i:MINI_X,SPL,AXP209_POWER,USB_EHCI                                                                                            Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               Mini-X-1Gb                            sun4i:MINI_X_1GB,SPL,AXP209_POWER,USB_EHCI                                                                                        Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               r7-tv-dongle                          sun5i:R7DONGLE,SPL,AXP152_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(13)                                                       Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          u8500       st-ericsson     snowball            snowball                              -                                                                                                                                 Mathieu Poirier <mathieu.poirier@linaro.org>
 Active  arm         armv7          u8500       st-ericsson     u8500               u8500_href                            -                                                                                                                                 -
-- 
2.0.1

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

[Ian Campbell]

On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
> Add support for boards which I own and which already have a dts file in the
> upstream kernel.

Between this and the next two patches are we missing any which have a
kernel dts? (Just OOI)

I don't think this conflicts with the DRAM reworking either textually or
in practical terms any more than the existing set of boards so I don't
see a reason to hold off on this.

> Signed-off-by: Henrik Nordstrom <henrik@henriknordstrom.net>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Ian Campbell <ijc@hellion.org.uk>

And you can apply that to the sun[57]i patches too.

I assume you will merge into #next when you are ready.

Ian.

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

[Hans de Goede]

Hi,

On 07/28/2014 09:54 AM, Ian Campbell wrote:
> On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
>> Add support for boards which I own and which already have a dts file in the
>> upstream kernel.
> 
> Between this and the next two patches are we missing any which have a
> kernel dts? (Just OOI)

We are missing the following 2 A10 boards:

1) The hackberry: https://www.miniand.com/products/Hackberry%20A10%20Developer%20Board
2) The "INet-97F Rev 02" generic no-name tablet:
   http://linux-sunxi.org/Inet_97f

I've not added those because I lack the hardware to test those.

> I don't think this conflicts with the DRAM reworking either textually or
> in practical terms any more than the existing set of boards so I don't
> see a reason to hold off on this.

Right, I've also checked that non of the added boards use odt_en = 1, as
that would potentially be a problem.

Note that the hackberry does use odt_en = 1, and there are several
reports of the hackberry being unreliable when using the linux-sunxi
u-boot, so chances are it would be better to disable it on the
hackberry too.

> 
>> Signed-off-by: Henrik Nordstrom <henrik@henriknordstrom.net>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> Acked-by: Ian Campbell <ijc@hellion.org.uk>
> 
> And you can apply that to the sun[57]i patches too.
> 
> I assume you will merge into #next when you are ready.

I've just pushed this to #next, and moved the patches to
accepted in patchwork, thanks for the quick review!

Regards,

Hans

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

[Ian Campbell]

On Mon, 2014-07-28 at 10:46 +0200, Hans de Goede wrote:
> Hi,
> 
> On 07/28/2014 09:54 AM, Ian Campbell wrote:
> > On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
> >> Add support for boards which I own and which already have a dts file in the
> >> upstream kernel.
> > 
> > Between this and the next two patches are we missing any which have a
> > kernel dts? (Just OOI)
> 
> We are missing the following 2 A10 boards:
> 
> 1) The hackberry: https://www.miniand.com/products/Hackberry%20A10%20Developer%20Board
> 2) The "INet-97F Rev 02" generic no-name tablet:
>    http://linux-sunxi.org/Inet_97f
> 
> I've not added those because I lack the hardware to test those.

I think that is the best approach.

> > I don't think this conflicts with the DRAM reworking either textually or
> > in practical terms any more than the existing set of boards so I don't
> > see a reason to hold off on this.
> 
> Right, I've also checked that non of the added boards use odt_en = 1, as
> that would potentially be a problem.
> 
> Note that the hackberry does use odt_en = 1, and there are several
> reports of the hackberry being unreliable when using the linux-sunxi
> u-boot, so chances are it would be better to disable it on the
> hackberry too.

Or to delay adding the hackberry until the new dram stuff is in place.

> >> Signed-off-by: Henrik Nordstrom <henrik@henriknordstrom.net>
> >> Signed-off-by: Stefan Roese <sr@denx.de>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > 
> > Acked-by: Ian Campbell <ijc@hellion.org.uk>
> > 
> > And you can apply that to the sun[57]i patches too.
> > 
> > I assume you will merge into #next when you are ready.
> 
> I've just pushed this to #next, and moved the patches to
> accepted in patchwork, thanks for the quick review!

Great.

Cheers,
Ian

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

[Siarhei Siamashka]

On Sun, 27 Jul 2014 23:25:21 +0200
Hans de Goede <hdegoede@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 <henrik@henriknordstrom.net>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Hans de Goede <hdegoede@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 at 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 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 at 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.

-- 
Best regards,
Siarhei Siamashka

[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@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@henriknordstrom.net>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> Signed-off-by: Hans de Goede <hdegoede@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 at 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 at 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

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

[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 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.
>> 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, 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/20140928/09c2d278/attachment.bin>

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

[Siarhei Siamashka]

On Sun, 28 Sep 2014 21:34:57 +0200
Arnd Gronenberg <arnd@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 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.

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.

Thanks again. And sorry for asking you to do a little bit more work for
additional confirmation.

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!

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

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.

-- 
Best regards,
Siarhei Siamashka

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

[Arnd Gronenberg]

On 09/29/2014 12:09 AM, Siarhei Siamashka wrote:
> On Sun, 28 Sep 2014 21:34:57 +0200
> Arnd Gronenberg <arnd@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 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: <http://lists.denx.de/pipermail/u-boot/attachments/20140929/e7450319/attachment.bin>

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

[Siarhei Siamashka]

On Sun, 28 Sep 2014 17:58:41 +0200
Hans de Goede <hdegoede@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 <hdegoede@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 at 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 at 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 at 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] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards

[Siarhei Siamashka]

On Mon, 29 Sep 2014 08:38:42 +0300
Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:

> On Sun, 28 Sep 2014 17:58:41 +0200
> Hans de Goede <hdegoede@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 at 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] [PATCH 6/7] sun5i: Add support for a number of new sun5i boards

[Hans de Goede]

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

Signed-off-by: Henrik Nordstrom <henrik@henriknordstrom.net>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 board/sunxi/Makefile                |  4 ++++
 board/sunxi/dram_a10s_olinuxino_m.c | 31 +++++++++++++++++++++++++++++++
 board/sunxi/dram_a13_olinuxino.c    | 31 +++++++++++++++++++++++++++++++
 boards.cfg                          |  3 +++
 4 files changed, 69 insertions(+)
 create mode 100644 board/sunxi/dram_a10s_olinuxino_m.c
 create mode 100644 board/sunxi/dram_a13_olinuxino.c

diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index b1db5d9..2510cd1 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -12,7 +12,11 @@ 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
+obj-$(CONFIG_A10S_OLINUXINO_M)	+= dram_a10s_olinuxino_m.o
+obj-$(CONFIG_A13_OLINUXINO)	+= dram_a13_olinuxino.o
 obj-$(CONFIG_A13_OLINUXINOM)	+= dram_a13_oli_micro.o
+# This is not a typo, uses the same mem settings as the a10s-olinuxino-m
+obj-$(CONFIG_AUXTEK_T004)	+= dram_a10s_olinuxino_m.o
 obj-$(CONFIG_BA10_TV_BOX)	+= dram_sun4i_384_1024_iow8.o
 obj-$(CONFIG_CUBIEBOARD)	+= dram_cubieboard.o
 obj-$(CONFIG_CUBIEBOARD2)	+= dram_cubieboard2.o
diff --git a/board/sunxi/dram_a10s_olinuxino_m.c b/board/sunxi/dram_a10s_olinuxino_m.c
new file mode 100644
index 0000000..8900539
--- /dev/null
+++ b/board/sunxi/dram_a10s_olinuxino_m.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 = 432,
+	.type = 3,
+	.rank_num = 1,
+	.density = 4096,
+	.io_width = 16,
+	.bus_width = 16,
+	.cas = 9,
+	.zq = 123,
+	.odt_en = 0,
+	.size = 512,
+	.tpr0 = 0x42d899b7,
+	.tpr1 = 0xa090,
+	.tpr2 = 0x22a00,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0x4,
+	.emr2 = 0x10,
+	.emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/board/sunxi/dram_a13_olinuxino.c b/board/sunxi/dram_a13_olinuxino.c
new file mode 100644
index 0000000..ca96260
--- /dev/null
+++ b/board/sunxi/dram_a13_olinuxino.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 = 408,
+	.type = 3,
+	.rank_num = 1,
+	.density = 2048,
+	.io_width = 8,
+	.bus_width = 16,
+	.cas = 9,
+	.zq = 123,
+	.odt_en = 0,
+	.size = 512,
+	.tpr0 = 0x42d899b7,
+	.tpr1 = 0xa090,
+	.tpr2 = 0x22a00,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0,
+	.emr2 = 0x10,
+	.emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index 8289c3c..cf99297 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -378,7 +378,10 @@ Active  arm         armv7          s5pc1xx     samsung         goni
 Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                              -                                                                                                                                 Minkyu Kang <mk7.kang@samsung.com>
 Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                      -                                                                                                                                 -
 Active  arm         armv7          sunxi       -               sunxi               A10-OLinuXino-Lime                    sun4i:A10_OLINUXINO_L,SPL,AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI                                              Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               A10s-OLinuXino-M                      sun5i:A10S_OLINUXINO_M,SPL,AXP152_POWER,SUNXI_EMAC,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPB(10)                                    Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               A13-OLinuXino                         sun5i:A13_OLINUXINO,SPL,CONS_INDEX=2,AXP209_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11)                                     Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               A13-OLinuXinoM                        sun5i:A13_OLINUXINOM,SPL,CONS_INDEX=2,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11)                                                 Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               Auxtek-T004                           sun5i:AUXTEK_T004,SPL,AXP152_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(13)                                                    Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               ba10_tv_box                           sun4i:BA10_TV_BOX,SPL,AXP209_POWER,SUNXI_EMAC,USB_EHCI,SUNXI_USB_VBUS1_GPIO=SUNXI_GPH(12)                                         Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubieboard                            sun4i:CUBIEBOARD,SPL,AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                                   Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubieboard2                           sun7i:CUBIEBOARD2,SPL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                                  Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
-- 
2.0.1

[U-Boot] [PATCH 7/7] sun7i: Add support for a number of new sun7i boards

[Hans de Goede]

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

Signed-off-by: Henrik Nordstrom <henrik@henriknordstrom.net>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 board/sunxi/Makefile                          |  4 ++++
 board/sunxi/dram_linksprite_pcduino3.c        | 31 +++++++++++++++++++++++++++
 board/sunxi/dram_sun7i_384_1024_iow16.c       | 31 +++++++++++++++++++++++++++
 board/sunxi/dram_sun7i_384_512_busw16_iow16.c | 31 +++++++++++++++++++++++++++
 boards.cfg                                    |  4 ++++
 5 files changed, 101 insertions(+)
 create mode 100644 board/sunxi/dram_linksprite_pcduino3.c
 create mode 100644 board/sunxi/dram_sun7i_384_1024_iow16.c
 create mode 100644 board/sunxi/dram_sun7i_384_512_busw16_iow16.c

diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 2510cd1..3fc7513 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -15,14 +15,18 @@ obj-$(CONFIG_A10_OLINUXINO_L)	+= dram_a10_olinuxino_l.o
 obj-$(CONFIG_A10S_OLINUXINO_M)	+= dram_a10s_olinuxino_m.o
 obj-$(CONFIG_A13_OLINUXINO)	+= dram_a13_olinuxino.o
 obj-$(CONFIG_A13_OLINUXINOM)	+= dram_a13_oli_micro.o
+obj-$(CONFIG_A20_OLINUXINO_M)	+= dram_sun7i_384_1024_iow16.o
 # This is not a typo, uses the same mem settings as the a10s-olinuxino-m
 obj-$(CONFIG_AUXTEK_T004)	+= dram_a10s_olinuxino_m.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_I12_TVBOX)		+= dram_sun7i_384_1024_iow16.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_PCDUINO3)		+= dram_linksprite_pcduino3.o
+obj-$(CONFIG_QT840A)		+= dram_sun7i_384_512_busw16_iow16.o
 obj-$(CONFIG_R7DONGLE)		+= dram_r7dongle.o
diff --git a/board/sunxi/dram_linksprite_pcduino3.c b/board/sunxi/dram_linksprite_pcduino3.c
new file mode 100644
index 0000000..9cc6e19
--- /dev/null
+++ b/board/sunxi/dram_linksprite_pcduino3.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 = 32,
+	.cas = 9,
+	.zq = 0x7a,
+	.odt_en = 0,
+	.size = 1024,
+	.tpr0 = 0x42d899b7,
+	.tpr1 = 0xa090,
+	.tpr2 = 0x22a00,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0x4,
+	.emr2 = 0x10,
+	.emr3 = 0x0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/board/sunxi/dram_sun7i_384_1024_iow16.c b/board/sunxi/dram_sun7i_384_1024_iow16.c
new file mode 100644
index 0000000..04e4b1e
--- /dev/null
+++ b/board/sunxi/dram_sun7i_384_1024_iow16.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 = 384,
+	.type = 3,
+	.rank_num = 1,
+	.density = 4096,
+	.io_width = 16,
+	.bus_width = 32,
+	.cas = 9,
+	.zq = 0x7f,
+	.odt_en = 0,
+	.size = 1024,
+	.tpr0 = 0x42d899b7,
+	.tpr1 = 0xa090,
+	.tpr2 = 0x22a00,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0x4,
+	.emr2 = 0x10,
+	.emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/board/sunxi/dram_sun7i_384_512_busw16_iow16.c b/board/sunxi/dram_sun7i_384_512_busw16_iow16.c
new file mode 100644
index 0000000..2e36011
--- /dev/null
+++ b/board/sunxi/dram_sun7i_384_512_busw16_iow16.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 = 384,
+	.type = 3,
+	.rank_num = 1,
+	.density = 4096,
+	.io_width = 16,
+	.bus_width = 16,
+	.cas = 9,
+	.zq = 0x7f,
+	.odt_en = 0,
+	.size = 512,
+	.tpr0 = 0x42d899b7,
+	.tpr1 = 0xa090,
+	.tpr2 = 0x22a00,
+	.tpr3 = 0,
+	.tpr4 = 0,
+	.tpr5 = 0,
+	.emr1 = 0x4,
+	.emr2 = 0x10,
+	.emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+	return dramc_init(&dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index cf99297..0257597 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -381,6 +381,7 @@ Active  arm         armv7          sunxi       -               sunxi
 Active  arm         armv7          sunxi       -               sunxi               A10s-OLinuXino-M                      sun5i:A10S_OLINUXINO_M,SPL,AXP152_POWER,SUNXI_EMAC,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPB(10)                                    Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               A13-OLinuXino                         sun5i:A13_OLINUXINO,SPL,CONS_INDEX=2,AXP209_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11)                                     Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               A13-OLinuXinoM                        sun5i:A13_OLINUXINOM,SPL,CONS_INDEX=2,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11)                                                 Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               A20-OLinuXino_MICRO                   sun7i:A20_OLINUXINO_M,SPL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                              Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Auxtek-T004                           sun5i:AUXTEK_T004,SPL,AXP152_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(13)                                                    Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               ba10_tv_box                           sun4i:BA10_TV_BOX,SPL,AXP209_POWER,SUNXI_EMAC,USB_EHCI,SUNXI_USB_VBUS1_GPIO=SUNXI_GPH(12)                                         Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubieboard                            sun4i:CUBIEBOARD,SPL,AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                                   Hans de Goede <hdegoede@redhat.com>
@@ -388,10 +389,13 @@ Active  arm         armv7          sunxi       -               sunxi
 Active  arm         armv7          sunxi       -               sunxi               Cubieboard2_FEL                       sun7i:CUBIEBOARD2,SPL_FEL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI                                              Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubietruck                            sun7i:CUBIETRUCK,SPL,AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(12),USB_EHCI                                            Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Cubietruck_FEL                        sun7i:CUBIETRUCK,SPL_FEL,AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(12),USB_EHCI                                        Ian Campbell <ijc@hellion.org.uk>:Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               i12-tvbox                             sun7i:I12_TVBOX,SPL,AXP209_POWER,SUNXI_GMAC,MACPWR=SUNXI_GPH(21),USB_EHCI                                                         Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               Linksprite_pcDuino3                   sun7i:PCDUINO3,SPL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPH(2),USB_EHCI                                                     Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Mele_A1000                            sun4i:MELE_A1000,SPL,AXP209_POWER,SUNXI_EMAC,MACPWR=SUNXI_GPH(15),AHCI,USB_EHCI                                                   Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Mele_A1000G                           sun4i:MELE_A1000G,SPL,AXP209_POWER,SUNXI_EMAC,MACPWR=SUNXI_GPH(15),AHCI,USB_EHCI                                                  Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Mini-X                                sun4i:MINI_X,SPL,AXP209_POWER,USB_EHCI                                                                                            Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               Mini-X-1Gb                            sun4i:MINI_X_1GB,SPL,AXP209_POWER,USB_EHCI                                                                                        Hans de Goede <hdegoede@redhat.com>
+Active  arm         armv7          sunxi       -               sunxi               qt840a                                sun7i:QT840A,SPL,AXP209_POWER,SUNXI_GMAC,MACPWR=SUNXI_GPH(21),USB_EHCI                                                            Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          sunxi       -               sunxi               r7-tv-dongle                          sun5i:R7DONGLE,SPL,AXP152_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(13)                                                       Hans de Goede <hdegoede@redhat.com>
 Active  arm         armv7          u8500       st-ericsson     snowball            snowball                              -                                                                                                                                 Mathieu Poirier <mathieu.poirier@linaro.org>
 Active  arm         armv7          u8500       st-ericsson     u8500               u8500_href                            -                                                                                                                                 -
-- 
2.0.1

[U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings

[Ian Campbell]

On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
> Specific USB EHCI settings to be set for sun4i if CONFIG_USB_EHCI is enabled.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Ian Campbell <ijc@hellion.org.uk>