* [PATCH 1/5] ARM: mvebu: Add common reset_cpu function
2014-09-15 7:41 mvebu multi SoC support Sascha Hauer
@ 2014-09-15 7:41 ` Sascha Hauer
2014-09-16 19:17 ` Sebastian Hesselbarth
2014-09-15 7:41 ` [PATCH 2/5] ARM: mvebu: Simplify memory init order Sascha Hauer
` (4 subsequent siblings)
5 siblings, 1 reply; 19+ messages in thread
From: Sascha Hauer @ 2014-09-15 7:41 UTC (permalink / raw)
To: barebox
mvebu has a reset_cpu function per SoC this does not work when multiple
SoCs are selected, so add a common reset_cpu function which calls into
the SoC specific ones.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-mvebu/armada-370-xp.c | 19 ++++++++++---------
arch/arm/mach-mvebu/common.c | 15 ++++++++++++++-
arch/arm/mach-mvebu/dove.c | 21 +++++++++++----------
arch/arm/mach-mvebu/include/mach/common.h | 1 +
arch/arm/mach-mvebu/kirkwood.c | 19 ++++++++++---------
5 files changed, 46 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index f2b991e..6251100 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -44,11 +44,21 @@ static inline void armada_370_xp_memory_find(unsigned long *phys_base,
}
}
+static void __noreturn armada_370_xp_reset_cpu(unsigned long addr)
+{
+ writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x60);
+ writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x64);
+ while (1)
+ ;
+}
+
static int armada_370_xp_init_soc(void)
{
unsigned long phys_base, phys_size;
u32 reg;
+ mvebu_set_reset(armada_370_xp_reset_cpu);
+
barebox_set_model("Marvell Armada 370/XP");
barebox_set_hostname("armada");
@@ -65,12 +75,3 @@ static int armada_370_xp_init_soc(void)
return 0;
}
core_initcall(armada_370_xp_init_soc);
-
-void __noreturn reset_cpu(unsigned long addr)
-{
- writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x60);
- writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x64);
- while (1)
- ;
-}
-EXPORT_SYMBOL(reset_cpu);
diff --git a/arch/arm/mach-mvebu/common.c b/arch/arm/mach-mvebu/common.c
index ac4b332..5c3ac14 100644
--- a/arch/arm/mach-mvebu/common.c
+++ b/arch/arm/mach-mvebu/common.c
@@ -21,6 +21,7 @@
#include <of.h>
#include <of_address.h>
#include <linux/clk.h>
+#include <mach/common.h>
/*
* Marvell MVEBU SoC id and revision can be read from any PCIe
@@ -137,4 +138,16 @@ static int mvebu_memory_of_fixup(struct device_node *root, void *context)
static int mvebu_memory_fixup_register(void) {
return of_register_fixup(mvebu_memory_of_fixup, NULL);
}
-pure_initcall(mvebu_memory_fixup_register);
+
+static __noreturn void (*mvebu_reset_cpu)(unsigned long addr);
+
+void __noreturn reset_cpu(unsigned long addr)
+{
+ mvebu_reset_cpu(addr);
+}
+EXPORT_SYMBOL(reset_cpu);
+
+void mvebu_set_reset(void __noreturn (*reset)(unsigned long addr))
+{
+ mvebu_reset_cpu = reset;
+}
diff --git a/arch/arm/mach-mvebu/dove.c b/arch/arm/mach-mvebu/dove.c
index 69c6436..17cee0b 100644
--- a/arch/arm/mach-mvebu/dove.c
+++ b/arch/arm/mach-mvebu/dove.c
@@ -68,10 +68,21 @@ static inline void dove_memory_find(unsigned long *phys_base,
}
}
+static void __noreturn dove_reset_cpu(unsigned long addr)
+{
+ /* enable and assert RSTOUTn */
+ writel(SOFT_RESET_OUT_EN, DOVE_BRIDGE_BASE + BRIDGE_RSTOUT_MASK);
+ writel(SOFT_RESET_EN, DOVE_BRIDGE_BASE + BRIDGE_SYS_SOFT_RESET);
+ while (1)
+ ;
+}
+
static int dove_init_soc(void)
{
unsigned long phys_base, phys_size;
+ mvebu_set_reset(dove_reset_cpu);
+
barebox_set_model("Marvell Dove");
barebox_set_hostname("dove");
@@ -85,13 +96,3 @@ static int dove_init_soc(void)
return 0;
}
core_initcall(dove_init_soc);
-
-void __noreturn reset_cpu(unsigned long addr)
-{
- /* enable and assert RSTOUTn */
- writel(SOFT_RESET_OUT_EN, DOVE_BRIDGE_BASE + BRIDGE_RSTOUT_MASK);
- writel(SOFT_RESET_EN, DOVE_BRIDGE_BASE + BRIDGE_SYS_SOFT_RESET);
- while (1)
- ;
-}
-EXPORT_SYMBOL(reset_cpu);
diff --git a/arch/arm/mach-mvebu/include/mach/common.h b/arch/arm/mach-mvebu/include/mach/common.h
index 9f6118e..30862e0 100644
--- a/arch/arm/mach-mvebu/include/mach/common.h
+++ b/arch/arm/mach-mvebu/include/mach/common.h
@@ -21,5 +21,6 @@
#define MVEBU_REMAP_INT_REG_BASE 0xf1000000
void mvebu_set_memory(u64 phys_base, u64 phys_size);
+void mvebu_set_reset(void __noreturn (*reset)(unsigned long addr));
#endif
diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
index c114bdb..7c0526b 100644
--- a/arch/arm/mach-mvebu/kirkwood.c
+++ b/arch/arm/mach-mvebu/kirkwood.c
@@ -43,10 +43,20 @@ static inline void kirkwood_memory_find(unsigned long *phys_base,
}
}
+static void __noreturn kirkwood_reset_cpu(unsigned long addr)
+{
+ writel(SOFT_RESET_OUT_EN, KIRKWOOD_BRIDGE_BASE + BRIDGE_RSTOUT_MASK);
+ writel(SOFT_RESET_EN, KIRKWOOD_BRIDGE_BASE + BRIDGE_SYS_SOFT_RESET);
+ for(;;)
+ ;
+}
+
static int kirkwood_init_soc(void)
{
unsigned long phys_base, phys_size;
+ mvebu_set_reset(kirkwood_reset_cpu);
+
barebox_set_model("Marvell Kirkwood");
barebox_set_hostname("kirkwood");
@@ -58,12 +68,3 @@ static int kirkwood_init_soc(void)
return 0;
}
core_initcall(kirkwood_init_soc);
-
-void __noreturn reset_cpu(unsigned long addr)
-{
- writel(SOFT_RESET_OUT_EN, KIRKWOOD_BRIDGE_BASE + BRIDGE_RSTOUT_MASK);
- writel(SOFT_RESET_EN, KIRKWOOD_BRIDGE_BASE + BRIDGE_SYS_SOFT_RESET);
- for(;;)
- ;
-}
-EXPORT_SYMBOL(reset_cpu);
--
2.1.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 1/5] ARM: mvebu: Add common reset_cpu function
2014-09-15 7:41 ` [PATCH 1/5] ARM: mvebu: Add common reset_cpu function Sascha Hauer
@ 2014-09-16 19:17 ` Sebastian Hesselbarth
2014-09-17 6:32 ` Sascha Hauer
0 siblings, 1 reply; 19+ messages in thread
From: Sebastian Hesselbarth @ 2014-09-16 19:17 UTC (permalink / raw)
To: Sascha Hauer, barebox
On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> mvebu has a reset_cpu function per SoC this does not work when multiple
> SoCs are selected, so add a common reset_cpu function which calls into
> the SoC specific ones.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> arch/arm/mach-mvebu/armada-370-xp.c | 19 ++++++++++---------
> arch/arm/mach-mvebu/common.c | 15 ++++++++++++++-
> arch/arm/mach-mvebu/dove.c | 21 +++++++++++----------
> arch/arm/mach-mvebu/include/mach/common.h | 1 +
> arch/arm/mach-mvebu/kirkwood.c | 19 ++++++++++---------
> 5 files changed, 46 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> index f2b991e..6251100 100644
> --- a/arch/arm/mach-mvebu/armada-370-xp.c
> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> @@ -44,11 +44,21 @@ static inline void armada_370_xp_memory_find(unsigned long *phys_base,
> }
> }
>
> +static void __noreturn armada_370_xp_reset_cpu(unsigned long addr)
> +{
> + writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x60);
> + writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x64);
> + while (1)
> + ;
> +}
> +
> static int armada_370_xp_init_soc(void)
> {
> unsigned long phys_base, phys_size;
> u32 reg;
>
> + mvebu_set_reset(armada_370_xp_reset_cpu);
> +
> barebox_set_model("Marvell Armada 370/XP");
> barebox_set_hostname("armada");
>
> @@ -65,12 +75,3 @@ static int armada_370_xp_init_soc(void)
> return 0;
> }
> core_initcall(armada_370_xp_init_soc);
> -
> -void __noreturn reset_cpu(unsigned long addr)
> -{
> - writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x60);
> - writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x64);
> - while (1)
> - ;
> -}
> -EXPORT_SYMBOL(reset_cpu);
> diff --git a/arch/arm/mach-mvebu/common.c b/arch/arm/mach-mvebu/common.c
> index ac4b332..5c3ac14 100644
> --- a/arch/arm/mach-mvebu/common.c
> +++ b/arch/arm/mach-mvebu/common.c
> @@ -21,6 +21,7 @@
> #include <of.h>
> #include <of_address.h>
> #include <linux/clk.h>
> +#include <mach/common.h>
>
> /*
> * Marvell MVEBU SoC id and revision can be read from any PCIe
> @@ -137,4 +138,16 @@ static int mvebu_memory_of_fixup(struct device_node *root, void *context)
> static int mvebu_memory_fixup_register(void) {
> return of_register_fixup(mvebu_memory_of_fixup, NULL);
> }
> -pure_initcall(mvebu_memory_fixup_register);
Unrelated removal, this should move to the next patch.
Sebastian
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 1/5] ARM: mvebu: Add common reset_cpu function
2014-09-16 19:17 ` Sebastian Hesselbarth
@ 2014-09-17 6:32 ` Sascha Hauer
0 siblings, 0 replies; 19+ messages in thread
From: Sascha Hauer @ 2014-09-17 6:32 UTC (permalink / raw)
To: Sebastian Hesselbarth; +Cc: barebox
On Tue, Sep 16, 2014 at 09:17:03PM +0200, Sebastian Hesselbarth wrote:
> On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> > mvebu has a reset_cpu function per SoC this does not work when multiple
> > SoCs are selected, so add a common reset_cpu function which calls into
> > the SoC specific ones.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > arch/arm/mach-mvebu/armada-370-xp.c | 19 ++++++++++---------
> > arch/arm/mach-mvebu/common.c | 15 ++++++++++++++-
> > arch/arm/mach-mvebu/dove.c | 21 +++++++++++----------
> > arch/arm/mach-mvebu/include/mach/common.h | 1 +
> > arch/arm/mach-mvebu/kirkwood.c | 19 ++++++++++---------
> > 5 files changed, 46 insertions(+), 29 deletions(-)
> >
> > diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> > index f2b991e..6251100 100644
> > --- a/arch/arm/mach-mvebu/armada-370-xp.c
> > +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> > @@ -44,11 +44,21 @@ static inline void armada_370_xp_memory_find(unsigned long *phys_base,
> > }
> > }
> >
> > +static void __noreturn armada_370_xp_reset_cpu(unsigned long addr)
> > +{
> > + writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x60);
> > + writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x64);
> > + while (1)
> > + ;
> > +}
> > +
> > static int armada_370_xp_init_soc(void)
> > {
> > unsigned long phys_base, phys_size;
> > u32 reg;
> >
> > + mvebu_set_reset(armada_370_xp_reset_cpu);
> > +
> > barebox_set_model("Marvell Armada 370/XP");
> > barebox_set_hostname("armada");
> >
> > @@ -65,12 +75,3 @@ static int armada_370_xp_init_soc(void)
> > return 0;
> > }
> > core_initcall(armada_370_xp_init_soc);
> > -
> > -void __noreturn reset_cpu(unsigned long addr)
> > -{
> > - writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x60);
> > - writel(0x1, ARMADA_370_XP_SYSCTL_BASE + 0x64);
> > - while (1)
> > - ;
> > -}
> > -EXPORT_SYMBOL(reset_cpu);
> > diff --git a/arch/arm/mach-mvebu/common.c b/arch/arm/mach-mvebu/common.c
> > index ac4b332..5c3ac14 100644
> > --- a/arch/arm/mach-mvebu/common.c
> > +++ b/arch/arm/mach-mvebu/common.c
> > @@ -21,6 +21,7 @@
> > #include <of.h>
> > #include <of_address.h>
> > #include <linux/clk.h>
> > +#include <mach/common.h>
> >
> > /*
> > * Marvell MVEBU SoC id and revision can be read from any PCIe
> > @@ -137,4 +138,16 @@ static int mvebu_memory_of_fixup(struct device_node *root, void *context)
> > static int mvebu_memory_fixup_register(void) {
> > return of_register_fixup(mvebu_memory_of_fixup, NULL);
> > }
> > -pure_initcall(mvebu_memory_fixup_register);
>
> Unrelated removal, this should move to the next patch.
Right, fixed this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 2/5] ARM: mvebu: Simplify memory init order
2014-09-15 7:41 mvebu multi SoC support Sascha Hauer
2014-09-15 7:41 ` [PATCH 1/5] ARM: mvebu: Add common reset_cpu function Sascha Hauer
@ 2014-09-15 7:41 ` Sascha Hauer
2014-09-16 20:05 ` Sebastian Hesselbarth
2014-09-15 7:41 ` [PATCH 3/5] ARM: mvebu: Check for correct SoC in of_fixup callback Sascha Hauer
` (3 subsequent siblings)
5 siblings, 1 reply; 19+ messages in thread
From: Sascha Hauer @ 2014-09-15 7:41 UTC (permalink / raw)
To: barebox
The initialisation of the memory nodes on mvebu is a bit
compilcated:
pure_initcall(mvebu_memory_fixup_register)
of_register_fixup(mvebu_memory_of_fixup, NULL)
core_initcall(kirkwood_init_soc)
mvebu_set_memory()
core_initcall(of_arm_init)
of_fix_tree()
mvebu_memory_of_fixup()
First a mvebu common of_fixup function is registered, then the SoC
calls mvebu_set_memory which stores the memory base and size in global
variables. Afterwards the of_fixup is executed which fixes the memory
nodes according to the global variables.
Instead register a SoC specific fixup which directly calls mvebu_set_memory
with the memory base and size as arguments:
pure_initcall(kirkwood_register_soc_fixup);
of_register_fixup(kirkwood_init_soc, NULL);
core_initcall(of_arm_init)
of_fix_tree()
kirkwood_init_soc()
mvebu_set_memory(phys_base, phys_size);
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-mvebu/armada-370-xp.c | 9 ++++++--
arch/arm/mach-mvebu/common.c | 34 ++++++++++---------------------
arch/arm/mach-mvebu/dove.c | 9 ++++++--
arch/arm/mach-mvebu/include/mach/common.h | 2 +-
arch/arm/mach-mvebu/kirkwood.c | 9 ++++++--
5 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 6251100..5c8499b 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -52,7 +52,7 @@ static void __noreturn armada_370_xp_reset_cpu(unsigned long addr)
;
}
-static int armada_370_xp_init_soc(void)
+static int armada_370_xp_init_soc(struct device_node *root, void *context)
{
unsigned long phys_base, phys_size;
u32 reg;
@@ -74,4 +74,9 @@ static int armada_370_xp_init_soc(void)
return 0;
}
-core_initcall(armada_370_xp_init_soc);
+
+static int armada_370_register_soc_fixup(void)
+{
+ return of_register_fixup(armada_370_xp_init_soc, NULL);
+}
+pure_initcall(armada_370_register_soc_fixup);
diff --git a/arch/arm/mach-mvebu/common.c b/arch/arm/mach-mvebu/common.c
index 5c3ac14..309f7a6 100644
--- a/arch/arm/mach-mvebu/common.c
+++ b/arch/arm/mach-mvebu/common.c
@@ -81,29 +81,21 @@ static int mvebu_soc_id_init(void)
}
postcore_initcall(mvebu_soc_id_init);
-static u64 mvebu_mem[2];
-
-void mvebu_set_memory(u64 phys_base, u64 phys_size)
-{
- mvebu_mem[0] = phys_base;
- mvebu_mem[1] = phys_size;
-}
-
/*
* Memory size is set up by BootROM and can be read from SoC's ram controller
* registers. Fixup provided DTs to reflect accessible amount of directly
* attached RAM. Removable RAM, e.g. SODIMM, should be added by a per-board
* fixup.
*/
-static int mvebu_memory_of_fixup(struct device_node *root, void *context)
+int mvebu_set_memory(u64 phys_base, u64 phys_size)
{
- struct device_node *np;
+ struct device_node *np, *root;
__be32 reg[4];
int na, ns;
- /* bail out on zero-sized mem */
- if (!mvebu_mem[1])
- return -ENODEV;
+ root = of_get_root_node();
+ if (!root)
+ return -EINVAL;
np = of_find_node_by_path("/memory");
if (!np)
@@ -115,17 +107,17 @@ static int mvebu_memory_of_fixup(struct device_node *root, void *context)
ns = of_n_size_cells(np);
if (na == 2) {
- reg[0] = cpu_to_be32(mvebu_mem[0] >> 32);
- reg[1] = cpu_to_be32(mvebu_mem[0] & 0xffffffff);
+ reg[0] = cpu_to_be32(phys_base >> 32);
+ reg[1] = cpu_to_be32(phys_base & 0xffffffff);
} else {
- reg[0] = cpu_to_be32(mvebu_mem[0] & 0xffffffff);
+ reg[0] = cpu_to_be32(phys_base & 0xffffffff);
}
if (ns == 2) {
- reg[2] = cpu_to_be32(mvebu_mem[1] >> 32);
- reg[3] = cpu_to_be32(mvebu_mem[1] & 0xffffffff);
+ reg[2] = cpu_to_be32(phys_size >> 32);
+ reg[3] = cpu_to_be32(phys_size & 0xffffffff);
} else {
- reg[1] = cpu_to_be32(mvebu_mem[1] & 0xffffffff);
+ reg[1] = cpu_to_be32(phys_size & 0xffffffff);
}
if (of_set_property(np, "device_type", "memory", sizeof("memory"), 1) ||
@@ -135,10 +127,6 @@ static int mvebu_memory_of_fixup(struct device_node *root, void *context)
return 0;
}
-static int mvebu_memory_fixup_register(void) {
- return of_register_fixup(mvebu_memory_of_fixup, NULL);
-}
-
static __noreturn void (*mvebu_reset_cpu)(unsigned long addr);
void __noreturn reset_cpu(unsigned long addr)
diff --git a/arch/arm/mach-mvebu/dove.c b/arch/arm/mach-mvebu/dove.c
index 17cee0b..58d5439 100644
--- a/arch/arm/mach-mvebu/dove.c
+++ b/arch/arm/mach-mvebu/dove.c
@@ -77,7 +77,7 @@ static void __noreturn dove_reset_cpu(unsigned long addr)
;
}
-static int dove_init_soc(void)
+static int dove_init_soc(struct device_node *root, void *context)
{
unsigned long phys_base, phys_size;
@@ -95,4 +95,9 @@ static int dove_init_soc(void)
return 0;
}
-core_initcall(dove_init_soc);
+
+static int dove_register_soc_fixup(void)
+{
+ return of_register_fixup(dove_init_soc, NULL);
+}
+pure_initcall(dove_register_soc_fixup);
diff --git a/arch/arm/mach-mvebu/include/mach/common.h b/arch/arm/mach-mvebu/include/mach/common.h
index 30862e0..5ce33fd 100644
--- a/arch/arm/mach-mvebu/include/mach/common.h
+++ b/arch/arm/mach-mvebu/include/mach/common.h
@@ -20,7 +20,7 @@
#define MVEBU_REMAP_INT_REG_BASE 0xf1000000
-void mvebu_set_memory(u64 phys_base, u64 phys_size);
+int mvebu_set_memory(u64 phys_base, u64 phys_size);
void mvebu_set_reset(void __noreturn (*reset)(unsigned long addr));
#endif
diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
index 7c0526b..a4b0853 100644
--- a/arch/arm/mach-mvebu/kirkwood.c
+++ b/arch/arm/mach-mvebu/kirkwood.c
@@ -51,7 +51,7 @@ static void __noreturn kirkwood_reset_cpu(unsigned long addr)
;
}
-static int kirkwood_init_soc(void)
+static int kirkwood_init_soc(struct device_node *root, void *context)
{
unsigned long phys_base, phys_size;
@@ -67,4 +67,9 @@ static int kirkwood_init_soc(void)
return 0;
}
-core_initcall(kirkwood_init_soc);
+
+static int kirkwood_register_soc_fixup(void)
+{
+ return of_register_fixup(kirkwood_init_soc, NULL);
+}
+pure_initcall(kirkwood_register_soc_fixup);
--
2.1.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 2/5] ARM: mvebu: Simplify memory init order
2014-09-15 7:41 ` [PATCH 2/5] ARM: mvebu: Simplify memory init order Sascha Hauer
@ 2014-09-16 20:05 ` Sebastian Hesselbarth
2014-09-17 6:45 ` Sascha Hauer
0 siblings, 1 reply; 19+ messages in thread
From: Sebastian Hesselbarth @ 2014-09-16 20:05 UTC (permalink / raw)
To: Sascha Hauer, barebox
On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> The initialisation of the memory nodes on mvebu is a bit
> compilcated:
>
> pure_initcall(mvebu_memory_fixup_register)
> of_register_fixup(mvebu_memory_of_fixup, NULL)
> core_initcall(kirkwood_init_soc)
> mvebu_set_memory()
> core_initcall(of_arm_init)
> of_fix_tree()
> mvebu_memory_of_fixup()
>
> First a mvebu common of_fixup function is registered, then the SoC
> calls mvebu_set_memory which stores the memory base and size in global
> variables. Afterwards the of_fixup is executed which fixes the memory
> nodes according to the global variables.
>
> Instead register a SoC specific fixup which directly calls mvebu_set_memory
> with the memory base and size as arguments:
>
> pure_initcall(kirkwood_register_soc_fixup);
> of_register_fixup(kirkwood_init_soc, NULL);
> core_initcall(of_arm_init)
> of_fix_tree()
> kirkwood_init_soc()
> mvebu_set_memory(phys_base, phys_size);
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Hmm, this breaks Armada 370 and most likely also Armada XP. Actually,
it breaks any SoC that has a DTB with internal regs set to 0xd0000000.
> ---
> arch/arm/mach-mvebu/armada-370-xp.c | 9 ++++++--
> arch/arm/mach-mvebu/common.c | 34 ++++++++++---------------------
> arch/arm/mach-mvebu/dove.c | 9 ++++++--
> arch/arm/mach-mvebu/include/mach/common.h | 2 +-
> arch/arm/mach-mvebu/kirkwood.c | 9 ++++++--
> 5 files changed, 33 insertions(+), 30 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> index 6251100..5c8499b 100644
> --- a/arch/arm/mach-mvebu/armada-370-xp.c
> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> @@ -52,7 +52,7 @@ static void __noreturn armada_370_xp_reset_cpu(unsigned long addr)
> ;
> }
>
> -static int armada_370_xp_init_soc(void)
> +static int armada_370_xp_init_soc(struct device_node *root, void *context)
> {
> unsigned long phys_base, phys_size;
> u32 reg;
> @@ -74,4 +74,9 @@ static int armada_370_xp_init_soc(void)
Because armada_370_xp_init_soc() does
mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
right above, which will add the range(s) required for internal register
of_fixup. Since this patch moved armada_370_xp_init_soc to the
of_fixups, we don't fix this up for the initial DT tree.
>
> return 0;
> }
> -core_initcall(armada_370_xp_init_soc);
> +
> +static int armada_370_register_soc_fixup(void)
> +{
I guess moving mvebu_mbus_add_range() in here does not work, because
it will add the armada_370_xp range also for dove and kirkwood.
> + return of_register_fixup(armada_370_xp_init_soc, NULL);
> +}
> +pure_initcall(armada_370_register_soc_fixup);
nit: s/armada_370_/armada_370_xp_/
I like the overall change, but haven't made my mind how this will work
out..
Sebastian
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 2/5] ARM: mvebu: Simplify memory init order
2014-09-16 20:05 ` Sebastian Hesselbarth
@ 2014-09-17 6:45 ` Sascha Hauer
2014-09-17 7:19 ` Sebastian Hesselbarth
0 siblings, 1 reply; 19+ messages in thread
From: Sascha Hauer @ 2014-09-17 6:45 UTC (permalink / raw)
To: Sebastian Hesselbarth; +Cc: barebox
On Tue, Sep 16, 2014 at 10:05:44PM +0200, Sebastian Hesselbarth wrote:
> On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> > The initialisation of the memory nodes on mvebu is a bit
> > compilcated:
> >
> > pure_initcall(mvebu_memory_fixup_register)
> > of_register_fixup(mvebu_memory_of_fixup, NULL)
> > core_initcall(kirkwood_init_soc)
> > mvebu_set_memory()
> > core_initcall(of_arm_init)
> > of_fix_tree()
> > mvebu_memory_of_fixup()
> >
> > First a mvebu common of_fixup function is registered, then the SoC
> > calls mvebu_set_memory which stores the memory base and size in global
> > variables. Afterwards the of_fixup is executed which fixes the memory
> > nodes according to the global variables.
> >
> > Instead register a SoC specific fixup which directly calls mvebu_set_memory
> > with the memory base and size as arguments:
> >
> > pure_initcall(kirkwood_register_soc_fixup);
> > of_register_fixup(kirkwood_init_soc, NULL);
> > core_initcall(of_arm_init)
> > of_fix_tree()
> > kirkwood_init_soc()
> > mvebu_set_memory(phys_base, phys_size);
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> Hmm, this breaks Armada 370 and most likely also Armada XP. Actually,
> it breaks any SoC that has a DTB with internal regs set to 0xd0000000.
>
> > ---
> > arch/arm/mach-mvebu/armada-370-xp.c | 9 ++++++--
> > arch/arm/mach-mvebu/common.c | 34 ++++++++++---------------------
> > arch/arm/mach-mvebu/dove.c | 9 ++++++--
> > arch/arm/mach-mvebu/include/mach/common.h | 2 +-
> > arch/arm/mach-mvebu/kirkwood.c | 9 ++++++--
> > 5 files changed, 33 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> > index 6251100..5c8499b 100644
> > --- a/arch/arm/mach-mvebu/armada-370-xp.c
> > +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> > @@ -52,7 +52,7 @@ static void __noreturn armada_370_xp_reset_cpu(unsigned long addr)
> > ;
> > }
> >
> > -static int armada_370_xp_init_soc(void)
> > +static int armada_370_xp_init_soc(struct device_node *root, void *context)
> > {
> > unsigned long phys_base, phys_size;
> > u32 reg;
> > @@ -74,4 +74,9 @@ static int armada_370_xp_init_soc(void)
>
> Because armada_370_xp_init_soc() does
>
> mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
>
> right above, which will add the range(s) required for internal register
> of_fixup. Since this patch moved armada_370_xp_init_soc to the
> of_fixups, we don't fix this up for the initial DT tree.
>
> >
> > return 0;
> > }
> > -core_initcall(armada_370_xp_init_soc);
> > +
> > +static int armada_370_register_soc_fixup(void)
> > +{
>
> I guess moving mvebu_mbus_add_range() in here does not work, because
> it will add the armada_370_xp range also for dove and kirkwood.
Do we need a separate of_fixup registered for fixing up the mbus? Can't
we just call mvebu_mbus_of_fixup() directly from mvebu_mbus_add_range()?
This won't be very efficient for dove which calls mvebu_mbus_add_range()
twice so it has to iterate over the device tree twice, but it should
work, right?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 2/5] ARM: mvebu: Simplify memory init order
2014-09-17 6:45 ` Sascha Hauer
@ 2014-09-17 7:19 ` Sebastian Hesselbarth
2014-09-17 7:29 ` Sascha Hauer
0 siblings, 1 reply; 19+ messages in thread
From: Sebastian Hesselbarth @ 2014-09-17 7:19 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
On 09/17/2014 08:45 AM, Sascha Hauer wrote:
> On Tue, Sep 16, 2014 at 10:05:44PM +0200, Sebastian Hesselbarth wrote:
>> On 09/15/2014 09:41 AM, Sascha Hauer wrote:
>>> The initialisation of the memory nodes on mvebu is a bit
>>> compilcated:
>>>
>>> pure_initcall(mvebu_memory_fixup_register)
>>> of_register_fixup(mvebu_memory_of_fixup, NULL)
>>> core_initcall(kirkwood_init_soc)
>>> mvebu_set_memory()
>>> core_initcall(of_arm_init)
>>> of_fix_tree()
>>> mvebu_memory_of_fixup()
>>>
>>> First a mvebu common of_fixup function is registered, then the SoC
>>> calls mvebu_set_memory which stores the memory base and size in global
>>> variables. Afterwards the of_fixup is executed which fixes the memory
>>> nodes according to the global variables.
>>>
>>> Instead register a SoC specific fixup which directly calls mvebu_set_memory
>>> with the memory base and size as arguments:
>>>
>>> pure_initcall(kirkwood_register_soc_fixup);
>>> of_register_fixup(kirkwood_init_soc, NULL);
>>> core_initcall(of_arm_init)
>>> of_fix_tree()
>>> kirkwood_init_soc()
>>> mvebu_set_memory(phys_base, phys_size);
>>>
>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>
>> Hmm, this breaks Armada 370 and most likely also Armada XP. Actually,
>> it breaks any SoC that has a DTB with internal regs set to 0xd0000000.
>>
>>> ---
>>> arch/arm/mach-mvebu/armada-370-xp.c | 9 ++++++--
>>> arch/arm/mach-mvebu/common.c | 34 ++++++++++---------------------
>>> arch/arm/mach-mvebu/dove.c | 9 ++++++--
>>> arch/arm/mach-mvebu/include/mach/common.h | 2 +-
>>> arch/arm/mach-mvebu/kirkwood.c | 9 ++++++--
>>> 5 files changed, 33 insertions(+), 30 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
>>> index 6251100..5c8499b 100644
>>> --- a/arch/arm/mach-mvebu/armada-370-xp.c
>>> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
>>> @@ -52,7 +52,7 @@ static void __noreturn armada_370_xp_reset_cpu(unsigned long addr)
>>> ;
>>> }
>>>
>>> -static int armada_370_xp_init_soc(void)
>>> +static int armada_370_xp_init_soc(struct device_node *root, void *context)
>>> {
>>> unsigned long phys_base, phys_size;
>>> u32 reg;
>>> @@ -74,4 +74,9 @@ static int armada_370_xp_init_soc(void)
>>
>> Because armada_370_xp_init_soc() does
>>
>> mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
>>
>> right above, which will add the range(s) required for internal register
>> of_fixup. Since this patch moved armada_370_xp_init_soc to the
>> of_fixups, we don't fix this up for the initial DT tree.
>>
>>>
>>> return 0;
>>> }
>>> -core_initcall(armada_370_xp_init_soc);
>>> +
>>> +static int armada_370_register_soc_fixup(void)
>>> +{
>>
>> I guess moving mvebu_mbus_add_range() in here does not work, because
>> it will add the armada_370_xp range also for dove and kirkwood.
>
> Do we need a separate of_fixup registered for fixing up the mbus? Can't
> we just call mvebu_mbus_of_fixup() directly from mvebu_mbus_add_range()?
>
> This won't be very efficient for dove which calls mvebu_mbus_add_range()
> twice so it has to iterate over the device tree twice, but it should
> work, right?
It is not the number of iterations I am concerned about. In a Multi-SoC
environment, we add ranges for MBUS_ID(0xf0, 0x01) three times anyway
plus Dove's MBUS_ID(0xf0, 0x02).
Currently, we are lucky that MBUS_ID(0xf0, 0x01) is the same for all
SoCs and MBUS_ID(0xf0, 0x02) is exclusive for Dove. If we cross our
fingers and hope it will never change, we can just do:
static int dove_register_soc_fixup(void)
{
mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
mvebu_mbus_add_range(0xf0, 0x02, DOVE_REMAP_MC_REGS);
return of_register_fixup(dove_init_soc, NULL);
}
pure_initcall(dove_register_soc_fixup);
and
static int armada_370_xp_register_soc_fixup(void)
{
mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
return of_register_fixup(armada_370_xp_init_soc, NULL);
}
pure_initcall(armada_370_xp_register_soc_fixup);
and the same for Kirkwood.
If we want to make it safe for any future SoC that might break the
MBUS_ID() assumptions above, we can add the machine_id compatible
to mvebu_mbus_add_range(), i.e.
static int armada_370_xp_register_soc_fixup(void)
{
mvebu_mbus_add_range("marvell,armada-370-xp", 0xf0, 0x01,
MVEBU_REMAP_INT_REG_BASE);
return of_register_fixup(armada_370_xp_init_soc, NULL);
}
pure_initcall(armada_370_xp_register_soc_fixup);
If you put your current series into some branch I can pull, I can
add the required patches later today.
Sebastian
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 2/5] ARM: mvebu: Simplify memory init order
2014-09-17 7:19 ` Sebastian Hesselbarth
@ 2014-09-17 7:29 ` Sascha Hauer
0 siblings, 0 replies; 19+ messages in thread
From: Sascha Hauer @ 2014-09-17 7:29 UTC (permalink / raw)
To: Sebastian Hesselbarth; +Cc: barebox
On Wed, Sep 17, 2014 at 09:19:33AM +0200, Sebastian Hesselbarth wrote:
> On 09/17/2014 08:45 AM, Sascha Hauer wrote:
> >On Tue, Sep 16, 2014 at 10:05:44PM +0200, Sebastian Hesselbarth wrote:
> >>On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> >>>The initialisation of the memory nodes on mvebu is a bit
> >>>compilcated:
> >>>
> >>>pure_initcall(mvebu_memory_fixup_register)
> >>> of_register_fixup(mvebu_memory_of_fixup, NULL)
> >>>core_initcall(kirkwood_init_soc)
> >>> mvebu_set_memory()
> >>>core_initcall(of_arm_init)
> >>> of_fix_tree()
> >>> mvebu_memory_of_fixup()
> >>>
> >>>First a mvebu common of_fixup function is registered, then the SoC
> >>>calls mvebu_set_memory which stores the memory base and size in global
> >>>variables. Afterwards the of_fixup is executed which fixes the memory
> >>>nodes according to the global variables.
> >>>
> >>>Instead register a SoC specific fixup which directly calls mvebu_set_memory
> >>>with the memory base and size as arguments:
> >>>
> >>>pure_initcall(kirkwood_register_soc_fixup);
> >>> of_register_fixup(kirkwood_init_soc, NULL);
> >>>core_initcall(of_arm_init)
> >>> of_fix_tree()
> >>> kirkwood_init_soc()
> >>> mvebu_set_memory(phys_base, phys_size);
> >>>
> >>>Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >>
> >>Hmm, this breaks Armada 370 and most likely also Armada XP. Actually,
> >>it breaks any SoC that has a DTB with internal regs set to 0xd0000000.
> >>
> >>>---
> >>> arch/arm/mach-mvebu/armada-370-xp.c | 9 ++++++--
> >>> arch/arm/mach-mvebu/common.c | 34 ++++++++++---------------------
> >>> arch/arm/mach-mvebu/dove.c | 9 ++++++--
> >>> arch/arm/mach-mvebu/include/mach/common.h | 2 +-
> >>> arch/arm/mach-mvebu/kirkwood.c | 9 ++++++--
> >>> 5 files changed, 33 insertions(+), 30 deletions(-)
> >>>
> >>>diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> >>>index 6251100..5c8499b 100644
> >>>--- a/arch/arm/mach-mvebu/armada-370-xp.c
> >>>+++ b/arch/arm/mach-mvebu/armada-370-xp.c
> >>>@@ -52,7 +52,7 @@ static void __noreturn armada_370_xp_reset_cpu(unsigned long addr)
> >>> ;
> >>> }
> >>>
> >>>-static int armada_370_xp_init_soc(void)
> >>>+static int armada_370_xp_init_soc(struct device_node *root, void *context)
> >>> {
> >>> unsigned long phys_base, phys_size;
> >>> u32 reg;
> >>>@@ -74,4 +74,9 @@ static int armada_370_xp_init_soc(void)
> >>
> >>Because armada_370_xp_init_soc() does
> >>
> >> mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
> >>
> >>right above, which will add the range(s) required for internal register
> >>of_fixup. Since this patch moved armada_370_xp_init_soc to the
> >>of_fixups, we don't fix this up for the initial DT tree.
> >>
> >>>
> >>> return 0;
> >>> }
> >>>-core_initcall(armada_370_xp_init_soc);
> >>>+
> >>>+static int armada_370_register_soc_fixup(void)
> >>>+{
> >>
> >>I guess moving mvebu_mbus_add_range() in here does not work, because
> >>it will add the armada_370_xp range also for dove and kirkwood.
> >
> >Do we need a separate of_fixup registered for fixing up the mbus? Can't
> >we just call mvebu_mbus_of_fixup() directly from mvebu_mbus_add_range()?
> >
> >This won't be very efficient for dove which calls mvebu_mbus_add_range()
> >twice so it has to iterate over the device tree twice, but it should
> >work, right?
>
> It is not the number of iterations I am concerned about. In a Multi-SoC
> environment, we add ranges for MBUS_ID(0xf0, 0x01) three times anyway
> plus Dove's MBUS_ID(0xf0, 0x02).
>
> Currently, we are lucky that MBUS_ID(0xf0, 0x01) is the same for all
> SoCs and MBUS_ID(0xf0, 0x02) is exclusive for Dove. If we cross our
> fingers and hope it will never change, we can just do:
>
> static int dove_register_soc_fixup(void)
> {
> mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
> mvebu_mbus_add_range(0xf0, 0x02, DOVE_REMAP_MC_REGS);
> return of_register_fixup(dove_init_soc, NULL);
> }
> pure_initcall(dove_register_soc_fixup);
>
> and
>
> static int armada_370_xp_register_soc_fixup(void)
> {
> mvebu_mbus_add_range(0xf0, 0x01, MVEBU_REMAP_INT_REG_BASE);
> return of_register_fixup(armada_370_xp_init_soc, NULL);
> }
> pure_initcall(armada_370_xp_register_soc_fixup);
>
> and the same for Kirkwood.
>
> If we want to make it safe for any future SoC that might break the
> MBUS_ID() assumptions above, we can add the machine_id compatible
> to mvebu_mbus_add_range(), i.e.
>
> static int armada_370_xp_register_soc_fixup(void)
> {
> mvebu_mbus_add_range("marvell,armada-370-xp", 0xf0, 0x01,
> MVEBU_REMAP_INT_REG_BASE);
> return of_register_fixup(armada_370_xp_init_soc, NULL);
> }
> pure_initcall(armada_370_xp_register_soc_fixup);
>
> If you put your current series into some branch I can pull, I can
> add the required patches later today.
I pushed it to the work/mvebu-multisoc branch in the master repository.
It should have your previous comments integrated.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 3/5] ARM: mvebu: Check for correct SoC in of_fixup callback
2014-09-15 7:41 mvebu multi SoC support Sascha Hauer
2014-09-15 7:41 ` [PATCH 1/5] ARM: mvebu: Add common reset_cpu function Sascha Hauer
2014-09-15 7:41 ` [PATCH 2/5] ARM: mvebu: Simplify memory init order Sascha Hauer
@ 2014-09-15 7:41 ` Sascha Hauer
2014-09-15 7:41 ` [PATCH 4/5] ARM: mvebu: Allow multiple SoCs Sascha Hauer
` (2 subsequent siblings)
5 siblings, 0 replies; 19+ messages in thread
From: Sascha Hauer @ 2014-09-15 7:41 UTC (permalink / raw)
To: barebox
Only run the fixup when we are actually on the corresponding
SoC.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-mvebu/armada-370-xp.c | 3 +++
arch/arm/mach-mvebu/dove.c | 3 +++
arch/arm/mach-mvebu/kirkwood.c | 3 +++
3 files changed, 9 insertions(+)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 5c8499b..86a0993 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -57,6 +57,9 @@ static int armada_370_xp_init_soc(struct device_node *root, void *context)
unsigned long phys_base, phys_size;
u32 reg;
+ if (!of_machine_is_compatible("marvell,armada-370-xp"))
+ return 0;
+
mvebu_set_reset(armada_370_xp_reset_cpu);
barebox_set_model("Marvell Armada 370/XP");
diff --git a/arch/arm/mach-mvebu/dove.c b/arch/arm/mach-mvebu/dove.c
index 58d5439..8ec0e7c 100644
--- a/arch/arm/mach-mvebu/dove.c
+++ b/arch/arm/mach-mvebu/dove.c
@@ -81,6 +81,9 @@ static int dove_init_soc(struct device_node *root, void *context)
{
unsigned long phys_base, phys_size;
+ if (!of_machine_is_compatible("marvell,dove"))
+ return 0;
+
mvebu_set_reset(dove_reset_cpu);
barebox_set_model("Marvell Dove");
diff --git a/arch/arm/mach-mvebu/kirkwood.c b/arch/arm/mach-mvebu/kirkwood.c
index a4b0853..3251120 100644
--- a/arch/arm/mach-mvebu/kirkwood.c
+++ b/arch/arm/mach-mvebu/kirkwood.c
@@ -55,6 +55,9 @@ static int kirkwood_init_soc(struct device_node *root, void *context)
{
unsigned long phys_base, phys_size;
+ if (!of_machine_is_compatible("marvell,kirkwood"))
+ return 0;
+
mvebu_set_reset(kirkwood_reset_cpu);
barebox_set_model("Marvell Kirkwood");
--
2.1.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4/5] ARM: mvebu: Allow multiple SoCs
2014-09-15 7:41 mvebu multi SoC support Sascha Hauer
` (2 preceding siblings ...)
2014-09-15 7:41 ` [PATCH 3/5] ARM: mvebu: Check for correct SoC in of_fixup callback Sascha Hauer
@ 2014-09-15 7:41 ` Sascha Hauer
2014-09-15 8:00 ` Sebastian Hesselbarth
2014-09-15 7:41 ` [PATCH 5/5] ARM: Add mvebu_defconfig Sascha Hauer
2014-09-15 8:09 ` mvebu multi SoC support Ezequiel Garcia
5 siblings, 1 reply; 19+ messages in thread
From: Sascha Hauer @ 2014-09-15 7:41 UTC (permalink / raw)
To: barebox
Now that the correct SoC specific memory fixup function is called
we can allow to select multiple SoCs in Kconfig.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-mvebu/Kconfig | 38 ++++++++++++--------------------------
1 file changed, 12 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 3270f92..c5e6b59 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -7,87 +7,73 @@ config ARCH_TEXT_BASE
default 0x2000000 if ARCH_DOVE
default 0x2000000 if ARCH_KIRKWOOD
-choice
- prompt "Marvell EBU Processor"
-
config ARCH_ARMADA_370
- bool "Armada 370"
+ bool
select CPU_V7
select CLOCKSOURCE_MVEBU
select PINCTRL_ARMADA_370
config ARCH_ARMADA_XP
- bool "Armada XP"
+ bool
select CPU_V7
select CLOCKSOURCE_MVEBU
select PINCTRL_ARMADA_XP
config ARCH_DOVE
- bool "Dove 88AP510"
+ bool
select CPU_V7
select CLOCKSOURCE_ORION
select PINCTRL_DOVE
config ARCH_KIRKWOOD
- bool "Kirkwood"
+ bool
select CPU_FEROCEON
select CLOCKSOURCE_ORION
select PINCTRL_KIRKWOOD
-endchoice
-
#
# Armada 370 SoC boards
#
-
-if ARCH_ARMADA_370
-
+#
config MACH_GLOBALSCALE_MIRABOX
bool "Globalscale Mirabox"
-
-endif # ARCH_ARMADA_370
+ select ARCH_ARMADA_370
#
# Armada XP SoC boards
#
-if ARCH_ARMADA_XP
-
config MACH_PLATHOME_OPENBLOCKS_AX3
bool "PlatHome OpenBlocks AX3"
+ select ARCH_ARMADA_XP
config MACH_MARVELL_ARMADA_XP_GP
bool "Marvell Armada XP GP"
-
-endif # ARCH_ARMADA_XP
+ select ARCH_ARMADA_XP
#
# Dove 88AP510 SoC boards
#
-if ARCH_DOVE
-
config MACH_SOLIDRUN_CUBOX
bool "SolidRun CuBox"
-
-endif # ARCH_DOVE
+ select ARCH_DOVE
#
# Kirkwood SoC boards
#
-if ARCH_KIRKWOOD
-
config MACH_GLOBALSCALE_GURUPLUG
bool "Guruplug"
+ select ARCH_KIRKWOOD
config MACH_PLATHOME_OPENBLOCKS_A6
bool "PlatHome OpenBlocks A6"
+ select ARCH_KIRKWOOD
config MACH_USI_TOPKICK
bool "Topkick"
-
-endif # ARCH_KIRKWOOD
+ select ARCH_KIRKWOOD
#
# Common options
--
2.1.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 4/5] ARM: mvebu: Allow multiple SoCs
2014-09-15 7:41 ` [PATCH 4/5] ARM: mvebu: Allow multiple SoCs Sascha Hauer
@ 2014-09-15 8:00 ` Sebastian Hesselbarth
2014-09-15 9:13 ` Sascha Hauer
0 siblings, 1 reply; 19+ messages in thread
From: Sebastian Hesselbarth @ 2014-09-15 8:00 UTC (permalink / raw)
To: Sascha Hauer, barebox
On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> Now that the correct SoC specific memory fixup function is called
> we can allow to select multiple SoCs in Kconfig.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha,
thanks for the patches, I'll give them a try later. FWIW, this
patch allows to build Kirkwood together with Dove and Armada ones,
which will not work at all. Kirkwood is armv5, while the others
are armv7. There is no way you run a multiv7 barebox on kirkwood,
right?
Sebastian
> ---
> arch/arm/mach-mvebu/Kconfig | 38 ++++++++++++--------------------------
> 1 file changed, 12 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index 3270f92..c5e6b59 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -7,87 +7,73 @@ config ARCH_TEXT_BASE
> default 0x2000000 if ARCH_DOVE
> default 0x2000000 if ARCH_KIRKWOOD
>
> -choice
> - prompt "Marvell EBU Processor"
> -
> config ARCH_ARMADA_370
> - bool "Armada 370"
> + bool
> select CPU_V7
> select CLOCKSOURCE_MVEBU
> select PINCTRL_ARMADA_370
>
> config ARCH_ARMADA_XP
> - bool "Armada XP"
> + bool
> select CPU_V7
> select CLOCKSOURCE_MVEBU
> select PINCTRL_ARMADA_XP
>
> config ARCH_DOVE
> - bool "Dove 88AP510"
> + bool
> select CPU_V7
> select CLOCKSOURCE_ORION
> select PINCTRL_DOVE
>
> config ARCH_KIRKWOOD
> - bool "Kirkwood"
> + bool
> select CPU_FEROCEON
> select CLOCKSOURCE_ORION
> select PINCTRL_KIRKWOOD
>
> -endchoice
> -
> #
> # Armada 370 SoC boards
> #
> -
> -if ARCH_ARMADA_370
> -
> +#
> config MACH_GLOBALSCALE_MIRABOX
> bool "Globalscale Mirabox"
> -
> -endif # ARCH_ARMADA_370
> + select ARCH_ARMADA_370
>
> #
> # Armada XP SoC boards
> #
>
> -if ARCH_ARMADA_XP
> -
> config MACH_PLATHOME_OPENBLOCKS_AX3
> bool "PlatHome OpenBlocks AX3"
> + select ARCH_ARMADA_XP
>
> config MACH_MARVELL_ARMADA_XP_GP
> bool "Marvell Armada XP GP"
> -
> -endif # ARCH_ARMADA_XP
> + select ARCH_ARMADA_XP
>
> #
> # Dove 88AP510 SoC boards
> #
>
> -if ARCH_DOVE
> -
> config MACH_SOLIDRUN_CUBOX
> bool "SolidRun CuBox"
> -
> -endif # ARCH_DOVE
> + select ARCH_DOVE
>
> #
> # Kirkwood SoC boards
> #
>
> -if ARCH_KIRKWOOD
> -
> config MACH_GLOBALSCALE_GURUPLUG
> bool "Guruplug"
> + select ARCH_KIRKWOOD
>
> config MACH_PLATHOME_OPENBLOCKS_A6
> bool "PlatHome OpenBlocks A6"
> + select ARCH_KIRKWOOD
>
> config MACH_USI_TOPKICK
> bool "Topkick"
> -
> -endif # ARCH_KIRKWOOD
> + select ARCH_KIRKWOOD
>
> #
> # Common options
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 4/5] ARM: mvebu: Allow multiple SoCs
2014-09-15 8:00 ` Sebastian Hesselbarth
@ 2014-09-15 9:13 ` Sascha Hauer
2014-09-15 21:12 ` Sebastian Hesselbarth
0 siblings, 1 reply; 19+ messages in thread
From: Sascha Hauer @ 2014-09-15 9:13 UTC (permalink / raw)
To: Sebastian Hesselbarth; +Cc: barebox
On Mon, Sep 15, 2014 at 10:00:40AM +0200, Sebastian Hesselbarth wrote:
> On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> >Now that the correct SoC specific memory fixup function is called
> >we can allow to select multiple SoCs in Kconfig.
> >
> >Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> Sascha,
>
> thanks for the patches, I'll give them a try later. FWIW, this
> patch allows to build Kirkwood together with Dove and Armada ones,
> which will not work at all. Kirkwood is armv5, while the others
> are armv7. There is no way you run a multiv7 barebox on kirkwood,
> right?
Oh, I didn't realize that Kirkwood is armv5. It should work though.
The only reason to additionally add a mvebu_v7_config is to make
Thumb2 mode available to the SoCs that support it.
> > #
> >
> >-if ARCH_KIRKWOOD
Instead of removing this I could turn this into
comment "Kirkwood based boards"
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 4/5] ARM: mvebu: Allow multiple SoCs
2014-09-15 9:13 ` Sascha Hauer
@ 2014-09-15 21:12 ` Sebastian Hesselbarth
2014-09-16 6:00 ` Sascha Hauer
0 siblings, 1 reply; 19+ messages in thread
From: Sebastian Hesselbarth @ 2014-09-15 21:12 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
On 09/15/2014 11:13 AM, Sascha Hauer wrote:
> On Mon, Sep 15, 2014 at 10:00:40AM +0200, Sebastian Hesselbarth wrote:
>> On 09/15/2014 09:41 AM, Sascha Hauer wrote:
>>> Now that the correct SoC specific memory fixup function is called
>>> we can allow to select multiple SoCs in Kconfig.
>>>
>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>
>> Sascha,
>>
>> thanks for the patches, I'll give them a try later. FWIW, this
>> patch allows to build Kirkwood together with Dove and Armada ones,
>> which will not work at all. Kirkwood is armv5, while the others
>> are armv7. There is no way you run a multiv7 barebox on kirkwood,
>> right?
>
> Oh, I didn't realize that Kirkwood is armv5. It should work though.
> The only reason to additionally add a mvebu_v7_config is to make
> Thumb2 mode available to the SoCs that support it.
I did some initial testing on Kirkwood Guruplug. In mvebu_defconfig
you select CONFIG_AEABI=y resulting in
$ readelf -h barebox | grep Flags
Flags: 0x5000000, Version5 EABI
And failing on Kirkwood at some places with
Board: Globalscale Technologies Guruplug Server Plus
SoC: Marvell 6281 rev 3
mdio_bus: miibus0: probed
unable to handle paging request at address 0x01f0ebac
pc : [<03e0de20>] lr : [<03e0de08>]
sp : 03fffeb0 ip : 03fffea8 fp : 00000001
r10: 03ff4000 r9 : 01000e00 r8 : 01003a84
r7 : 01f07324 r6 : 03e55f88 r5 : 01f0eaa4 r4 : 01f0eaa8
r3 : 00000000 r2 : 00000040 r1 : 00000104 r0 : 01f11094
Flags: Nzcv IRQs off FIQs off Mode SVC_32
[<03e0de20>] (mdio_bus_probe+0x150/0x188) from [<03e0cb24>]
(device_probe+0x1c/0x70)
[<03e0cb24>] (device_probe+0x1c/0x70) from [<03e0cbbc>]
(match.part.2+0x44/0x50)
[<03e0cbbc>] (match.part.2+0x44/0x50) from [<03e0cda8>]
(register_device+0x118/0x168)
[<03e0cda8>] (register_device+0x118/0x168) from [<03e0d2e8>]
(phy_register_device+0x2c/0x94)
[<03e0d2e8>] (phy_register_device+0x2c/0x94) from [<03e0df9c>]
(mdiobus_register+0x144/0x18c)
[<03e0df9c>] (mdiobus_register+0x144/0x18c) from [<03e0ce8c>]
(platform_probe+0x10/0x14)
[<03e0ce8c>] (platform_probe+0x10/0x14) from [<03e0cb24>]
(device_probe+0x1c/0x70)
[<03e0cb24>] (device_probe+0x1c/0x70) from [<03e0cbbc>]
(match.part.2+0x44/0x50)
[<03e0cbbc>] (match.part.2+0x44/0x50) from [<03e0cc58>]
(register_driver+0x90/0xc8)
[<03e0cc58>] (register_driver+0x90/0xc8) from [<03e00ae8>]
(start_barebox+0x28/0x130)
[<03e00ae8>] (start_barebox+0x28/0x130) from [<03e3e3e8>]
(__start+0xf8/0x10c)
[<03e3e3e8>] (__start+0xf8/0x10c) from [<03e00004>]
(__bare_init_start+0x0/0x10)
[<03e3dce0>] (unwind_backtrace+0x0/0xa0) from [<03e240a8>] (panic+0x28/0x48)
[<03e240a8>] (panic+0x28/0x48) from [<03e3e220>] (do_exception+0x10/0x14)
[<03e3e220>] (do_exception+0x10/0x14) from [<03e3e2ac>]
(do_data_abort+0x2c/0x38)
[<03e3e2ac>] (do_data_abort+0x2c/0x38) from [<03e3dee8>]
(data_abort+0x48/0x60)
I first noticed that with orion-mdio disabled and on calling
devinfo. Looks like u64 dereferencing is definitely causing
this but I admit, I haven't looked at mdio.
Disabling CONFIG_AEABI gives
$ readelf -h barebox | grep Flags
Flags: 0x600, GNU EABI, software FP, VFP
which also works in a Multi-SoC image on Kirkwood.
>>> #
>>>
>>> -if ARCH_KIRKWOOD
>
> Instead of removing this I could turn this into
>
> comment "Kirkwood based boards"
I am not too much into v5/v7 differences (or EABI FWIW). If
you say, a multi_v5+v7 image is fine, I am too.
I'll continue testing on !KIRKWOOD tomorrow evening.
Sebastian
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 4/5] ARM: mvebu: Allow multiple SoCs
2014-09-15 21:12 ` Sebastian Hesselbarth
@ 2014-09-16 6:00 ` Sascha Hauer
0 siblings, 0 replies; 19+ messages in thread
From: Sascha Hauer @ 2014-09-16 6:00 UTC (permalink / raw)
To: Sebastian Hesselbarth; +Cc: barebox
On Mon, Sep 15, 2014 at 11:12:03PM +0200, Sebastian Hesselbarth wrote:
> On 09/15/2014 11:13 AM, Sascha Hauer wrote:
> > On Mon, Sep 15, 2014 at 10:00:40AM +0200, Sebastian Hesselbarth wrote:
> >> On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> >>> Now that the correct SoC specific memory fixup function is called
> >>> we can allow to select multiple SoCs in Kconfig.
> >>>
> >>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >>
> >> Sascha,
> >>
> >> thanks for the patches, I'll give them a try later. FWIW, this
> >> patch allows to build Kirkwood together with Dove and Armada ones,
> >> which will not work at all. Kirkwood is armv5, while the others
> >> are armv7. There is no way you run a multiv7 barebox on kirkwood,
> >> right?
> >
> > Oh, I didn't realize that Kirkwood is armv5. It should work though.
> > The only reason to additionally add a mvebu_v7_config is to make
> > Thumb2 mode available to the SoCs that support it.
>
> I did some initial testing on Kirkwood Guruplug. In mvebu_defconfig
> you select CONFIG_AEABI=y resulting in
>
> $ readelf -h barebox | grep Flags
> Flags: 0x5000000, Version5 EABI
>
> And failing on Kirkwood at some places with
>
> Board: Globalscale Technologies Guruplug Server Plus
> SoC: Marvell 6281 rev 3
> mdio_bus: miibus0: probed
> unable to handle paging request at address 0x01f0ebac
> pc : [<03e0de20>] lr : [<03e0de08>]
> sp : 03fffeb0 ip : 03fffea8 fp : 00000001
> r10: 03ff4000 r9 : 01000e00 r8 : 01003a84
> r7 : 01f07324 r6 : 03e55f88 r5 : 01f0eaa4 r4 : 01f0eaa8
> r3 : 00000000 r2 : 00000040 r1 : 00000104 r0 : 01f11094
> Flags: Nzcv IRQs off FIQs off Mode SVC_32
> [<03e0de20>] (mdio_bus_probe+0x150/0x188) from [<03e0cb24>]
> (device_probe+0x1c/0x70)
> [<03e0cb24>] (device_probe+0x1c/0x70) from [<03e0cbbc>]
> (match.part.2+0x44/0x50)
> [<03e0cbbc>] (match.part.2+0x44/0x50) from [<03e0cda8>]
> (register_device+0x118/0x168)
> [<03e0cda8>] (register_device+0x118/0x168) from [<03e0d2e8>]
> (phy_register_device+0x2c/0x94)
> [<03e0d2e8>] (phy_register_device+0x2c/0x94) from [<03e0df9c>]
> (mdiobus_register+0x144/0x18c)
> [<03e0df9c>] (mdiobus_register+0x144/0x18c) from [<03e0ce8c>]
> (platform_probe+0x10/0x14)
> [<03e0ce8c>] (platform_probe+0x10/0x14) from [<03e0cb24>]
> (device_probe+0x1c/0x70)
> [<03e0cb24>] (device_probe+0x1c/0x70) from [<03e0cbbc>]
> (match.part.2+0x44/0x50)
> [<03e0cbbc>] (match.part.2+0x44/0x50) from [<03e0cc58>]
> (register_driver+0x90/0xc8)
> [<03e0cc58>] (register_driver+0x90/0xc8) from [<03e00ae8>]
> (start_barebox+0x28/0x130)
> [<03e00ae8>] (start_barebox+0x28/0x130) from [<03e3e3e8>]
> (__start+0xf8/0x10c)
> [<03e3e3e8>] (__start+0xf8/0x10c) from [<03e00004>]
> (__bare_init_start+0x0/0x10)
>
> [<03e3dce0>] (unwind_backtrace+0x0/0xa0) from [<03e240a8>] (panic+0x28/0x48)
> [<03e240a8>] (panic+0x28/0x48) from [<03e3e220>] (do_exception+0x10/0x14)
> [<03e3e220>] (do_exception+0x10/0x14) from [<03e3e2ac>]
> (do_data_abort+0x2c/0x38)
> [<03e3e2ac>] (do_data_abort+0x2c/0x38) from [<03e3dee8>]
> (data_abort+0x48/0x60)
>
> I first noticed that with orion-mdio disabled and on calling
> devinfo. Looks like u64 dereferencing is definitely causing
> this but I admit, I haven't looked at mdio.
Uh, that's strange. I never had any problems with enabling/disabling this
options.
>
> Disabling CONFIG_AEABI gives
>
> $ readelf -h barebox | grep Flags
> Flags: 0x600, GNU EABI, software FP, VFP
>
> which also works in a Multi-SoC image on Kirkwood.
>
> >>> #
> >>>
> >>> -if ARCH_KIRKWOOD
> >
> > Instead of removing this I could turn this into
> >
> > comment "Kirkwood based boards"
>
> I am not too much into v5/v7 differences (or EABI FWIW). If
> you say, a multi_v5+v7 image is fine, I am too.
In the Kernel compiling for armv5 and armv7 is not possible due to
changes in the spinlock implementations. Doing that would involve
patching the Kernel binary during startup. We don't have locking
in barebox. So until we introduce locking we don't have a problem ;)
>
> I'll continue testing on !KIRKWOOD tomorrow evening.
Thanks
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 5/5] ARM: Add mvebu_defconfig
2014-09-15 7:41 mvebu multi SoC support Sascha Hauer
` (3 preceding siblings ...)
2014-09-15 7:41 ` [PATCH 4/5] ARM: mvebu: Allow multiple SoCs Sascha Hauer
@ 2014-09-15 7:41 ` Sascha Hauer
2014-09-15 21:15 ` Sebastian Hesselbarth
2014-09-15 8:09 ` mvebu multi SoC support Ezequiel Garcia
5 siblings, 1 reply; 19+ messages in thread
From: Sascha Hauer @ 2014-09-15 7:41 UTC (permalink / raw)
To: barebox
This adds a mvebu_defconfig which enables all mvebu based boards.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/configs/mvebu_defconfig | 108 +++++++++++++++++++++++++++++++++++++++
1 file changed, 108 insertions(+)
create mode 100644 arch/arm/configs/mvebu_defconfig
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
new file mode 100644
index 0000000..87b35f0
--- /dev/null
+++ b/arch/arm/configs/mvebu_defconfig
@@ -0,0 +1,108 @@
+CONFIG_ARCH_MVEBU=y
+CONFIG_MACH_GLOBALSCALE_MIRABOX=y
+CONFIG_MACH_PLATHOME_OPENBLOCKS_AX3=y
+CONFIG_MACH_MARVELL_ARMADA_XP_GP=y
+CONFIG_MACH_SOLIDRUN_CUBOX=y
+CONFIG_MACH_GLOBALSCALE_GURUPLUG=y
+CONFIG_MACH_PLATHOME_OPENBLOCKS_A6=y
+CONFIG_MACH_USI_TOPKICK=y
+CONFIG_AEABI=y
+CONFIG_ARM_OPTIMZED_STRING_FUNCTIONS=y
+CONFIG_ARM_UNWIND=y
+CONFIG_MMU=y
+CONFIG_TEXT_BASE=0x0
+CONFIG_MALLOC_SIZE=0x0
+CONFIG_MALLOC_TLSF=y
+CONFIG_KALLSYMS=y
+CONFIG_RELOCATABLE=y
+CONFIG_HUSH_FANCY_PROMPT=y
+CONFIG_CMDLINE_EDITING=y
+CONFIG_AUTO_COMPLETE=y
+CONFIG_MENU=y
+CONFIG_BLSPEC=y
+CONFIG_IMD_TARGET=y
+CONFIG_CONSOLE_ACTIVATE_NONE=y
+CONFIG_PARTITION_DISK_EFI=y
+CONFIG_LONGHELP=y
+CONFIG_CMD_IOMEM=y
+CONFIG_CMD_IMD=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_ARM_MMUINFO=y
+CONFIG_CMD_BOOT=y
+CONFIG_CMD_BOOTM_SHOW_TYPE=y
+CONFIG_CMD_BOOTM_VERBOSE=y
+CONFIG_CMD_BOOTM_INITRD=y
+CONFIG_CMD_BOOTM_OFTREE=y
+CONFIG_CMD_BOOTM_OFTREE_UIMAGE=y
+CONFIG_CMD_GO=y
+CONFIG_CMD_LOADS=y
+CONFIG_CMD_LOADY=y
+CONFIG_CMD_RESET=y
+CONFIG_CMD_UIMAGE=y
+CONFIG_CMD_PARTITION=y
+CONFIG_CMD_AUTOMOUNT=y
+CONFIG_CMD_EXPORT=y
+CONFIG_CMD_GLOBAL=y
+CONFIG_CMD_LOADENV=y
+CONFIG_CMD_PRINTENV=y
+CONFIG_CMD_MAGICVAR=y
+CONFIG_CMD_MAGICVAR_HELP=y
+CONFIG_CMD_SAVEENV=y
+CONFIG_CMD_BASENAME=y
+CONFIG_CMD_DIRNAME=y
+CONFIG_CMD_FILETYPE=y
+CONFIG_CMD_LN=y
+CONFIG_CMD_MD5SUM=y
+CONFIG_CMD_READLINK=y
+CONFIG_CMD_SHA1SUM=y
+CONFIG_CMD_SHA224SUM=y
+CONFIG_CMD_SHA256SUM=y
+CONFIG_CMD_UNCOMPRESS=y
+CONFIG_CMD_GETOPT=y
+CONFIG_CMD_LET=y
+CONFIG_CMD_MSLEEP=y
+CONFIG_CMD_READF=y
+CONFIG_CMD_SLEEP=y
+CONFIG_CMD_ECHO_E=y
+CONFIG_CMD_EDIT=y
+CONFIG_CMD_MENU=y
+CONFIG_CMD_MENU_MANAGEMENT=y
+CONFIG_CMD_MENUTREE=y
+CONFIG_CMD_READLINE=y
+CONFIG_CMD_TIMEOUT=y
+CONFIG_CMD_CRC=y
+CONFIG_CMD_CRC_CMP=y
+CONFIG_CMD_CLK=y
+CONFIG_CMD_DETECT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_LED=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_LED_TRIGGER=y
+CONFIG_CMD_WD=y
+CONFIG_CMD_OF_NODE=y
+CONFIG_CMD_OF_PROPERTY=y
+CONFIG_CMD_OFTREE=y
+CONFIG_CMD_TIME=y
+CONFIG_OFDEVICE=y
+CONFIG_OF_BAREBOX_DRIVERS=y
+CONFIG_DRIVER_SERIAL_NS16550=y
+CONFIG_I2C=y
+CONFIG_MTD=y
+CONFIG_MTD_M25P80=y
+CONFIG_DISK_AHCI=y
+CONFIG_USB_HOST=y
+CONFIG_USB_EHCI=y
+CONFIG_USB_STORAGE=y
+CONFIG_MCI=y
+CONFIG_MCI_STARTUP=y
+CONFIG_MCI_MMC_BOOT_PARTITIONS=y
+CONFIG_LED=y
+CONFIG_LED_TRIGGERS=y
+CONFIG_WATCHDOG=y
+CONFIG_FS_CRAMFS=y
+CONFIG_FS_EXT4=y
+CONFIG_FS_FAT=y
+CONFIG_FS_FAT_WRITE=y
+CONFIG_FS_FAT_LFN=y
+CONFIG_BZLIB=y
+CONFIG_LZO_DECOMPRESS=y
--
2.1.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 5/5] ARM: Add mvebu_defconfig
2014-09-15 7:41 ` [PATCH 5/5] ARM: Add mvebu_defconfig Sascha Hauer
@ 2014-09-15 21:15 ` Sebastian Hesselbarth
2014-09-16 6:05 ` Sascha Hauer
0 siblings, 1 reply; 19+ messages in thread
From: Sebastian Hesselbarth @ 2014-09-15 21:15 UTC (permalink / raw)
To: Sascha Hauer, barebox
On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> This adds a mvebu_defconfig which enables all mvebu based boards.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha,
we should also select
CONFIG_DRIVER_NET_ORION=y
CONFIG_MDIO_MVEBU=y
CONFIG_MARVELL_PHY=y
and some NET commands would be helpful too.
Also,
CONFIG_DRIVER_NET_MVNETA=y
_if_ Ezequiel reposts mvneta before this gets in.
Sebastian
> ---
> arch/arm/configs/mvebu_defconfig | 108 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 108 insertions(+)
> create mode 100644 arch/arm/configs/mvebu_defconfig
>
> diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
> new file mode 100644
> index 0000000..87b35f0
> --- /dev/null
> +++ b/arch/arm/configs/mvebu_defconfig
> @@ -0,0 +1,108 @@
> +CONFIG_ARCH_MVEBU=y
> +CONFIG_MACH_GLOBALSCALE_MIRABOX=y
> +CONFIG_MACH_PLATHOME_OPENBLOCKS_AX3=y
> +CONFIG_MACH_MARVELL_ARMADA_XP_GP=y
> +CONFIG_MACH_SOLIDRUN_CUBOX=y
> +CONFIG_MACH_GLOBALSCALE_GURUPLUG=y
> +CONFIG_MACH_PLATHOME_OPENBLOCKS_A6=y
> +CONFIG_MACH_USI_TOPKICK=y
> +CONFIG_AEABI=y
> +CONFIG_ARM_OPTIMZED_STRING_FUNCTIONS=y
> +CONFIG_ARM_UNWIND=y
> +CONFIG_MMU=y
> +CONFIG_TEXT_BASE=0x0
> +CONFIG_MALLOC_SIZE=0x0
> +CONFIG_MALLOC_TLSF=y
> +CONFIG_KALLSYMS=y
> +CONFIG_RELOCATABLE=y
> +CONFIG_HUSH_FANCY_PROMPT=y
> +CONFIG_CMDLINE_EDITING=y
> +CONFIG_AUTO_COMPLETE=y
> +CONFIG_MENU=y
> +CONFIG_BLSPEC=y
> +CONFIG_IMD_TARGET=y
> +CONFIG_CONSOLE_ACTIVATE_NONE=y
> +CONFIG_PARTITION_DISK_EFI=y
> +CONFIG_LONGHELP=y
> +CONFIG_CMD_IOMEM=y
> +CONFIG_CMD_IMD=y
> +CONFIG_CMD_MEMINFO=y
> +CONFIG_CMD_ARM_MMUINFO=y
> +CONFIG_CMD_BOOT=y
> +CONFIG_CMD_BOOTM_SHOW_TYPE=y
> +CONFIG_CMD_BOOTM_VERBOSE=y
> +CONFIG_CMD_BOOTM_INITRD=y
> +CONFIG_CMD_BOOTM_OFTREE=y
> +CONFIG_CMD_BOOTM_OFTREE_UIMAGE=y
> +CONFIG_CMD_GO=y
> +CONFIG_CMD_LOADS=y
> +CONFIG_CMD_LOADY=y
> +CONFIG_CMD_RESET=y
> +CONFIG_CMD_UIMAGE=y
> +CONFIG_CMD_PARTITION=y
> +CONFIG_CMD_AUTOMOUNT=y
> +CONFIG_CMD_EXPORT=y
> +CONFIG_CMD_GLOBAL=y
> +CONFIG_CMD_LOADENV=y
> +CONFIG_CMD_PRINTENV=y
> +CONFIG_CMD_MAGICVAR=y
> +CONFIG_CMD_MAGICVAR_HELP=y
> +CONFIG_CMD_SAVEENV=y
> +CONFIG_CMD_BASENAME=y
> +CONFIG_CMD_DIRNAME=y
> +CONFIG_CMD_FILETYPE=y
> +CONFIG_CMD_LN=y
> +CONFIG_CMD_MD5SUM=y
> +CONFIG_CMD_READLINK=y
> +CONFIG_CMD_SHA1SUM=y
> +CONFIG_CMD_SHA224SUM=y
> +CONFIG_CMD_SHA256SUM=y
> +CONFIG_CMD_UNCOMPRESS=y
> +CONFIG_CMD_GETOPT=y
> +CONFIG_CMD_LET=y
> +CONFIG_CMD_MSLEEP=y
> +CONFIG_CMD_READF=y
> +CONFIG_CMD_SLEEP=y
> +CONFIG_CMD_ECHO_E=y
> +CONFIG_CMD_EDIT=y
> +CONFIG_CMD_MENU=y
> +CONFIG_CMD_MENU_MANAGEMENT=y
> +CONFIG_CMD_MENUTREE=y
> +CONFIG_CMD_READLINE=y
> +CONFIG_CMD_TIMEOUT=y
> +CONFIG_CMD_CRC=y
> +CONFIG_CMD_CRC_CMP=y
> +CONFIG_CMD_CLK=y
> +CONFIG_CMD_DETECT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_LED=y
> +CONFIG_CMD_SPI=y
> +CONFIG_CMD_LED_TRIGGER=y
> +CONFIG_CMD_WD=y
> +CONFIG_CMD_OF_NODE=y
> +CONFIG_CMD_OF_PROPERTY=y
> +CONFIG_CMD_OFTREE=y
> +CONFIG_CMD_TIME=y
> +CONFIG_OFDEVICE=y
> +CONFIG_OF_BAREBOX_DRIVERS=y
> +CONFIG_DRIVER_SERIAL_NS16550=y
> +CONFIG_I2C=y
> +CONFIG_MTD=y
> +CONFIG_MTD_M25P80=y
> +CONFIG_DISK_AHCI=y
> +CONFIG_USB_HOST=y
> +CONFIG_USB_EHCI=y
> +CONFIG_USB_STORAGE=y
> +CONFIG_MCI=y
> +CONFIG_MCI_STARTUP=y
> +CONFIG_MCI_MMC_BOOT_PARTITIONS=y
> +CONFIG_LED=y
> +CONFIG_LED_TRIGGERS=y
> +CONFIG_WATCHDOG=y
> +CONFIG_FS_CRAMFS=y
> +CONFIG_FS_EXT4=y
> +CONFIG_FS_FAT=y
> +CONFIG_FS_FAT_WRITE=y
> +CONFIG_FS_FAT_LFN=y
> +CONFIG_BZLIB=y
> +CONFIG_LZO_DECOMPRESS=y
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 5/5] ARM: Add mvebu_defconfig
2014-09-15 21:15 ` Sebastian Hesselbarth
@ 2014-09-16 6:05 ` Sascha Hauer
0 siblings, 0 replies; 19+ messages in thread
From: Sascha Hauer @ 2014-09-16 6:05 UTC (permalink / raw)
To: Sebastian Hesselbarth; +Cc: barebox
On Mon, Sep 15, 2014 at 11:15:52PM +0200, Sebastian Hesselbarth wrote:
> On 09/15/2014 09:41 AM, Sascha Hauer wrote:
> > This adds a mvebu_defconfig which enables all mvebu based boards.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> Sascha,
>
> we should also select
>
> CONFIG_DRIVER_NET_ORION=y
> CONFIG_MDIO_MVEBU=y
> CONFIG_MARVELL_PHY=y
>
> and some NET commands would be helpful too.
Did that locally here for now. I will include it once the rest of this
series is fine.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: mvebu multi SoC support
2014-09-15 7:41 mvebu multi SoC support Sascha Hauer
` (4 preceding siblings ...)
2014-09-15 7:41 ` [PATCH 5/5] ARM: Add mvebu_defconfig Sascha Hauer
@ 2014-09-15 8:09 ` Ezequiel Garcia
5 siblings, 0 replies; 19+ messages in thread
From: Ezequiel Garcia @ 2014-09-15 8:09 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
On 15 Sep 09:41 AM, Sascha Hauer wrote:
>
> The following series allows to select multiple mvebu SoCs at once.
Hm, that sounds really good!
> Additionally a mvebu_defconfig is added to collect all mvebu based
> boards.
>
> I couldn't test this series. We have a cubox somewhere, but it seems
> to have disappeared from our remotelab. Sebastian, could you give
> this series a try?
>
FWIW: Right now I'm on a trip, so no access to my boards, but I shall
test this as soon as I get back (i.e. in a few weeks).
Thanks,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 19+ messages in thread