* [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings
@ 2014-07-27 21:25 Hans de Goede
2014-07-27 21:25 ` [U-Boot] [PATCH 2/7] sun5i: " Hans de Goede
` (6 more replies)
0 siblings, 7 replies; 27+ messages in thread
From: Hans de Goede @ 2014-07-27 21:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 2/7] sun5i: add USB EHCI settings
2014-07-27 21:25 [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Hans de Goede
@ 2014-07-27 21:25 ` Hans de Goede
2014-07-28 7:42 ` Ian Campbell
2014-07-27 21:25 ` [U-Boot] [PATCH 3/7] sunxi: Enable EHCI on various sunxi boards Hans de Goede
` (5 subsequent siblings)
6 siblings, 1 reply; 27+ messages in thread
From: Hans de Goede @ 2014-07-27 21:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 3/7] sunxi: Enable EHCI on various sunxi boards
2014-07-27 21:25 [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Hans de Goede
2014-07-27 21:25 ` [U-Boot] [PATCH 2/7] sun5i: " Hans de Goede
@ 2014-07-27 21:25 ` Hans de Goede
2014-07-28 7:44 ` Ian Campbell
2014-07-27 21:25 ` [U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option Hans de Goede
` (4 subsequent siblings)
6 siblings, 1 reply; 27+ messages in thread
From: Hans de Goede @ 2014-07-27 21:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option
2014-07-27 21:25 [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Hans de Goede
2014-07-27 21:25 ` [U-Boot] [PATCH 2/7] sun5i: " Hans de Goede
2014-07-27 21:25 ` [U-Boot] [PATCH 3/7] sunxi: Enable EHCI on various sunxi boards Hans de Goede
@ 2014-07-27 21:25 ` Hans de Goede
2014-07-28 7:48 ` Ian Campbell
2014-07-28 8:09 ` [U-Boot] " thomas.langer at lantiq.com
2014-07-27 21:25 ` [U-Boot] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards Hans de Goede
` (3 subsequent siblings)
6 siblings, 2 replies; 27+ messages in thread
From: Hans de Goede @ 2014-07-27 21:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-07-27 21:25 [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Hans de Goede
` (2 preceding siblings ...)
2014-07-27 21:25 ` [U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option Hans de Goede
@ 2014-07-27 21:25 ` Hans de Goede
2014-07-28 7:54 ` Ian Campbell
2014-09-18 16:07 ` [U-Boot] [linux-sunxi] " Siarhei Siamashka
2014-07-27 21:25 ` [U-Boot] [PATCH 6/7] sun5i: Add support for a number of new sun5i boards Hans de Goede
` (2 subsequent siblings)
6 siblings, 2 replies; 27+ messages in thread
From: Hans de Goede @ 2014-07-27 21:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 6/7] sun5i: Add support for a number of new sun5i boards
2014-07-27 21:25 [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Hans de Goede
` (3 preceding siblings ...)
2014-07-27 21:25 ` [U-Boot] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards Hans de Goede
@ 2014-07-27 21:25 ` Hans de Goede
2014-07-27 21:25 ` [U-Boot] [PATCH 7/7] sun7i: Add support for a number of new sun7i boards Hans de Goede
2014-07-28 7:38 ` [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Ian Campbell
6 siblings, 0 replies; 27+ messages in thread
From: Hans de Goede @ 2014-07-27 21:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 7/7] sun7i: Add support for a number of new sun7i boards
2014-07-27 21:25 [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Hans de Goede
` (4 preceding siblings ...)
2014-07-27 21:25 ` [U-Boot] [PATCH 6/7] sun5i: Add support for a number of new sun5i boards Hans de Goede
@ 2014-07-27 21:25 ` Hans de Goede
2014-07-28 7:38 ` [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Ian Campbell
6 siblings, 0 replies; 27+ messages in thread
From: Hans de Goede @ 2014-07-27 21:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings
2014-07-27 21:25 [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Hans de Goede
` (5 preceding siblings ...)
2014-07-27 21:25 ` [U-Boot] [PATCH 7/7] sun7i: Add support for a number of new sun7i boards Hans de Goede
@ 2014-07-28 7:38 ` Ian Campbell
6 siblings, 0 replies; 27+ messages in thread
From: Ian Campbell @ 2014-07-28 7:38 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 2/7] sun5i: add USB EHCI settings
2014-07-27 21:25 ` [U-Boot] [PATCH 2/7] sun5i: " Hans de Goede
@ 2014-07-28 7:42 ` Ian Campbell
2014-07-28 8:22 ` Hans de Goede
0 siblings, 1 reply; 27+ messages in thread
From: Ian Campbell @ 2014-07-28 7:42 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 3/7] sunxi: Enable EHCI on various sunxi boards
2014-07-27 21:25 ` [U-Boot] [PATCH 3/7] sunxi: Enable EHCI on various sunxi boards Hans de Goede
@ 2014-07-28 7:44 ` Ian Campbell
0 siblings, 0 replies; 27+ messages in thread
From: Ian Campbell @ 2014-07-28 7:44 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option
2014-07-27 21:25 ` [U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option Hans de Goede
@ 2014-07-28 7:48 ` Ian Campbell
2014-07-28 7:51 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
2014-07-28 8:23 ` Hans de Goede
2014-07-28 8:09 ` [U-Boot] " thomas.langer at lantiq.com
1 sibling, 2 replies; 27+ messages in thread
From: Ian Campbell @ 2014-07-28 7:48 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] Re: [PATCH 4/7] sunxi: Add CONFIG_MACPWR option
2014-07-28 7:48 ` Ian Campbell
@ 2014-07-28 7:51 ` Chen-Yu Tsai
2014-07-28 7:59 ` Ian Campbell
2014-07-28 8:23 ` Hans de Goede
1 sibling, 1 reply; 27+ messages in thread
From: Chen-Yu Tsai @ 2014-07-28 7:51 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-07-27 21:25 ` [U-Boot] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards Hans de Goede
@ 2014-07-28 7:54 ` Ian Campbell
2014-07-28 8:46 ` Hans de Goede
2014-09-18 16:07 ` [U-Boot] [linux-sunxi] " Siarhei Siamashka
1 sibling, 1 reply; 27+ messages in thread
From: Ian Campbell @ 2014-07-28 7:54 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] Re: [PATCH 4/7] sunxi: Add CONFIG_MACPWR option
2014-07-28 7:51 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
@ 2014-07-28 7:59 ` Ian Campbell
0 siblings, 0 replies; 27+ messages in thread
From: Ian Campbell @ 2014-07-28 7:59 UTC (permalink / raw)
To: u-boot
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>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option
2014-07-27 21:25 ` [U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option Hans de Goede
2014-07-28 7:48 ` Ian Campbell
@ 2014-07-28 8:09 ` thomas.langer at lantiq.com
2014-07-28 8:59 ` Hans de Goede
1 sibling, 1 reply; 27+ messages in thread
From: thomas.langer at lantiq.com @ 2014-07-28 8:09 UTC (permalink / raw)
To: u-boot
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.
---
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 2/7] sun5i: add USB EHCI settings
2014-07-28 7:42 ` Ian Campbell
@ 2014-07-28 8:22 ` Hans de Goede
0 siblings, 0 replies; 27+ messages in thread
From: Hans de Goede @ 2014-07-28 8:22 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] Re: [PATCH 4/7] sunxi: Add CONFIG_MACPWR option
2014-07-28 7:48 ` Ian Campbell
2014-07-28 7:51 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
@ 2014-07-28 8:23 ` Hans de Goede
1 sibling, 0 replies; 27+ messages in thread
From: Hans de Goede @ 2014-07-28 8:23 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-07-28 7:54 ` Ian Campbell
@ 2014-07-28 8:46 ` Hans de Goede
2014-07-28 8:50 ` Ian Campbell
0 siblings, 1 reply; 27+ messages in thread
From: Hans de Goede @ 2014-07-28 8:46 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-07-28 8:46 ` Hans de Goede
@ 2014-07-28 8:50 ` Ian Campbell
0 siblings, 0 replies; 27+ messages in thread
From: Ian Campbell @ 2014-07-28 8:50 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option
2014-07-28 8:09 ` [U-Boot] " thomas.langer at lantiq.com
@ 2014-07-28 8:59 ` Hans de Goede
0 siblings, 0 replies; 27+ messages in thread
From: Hans de Goede @ 2014-07-28 8:59 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-07-27 21:25 ` [U-Boot] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards Hans de Goede
2014-07-28 7:54 ` Ian Campbell
@ 2014-09-18 16:07 ` Siarhei Siamashka
2014-09-28 15:58 ` Hans de Goede
1 sibling, 1 reply; 27+ messages in thread
From: Siarhei Siamashka @ 2014-09-18 16:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-09-18 16:07 ` [U-Boot] [linux-sunxi] " Siarhei Siamashka
@ 2014-09-28 15:58 ` Hans de Goede
2014-09-28 19:34 ` Arnd Gronenberg
2014-09-29 5:38 ` Siarhei Siamashka
0 siblings, 2 replies; 27+ messages in thread
From: Hans de Goede @ 2014-09-28 15:58 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-09-28 15:58 ` Hans de Goede
@ 2014-09-28 19:34 ` Arnd Gronenberg
2014-09-28 22:09 ` Siarhei Siamashka
2014-09-29 5:38 ` Siarhei Siamashka
1 sibling, 1 reply; 27+ messages in thread
From: Arnd Gronenberg @ 2014-09-28 19:34 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-09-28 19:34 ` Arnd Gronenberg
@ 2014-09-28 22:09 ` Siarhei Siamashka
2014-09-29 8:31 ` Arnd Gronenberg
0 siblings, 1 reply; 27+ messages in thread
From: Siarhei Siamashka @ 2014-09-28 22:09 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-09-28 15:58 ` Hans de Goede
2014-09-28 19:34 ` Arnd Gronenberg
@ 2014-09-29 5:38 ` Siarhei Siamashka
2014-09-29 5:46 ` Siarhei Siamashka
1 sibling, 1 reply; 27+ messages in thread
From: Siarhei Siamashka @ 2014-09-29 5:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-09-29 5:38 ` Siarhei Siamashka
@ 2014-09-29 5:46 ` Siarhei Siamashka
0 siblings, 0 replies; 27+ messages in thread
From: Siarhei Siamashka @ 2014-09-29 5:46 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
2014-09-28 22:09 ` Siarhei Siamashka
@ 2014-09-29 8:31 ` Arnd Gronenberg
0 siblings, 0 replies; 27+ messages in thread
From: Arnd Gronenberg @ 2014-09-29 8:31 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2014-09-29 8:31 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-27 21:25 [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Hans de Goede
2014-07-27 21:25 ` [U-Boot] [PATCH 2/7] sun5i: " Hans de Goede
2014-07-28 7:42 ` Ian Campbell
2014-07-28 8:22 ` Hans de Goede
2014-07-27 21:25 ` [U-Boot] [PATCH 3/7] sunxi: Enable EHCI on various sunxi boards Hans de Goede
2014-07-28 7:44 ` Ian Campbell
2014-07-27 21:25 ` [U-Boot] [PATCH 4/7] sunxi: Add CONFIG_MACPWR option Hans de Goede
2014-07-28 7:48 ` Ian Campbell
2014-07-28 7:51 ` [U-Boot] [linux-sunxi] " Chen-Yu Tsai
2014-07-28 7:59 ` Ian Campbell
2014-07-28 8:23 ` Hans de Goede
2014-07-28 8:09 ` [U-Boot] " thomas.langer at lantiq.com
2014-07-28 8:59 ` Hans de Goede
2014-07-27 21:25 ` [U-Boot] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards Hans de Goede
2014-07-28 7:54 ` Ian Campbell
2014-07-28 8:46 ` Hans de Goede
2014-07-28 8:50 ` Ian Campbell
2014-09-18 16:07 ` [U-Boot] [linux-sunxi] " Siarhei Siamashka
2014-09-28 15:58 ` Hans de Goede
2014-09-28 19:34 ` Arnd Gronenberg
2014-09-28 22:09 ` Siarhei Siamashka
2014-09-29 8:31 ` Arnd Gronenberg
2014-09-29 5:38 ` Siarhei Siamashka
2014-09-29 5:46 ` Siarhei Siamashka
2014-07-27 21:25 ` [U-Boot] [PATCH 6/7] sun5i: Add support for a number of new sun5i boards Hans de Goede
2014-07-27 21:25 ` [U-Boot] [PATCH 7/7] sun7i: Add support for a number of new sun7i boards Hans de Goede
2014-07-28 7:38 ` [U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings Ian Campbell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.