[U-Boot] [PATCH 1/7] sun4i: add USB EHCI settings
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 */
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 */
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
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
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
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
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) {
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
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
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
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
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. ---
Hi,
On 07/28/2014 10:09 AM, thomas.langer@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
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 - -
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.
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
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:
- The hackberry: https://www.miniand.com/products/Hackberry%20A10%20Developer%20Board
- 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
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@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@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.
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@googlegroups.com/msg04343.html
I have a revision A board.
A bunch of revision C boards were all fine in Oliver's tests. And nobody has ever tested revision B so far, so we have no idea whether it is stable or not. A mysterious thing is that the Olimex representatives on IRC were not aware of any fixes of this kind applied to the PCB.
My understanding is that the revision A was just a small pre-production batch, donated by OLIMEX to a number of open source developers. Some of these boards were distributed at FOSDEM. I'm not sure if we should really worry about the reliability of the revision A, because none of the 'normal' customers probably have such boards. We only need to clarify the status of revision B.
But if we want to support the revision A too, then it probably needs its own config, which would somehow restrict the CPU clock speed.
My revision A was actually ordered normally, a couple of days before the first batch sold-out. So it is likely that the entire first batch was revision A.
Do you have any easy step-by-step document (or ready to use sdcard image to download) to do some stress tests on my revision A ?
Maybe the first couple handed out to developers where hand soldered or some such ? Either way it would be good to either confirm that my revision A has the same issues, or not :)
obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o +obj-$(CONFIG_BA10_TV_BOX) += dram_sun4i_384_1024_iow8.o obj-$(CONFIG_CUBIEBOARD) += dram_cubieboard.o obj-$(CONFIG_CUBIEBOARD2) += dram_cubieboard2.o obj-$(CONFIG_CUBIETRUCK) += dram_cubietruck.o +obj-$(CONFIG_MELE_A1000) += dram_sun4i_360_512.o +obj-$(CONFIG_MELE_A1000G) += dram_sun4i_360_1024_iow8.o +obj-$(CONFIG_MINI_X) += dram_sun4i_360_512.o +obj-$(CONFIG_MINI_X_1GB) += dram_sun4i_360_1024_iow16.o obj-$(CONFIG_R7DONGLE) += dram_r7dongle.o diff --git a/board/sunxi/dram_a10_olinuxino_l.c b/board/sunxi/dram_a10_olinuxino_l.c new file mode 100644 index 0000000..24a1bd9 --- /dev/null +++ b/board/sunxi/dram_a10_olinuxino_l.c @@ -0,0 +1,31 @@ +/* this file is generated, don't edit it yourself */
+#include <common.h> +#include <asm/arch/dram.h>
+static struct dram_para dram_para = {
- .clock = 480,
- .type = 3,
- .rank_num = 1,
- .density = 4096,
- .io_width = 16,
- .bus_width = 16,
- .cas = 6,
The CAS=6 is not quite right for the 480MHz DRAM clock speed if we are dealing with the typical DDR3 chips, with the timings mostly representing the standard JEDEC speed bins.
CAS=6 is good up to 400MHz. CAS=7 is good up to 533MHz. And CAS=9 is good up to 667MHz.
- .zq = 123,
- .odt_en = 0,
- .size = 512,
- .tpr0 = 0x30926692,
- .tpr1 = 0x1090,
- .tpr2 = 0x1a0c8,
The .tpr0/.tpr1/.tpr2 settings here are simply using the default reset values of the DRAM controller hardware registers. Which happen to match the DDR2-800E speed bin, as identified by Jens Kuske: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg03548.html
Either way, these settings are outside of the valid range when running at 480MHz (which would be something like DDR3-960 in our case).
The fundamental problem here is that u-boot-sunxi essentially trusted the device manufacturers to pick the correct DRAM settings. However it looks like the device manufacturers did not have any proper DRAM documentation either. And they just ended up picking some random settings, which seemed to kinda work (and then copy/pasted these settings from one device to another with minor variation). Also without doubt, they were all under a heavy time-to-market pressure.
Now this patch is just taking these obviously incorrect settings and putting them into the mainline u-boot. Sure, these settings can't be completely unreliable, because they are used in production on a huge number of commercially sold devices. The DRAM controller and the DDR3 chips have some safety headroom in practice and may tolerate a bit of abuse before failing. However all these settings have to be eventually formally validated in some way (ensure that the supported boards at least do not obviously fail the https://github.com/ssvb/lima-memtester test). And IMHO this preferably should be done before the v2014.10 release.
I don't think we will have time to fix these for v2014.10, regardless I don't think that validating is a real option, since we have to small a sample of each board to do anything statistically meaningful, and most of us also don't have the time to run many tests either.
So I think that the best way forward with this, is now that we know what the all the magic values actually do, to tweak the settings to be inside the relevant DRAM specs for the speed we're operating the RAM at on each board. AFAIK making things (somewhat) slower should always be safe / not lead to regressions, so this seems like the safe thing to do.
Regards,
Hans
On 09/28/2014 05:58 PM, Hans de Goede wrote:
[...]
On 09/18/2014 06:07 PM, Siarhei Siamashka wrote:
Which revision of A10-OLinuXino-LIME do you have? Revision A is known to have troubles running stable at 1008MHz CPU clock speed, as confirmed on a sample set of two boards (mine and Oliver Schinagl's): https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html
I have a revision A board.
My Olimex A10 OLinuXino Lime is also labelled "Rev. A"... It is running stable at 1008MHz and I just tried Olivers djpeg test without any problems.
I'm running Hans' u-boot-sunxi 2014.10-rc1-g7190869 and Linux mainline 3.17.0-rc1-00158-g451fd72.
A bunch of revision C boards were all fine in Oliver's tests. And nobody has ever tested revision B so far, so we have no idea whether it is stable or not. A mysterious thing is that the Olimex representatives on IRC were not aware of any fixes of this kind applied to the PCB.
My understanding is that the revision A was just a small pre-production batch, donated by OLIMEX to a number of open source developers. Some of these boards were distributed at FOSDEM. I'm not sure if we should really worry about the reliability of the revision A, because none of the 'normal' customers probably have such boards. We only need to clarify the status of revision B.
But if we want to support the revision A too, then it probably needs its own config, which would somehow restrict the CPU clock speed. I also ha
My revision A was actually ordered normally, a couple of days before the first batch sold-out. So it is likely that the entire first batch was revision A.
Do you have any easy step-by-step document (or ready to use sdcard image to download) to do some stress tests on my revision A ?
Maybe the first couple handed out to developers where hand soldered or some such ? Either way it would be good to either confirm that my revision A has the same issues, or not :)
I bought my revision A from a German distributor (exp-tech.de) and it doesn't look hand soldered (except for the through hole parts :-) ).
If I correctly compared the schematics for revision A,B and C, there is only one change in regard to the DRAM: R8 (connected to ZQ) has a different value: - Revision A: 237 Ohm / 1% - Revision B: 430 Ohm / 1% - Revision C: 330 Ohm / 1%
I checked R8 on my revision A's PCB: It is a 330 Ohm / 1%, therefore the value specified in the revision C schematic. So it may make sense to check R8 on the problematic revision A boards and replace it by a 330 Ohm resistor. The DRAM data sheet specifies this resistor with 240 Ohm / 1%...
[...]
Either way, these settings are outside of the valid range when running at 480MHz (which would be something like DDR3-960 in our case).
[...]
The current (probably incorrect) values work fine with my board (even though they may be out of spec), but the value of R8 may have some impact here.
Best regards, Arnd
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@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... 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.
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@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... 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.
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@googlegroups.com/msg04343.html
I have a revision A board.
A bunch of revision C boards were all fine in Oliver's tests. And nobody has ever tested revision B so far, so we have no idea whether it is stable or not. A mysterious thing is that the Olimex representatives on IRC were not aware of any fixes of this kind applied to the PCB.
My understanding is that the revision A was just a small pre-production batch, donated by OLIMEX to a number of open source developers. Some of these boards were distributed at FOSDEM. I'm not sure if we should really worry about the reliability of the revision A, because none of the 'normal' customers probably have such boards. We only need to clarify the status of revision B.
But if we want to support the revision A too, then it probably needs its own config, which would somehow restrict the CPU clock speed.
My revision A was actually ordered normally, a couple of days before the first batch sold-out. So it is likely that the entire first batch was revision A.
Do you have any easy step-by-step document (or ready to use sdcard image to download) to do some stress tests on my revision A ?
The easy step-by-step document was there since the beginning of May: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html
If you don't mind to download random binaries from the Internet, there was also a link to the static djpeg binary if you are unsure about the one used in your distro and don't want to waste time compiling libjpeg-turbo yourself.
Also it looks like now we need to try a little bit harder with the mainline kernel, so I have posted some updates in my reply to Arnd Gronenberg: http://lists.denx.de/pipermail/u-boot/2014-September/190061.html
Taking all of this into account and with the use of the djpeg static binary download, it's just a few lines to type in the console:
cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg wget http://people.freedesktop.org/~siamashka/files/20140504/djpeg-static chmod +x djpeg-static while true ; do ./djpeg-static A10-LIME.jpg | md5sum ; done
If identical hashes show up in each line of the output, then everything is fine. If some hashes end up to be different, then there is data corruption happening during JPEG decoding, which indicates hardware reliability issues.
Maybe the first couple handed out to developers where hand soldered or some such ? Either way it would be good to either confirm that my revision A has the same issues, or not :)
My board looks fine (without any visible soldering problems). As discussed months ago on the linux-sunxi mailing list, we are suspecting that the root cause is some significant voltage drop on the dcdc2 power line between the PMIC and the SoC. So that if the current is high (under high CPU usage) then the SoC actually gets a substantially reduced voltage compared to the requested 1.4V from the PMIC.
Newer revisions of the A10-Lime PCB might just have a beefier power line with reduced resistance, but that's only a speculation.
By the way, it looks like the Banana Pi might suffer from the very same problem. Somebody has just submitted a FEX file update (FEX serves a similar purpose as DTS in the sunxi-3.4 kernel): https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg07629.html The commit message only says "Fix the unstable problem caused by dvfs table" without going into any details. The change that they are introducing is in fact moving the highest cpufreq operating point from "912MHz at 1.4V" to "912MHz at 1.425V". Supposedly to fix some reliability problems reproduced on some undisclosed use case. Now if we are trying to use the mainline kernel, then it does not have cpufreq support and the CPU clock frequency/voltage settings are inherited from u-boot. And u-boot currently configures them to, surprise surprise, "912MHz at 1.4V" which is expected to be unstable according to that FEX update submitter. This raises an obvious red flag.
The libjpeg-turbo decoding test appears to be sensitive to the CPU clock frequency/voltage (at least for Cortex-A8), so somebody might want to give it a try also on the Banana Pi. Or if the libjpeg-turbo test does not reveal anything interesting, then we might want to ask the Banana Pi FEX update submitter to find out how the reliability problem is supposed to be reproduced.
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@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
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
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 - -
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
participants (6)
-
Arnd Gronenberg -
Chen-Yu Tsai -
Hans de Goede -
Ian Campbell -
Siarhei Siamashka -
thomas.langer＠lantiq.com