* Re: [PATCH] [POWERPC] qe_lib: fix few fluffy negligences (was: Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model)
From: Stephen Rothwell @ 2008-02-04 14:48 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080204134617.GA10377@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On Mon, 4 Feb 2008 16:46:17 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> On Tue, Feb 05, 2008 at 12:13:18AM +1100, Stephen Rothwell wrote:
> >
> > If you don't care about the returned length (argument three to
> > of_get_property), you can just pass NULL (and dispense with "size").
> > Also, what happens if prop is NULL?
>
> All this was in the old code already, I just didn't fix that.
I appreciate that, but it did need fixing.
> - - - -
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [POWERPC] qe_lib: fix few fluffy negligences
>
> One is intoduced by me (of_node_put() absence) and another was
> present already (not checking for NULL).
>
> Found by Stephen Rothwell.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ehea: add memory remove hotplug support
From: Michael Ellerman @ 2008-02-04 14:46 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <200802041404.49960.ossthema@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
On Mon, 2008-02-04 at 14:04 +0100, Jan-Bernd Themann wrote:
> Add memory remove hotplug support
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
> ---
> Comment: This patch depends on the following patch that
> exports the symbols
> register_memory_notifier()
> unregister_memory_notifier()
>
> http://lkml.org/lkml/2008/2/1/293
>
>
> drivers/net/ehea/ehea_main.c | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index 21af674..b75afcc 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
> if (ret)
> ehea_info("failed registering reboot notifier");
>
> + ret = register_memory_notifier(&ehea_mem_nb);
> + if (ret)
> + ehea_info("failed registering memory remove notifier");
>
> ret = crash_shutdown_register(&ehea_crash_handler);
> if (ret)
> ehea_info("failed registering crash handler");
You don't do anything except print a message if the registration fails.
What happens when someone tries to remove memory but the memory notifier
wasn't registered properly? Bang?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC: add missing native dcr dcr_ind_lock spinlock
From: Valentine Barshak @ 2008-02-04 14:08 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080201203634.GA21024@ru.mvista.com>
Oops, sorry, please discard this one.
DEFINE_SPINLOCK should be used here.
Valentine Barshak wrote:
> The include/asm-powerpc/dcr-native.h declares extern spinlock_t dcr_ind_lock,
> but it's actually isn't defined. This patch adds a missing dcr_ind_lock.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> arch/powerpc/sysdev/dcr.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff -pruN linux-2.6.orig/arch/powerpc/sysdev/dcr.c linux-2.6/arch/powerpc/sysdev/dcr.c
> --- linux-2.6.orig/arch/powerpc/sysdev/dcr.c 2008-01-31 16:58:32.000000000 +0300
> +++ linux-2.6/arch/powerpc/sysdev/dcr.c 2008-02-01 23:17:35.000000000 +0300
> @@ -137,5 +137,6 @@ void dcr_unmap(dcr_host_t host, unsigned
> h.token = NULL;
> }
> EXPORT_SYMBOL_GPL(dcr_unmap);
> -
> -#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
> +#else /* defined(CONFIG_PPC_DCR_NATIVE) */
> +spinlock_t dcr_ind_lock;
> +#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] PowerPC: add missing native dcr dcr_ind_lock spinlock
From: Valentine Barshak @ 2008-02-01 20:36 UTC (permalink / raw)
To: linuxppc-dev
The include/asm-powerpc/dcr-native.h declares extern spinlock_t dcr_ind_lock,
but it's actually isn't defined. This patch adds a missing dcr_ind_lock.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/sysdev/dcr.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/sysdev/dcr.c linux-2.6/arch/powerpc/sysdev/dcr.c
--- linux-2.6.orig/arch/powerpc/sysdev/dcr.c 2008-01-31 16:58:32.000000000 +0300
+++ linux-2.6/arch/powerpc/sysdev/dcr.c 2008-02-01 23:17:35.000000000 +0300
@@ -137,5 +137,6 @@ void dcr_unmap(dcr_host_t host, unsigned
h.token = NULL;
}
EXPORT_SYMBOL_GPL(dcr_unmap);
-
-#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
+#else /* defined(CONFIG_PPC_DCR_NATIVE) */
+spinlock_t dcr_ind_lock;
+#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
^ permalink raw reply
* [Virtex 4 PPC] Which Linux?
From: IngoM @ 2008-02-04 13:54 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
we develop a new laser-ranging-system and our hardware freaks have choosen
the Virtex 4 FX 12 on the "AVNET FX12 Mini-Module". The system had to
deliver the raw data via UDP (12 Mbyte/sec) and on TCP the processed data
(about 6 Mbyte/sec). When you get the processed data via TCP then no data
send by UDP.
I'm confused by the following:
1) Hard-TEMAC vs. Soft-TEMAC.
Avnet provide a demo for the module which using Soft-TEMAC. If I get it
right this core has to be licenced. But when ther is a hard-TEMAC why pay
for it?
2) Linux
I'd like to build my kernel and filesystem myself. But which way to go?
Using OE, buildroot, ELDK...
Can you please provide some starting points for me?
3) Boot-Concept
The Mini-Module had only 4MB Flash. Is this enough for a root-fs?
Best Regards and thanks a lot,
Ingo
--
View this message in context: http://www.nabble.com/-Virtex-4-PPC--Which-Linux--tp15268468p15268468.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] [POWERPC] qe_lib: fix few fluffy negligences (was: Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model)
From: Anton Vorontsov @ 2008-02-04 13:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080205001318.5fbc60fa.sfr@canb.auug.org.au>
On Tue, Feb 05, 2008 at 12:13:18AM +1100, Stephen Rothwell wrote:
> Hi Anton,
>
> I know this is late, but a couple of comments anyway.
>
> On Thu, 24 Jan 2008 18:39:59 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> >
> > +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> > @@ -65,17 +65,22 @@ static phys_addr_t qebase = -1;
> > phys_addr_t get_qe_base(void)
> > {
> > struct device_node *qe;
> > + unsigned int size;
> > + const void *prop;
> >
> > if (qebase != -1)
> > return qebase;
> >
> > - qe = of_find_node_by_type(NULL, "qe");
> > - if (qe) {
> > - unsigned int size;
> > - const void *prop = of_get_property(qe, "reg", &size);
> > - qebase = of_translate_address(qe, prop);
> > - of_node_put(qe);
> > - };
> > + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> > + if (!qe) {
> > + qe = of_find_node_by_type(NULL, "qe");
> > + if (!qe)
> > + return qebase;
> > + }
> > +
> > + prop = of_get_property(qe, "reg", &size);
> > + qebase = of_translate_address(qe, prop);
>
> If you don't care about the returned length (argument three to
> of_get_property), you can just pass NULL (and dispense with "size").
> Also, what happens if prop is NULL?
All this was in the old code already, I just didn't fix that.
> > @@ -153,16 +158,26 @@ static unsigned int brg_clk = 0;
> > unsigned int get_brg_clk(void)
> > {
> > struct device_node *qe;
> > + unsigned int size;
> > + const u32 *prop;
> > +
> > if (brg_clk)
> > return brg_clk;
> >
> > - qe = of_find_node_by_type(NULL, "qe");
> > - if (qe) {
> > - unsigned int size;
> > - const u32 *prop = of_get_property(qe, "brg-frequency", &size);
> > - brg_clk = *prop;
> > - of_node_put(qe);
> > - };
> > + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> > + if (!qe) {
> > + qe = of_find_node_by_type(NULL, "qe");
> > + if (!qe)
> > + return brg_clk;
> > + }
> > +
> > + prop = of_get_property(qe, "brg-frequency", &size);
> > + if (!prop || size != sizeof(*prop))
> > + return brg_clk;
>
> You need an of_node_put(qe) before the return ...
This is new. :-) Thanks.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [POWERPC] qe_lib: fix few fluffy negligences
One is intoduced by me (of_node_put() absence) and another was
present already (not checking for NULL).
Found by Stephen Rothwell.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/qe.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 5ef844d..6efbd5e 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -66,7 +66,7 @@ phys_addr_t get_qe_base(void)
{
struct device_node *qe;
unsigned int size;
- const void *prop;
+ const u32 *prop;
if (qebase != -1)
return qebase;
@@ -79,7 +79,8 @@ phys_addr_t get_qe_base(void)
}
prop = of_get_property(qe, "reg", &size);
- qebase = of_translate_address(qe, prop);
+ if (prop && size >= sizeof(*prop))
+ qebase = of_translate_address(qe, prop);
of_node_put(qe);
return qebase;
@@ -172,10 +173,9 @@ unsigned int get_brg_clk(void)
}
prop = of_get_property(qe, "brg-frequency", &size);
- if (!prop || size != sizeof(*prop))
- return brg_clk;
+ if (prop && size == sizeof(*prop))
+ brg_clk = *prop;
- brg_clk = *prop;
of_node_put(qe);
return brg_clk;
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH 7/9] powerpc: add MPC837x RDB platform support
From: Stephen Rothwell @ 2008-02-04 13:41 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, D'Abbraccio, Joe
In-Reply-To: <20080124204711.02ba14f0.kim.phillips@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
Hi Kim,
Again, a bit late but a couple of comments.
On Thu, 24 Jan 2008 20:47:11 -0600 Kim Phillips <kim.phillips@freescale.com> wrote:
>
> +static struct of_device_id mpc837x_ids[] = {
Make this __initdata, please.
> +static void __init mpc837x_rdb_init_IRQ(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,ipic");
> + if (!np)
> + return;
> +
> + ipic_init(np, 0);
You need an of_node_put(np) here.
> +static int __init mpc837x_rdb_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "fsl,mpc8377rdb") ||
> + of_flat_dt_is_compatible(root, "fsl,mpc8378rdb") ||
> + of_flat_dt_is_compatible(root, "fsl,mpc8379rdb");
You need to include asm/prom.h to use the flattened device tree accessors.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] powerpc: fold the mpc8313 platform into the mpc831x platform
From: Stephen Rothwell @ 2008-02-04 13:29 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20080124204551.10cea5fd.kim.phillips@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
Hi Kim,
I know this is late, but just a trivial comment.
On Thu, 24 Jan 2008 20:45:51 -0600 Kim Phillips <kim.phillips@freescale.com> wrote:
>
> --- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
> @@ -1,7 +1,7 @@
> /*
> - * arch/powerpc/platforms/83xx/mpc8313_rdb.c
> + * arch/powerpc/platforms/83xx/mpc831x_rdb.c
Just remove the file name from the comment.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* patches "using mii-bitbang on different processor ports"
From: Sergej Stepanov @ 2008-02-04 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, jgarzik
Hello!
I am about this two patches.
http://www.spinics.net/lists/netdev/msg45778.html
http://www.spinics.net/lists/netdev/msg47159.html
They was not applied. Could they be picked?
Thank you
Sergej.
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] Implement support for the GPIO LIB API
From: Anton Vorontsov @ 2008-02-04 13:19 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev
In-Reply-To: <200802031317.43858.david-b@pacbell.net>
On Sun, Feb 03, 2008 at 01:17:43PM -0800, David Brownell wrote:
> On Sunday 03 February 2008, Anton Vorontsov wrote:
> > This patch implements support for the GPIO LIB API. Two calls
> > unimplemented though: irq_to_gpio and gpio_to_irq.
>
> Also gpio_cansleep().
>
>
> > +Example of two SOC GPIO banks defined as gpio-controller nodes:
> > +
> > + qe_pio_a: gpio-controller@1400 {
> > + #gpio-cells = <2>;
> > + compatible = "fsl,qe-pario-bank";
> > + reg = <0x1400 0x18>;
> > + gpio-controller;
> > + };
> > +
> > + qe_pio_e: gpio-controller@1460 {
> > + #gpio-cells = <2>;
> > + compatible = "fsl,qe-pario-bank";
> > + reg = <0x1460 0x18>;
> > + gpio-controller;
> > + };
>
> Let me suggest another example to provide: an I2C GPIO expander
> such as a pcf8574 or pca9354 (both eight bit expanders). The SOC
> case is probably the easiest to cover.
I2C expander will be easy to support via device tree too, something
like:
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <14 8>;
interrupt-parent = <&ipic>;
dfsrr;
pcf_pio: gpio-controller@27 {
#gpio-cells = <2>;
compatible = "ti,pcf8574";
reg = <0x27>;
gpio-controller;
};
};
Of course, to support this, pcf857x driver needs OF bindings.
> > +#define ARCH_OF_GPIOS_PER_CHIP 32
>
> Well, ARCH_OF_* is clearly not the now-removed ARCH_GPIOS_PER_CHIP,
> but I still suggest moving away from that concept.
Yes, I noticed that ARCH_GPIOS_PER_CHIP is removed from the
gpiolib. But I solely use it to assign gpio_bases to the chips:
static int of_get_gpiochip_base(struct device_node *np)
{
struct device_node *gc = NULL;
int gpiochip_base = 0;
while ((gc = of_find_all_nodes(gc))) {
if (!of_get_property(gc, "gpio-controller", NULL))
continue;
if (gc != np) {
gpiochip_base += ARCH_OF_GPIOS_PER_CHIP;
continue;
}
of_node_put(gc);
if (gpiochip_base >= ARCH_OF_GPIOS_END)
return -ENOSPC;
return gpiochip_base;
}
return -ENOENT;
}
This function walks the device tree and assigns gpio_base 0 to
the first encountered gpio-controller, ARCH_OF_GPIOS_PER_CHIP * N
to the Nth controller...
Technically, I can replace
if (gc != np) {
gpiochip_base += ARCH_OF_GPIOS_PER_CHIP;
continue;
}
With
if (gc != np) {
struct gpio_chip *chip = gc->data;
if (chip)
gpiochip_base += chip->ngpio;
continue;
}
Here we're getting next available GPIO base. But then this code can't
handle gpio chip removal. So, we need smart "dynamic GPIO base
allocator" as described asm-generic/gpio.h, gpio_find_base(ngpios)
that will find free gpio base suitable for ngpios to place. Until
that allocator implemented, we use simple allocator with
OF_GPIOS_PER_CHIP...
> > +static inline int gpio_get_value(unsigned int gpio)
> > +{
> > + return __gpio_get_value(gpio);
> > +}
> > +
> > +static inline void gpio_set_value(unsigned int gpio, int value)
> > +{
> > + __gpio_set_value(gpio, value);
> > +}
>
> static inline int gpio_cansleep(unsigned int gpio)
> {
> return __gpio_cansleep(gpio);
> }
Will fix.
> > +static inline int irq_to_gpio(unsigned int irq)
> > +{
> > + return -ENOSYS;
>
> Minor nit: "-EINVAL" would be better here, since the argument
> is constrained to have been returned from gpio_to_irq(), and
> as you wrote that call there can be no such values.
Will change.
Thanks!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model
From: Stephen Rothwell @ 2008-02-04 13:13 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080124153959.GA23246@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]
Hi Anton,
I know this is late, but a couple of comments anyway.
On Thu, 24 Jan 2008 18:39:59 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -65,17 +65,22 @@ static phys_addr_t qebase = -1;
> phys_addr_t get_qe_base(void)
> {
> struct device_node *qe;
> + unsigned int size;
> + const void *prop;
>
> if (qebase != -1)
> return qebase;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> - unsigned int size;
> - const void *prop = of_get_property(qe, "reg", &size);
> - qebase = of_translate_address(qe, prop);
> - of_node_put(qe);
> - };
> + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!qe) {
> + qe = of_find_node_by_type(NULL, "qe");
> + if (!qe)
> + return qebase;
> + }
> +
> + prop = of_get_property(qe, "reg", &size);
> + qebase = of_translate_address(qe, prop);
If you don't care about the returned length (argument three to
of_get_property), you can just pass NULL (and dispense with "size").
Also, what happens if prop is NULL?
> @@ -153,16 +158,26 @@ static unsigned int brg_clk = 0;
> unsigned int get_brg_clk(void)
> {
> struct device_node *qe;
> + unsigned int size;
> + const u32 *prop;
> +
> if (brg_clk)
> return brg_clk;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> - unsigned int size;
> - const u32 *prop = of_get_property(qe, "brg-frequency", &size);
> - brg_clk = *prop;
> - of_node_put(qe);
> - };
> + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!qe) {
> + qe = of_find_node_by_type(NULL, "qe");
> + if (!qe)
> + return brg_clk;
> + }
> +
> + prop = of_get_property(qe, "brg-frequency", &size);
> + if (!prop || size != sizeof(*prop))
> + return brg_clk;
You need an of_node_put(qe) before the return ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/2] ehea: add memory remove hotplug support
From: Jan-Bernd Themann @ 2008-02-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
Add memory remove hotplug support
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
Comment: This patch depends on the following patch that
exports the symbols
register_memory_notifier()
unregister_memory_notifier()
http://lkml.org/lkml/2008/2/1/293
drivers/net/ehea/ehea_main.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 21af674..b75afcc 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -35,6 +35,7 @@
#include <linux/if_ether.h>
#include <linux/notifier.h>
#include <linux/reboot.h>
+#include <linux/memory.h>
#include <asm/kexec.h>
#include <net/ip.h>
@@ -3480,6 +3481,24 @@ void ehea_crash_handler(void)
0, H_DEREG_BCMC);
}
+static int ehea_mem_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ switch (action) {
+ case MEM_OFFLINE:
+ ehea_info("memory has been removed");
+ ehea_rereg_mrs(NULL);
+ break;
+ default:
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block ehea_mem_nb = {
+ .notifier_call = ehea_mem_notifier,
+};
+
static int ehea_reboot_notifier(struct notifier_block *nb,
unsigned long action, void *unused)
{
@@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
if (ret)
ehea_info("failed registering reboot notifier");
+ ret = register_memory_notifier(&ehea_mem_nb);
+ if (ret)
+ ehea_info("failed registering memory remove notifier");
+
ret = crash_shutdown_register(&ehea_crash_handler);
if (ret)
ehea_info("failed registering crash handler");
@@ -3582,6 +3605,7 @@ int __init ehea_module_init(void)
out3:
ibmebus_unregister_driver(&ehea_driver);
out2:
+ unregister_memory_notifier(&ehea_mem_nb);
unregister_reboot_notifier(&ehea_reboot_nb);
crash_shutdown_unregister(&ehea_crash_handler);
out:
@@ -3599,6 +3623,7 @@ static void __exit ehea_module_exit(void)
ret = crash_shutdown_unregister(&ehea_crash_handler);
if (ret)
ehea_info("failed unregistering crash handler");
+ unregister_memory_notifier(&ehea_mem_nb);
kfree(ehea_fw_handles.arr);
kfree(ehea_bcmc_regs.arr);
ehea_destroy_busmap();
--
1.5.2
^ permalink raw reply related
* [PATCH 1/2] ehea: kdump support
From: Jan-Bernd Themann @ 2008-02-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
This patch adds kdump support to the ehea driver. As the firmware doesn't free
resource handles automatically, the driver has to run an as simple as possible
free resource function in case of a crash shutdown. The function iterates over
two arrays freeing all resource handles which are stored there. The arrays are
kept up-to-date during normal runtime. The crash handler fn is triggered by the
recently introduced PPC crash shutdown reg/unreg functions.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 34 +++++-
drivers/net/ehea/ehea_main.c | 281 ++++++++++++++++++++++++++++++++++++++----
2 files changed, 290 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 88fb53e..7c4ead3 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0083"
+#define DRV_VERSION "EHEA_0087"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -386,6 +386,13 @@ struct ehea_port_res {
#define EHEA_MAX_PORTS 16
+
+#define EHEA_NUM_PORTRES_FW_HANDLES 6 /* QP handle, SendCQ handle,
+ RecvCQ handle, EQ handle,
+ SendMR handle, RecvMR handle */
+#define EHEA_NUM_PORT_FW_HANDLES 1 /* EQ handle */
+#define EHEA_NUM_ADAPTER_FW_HANDLES 2 /* MR handle, NEQ handle */
+
struct ehea_adapter {
u64 handle;
struct of_device *ofdev;
@@ -405,6 +412,31 @@ struct ehea_mc_list {
u64 macaddr;
};
+/* kdump support */
+struct ehea_fw_handle_entry {
+ u64 adh; /* Adapter Handle */
+ u64 fwh; /* Firmware Handle */
+};
+
+struct ehea_fw_handle_array {
+ struct ehea_fw_handle_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
+struct ehea_bcmc_reg_entry {
+ u64 adh; /* Adapter Handle */
+ u32 port_id; /* Logical Port Id */
+ u8 reg_type; /* Registration Type */
+ u64 macaddr;
+};
+
+struct ehea_bcmc_reg_array {
+ struct ehea_bcmc_reg_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
#define EHEA_PORT_UP 1
#define EHEA_PORT_DOWN 0
#define EHEA_PHY_LINK_UP 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c051c7e..21af674 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -35,6 +35,7 @@
#include <linux/if_ether.h>
#include <linux/notifier.h>
#include <linux/reboot.h>
+#include <asm/kexec.h>
#include <net/ip.h>
@@ -98,8 +99,10 @@ static int port_name_cnt;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags;
struct work_struct ehea_rereg_mr_task;
-
struct semaphore dlpar_mem_lock;
+struct ehea_fw_handle_array ehea_fw_handles;
+struct ehea_bcmc_reg_array ehea_bcmc_regs;
+
static int __devinit ehea_probe_adapter(struct of_device *dev,
const struct of_device_id *id);
@@ -132,6 +135,160 @@ void ehea_dump(void *adr, int len, char *msg)
}
}
+static void ehea_update_firmware_handles(void)
+{
+ struct ehea_fw_handle_entry *arr = NULL;
+ struct ehea_adapter *adapter;
+ int num_adapters = 0;
+ int num_ports = 0;
+ int num_portres = 0;
+ int i = 0;
+ int num_fw_handles, k, l;
+
+ /* Determine number of handles */
+ list_for_each_entry(adapter, &adapter_list, list) {
+ num_adapters++;
+
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ num_ports++;
+ num_portres += port->num_def_qps + port->num_add_tx_qps;
+ }
+ }
+
+ num_fw_handles = num_adapters * EHEA_NUM_ADAPTER_FW_HANDLES +
+ num_ports * EHEA_NUM_PORT_FW_HANDLES +
+ num_portres * EHEA_NUM_PORTRES_FW_HANDLES;
+
+ if (num_fw_handles) {
+ arr = kzalloc(num_fw_handles * sizeof(*arr), GFP_KERNEL);
+ if (!arr)
+ return; /* Keep the existing array */
+ } else
+ goto out_update;
+
+ list_for_each_entry(adapter, &adapter_list, list) {
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ for (l = 0;
+ l < port->num_def_qps + port->num_add_tx_qps;
+ l++) {
+ struct ehea_port_res *pr = &port->port_res[l];
+
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->qp->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->send_cq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->recv_cq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->eq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->send_mr.handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->recv_mr.handle;
+ }
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = port->qp_eq->fw_handle;
+ }
+
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = adapter->neq->fw_handle;
+
+ if (adapter->mr.handle) {
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = adapter->mr.handle;
+ }
+ }
+
+out_update:
+ kfree(ehea_fw_handles.arr);
+ ehea_fw_handles.arr = arr;
+ ehea_fw_handles.num_entries = i;
+}
+
+static void ehea_update_bcmc_registrations(void)
+{
+ struct ehea_bcmc_reg_entry *arr = NULL;
+ struct ehea_adapter *adapter;
+ struct ehea_mc_list *mc_entry;
+ int num_registrations = 0;
+ int i = 0;
+ int k;
+
+ /* Determine number of registrations */
+ list_for_each_entry(adapter, &adapter_list, list)
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ num_registrations += 2; /* Broadcast registrations */
+
+ list_for_each_entry(mc_entry, &port->mc_list->list,list)
+ num_registrations += 2;
+ }
+
+ if (num_registrations) {
+ arr = kzalloc(num_registrations * sizeof(*arr), GFP_KERNEL);
+ if (!arr)
+ return; /* Keep the existing array */
+ } else
+ goto out_update;
+
+ list_for_each_entry(adapter, &adapter_list, list) {
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_BROADCAST |
+ EHEA_BCMC_UNTAGGED;
+ arr[i++].macaddr = port->mac_addr;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_BROADCAST |
+ EHEA_BCMC_VLANID_ALL;
+ arr[i++].macaddr = port->mac_addr;
+
+ list_for_each_entry(mc_entry,
+ &port->mc_list->list, list) {
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_SCOPE_ALL |
+ EHEA_BCMC_MULTICAST |
+ EHEA_BCMC_UNTAGGED;
+ arr[i++].macaddr = mc_entry->macaddr;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_SCOPE_ALL |
+ EHEA_BCMC_MULTICAST |
+ EHEA_BCMC_VLANID_ALL;
+ arr[i++].macaddr = mc_entry->macaddr;
+ }
+ }
+ }
+
+out_update:
+ kfree(ehea_bcmc_regs.arr);
+ ehea_bcmc_regs.arr = arr;
+ ehea_bcmc_regs.num_entries = i;
+}
+
static struct net_device_stats *ehea_get_stats(struct net_device *dev)
{
struct ehea_port *port = netdev_priv(dev);
@@ -1601,19 +1758,25 @@ static int ehea_set_mac_addr(struct net_device *dev, void *sa)
memcpy(dev->dev_addr, mac_addr->sa_data, dev->addr_len);
+ down(&ehea_bcmc_regs.lock);
+
/* Deregister old MAC in pHYP */
ret = ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
if (ret)
- goto out_free;
+ goto out_upregs;
port->mac_addr = cb0->port_mac_addr << 16;
/* Register new MAC in pHYP */
ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
if (ret)
- goto out_free;
+ goto out_upregs;
ret = 0;
+
+out_upregs:
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
out_free:
kfree(cb0);
out:
@@ -1775,9 +1938,11 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
ehea_promiscuous(dev, 0);
+ down(&ehea_bcmc_regs.lock);
+
if (dev->flags & IFF_ALLMULTI) {
ehea_allmulti(dev, 1);
- return;
+ goto out;
}
ehea_allmulti(dev, 0);
@@ -1803,6 +1968,8 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
out:
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
return;
}
@@ -2285,6 +2452,8 @@ static int ehea_up(struct net_device *dev)
if (port->state == EHEA_PORT_UP)
return 0;
+ down(&ehea_fw_handles.lock);
+
ret = ehea_port_res_setup(port, port->num_def_qps,
port->num_add_tx_qps);
if (ret) {
@@ -2321,8 +2490,17 @@ static int ehea_up(struct net_device *dev)
}
}
- ret = 0;
+ down(&ehea_bcmc_regs.lock);
+
+ ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
+ if (ret) {
+ ret = -EIO;
+ goto out_free_irqs;
+ }
+
port->state = EHEA_PORT_UP;
+
+ ret = 0;
goto out;
out_free_irqs:
@@ -2334,6 +2512,12 @@ out:
if (ret)
ehea_info("Failed starting %s. ret=%i", dev->name, ret);
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
+
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return ret;
}
@@ -2382,16 +2566,27 @@ static int ehea_down(struct net_device *dev)
if (port->state == EHEA_PORT_DOWN)
return 0;
+ down(&ehea_bcmc_regs.lock);
ehea_drop_multicast_list(dev);
+ ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
+
ehea_free_interrupts(dev);
+ down(&ehea_fw_handles.lock);
+
port->state = EHEA_PORT_DOWN;
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
+
ret = ehea_clean_all_portres(port);
if (ret)
ehea_info("Failed freeing resources for %s. ret=%i",
dev->name, ret);
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return ret;
}
@@ -2920,19 +3115,12 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
INIT_WORK(&port->reset_task, ehea_reset_port);
-
- ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
- if (ret) {
- ret = -EIO;
- goto out_unreg_port;
- }
-
ehea_set_ethtool_ops(dev);
ret = register_netdev(dev);
if (ret) {
ehea_error("register_netdev failed. ret=%d", ret);
- goto out_dereg_bc;
+ goto out_unreg_port;
}
port->lro_max_aggr = lro_max_aggr;
@@ -2949,9 +3137,6 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
return port;
-out_dereg_bc:
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
-
out_unreg_port:
ehea_unregister_port(port);
@@ -2971,7 +3156,6 @@ static void ehea_shutdown_single_port(struct ehea_port *port)
{
unregister_netdev(port->netdev);
ehea_unregister_port(port);
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
kfree(port->mc_list);
free_netdev(port->netdev);
port->adapter->active_ports--;
@@ -3014,7 +3198,6 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
i++;
};
-
return 0;
}
@@ -3159,6 +3342,7 @@ static int __devinit ehea_probe_adapter(struct of_device *dev,
ehea_error("Invalid ibmebus device probed");
return -EINVAL;
}
+ down(&ehea_fw_handles.lock);
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
@@ -3239,7 +3423,10 @@ out_kill_eq:
out_free_ad:
kfree(adapter);
+
out:
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
return ret;
}
@@ -3258,18 +3445,41 @@ static int __devexit ehea_remove(struct of_device *dev)
flush_scheduled_work();
+ down(&ehea_fw_handles.lock);
+
ibmebus_free_irq(adapter->neq->attr.ist1, adapter);
tasklet_kill(&adapter->neq_tasklet);
ehea_destroy_eq(adapter->neq);
ehea_remove_adapter_mr(adapter);
list_del(&adapter->list);
-
kfree(adapter);
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return 0;
}
+void ehea_crash_handler(void)
+{
+ int i;
+
+ if (ehea_fw_handles.arr)
+ for (i = 0; i < ehea_fw_handles.num_entries; i++)
+ ehea_h_free_resource(ehea_fw_handles.arr[i].adh,
+ ehea_fw_handles.arr[i].fwh,
+ FORCE_FREE);
+
+ if (ehea_bcmc_regs.arr)
+ for (i = 0; i < ehea_bcmc_regs.num_entries; i++)
+ ehea_h_reg_dereg_bcmc(ehea_bcmc_regs.arr[i].adh,
+ ehea_bcmc_regs.arr[i].port_id,
+ ehea_bcmc_regs.arr[i].reg_type,
+ ehea_bcmc_regs.arr[i].macaddr,
+ 0, H_DEREG_BCMC);
+}
+
static int ehea_reboot_notifier(struct notifier_block *nb,
unsigned long action, void *unused)
{
@@ -3330,7 +3540,12 @@ int __init ehea_module_init(void)
INIT_WORK(&ehea_rereg_mr_task, ehea_rereg_mrs);
+ memset(&ehea_fw_handles, 0, sizeof(ehea_fw_handles));
+ memset(&ehea_bcmc_regs, 0, sizeof(ehea_bcmc_regs));
+
sema_init(&dlpar_mem_lock, 1);
+ sema_init(&ehea_fw_handles.lock, 1);
+ sema_init(&ehea_bcmc_regs.lock, 1);
ret = check_module_parm();
if (ret)
@@ -3340,12 +3555,18 @@ int __init ehea_module_init(void)
if (ret)
goto out;
- register_reboot_notifier(&ehea_reboot_nb);
+ ret = register_reboot_notifier(&ehea_reboot_nb);
+ if (ret)
+ ehea_info("failed registering reboot notifier");
+
+ ret = crash_shutdown_register(&ehea_crash_handler);
+ if (ret)
+ ehea_info("failed registering crash handler");
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
ehea_error("failed registering eHEA device driver on ebus");
- goto out;
+ goto out2;
}
ret = driver_create_file(&ehea_driver.driver,
@@ -3353,21 +3574,33 @@ int __init ehea_module_init(void)
if (ret) {
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
- unregister_reboot_notifier(&ehea_reboot_nb);
- ibmebus_unregister_driver(&ehea_driver);
- goto out;
+ goto out3;
}
+ return ret;
+
+out3:
+ ibmebus_unregister_driver(&ehea_driver);
+out2:
+ unregister_reboot_notifier(&ehea_reboot_nb);
+ crash_shutdown_unregister(&ehea_crash_handler);
out:
return ret;
}
static void __exit ehea_module_exit(void)
{
+ int ret;
+
flush_scheduled_work();
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ret = crash_shutdown_unregister(&ehea_crash_handler);
+ if (ret)
+ ehea_info("failed unregistering crash handler");
+ kfree(ehea_fw_handles.arr);
+ kfree(ehea_bcmc_regs.arr);
ehea_destroy_busmap();
}
--
1.5.2
^ permalink raw reply related
* [PATCH 0/2] ehea: kdump & memory remove support
From: Jan-Bernd Themann @ 2008-02-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
This patch set adds support for kdump and hotplug memory remove
to the eHEA driver.=20
The "memory remove" patch depends on the following patch that
has been posted a few days ago. That patch exports the symbols
=A0- register_memory_notifier()
=A0- unregister_memory_notifier()
http://lkml.org/lkml/2008/2/1/293
Regards,
Jan-Bernd
^ permalink raw reply
* Re: Commit for mm/page_alloc.c breaks boot process on my machine
From: Mel Gorman @ 2008-02-04 10:42 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080201210656.174030@gmx.net>
On (01/02/08 22:06), Gerhard Pircher didst pronounce:
>
> -------- Original-Nachricht --------
> > Datum: Fri, 1 Feb 2008 20:25:18 +0000
> > Von: Mel Gorman <mel@csn.ul.ie>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > CC: linux-kernel@vger.kernel.org
> > Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine
>
> > I meant uninitialised memory but I also wonder could something like this
> > happen if you are trying to use memory that doesn't exist. i.e. you are
> > trying to access more memory than you really have but you indicate later
> > that this is not the case.
>
> Good question. The memory is in the physical address range from 0x00000000
> to 0x60000000 (1536MB).
>
> > > > 2. Any chance of seeing a dmesg log?
> > > That's a little bit of a problem. The kernel log in memory doesn't show
> > > any kernel oops, but is also fragmented (small fragments seem to have
> > > been overwritten with 0x0).
> >
> > err, that doesn't sound very healthy.
>
> Yeah, I know. But the platform code hasn't changed much when porting it
> from arch/ppc to arch/powerpc. That's why I'm a little bit lost in this
> case. :-)
>
I'm at a bit of a loss to guess what might have changed in powerpc code
that would explain this. I've added the linuxppc-dev mailing list in
case they can make a guess.
I think you are also going to need to start bisecting searching
specifically for the patch that causes these overwrites.
> > > Well, I can't answer this question. The kernel currently locks up when
> > > loading the INIT program. But that is another problem (I still have to
> > > bisect it) and doesn't seem to be related to this problem.
> >
> > INIT would be the first MOVABLE allocation so it would be using memory
> > at the end of the physical adddress range. i.e. the crash happens when
> > memory towards the end and the only difference between the patch applied
> > and reverted is when it happens.
> Oh, that sounds interesting!
>
> > Could you try booting with 16MB less memory using mem=?
> I started the kernel with 512MB RAM (mem=496) and 1.5GB (mem=1520). The
> kernel oopes in both cases with a "Unable to handle kernel paging request
> for data address 0xbffff000", followed by a "Oops: kernel access of bad
> area, sig 11" message. The end of the stack trace shows the start_here()
> function.
> I'm not a PowerPC expert, but if 0xbffff000 is a virtual address, then
> it would be in the user program address space, right? If it is a physical
> address, then it is somewhere in the unallocated PCI address space.
>
It's a virtual address so it depends on the value of CONFIG_KERNEL_START
as to whether this is a user program address or not.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Bernhard Reiter @ 2008-02-04 10:26 UTC (permalink / raw)
To: Sven Luther; +Cc: debian-powerpc, paulus, linuxppc-dev
In-Reply-To: <20080204095121.GA18167@powerlinux.fr>
[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]
On Monday 04 February 2008 10:51, Sven Luther wrote:
> On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> > Dear linux powerpc Maintainers and Users,
> >
> > recently I have tried to compile a new kernel on a Debian sarge ppc
> > system (PowerBook5,6 MacRISC3 Power Macintosh).
>
> This is a G4 based system.
Yes.
> > The build system bailed out with
> > BOOTCC arch/powerpc/boot/4xx.o
> > cc1: error: bad value (440) for -mcpu= switch
> > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
> >
> > I have tracked this a few steps and the attached patch made the compile
> > for me as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> > cannot produce code for 4xx it seems.
>
> You should normally not need to build the 4xx bootloader part. Make sure
> that, i don't know why this happens. Can you look into
> arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
> and make sure it is disabled in the main config ?
I have tried to do this, but it looks like it is just hardcoded into the
Makefile as you can see from the patch. There is probably more that I do not
understand - thus my report with on the workaround.
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Build failure with 2.6.24-mm1
From: Andrew Morton @ 2008-02-04 10:19 UTC (permalink / raw)
To: balbir; +Cc: linuxppc-dev, Shaohua, Zhang Yanmin, Greg KH, Li
In-Reply-To: <20080204100743.GA4445@balbir.in.ibm.com>
On Mon, 4 Feb 2008 15:37:43 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> * Balbir Singh <balbir@linux.vnet.ibm.com> [2008-02-04 15:35:09]:
>
> I just saw the following build failure on a power machine.
>
> In file included from include/acpi/platform/acenv.h:140,
> from include/acpi/acpi.h:54,
> from include/acpi/acpi_bus.h:31,
> from drivers/pci/pcie/aspm.c:20:
> include/acpi/platform/aclinux.h:59:22: error: asm/acpi.h: No such file or directory
> In file included from include/acpi/platform/aclinux.h:120,
> from include/acpi/platform/acenv.h:140,
> from include/acpi/acpi.h:54,
> from include/acpi/acpi_bus.h:31,
> from drivers/pci/pcie/aspm.c:20:
> include/acpi/actypes.h:130: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before 'UINT64'
> include/acpi/actypes.h:131: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before 'INT64'
> include/acpi/actypes.h:753: error: expected ')' before '*' token
> include/acpi/actypes.h:756: error: expected ')' before '*' token
> In file included from include/acpi/acpi.h:61,
> from include/acpi/acpi_bus.h:31,
> from drivers/pci/pcie/aspm.c:20:
> include/acpi/acpiosxf.h:179: error: expected declaration specifiers or '...'
> before 'acpi_osd_handler'
> include/acpi/acpiosxf.h:183: error: expected declaration specifiers or '...'
> before 'acpi_osd_handler'
> include/acpi/acpiosxf.h:192: error: expected declaration specifiers or '...'
> before 'acpi_osd_exec_callback'
> make[3]: *** [drivers/pci/pcie/aspm.o] Error 1
> make[2]: *** [drivers/pci/pcie] Error 2
> make[2]: *** Waiting for unfinished jobs....
> CC drivers/ps3/ps3-vuart.o
> CC net/netlink/attr.o
> make[1]: *** [drivers/pci] Error 2
> make[1]: *** Waiting for unfinished jobs..
>
> The following config option is responsible for the build failure
>
> config PCIEASPM
> bool "PCI Express ASPM support(Experimental)"
> depends on PCI && EXPERIMENTAL && PCIEPORTBUS
> default y
> help
> This enables PCI Express ASPM (Active State Power Management) and
> Clock Power Management. ASPM supports state L0/L0s/L1.
>
> When in doubt, say N.
>
> Here's a probable fix for the problem.
>
>
> Make the build of drivers/pci/pcie/aspm.c depend on ACPI.
>
> NOTE, the patch has not been tested. The dependency on ACPI might be wrong,
> but setting it to default "y" caused the build on my powerpc box to break.
>
> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> ---
>
> drivers/pci/pcie/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/pci/pcie/Kconfig~fix-mm-ppc-build drivers/pci/pcie/Kconfig
> --- linux-2.6.24/drivers/pci/pcie/Kconfig~fix-mm-ppc-build 2008-02-04 15:30:29.000000000 +0530
> +++ linux-2.6.24-balbir/drivers/pci/pcie/Kconfig 2008-02-04 15:33:45.000000000 +0530
> @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
> #
> config PCIEASPM
> bool "PCI Express ASPM support(Experimental)"
> - depends on PCI && EXPERIMENTAL && PCIEPORTBUS
> + depends on PCI && EXPERIMENTAL && PCIEPORTBUS && ACPI
> default y
> help
> This enables PCI Express ASPM (Active State Power Management) and
Thanks. I think Greg is going to revert PCIEASPM altogether?
^ permalink raw reply
* Build failure with 2.6.24-mm1
From: Balbir Singh @ 2008-02-04 10:07 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev; +Cc: Shaohua Li, Zhang Yanmin
In-Reply-To: <47A6E355.8040404@linux.vnet.ibm.com>
* Balbir Singh <balbir@linux.vnet.ibm.com> [2008-02-04 15:35:09]:
I just saw the following build failure on a power machine.
In file included from include/acpi/platform/acenv.h:140,
from include/acpi/acpi.h:54,
from include/acpi/acpi_bus.h:31,
from drivers/pci/pcie/aspm.c:20:
include/acpi/platform/aclinux.h:59:22: error: asm/acpi.h: No such file or directory
In file included from include/acpi/platform/aclinux.h:120,
from include/acpi/platform/acenv.h:140,
from include/acpi/acpi.h:54,
from include/acpi/acpi_bus.h:31,
from drivers/pci/pcie/aspm.c:20:
include/acpi/actypes.h:130: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'UINT64'
include/acpi/actypes.h:131: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'INT64'
include/acpi/actypes.h:753: error: expected ')' before '*' token
include/acpi/actypes.h:756: error: expected ')' before '*' token
In file included from include/acpi/acpi.h:61,
from include/acpi/acpi_bus.h:31,
from drivers/pci/pcie/aspm.c:20:
include/acpi/acpiosxf.h:179: error: expected declaration specifiers or '...'
before 'acpi_osd_handler'
include/acpi/acpiosxf.h:183: error: expected declaration specifiers or '...'
before 'acpi_osd_handler'
include/acpi/acpiosxf.h:192: error: expected declaration specifiers or '...'
before 'acpi_osd_exec_callback'
make[3]: *** [drivers/pci/pcie/aspm.o] Error 1
make[2]: *** [drivers/pci/pcie] Error 2
make[2]: *** Waiting for unfinished jobs....
CC drivers/ps3/ps3-vuart.o
CC net/netlink/attr.o
make[1]: *** [drivers/pci] Error 2
make[1]: *** Waiting for unfinished jobs..
The following config option is responsible for the build failure
config PCIEASPM
bool "PCI Express ASPM support(Experimental)"
depends on PCI && EXPERIMENTAL && PCIEPORTBUS
default y
help
This enables PCI Express ASPM (Active State Power Management) and
Clock Power Management. ASPM supports state L0/L0s/L1.
When in doubt, say N.
Here's a probable fix for the problem.
Make the build of drivers/pci/pcie/aspm.c depend on ACPI.
NOTE, the patch has not been tested. The dependency on ACPI might be wrong,
but setting it to default "y" caused the build on my powerpc box to break.
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---
drivers/pci/pcie/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/pci/pcie/Kconfig~fix-mm-ppc-build drivers/pci/pcie/Kconfig
--- linux-2.6.24/drivers/pci/pcie/Kconfig~fix-mm-ppc-build 2008-02-04 15:30:29.000000000 +0530
+++ linux-2.6.24-balbir/drivers/pci/pcie/Kconfig 2008-02-04 15:33:45.000000000 +0530
@@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
#
config PCIEASPM
bool "PCI Express ASPM support(Experimental)"
- depends on PCI && EXPERIMENTAL && PCIEPORTBUS
+ depends on PCI && EXPERIMENTAL && PCIEPORTBUS && ACPI
default y
help
This enables PCI Express ASPM (Active State Power Management) and
_
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Sven Luther @ 2008-02-04 9:51 UTC (permalink / raw)
To: Bernhard Reiter; +Cc: debian-powerpc, paulus, linuxppc-dev
In-Reply-To: <200802031729.12069.bernhard@intevation.de>
On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> Dear linux powerpc Maintainers and Users,
>
> recently I have tried to compile a new kernel on a Debian sarge ppc
> system (PowerBook5,6 MacRISC3 Power Macintosh).
This is a G4 based system.
> The build system bailed out with
> BOOTCC arch/powerpc/boot/4xx.o
> cc1: error: bad value (440) for -mcpu= switch
> make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
>
> I have tracked this a few steps and the attached patch made the compile for me
> as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> cannot produce code for 4xx it seems.
You should normally not need to build the 4xx bootloader part. Make sure
that, i don't know why this happens. Can you look into
arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
and make sure it is disabled in the main config ?
Please bounce this message to debian-powerpc, as debian believes in
censorship instead of trying to solve inimity by discussion.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] Fix ext4 bitops
From: Aneesh Kumar K.V @ 2008-02-04 9:29 UTC (permalink / raw)
To: Heiko Carstens
Cc: linux-s390, Bastian Blank, Linux Kernel Development,
Linux/PPC Development, Geert Uytterhoeven, Andrew Morton,
linux-ext4
In-Reply-To: <20080204092436.GB7530@osiris.boeblingen.de.ibm.com>
On Mon, Feb 04, 2008 at 10:24:36AM +0100, Heiko Carstens wrote:
> > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
> > > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
> > > > >
> > > > > The s390 specific bitops uses parts of the generic implementation.
> > > > > Include the correct header.
> > > >
> > > > That doesn't work:
> > > >
> > > > fs/built-in.o: In function `ext4_mb_release_inode_pa':
> > > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
> > > > fs/built-in.o: In function `ext4_mb_init_cache':
> > > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
> > > >
> > > > This still needs generic_find_next_le_bit which comes
> > > > from lib/find_next_bit.c. That one doesn't get built on s390 since we
> > > > don't set GENERIC_FIND_NEXT_BIT.
> > > > Currently we have the lengthly patch below queued.
> > >
> > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
> > > impression the ext4 people don't (compile) test on big endian machines?
> > >
> > > Gr{oetje,eeting}s,
> > >
> >
> > I have sent this patches to linux-arch expecting a review from
> > different arch people. It is true that the patches are tested only on
> > powerpc, x86-64, x86. That's the primary reason of me sending the
> > patches to linux-arch.
>
> Is there anything special I need to do so the ext4 code actually uses
> ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to
> test if the s390 implementation is ok.
With the latest linus kernel in git you can test it by mounting ext4
mount -t ext4dev <device> <mntpoint>
-aneesh
^ permalink raw reply
* Re: [PATCH] Fix ext4 bitops
From: Heiko Carstens @ 2008-02-04 9:24 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: linux-s390, Bastian Blank, Linux Kernel Development,
Linux/PPC Development, Geert Uytterhoeven, Andrew Morton,
linux-ext4
In-Reply-To: <20080204045025.GA7494@skywalker>
> > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
> > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
> > > >
> > > > The s390 specific bitops uses parts of the generic implementation.
> > > > Include the correct header.
> > >
> > > That doesn't work:
> > >
> > > fs/built-in.o: In function `ext4_mb_release_inode_pa':
> > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
> > > fs/built-in.o: In function `ext4_mb_init_cache':
> > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
> > >
> > > This still needs generic_find_next_le_bit which comes
> > > from lib/find_next_bit.c. That one doesn't get built on s390 since we
> > > don't set GENERIC_FIND_NEXT_BIT.
> > > Currently we have the lengthly patch below queued.
> >
> > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
> > impression the ext4 people don't (compile) test on big endian machines?
> >
> > Gr{oetje,eeting}s,
> >
>
> I have sent this patches to linux-arch expecting a review from
> different arch people. It is true that the patches are tested only on
> powerpc, x86-64, x86. That's the primary reason of me sending the
> patches to linux-arch.
Is there anything special I need to do so the ext4 code actually uses
ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to
test if the s390 implementation is ok.
^ permalink raw reply
* Moving from 2.6.14 (ppc) to 2.6.20 (powerpc): problems with PCI-PCI bridge
From: Johan Borkhuis @ 2008-02-04 9:13 UTC (permalink / raw)
To: Linuxppc-dev, Linuxppc-embedded
Hello,
I was using kernel version 2.6.14 (ppc) on a MVME3100 board (MPC8540
processor). We are planning to move to 2.6.20 (powerpc), but I have some
problems with the initialization of a PCI-PCI bridge.
Connected to the MVME3100 board is a PCI-PCI bridge (HiNT, PCI6150,
3388:0022). When using the 2.6.14 kernel this bridge is initialized
correctly: it is setup as bus-master, memory and IO are configured, and
the memory allocation on the PCI-bus is correct.
When I use 2.6.20 (powerpc) the device is not configured correctly:
bus-master, memory and IO are not set, and the memory space of the
bridge on the PCI bus is set to the minimum value (0xfffff).
I can correct these settings by modifying the PCI_COMMAND register to
set the bus-master, memory and IO. I change the size of the memory space
in pci_32.c, by forcing the size to the required setting in
pci_relocate_bridge_resource. But to be honest, I don't like this very
much: modifying registers like this should not be needed, so I guess
there is something wrong in my configuration or setup.
How can I fix this problem in a better way? What could be wrong with my
configuration?
Below is some output from lspci:
bash-3.00# lspci -t
-[0000:00]-+-01.0
+-02.0-[0000:01]--
+-03.0-[0000:02-03]--+-00.0
| +-00.1
| +-00.2
| \-04.0-[0000:03]--+-02.0
| \-03.0
\-04.0
bash-3.00# lspci -vs 02:04.0
02:04.0 PCI bridge: Hint Corp HiNT HB4 PCI-PCI Bridge (PCI6150) (rev 04)
(prog-if 00 [Normal decode])
Flags: bus master, medium devsel, latency 0
Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00011000-00011fff
Memory behind bridge: 87f00000-87ffffff
Prefetchable memory behind bridge: 0000000087e00000-0000000087e00000
Capabilities: [dc] Power Management version 1
Capabilities: [e4] #06 [0094]
Capabilities: [e8] Vital Product Data
After the modifications to the PCI COMMAND register and memory map:
bash-3.00# lspci -vs 02:04.0
02:04.0 PCI bridge: Hint Corp HiNT HB4 PCI-PCI Bridge (PCI6150) (rev 04)
(prog-if 00 [Normal decode])
Flags: stepping, medium devsel
Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00011000-00011fff
Memory behind bridge: 82000000-87ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Capabilities: [dc] Power Management version 1
Capabilities: [e4] #06 [0094]
Capabilities: [e8] Vital Product Data
Kind regards,
Johan Borkhuis
--
Johan Borkhuis Dutch Space BV
email: j.borkhuis@dutchspace.nl Newtonweg 1
phone: 071-5245788 Leiden
fax: 071-5245499 The Netherlands
^ permalink raw reply
* Fwd: [RFC/PATCH v2] [POWERPC] bootwrapper: build multiple cuImages
From: Grant Likely @ 2008-02-04 7:05 UTC (permalink / raw)
To: David Woodhouse, linuxppc-dev
In-Reply-To: <20080201000706.18869.36903.stgit@trillian.secretlab.ca>
David, can you please take a look at this patch? It makes two changes
which will have an impact on distributions.
First, it changes the ps3 target from zImage.ps3 to zImage.dtb.ps3.
The change was made to simplify the build dependancies in
arch/powerpc/boot/Makefile so that each target that embeds a device
tree into the zImage doesn't need to clone a new makefile rule (which
affects 5 platforms at the moment).
Second, I've eliminated the BOOTIMAGE environmental variable. I don't
think it's used anywhere, but it's possible that distros make use of
it.
Let me know if either of these pose a serious problem.
Thanks,
g.
---------- Forwarded message ----------
From: Grant Likely <grant.likely@secretlab.ca>
Date: Jan 31, 2008 5:07 PM
Subject: [RFC/PATCH v2] [POWERPC] bootwrapper: build multiple cuImages
To: jwboyer@gmail.com, linuxppc-dev@ozlabs.org,
scotwood@freescale.com, galak@kernel.crashing.org,
stephen.neuendorffer@xilinx.com, jochen@scram.de,
geoffrey.levand@am.sony.com
From: Grant Likely <grant.likely@secretlab.ca>
Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image
with a fdt blob which means for any given configuration only one dts
file can be selected and so support for only one board can be built
This patch moves the selection of the default .dts file out of the kernel
config and into the bootwrapper makefile. The makefile chooses which
images to build based on the kernel config and the dts source file
name is taken directly from the image name. For example "cuImage.ebony"
will use "ebony.dts" as the device tree source file.
In addition, this patch allows a specific image to be requested from the
command line by adding "cuImage.%" and "treeImage.%" targets to the list
of valid built targets in arch/powerpc/Makefile. This allows the default
dts selection to be overridden.
Another advantage to this change is it allows a single defconfig to be
supplied for all boards using the same chip family and only differing in
the device tree.
Important note: This patch adds two new zImage targets; zImage.dtb.% and
zImage.dtb.initrd.% for zImages with embedded dtb files. Currently
there are 5 platforms which require this: ps3, ep405, mpc885ads, ep88xc,
adder875-redboot and ep8248e. This patch *changes the zImage filenames*
for those platforms. ie. 'zImage.ps3' is now 'zImage.dtb.ps3'.
This new zImage.dtb targets were added so that the .dts file could be
part of the dependancies list for building them.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Please review and comment. I have not exhaustively tested this patch
and I'm sure to have missed some boards. However, I think the concept
is sound and will be a good change.
This version fixes some bugs and adds new zImage.dtb and zImage.initrd.dtb
targets.
g.
---
arch/powerpc/Kconfig | 19 -----
arch/powerpc/Makefile | 9 +-
arch/powerpc/boot/Makefile | 132 ++++++++++++++++++++------------
arch/powerpc/boot/cuboot-hpc2.c | 48 ------------
arch/powerpc/boot/cuboot-mpc7448hpc2.c | 48 ++++++++++++
arch/powerpc/boot/wrapper | 23 ++++++
6 files changed, 157 insertions(+), 122 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2bf2f3f..4903796 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -415,25 +415,6 @@ config WANT_DEVICE_TREE
bool
default n
-config DEVICE_TREE
- string "Static device tree source file"
- depends on WANT_DEVICE_TREE
- help
- This specifies the device tree source (.dts) file to be
- compiled and included when building the bootwrapper. If a
- relative filename is given, then it will be relative to
- arch/powerpc/boot/dts. If you are not using the bootwrapper,
- or do not need to build a dts into the bootwrapper, this
- field is ignored.
-
- For example, this is required when building a cuImage target
- for an older U-Boot, which cannot pass a device tree itself.
- Such a kernel will not work with a newer U-Boot that tries to
- pass a device tree (unless you tell it not to). If your U-Boot
- does not mention a device tree in "help bootm", then use the
- cuImage target and specify a device tree here. Otherwise, use
- the uImage target and leave this field blank.
-
endmenu
config ISA_DMA_API
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f70df9b..6845482 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -151,14 +151,11 @@ core-$(CONFIG_XMON) += arch/powerpc/xmon/
drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
-defaultimage-y := zImage
-defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
-KBUILD_IMAGE := $(defaultimage-y)
-all: $(KBUILD_IMAGE)
+all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd uImage
+BOOT_TARGETS = zImage zImage.initrd uImage treeImage.% cuImage.%
PHONY += $(BOOT_TARGETS)
@@ -180,7 +177,7 @@ define archhelp
endef
install: vdso_install
- $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install
+ $(Q)$(MAKE) $(build)=$(boot) install
vdso_install:
ifeq ($(CONFIG_PPC64),y)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 122a270..bd2b98d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -60,8 +60,9 @@ src-wlib := string.S crt0.S stdio.c main.c \
src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c
cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
cuboot-bamboo.c \
- fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
+ cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
+ cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
+ fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c
src-boot := $(src-wlib) $(src-plat) empty.c
@@ -123,6 +124,8 @@ targets += $(patsubst
$(obj)/%,%,$(obj-boot) wrapper.a)
extra-y := $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
$(obj)/zImage.lds $(obj)/zImage.coff.lds
$(obj)/zImage.ps3.lds
+dtstree := $(srctree)/$(src)/dts
+
wrapper :=$(srctree)/$(src)/wrapper
wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff
mktree dtc) \
$(wrapper) FORCE
@@ -181,7 +184,7 @@ quiet_cmd_wrap = WRAP $@
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
image-$(CONFIG_PPC_MAPLE) += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
-image-$(CONFIG_PPC_PS3) += zImage.ps3
+image-$(CONFIG_PPC_PS3) += zImage.dtb.ps3
image-$(CONFIG_PPC_CELLEB) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
image-$(CONFIG_PPC_EFIKA) += zImage.chrp
@@ -191,33 +194,73 @@ image-$(CONFIG_PPC_PRPMC2800) +=
zImage.prpmc2800
image-$(CONFIG_PPC_ISERIES) += zImage.iseries
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
-ifneq ($(CONFIG_DEVICE_TREE),"")
-image-$(CONFIG_PPC_8xx) += cuImage.8xx
-image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
-image-$(CONFIG_EP405) += zImage.ep405
-image-$(CONFIG_8260) += cuImage.pq2
-image-$(CONFIG_EP8248E) += zImage.ep8248e
-image-$(CONFIG_PPC_MPC52xx) += cuImage.52xx
-image-$(CONFIG_STORCENTER) += cuImage.824x
-image-$(CONFIG_PPC_83xx) += cuImage.83xx
-image-$(CONFIG_PPC_85xx) += cuImage.85xx
-ifeq ($(CONFIG_CPM2),y)
-image-$(CONFIG_PPC_85xx) += cuImage.85xx-cpm2
-endif
-image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
+#
+# Targets which embed a device tree blob
+#
+# Theses are default targets to build images which embed device tree blobs.
+# They are only required on boards which do not have FDT support in firmware.
+# Boards with newish u-boot firmare can use the uImage target above
+#
+
+# Board ports in arch/powerpc/platform/40x/Kconfig
+image-$(CONFIG_EP405) += zImage.dtb.ep405
+image-$(CONFIG_WALNUT) += treeImage.walnut
+
+# Board ports in arch/powerpc/platform/44x/Kconfig
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
image-$(CONFIG_RAINIER) += cuImage.rainier
-image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN) += cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
-endif
-ifneq ($(CONFIG_REDBOOT),"")
-image-$(CONFIG_PPC_8xx) += zImage.redboot-8xx
-endif
+# Board ports in arch/powerpc/platform/8xx/Kconfig
+image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
+image-$(CONFIG_PPC_MPC885ADS) += zImage.dtb.mpc885ads
+image-$(CONFIG_PPC_EP88XC) += zImage.dtb.ep88xc
+image-$(CONFIG_PPC_ADDER875) += cuImage.adder875-uboot \
+ zImage.dtb.adder875-redboot
+
+# Board ports in arch/powerpc/platform/52xx/Kconfig
+image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
+
+# Board ports in arch/powerpc/platform/82xx/Kconfig
+image-$(CONFIG_MPC8272_ADS) += cuImage.mpc8272ads
+image-$(CONFIG_PQ2FADS) += cuImage.pq2fads
+image-$(CONFIG_EP8248E) += zImage.dtb.ep8248e
+
+# Board ports in arch/powerpc/platform/83xx/Kconfig
+image-$(CONFIG_MPC8313_RDB) += cuImage.mpc8313erdb
+image-$(CONFIG_MPC832x_MDS) += cuImage.mpc832x_mds
+image-$(CONFIG_MPC832x_RDB) += cuImage.mpc832x_rdb
+image-$(CONFIG_MPC834x_ITX) += cuImage.mpc8349emitx \
+ cuImage.mpc8349emitxgp
+image-$(CONFIG_MPC834x_MDS) += cuImage.mpc834x_mds
+image-$(CONFIG_MPC836x_MDS) += cuImage.mpc836x_mds
+image-$(CONFIG_MPC837x_MDS) += cuImage.mpc8377_mds \
+ cuImage.mpc8378_mds \
+ cuImage.mpc8379_mds
+
+# Board ports in arch/powerpc/platform/85xx/Kconfig
+image-$(CONFIG_MPC8540_ADS) += cuImage.mpc8540ads
+image-$(CONFIG_MPC8560_ADS) += cuImage.mpc8560ads
+image-$(CONFIG_MPC85xx_CDS) += cuImage.mpc8541cds \
+ cuImage.mpc8548cds \
+ cuImage.mpc8555cds
+image-$(CONFIG_MPC85xx_MDS) += cuImage.mpc8568mds
+image-$(CONFIG_MPC85xx_DS) += cuImage.mpc8544ds \
+ cuImage.mpc8572ds
+image-$(CONFIG_TQM8540) += cuImage.tqm8540
+image-$(CONFIG_TQM8541) += cuImage.tqm8541
+image-$(CONFIG_TQM8555) += cuImage.tqm8555
+image-$(CONFIG_TQM8560) += cuImage.tqm8560
+image-$(CONFIG_SBC8548) += cuImage.tqm8548
+image-$(CONFIG_SBC8560) += cuImage.tqm8560
+
+# Board ports in arch/powerpc/platform/embedded6xx/Kconfig
+image-$(CONFIG_STORCENTER) += cuImage.storcenter
+image-$(CONFIG_MPC7448HPC2) += cuImage.mpc7448hpc2
# For 32-bit powermacs, build the COFF and miboot images
# as well as the ELF images.
@@ -233,24 +276,20 @@ targets += $(image-y) $(initrd-y)
$(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
-# If CONFIG_WANT_DEVICE_TREE is set and CONFIG_DEVICE_TREE isn't an
-# empty string, define 'dts' to be path to the dts
-# CONFIG_DEVICE_TREE will have "" around it, make sure to strip them
-ifeq ($(CONFIG_WANT_DEVICE_TREE),y)
-ifneq ($(CONFIG_DEVICE_TREE),"")
-dts = $(if $(shell echo $(CONFIG_DEVICE_TREE) | grep '^/'),\
- ,$(srctree)/$(src)/dts/)$(CONFIG_DEVICE_TREE:"%"=%)
-endif
-endif
-
# Don't put the ramdisk on the pattern rule; when its missing make will try
# the pattern rule with less dependencies that also matches (even with the
# hard dependency listed).
-$(obj)/zImage.initrd.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/zImage.initrd.dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/zImage.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts))
+$(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*,,,$(obj)/ramdisk.image.gz)
+
+$(obj)/zImage.dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts)
+
+$(obj)/zImage.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*)
# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
# prefix
@@ -260,24 +299,17 @@ $(obj)/vmlinux.strip: vmlinux
$(obj)/zImage.iseries: vmlinux
$(STRIP) -s -R .comment $< -o $@
-$(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits)
$(srctree)/$(src)/dts/ps3.dts
- $(STRIP) -s -R .comment $< -o vmlinux.strip
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
-
-$(obj)/zImage.initrd.ps3: vmlinux $(wrapper) $(wrapperbits)
$(srctree)/$(src)/dts/ps3.dts $(obj)/ramdisk.image.gz
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,$(obj)/ramdisk.image.gz)
-
$(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
-$(obj)/cuImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,cuboot-$*,$(dts))
+$(obj)/cuImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,cuboot-$*,$(dtstree)/$*.dts)
-$(obj)/treeImage.initrd.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts))
+$(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
@@ -286,8 +318,10 @@ endif
$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
@rm -f $@; ln $< $@
+ @echo target images: $(image-y)
$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
@rm -f $@; ln $< $@
+ @echo target images: $(initrd-y)
install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux
System.map "$(INSTALL_PATH)" $<
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-hpc2.c
deleted file mode 100644
index 1b89532..0000000
--- a/arch/powerpc/boot/cuboot-hpc2.c
+++ /dev/null
@@ -1,48 +0,0 @@
-/*
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
- *
- * Author: Roy Zang <tie-fei.zang@freescale.com>
- *
- * Description:
- * Old U-boot compatibility for mpc7448hpc2 board
- * Based on the code of Scott Wood <scottwood@freescale.com>
- * for 83xx and 85xx.
- *
- * This is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- */
-
-#include "ops.h"
-#include "stdio.h"
-#include "cuboot.h"
-
-#define TARGET_HAS_ETH1
-#include "ppcboot.h"
-
-static bd_t bd;
-extern char _dtb_start[], _dtb_end[];
-
-static void platform_fixups(void)
-{
- void *tsi;
-
- dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
- dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
- dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
- tsi = find_node_by_devtype(NULL, "tsi-bridge");
- if (tsi)
- setprop(tsi, "bus-frequency", &bd.bi_busfreq,
- sizeof(bd.bi_busfreq));
-}
-
-void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
- unsigned long r6, unsigned long r7)
-{
- CUBOOT_INIT();
- fdt_init(_dtb_start);
- serial_console_init();
- platform_ops.fixups = platform_fixups;
-}
diff --git a/arch/powerpc/boot/cuboot-mpc7448hpc2.c
b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
new file mode 100644
index 0000000..1b89532
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Roy Zang <tie-fei.zang@freescale.com>
+ *
+ * Description:
+ * Old U-boot compatibility for mpc7448hpc2 board
+ * Based on the code of Scott Wood <scottwood@freescale.com>
+ * for 83xx and 85xx.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "cuboot.h"
+
+#define TARGET_HAS_ETH1
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *tsi;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+ tsi = find_node_by_devtype(NULL, "tsi-bridge");
+ if (tsi)
+ setprop(tsi, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ fdt_init(_dtb_start);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 763a0c4..c317815 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -158,6 +158,29 @@ miboot|uboot)
cuboot*)
binary=y
gzip=
+ case "$platform" in
+ *-mpc885ads|*-adder875*|*-ep88xc)
+ platformo=$object/cuboot-8xx.o
+ ;;
+ *5200*|*-motionpro)
+ platformo=$object/cuboot-52xx.o
+ ;;
+ *-pq2fads|*-ep8248e|*-mpc8272*|*-storcenter)
+ platformo=$object/cuboot-pq2.o
+ ;;
+ *-mpc824*)
+ platformo=$object/cuboot-824x.o
+ ;;
+ *-mpc83*)
+ platformo=$object/cuboot-83xx.o
+ ;;
+ *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+ platformo=$object/cuboot-85xx-cpm2.o
+ ;;
+ *-mpc85*)
+ platformo=$object/cuboot-85xx.o
+ ;;
+ esac
;;
ps3)
platformo="$object/ps3-head.o $object/ps3-hvcall.o $object/ps3.o"
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply related
* Re: [PATCH] create modalias file in sysfs for bus vio
From: Stephen Rothwell @ 2008-02-04 6:39 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080125170914.GA29887@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
Hi Olaf,
[Sorry, been on vacation]
On Fri, 25 Jan 2008 18:09:14 +0100 Olaf Hering <olaf@aepfle.de> wrote:
>
> On Wed, Jan 23, Stephen Rothwell wrote:
>
> > It would be nice if we could factor out the "vio:T%sS%s" string as it is
> > also used in vio_hotplug().
>
> What exactly do you have in mind?
> Creating a tempstring seems to make things more complicated.
Yeah, but it would be nice if the format only had to be known/changed in
one place. Don't worry about it for now. Or maybe create a "static const
char []" or #define with the string.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ppc] Disparity between sys_clock_getres and vdso implementation
From: Tony Breeds @ 2008-02-04 6:08 UTC (permalink / raw)
To: Sripathi Kodi; +Cc: linuxppc-dev, paulus, linux-kernel, john stultz
In-Reply-To: <200801271932.59823.sripathik@in.ibm.com>
On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote:
> Hi Paul,
>
> On PPC, I see a disparity between clock_getres implementations in the
> vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
> with CONFIG_HIGH_RES_TIMERS=y.
>
> clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
> when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
> sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
> to be returning some pre-defined (incorrect) variables.
>
> Could you please let me know the reason for this? Is it something that
> should be fixed in vdso?
Almost certainly It's something I missed when I enabled highres timers
on powerpc.
I'll fix this tomorrow.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox