* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Scott Wood @ 2007-10-05 18:01 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <47067ADE.9060306@ru.mvista.com>
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> Anton Vorontsov wrote:
>
> > Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
> > PCI/PCIe nodes, but actually it broke them even harder. ;-)
>
> Of course. But shouldn't those be the subnoses of the "soc" type node?
No -- the soc node is for immr/ccsr only, and while the PCI control
registers are there, the ranges are not. There was a lengthy discussion on
IRC about this a couple weeks ago. It'd be cleaner to split the control
node from the bus node, and connect them with phandles, but some people
didn't like that, and this is what we compromised on.
-Scott
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Sergei Shtylyov @ 2007-10-05 17:56 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071005174642.GB32145@localhost.localdomain>
Hello.
Anton Vorontsov wrote:
> Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
> PCI/PCIe nodes, but actually it broke them even harder. ;-)
Of course. But shouldn't those be the subnoses of the "soc" type node?
I don't suppose the PCI controllers could hang off the root node... :-/
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
> index b4aa5e7..5439437 100644
> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
> @@ -410,7 +410,7 @@
>
> };
>
> - pci@8000 {
> + pci@e0008000 {
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
> /* IDSEL 0x12 AD18 */
> @@ -434,13 +434,13 @@
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> - reg = <8000 1000>;
> + reg = <e0008000 1000>;
> compatible = "fsl,mpc8540-pci";
> device_type = "pci";
> };
>
> /* PCI Express */
> - pcie@a000 {
> + pcie@e000a000 {
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
>
> @@ -459,7 +459,7 @@
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> - reg = <a000 1000>;
> + reg = <e000a000 1000>;
> compatible = "fsl,mpc8548-pcie";
> device_type = "pci";
> pcie@0 {
WBR, Sergei
^ permalink raw reply
* [PATCH 1/7] [POWERPC] mpc85xx_mds: select QUICC_ENGINE
From: Anton Vorontsov @ 2007-10-05 17:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index b8476b2..cf815b2 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -25,7 +25,7 @@ config MPC85xx_CDS
config MPC85xx_MDS
bool "Freescale MPC85xx MDS"
select DEFAULT_UIMAGE
-# select QUICC_ENGINE
+ select QUICC_ENGINE
help
This option enables support for the MPC85xx MDS board
--
1.5.0.6
^ permalink raw reply related
* [PATCH 2/7] [POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Anton Vorontsov @ 2007-10-05 17:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
set_irq_chained_handler overwrites MPIC's handle_irq function
(handle_fasteoi_irq) thus MPIC never gets eoi event from the
cascaded IRQ. This situation hangs MPIC on MPC8568E.
To solve this problem efficiently, QEIC needs pluggable handlers,
specific to the underlaying interrupt controller.
Patch extends qe_ic_init() function to accept low and high interrupt
handlers. To avoid #ifdefs, stack of interrupt handlers specified in
the header file and functions are marked 'static inline', thus
handlers are compiled-in only if actually used (in the board file).
Another option would be to lookup for parent controller and
automatically detect handlers (will waste text size because of
never used handlers, so this option abolished).
qe_ic_init() also changed in regard to support multiplexed high/low
lines as found in MPC8568E-MDS, plus qe_ic_cascade_muxed_mpic()
handler implemented appropriately.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/83xx/mpc832x_mds.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 2 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c | 29 +++---------
include/asm-powerpc/qe_ic.h | 68 ++++++++++++++++++++++++++++-
6 files changed, 78 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index b8d8c91..972fa85 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -140,7 +140,7 @@ static void __init mpc832x_sys_init_IRQ(void)
if (!np)
return;
- qe_ic_init(np, 0);
+ qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
of_node_put(np);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index 4da0698..fbca336 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -151,7 +151,7 @@ void __init mpc832x_rdb_init_IRQ(void)
if (!np)
return;
- qe_ic_init(np, 0);
+ qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
of_node_put(np);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0b18a75..0f3855c 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -147,7 +147,7 @@ static void __init mpc836x_mds_init_IRQ(void)
if (!np)
return;
- qe_ic_init(np, 0);
+ qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
of_node_put(np);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 00f4c3a..57e840a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -180,7 +180,7 @@ static void __init mpc85xx_mds_pic_init(void)
if (!np)
return;
- qe_ic_init(np, 0);
+ qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);
of_node_put(np);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 9a2d1ed..e1c0fd6 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -321,25 +321,9 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
return irq_linear_revmap(qe_ic->irqhost, irq);
}
-void qe_ic_cascade_low(unsigned int irq, struct irq_desc *desc)
-{
- struct qe_ic *qe_ic = desc->handler_data;
- unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
-
- if (cascade_irq != NO_IRQ)
- generic_handle_irq(cascade_irq);
-}
-
-void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
-{
- struct qe_ic *qe_ic = desc->handler_data;
- unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
-
- if (cascade_irq != NO_IRQ)
- generic_handle_irq(cascade_irq);
-}
-
-void __init qe_ic_init(struct device_node *node, unsigned int flags)
+void __init qe_ic_init(struct device_node *node, unsigned int flags,
+ void (*low_handler)(unsigned int irq, struct irq_desc *desc),
+ void (*high_handler)(unsigned int irq, struct irq_desc *desc))
{
struct qe_ic *qe_ic;
struct resource res;
@@ -399,11 +383,12 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags)
qe_ic_write(qe_ic->regs, QEIC_CICR, temp);
set_irq_data(qe_ic->virq_low, qe_ic);
- set_irq_chained_handler(qe_ic->virq_low, qe_ic_cascade_low);
+ set_irq_chained_handler(qe_ic->virq_low, low_handler);
- if (qe_ic->virq_high != NO_IRQ) {
+ if (qe_ic->virq_high != NO_IRQ &&
+ qe_ic->virq_high != qe_ic->virq_low) {
set_irq_data(qe_ic->virq_high, qe_ic);
- set_irq_chained_handler(qe_ic->virq_high, qe_ic_cascade_high);
+ set_irq_chained_handler(qe_ic->virq_high, high_handler);
}
}
diff --git a/include/asm-powerpc/qe_ic.h b/include/asm-powerpc/qe_ic.h
index e386fb7..a779b2c 100644
--- a/include/asm-powerpc/qe_ic.h
+++ b/include/asm-powerpc/qe_ic.h
@@ -56,9 +56,75 @@ enum qe_ic_grp_id {
QE_IC_GRP_RISCB /* QE interrupt controller RISC group B */
};
-void qe_ic_init(struct device_node *node, unsigned int flags);
+void qe_ic_init(struct device_node *node, unsigned int flags,
+ void (*low_handler)(unsigned int irq, struct irq_desc *desc),
+ void (*high_handler)(unsigned int irq, struct irq_desc *desc));
void qe_ic_set_highest_priority(unsigned int virq, int high);
int qe_ic_set_priority(unsigned int virq, unsigned int priority);
int qe_ic_set_high_priority(unsigned int virq, unsigned int priority, int high);
+struct qe_ic;
+unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic);
+unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic);
+
+static inline void qe_ic_cascade_low_ipic(unsigned int irq,
+ struct irq_desc *desc)
+{
+ struct qe_ic *qe_ic = desc->handler_data;
+ unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+}
+
+static inline void qe_ic_cascade_high_ipic(unsigned int irq,
+ struct irq_desc *desc)
+{
+ struct qe_ic *qe_ic = desc->handler_data;
+ unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+}
+
+static inline void qe_ic_cascade_low_mpic(unsigned int irq,
+ struct irq_desc *desc)
+{
+ struct qe_ic *qe_ic = desc->handler_data;
+ unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ desc->chip->eoi(irq);
+}
+
+static inline void qe_ic_cascade_high_mpic(unsigned int irq,
+ struct irq_desc *desc)
+{
+ struct qe_ic *qe_ic = desc->handler_data;
+ unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ desc->chip->eoi(irq);
+}
+
+static inline void qe_ic_cascade_muxed_mpic(unsigned int irq,
+ struct irq_desc *desc)
+{
+ struct qe_ic *qe_ic = desc->handler_data;
+ unsigned int cascade_irq;
+
+ cascade_irq = qe_ic_get_high_irq(qe_ic);
+ if (cascade_irq == NO_IRQ)
+ cascade_irq = qe_ic_get_low_irq(qe_ic);
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ desc->chip->eoi(irq);
+}
+
#endif /* _ASM_POWERPC_QE_IC_H */
--
1.5.0.6
^ permalink raw reply related
* [PATCH 3/7] [POWERPC] QE pario: support for MPC85xx layout
From: Anton Vorontsov @ 2007-10-05 17:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
8 bytes padding required to match MPC85xx registers layout.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Reviewed-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/sysdev/qe_lib/qe_io.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c b/arch/powerpc/sysdev/qe_lib/qe_io.c
index a114cb0..e53ea4d 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_io.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
@@ -36,6 +36,9 @@ struct port_regs {
__be32 cpdir2; /* Direction register */
__be32 cppar1; /* Pin assignment register */
__be32 cppar2; /* Pin assignment register */
+#ifdef CONFIG_PPC_85xx
+ u8 pad[8];
+#endif
};
static struct port_regs *par_io = NULL;
--
1.5.0.6
^ permalink raw reply related
* [PATCH 4/7] [POWERPC] mpc8568mds: update dts to be able to use UCCs
From: Anton Vorontsov @ 2007-10-05 17:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
1. UCC1's RX_DV pin is 16, not 15;
2. UCC1's phy is at 0x7, not 0x1. Schematics says 0x7, and recent
u-boot also using 0x7.
3. Use gianfar's (eTSEC) mdio bus. This is hardware default setup.
4. tx-clock should be CLK16 (GE125, PB31);
5. phy-connection-type is RGMII-ID;
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 6ac134a..b4aa5e7 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -104,10 +104,10 @@
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
- phy0: ethernet-phy@0 {
+ phy0: ethernet-phy@7 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
@@ -242,7 +242,7 @@
4 1a 2 0 2 0 /* RxD7 */
4 0b 1 0 2 0 /* TX_EN */
4 18 1 0 2 0 /* TX_ER */
- 4 0f 2 0 2 0 /* RX_DV */
+ 4 10 2 0 2 0 /* RX_DV */
4 1e 2 0 2 0 /* RX_ER */
4 11 2 0 2 0 /* RX_CLK */
4 13 1 0 2 0 /* GTX_CLK */
@@ -334,10 +334,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <0>;
- tx-clock = <19>;
- phy-handle = <&qe_phy0>;
- phy-connection-type = "gmii";
+ tx-clock = <20>;
pio-handle = <&pio1>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
};
ucc@3000 {
@@ -356,10 +356,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <0>;
- tx-clock = <14>;
- phy-handle = <&qe_phy1>;
- phy-connection-type = "gmii";
+ tx-clock = <20>;
pio-handle = <&pio2>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
};
mdio@2120 {
@@ -371,10 +371,10 @@
/* These are the same PHYs as on
* gianfar's MDIO bus */
- qe_phy0: ethernet-phy@00 {
+ qe_phy0: ethernet-phy@07 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
qe_phy1: ethernet-phy@01 {
--
1.5.0.6
^ permalink raw reply related
* [PATCH 5/7] [POWERPC] mpc85xx_mds: reset UCC ethernet properly
From: Anton Vorontsov @ 2007-10-05 17:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
Apart from that the current code doesn't compile it's also
meaningless with regard to the MPC8568E-MDS' BCSR.
This patch used to reset UCCs properly.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 57e840a..6913e99 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -113,18 +113,22 @@ static void __init mpc85xx_mds_setup_arch(void)
}
if (bcsr_regs) {
- u8 bcsr_phy;
-
- /* Reset the Ethernet PHY */
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy &= ~0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
-
- udelay(1000);
-
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy |= 0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
+#define BCSR_UCC1_GETH_EN (0x1 << 7)
+#define BCSR_UCC2_GETH_EN (0x1 << 7)
+#define BCSR_UCC1_MODE_MSK (0x3 << 4)
+#define BCSR_UCC2_MODE_MSK (0x3 << 0)
+
+ /* Turn off UCC1 & UCC2 */
+ clrbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ clrbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
+
+ /* Mode is RGMII, all bits clear */
+ clrbits8(&bcsr_regs[11], BCSR_UCC1_MODE_MSK |
+ BCSR_UCC2_MODE_MSK);
+
+ /* Turn UCC1 & UCC2 on */
+ setbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ setbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
iounmap(bcsr_regs);
}
--
1.5.0.6
^ permalink raw reply related
* [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Anton Vorontsov @ 2007-10-05 17:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index b4aa5e7..5439437 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -410,7 +410,7 @@
};
- pci@8000 {
+ pci@e0008000 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x12 AD18 */
@@ -434,13 +434,13 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <8000 1000>;
+ reg = <e0008000 1000>;
compatible = "fsl,mpc8540-pci";
device_type = "pci";
};
/* PCI Express */
- pcie@a000 {
+ pcie@e000a000 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
@@ -459,7 +459,7 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <a000 1000>;
+ reg = <e000a000 1000>;
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
pcie@0 {
--
1.5.0.6
^ permalink raw reply related
* [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC Engine
From: Anton Vorontsov @ 2007-10-05 17:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: spi-devel-general
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
Currently, all QE SPI controllers are almost the same comparing to
MPC83xx's, thus let's use that driver for them.
Tested to work on MPC85xx in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
This is respin. Hope this time it will get ack from the
PowerPC team.
drivers/spi/Kconfig | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..a77ede5 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -124,16 +124,17 @@ config SPI_MPC52xx_PSC
Controller in master SPI mode.
config SPI_MPC83xx
- tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ tristate "Freescale MPC83xx/QUICC Engine SPI controller"
+ depends on SPI_MASTER && (PPC_83xx || QUICC_ENGINE) && EXPERIMENTAL
select SPI_BITBANG
help
- This enables using the Freescale MPC83xx SPI controller in master
- mode.
+ This enables using the Freescale MPC83xx and QUICC Engine SPI
+ controllers in master mode.
Note, this driver uniquely supports the SPI controller on the MPC83xx
- family of PowerPC processors. The MPC83xx uses a simple set of shift
- registers for data (opposed to the CPM based descriptor model).
+ family of PowerPC processors, plus processors with QUICC Engine
+ technology. This driver uses a simple set of shift registers for data
+ (opposed to the CPM based descriptor model).
config SPI_OMAP_UWIRE
tristate "OMAP1 MicroWire"
--
1.5.0.6
^ permalink raw reply related
* [PATCH respin 0/7] MPC8568E-MDS related patches
From: Anton Vorontsov @ 2007-10-05 17:40 UTC (permalink / raw)
To: linuxppc-dev
Hello Kumar,
This is respin of MPC8568E-MDS patches, on top of master branch
as of today.
If there are no objections against SPI patch, please Ack it, thus
David could pick it up.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Scott Wood @ 2007-10-05 17:30 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071005015849.GA9862@mag.az.mvista.com>
On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> Having the link address jump around depending on the size of the kernel
> or zImage is wrong IMHO. It just screams "weird can't boot issues."
> We need a way to specify exactly where we want the zImage linked no
> matter what the kernel or zImage size.
Why? The zImage is relocatable. It doesn't matter where it's linked.
> Also, being able to control the link address (that is, the download
> address with some firmwares) is not a u-boot specific issue and we
> shouldn't make a u-boot specific solution.
How is this a u-boot specific solution?
> The more general problem is that some firmwares examine the ELF header
> and download the zImage to address it was linked at. Some firmwares let
> you override this but some don't and those are the problem ones.
That's not the more general problem; it's the same problem with a different
file format.
> I still like my idea best. I haven't coded yet it so I don't have a patch
> but this is what I mean:
>
> 1) add a config option (default 4MB) for the link address
> 2) add a parameter to the wrapper script thru which we pass the value in
> the config option
> 3) the wrapper script changes the VMA/LMA to the address specified
> (objcopy --change-addresses=<some math to get correct incr> ?).
I'd much rather it be automatic than require the user to guess an
appropriate value (and be aware in the first place that it needs to be set).
-Scott
^ permalink raw reply
* Re: Patch: Fix regression. Make hot unlplug of CPU0 work again.
From: Milton Miller @ 2007-10-05 17:16 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071005070519.GQ9814@bakeyournoodle.com>
On Fri, Oct 05, 2007 at 05:05:21PM, Tony Breeds wrote:
>> On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote:
>> Early in the 2.6.23 cycle we broke the ability to offline cpu0
>> (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
>> ensuring that the (xics) default irq server, will not be 0 when taking
>> cpu0 offline.
>>
>> Also catches a use of irq, when virq should be used (I think that the
>> last one).
>
> Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go
> back to the drawing board.
Reviewing the first patch, xics_set_affinity no longer looks at the
cpu_mask arg, instead get_irq_server reads it from the irq descriptor.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
On top of tonys patch (13926)
I don't have a system to test hotplug, so this is only compile tested.
A more complete fix might be to pass the cpu_mask struct to get_irq_server,
but kernel/irq/manage.c currently sets the descriptor first.
Index: kernel/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- kernel.orig/arch/powerpc/platforms/pseries/xics.c 2007-10-05 11:37:01.000000000 -0500
+++ kernel/arch/powerpc/platforms/pseries/xics.c 2007-10-05 11:37:16.000000000 -0500
@@ -890,8 +890,8 @@ void xics_migrate_irqs_away(void)
virq, cpu);
/* Reset affinity to all cpus */
- desc->chip->set_affinity(virq, CPU_MASK_ALL);
irq_desc[virq].affinity = CPU_MASK_ALL;
+ desc->chip->set_affinity(virq, CPU_MASK_ALL);
unlock:
spin_unlock_irqrestore(&desc->lock, flags);
}
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Linas Vepstas @ 2007-10-05 16:03 UTC (permalink / raw)
To: Nish Aravamudan; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <29495f1d0710041701g4ed73441ie583058c78f95857@mail.gmail.com>
On Thu, Oct 04, 2007 at 05:01:47PM -0700, Nish Aravamudan wrote:
> On 10/2/07, Tony Breeds <tony@bakeyournoodle.com> wrote:
> > On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
> >
> > > I realise it'll make the patch bigger, but this doesn't seem like a
> > > particularly good name for the variable anymore.
> >
> > Sure, what about?
> >
> > Clarify when RTAS logging is enabled.
> >
> > Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
>
> For what it's worth, on a different ppc64 box, this resolves a similar
> panic for me.
>
> Tested-by: Nishanth Aravamudan <nacc@us.ibm.com>
For the reasons explained, I'd really like to nack Tony's patch.
--linas
^ permalink raw reply
* jedec probe for AMD/Spansion flash (16 bit) device in 8 bit mode fails
From: Norbert van Bolhuis @ 2007-10-05 15:25 UTC (permalink / raw)
To: linuxppc-embedded, linux-mtd
My board has a regular AMD/Spansion compatible flash device. It's a
Spansion S29AL016D (2MB) which supports 8/16 bit access.
We use it in 8 bit and top boot block mode.
I thought the linux kernel would have no problem recognizing/supporting this
(regular) flash device. I was wrong.
The S29AL016D/AM29LV160DT datasheet says the following:
first second third fourth (read)
addr/data addr/data addr/data addr/data
Manufacturer ID, word 555/AA 2AA/55 555/90 X00/01
byte AAA/AA 555/55 AAA/90 X00/01
Device ID (top boot block), word 555/AA 2AA/55 555/90 X01/22C4
byte AAA/AA 555/55 AAA/90 X02/C4
Unfortunately the linux kernel does not recognize the chip.
The jedec_probe_chip function fails to recognize the chip, even though it's
present in the jedec_table[], the is the entry that represents the S29AL016D
(the S29AL016D is comptabile with AM29LV160DT):
.mfr_id = MANUFACTURER_AMD,
.dev_id = AM29LV160DT,
.name = "AMD AM29LV160DT",
.uaddr = {
[0] = MTD_UADDR_0x0AAA_0x0555, /* x8 */
[1] = MTD_UADDR_0x0555_0x02AA /* x16 */
},
.DevSize = SIZE_2MiB,
.CmdSet = P_ID_AMD_STD,
.NumEraseRegions= 4,
.regions = {
ERASEINFO(0x10000,31),
ERASEINFO(0x08000,1),
ERASEINFO(0x02000,2),
ERASEINFO(0x04000,1)
}
The above jedec_table entry seems to be correct and it should be the one to
find/match.
The problem when probing if "cfi->interleave=1 and cfi->device_type=2 (x16)" is
that the device is not put into autoselect mode properly.
This is because the unlock addresses are multiplied with the cfi->device_type
(this is done by cfi_build_cmd_addr) and thus the autoselect mode
(for MTD_UADDR_0x0AAA_0x0555, /* x8 */) is entered by writing:
address=0x1554, data=0xaa
address=0x0aaa, data=0x55
address=0x1554, data=0x90
This fails to put the chip into autoselect mode.
Here's the kernel corresponding kernel console output:
reset unlock called aaa 555
Search for id:(0a 00) interleave(1) type(2)
Note that 0a 00 is ordinary data.
Other unlock addresses (2aa 555 and 555 aaa) do get the device in autoselect mode,
but now there are two other problems which make jedec_match fail:
-1- the following code from jedec_match makes matching always fail for any x16
device in x8 mode ?
if ( cfi->mfr != mfr) || cfi->id != id ) {
goto match_done;
}
id is 16 bit (0x22c4), so it won't match 0xc4.
-2- the unlock address is wrong. Here's the corresponding kernel console output:
reset unlock called 555 2aa
Search for id:(01 c4) interleave(1) type(2)
MTD jedec_match(): Check fit 0x00000000 + 0x00200000 = 0x00200000
MTD jedec_match(): check unlock addrs 0x0555 0x02aa
MTD jedec_match(): 0x0aaa 0x0555 did not match 0x0555 0x02aa
reset unlock called 555 aaa
Search for id:(01 c4) interleave(1) type(2)
MTD jedec_match(): Check fit 0x00000000 + 0x00200000 = 0x00200000
MTD jedec_match(): check unlock addrs 0x0555 0x0aaa
MTD jedec_match(): 0x0aaa 0x0555 did not match 0x0555 0x0aaa
It wants to match with unlock address 0x0aaa 0x0555 (because this is the one
listed in the jedec_table[] entry for cfi->device_type=2=x16) and both pair
of unlock addresses (which do get the chip in autoselect mode) do not match.
I'm not sure whether the kernel should recognize the chip as 8 or 16 bit, I
guess 16 bit. Let me anyway discuss the 8 bit case also.
The problem when probing if "cfi->interleave=1 and cfi->device_type=1 (x8)" is
twofold:
-1- device id is not read correctly. After putting the device in "Autoselect Mode"
the device id is read from address 1 (it should be 2). This makes the device id
equal to the manufacture id. Here's the corresponding kernel console output:
reset unlock called aaa 555
Search for id:(01 01) interleave(1) type(1)
-2- even if the device id and manufacturer id would be read correctly the
chip won't be recognized anyway since jedec_match has the following code:
/* bjd: it seems that if we do this, we can end up
* detecting 16bit flashes as an 8bit device, even though
* there aren't.
*/
if (finfo->dev_id > 0xff) {
DEBUG( MTD_DEBUG_LEVEL3, "%s(): ID is not 8bit\n",
__func__);
goto match_done;
Because finfo->devid=AM29LV160DT=0x22C4 -> the ID is not 8 bit.
I'm sure I miss something. Our linux kernel is ancient (2.4.25) but more recent
linux kernel seem to have the same mtd/jedec code in this repect.
I anyone could help me pointing out what is wrong it would be great.
BR,
N. van Bolhuis.
Btw. is the linux mtd mailing list (linux-mtd@lists.infradead.org) still alive ?
I couldn't reach the archives at http://lists.infradead.org/pipermail/linux-mtd/
--
This message has been scanned for viruses and is believed to be clean
^ permalink raw reply
* Re: [PATCH] fsl_spi_init: Support non-QE processors
From: Kumar Gala @ 2007-10-05 14:11 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: PowerPC dev list, Stephen Rothwell
In-Reply-To: <20071004140126.99c0fab0.sfr@canb.auug.org.au>
On Oct 3, 2007, at 11:01 PM, Stephen Rothwell wrote:
> On Wed, 03 Oct 2007 17:43:50 +0200 Peter Korsgaard
> <jacmet@sunsite.dk> wrote:
>>
>> @@ -1220,14 +1220,17 @@ int __init fsl_spi_init(struct
>> spi_board_info *board_infos,
>> {
>> struct device_node *np;
>> unsigned int i;
>> - const u32 *sysclk;
>> + const u32 *qe_sysclk = 0, *soc_sysclk = 0;
>
> Please use NULL when referring to pointers.
Peter, any chance of getting a respin. I'd like this to go into 2.6.24.
- k
^ permalink raw reply
* Re: [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Anton Vorontsov @ 2007-10-05 12:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list
In-Reply-To: <E6B4F79B-254F-4273-8E49-D15BCFF6955A@kernel.crashing.org>
On Fri, Oct 05, 2007 at 12:18:58AM -0500, Kumar Gala wrote:
[...]
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>
>> Looks allright, if it also works, then ship it :-)
>>
>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Now that this has been ack'd by Ben if you can respin the patch set we can
> get these in for 2.6.24
Great, will do.
> (I assume you are using a UCC as ethernet for test some of the QE support
> on 8568?)
Yup, UCC as eth. Plus I've also tested SPI (which is in QE) in
loopback mode.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Fix regression. Make hot unlplug of CPU0 work again.
From: Michael Ellerman @ 2007-10-05 12:20 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071005070519.GQ9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
On Fri, 2007-10-05 at 17:05 +1000, Tony Breeds wrote:
> On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote:
> > Early in the 2.6.23 cycle we broke the ability to offline cpu0
> > (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
> > ensuring that the (xics) default irq server, will not be 0 when taking
> > cpu0 offline.
> >
> > Also catches a use of irq, when virq should be used (I think that the
> > last one).
>
> Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go
> back to the drawing board.
Maybe we should revert the original patch and go back to the drawing
board for 2.6.24? Making sure we address the initial problem (which was
exposed by kexec I think) and that we don't break cpu hotplug on the
way.
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: Device tree and external RTC
From: Guennadi Liakhovetski @ 2007-10-05 10:45 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: Peter Korsgaard, linuxppc-embedded
In-Reply-To: <OFF5EAF9C9.4E27AE67-ON8825736A.0064875E-8825736A.00652EB0@selinc.com>
On Thu, 4 Oct 2007 Bruce_Leonard@selinc.com wrote:
> A follow on question though. I've looked at the patch and it seems to be
> just adding 6 lines to an existing array in fsl_soc.c. However, I can't
> seem to find any array in fsl_soc.c that contains lines that the patch
> indicates should already be there (i.e., there's nothing in fsl_soc.c that
> has the word "ricoh" in it which the patch indicates it should). Is my
> fsl_soc.c already out of date? Will the patch apply? I've got 2.6.22.
Ok, we both (Peter and myself) have forgotten, that this change has first
aooeared after 2.6.22. So, best try 2.6.23-rc9, or use one of the
git-trees (from Linux or from Paulus, or from Kumar Gala, or...) _plus_
the patch we both pointed at.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Fix regression. Make hot unlplug of CPU0 work again.
From: Tony Breeds @ 2007-10-05 7:05 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
In-Reply-To: <20071005035241.GO9814@bakeyournoodle.com>
On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote:
> Early in the 2.6.23 cycle we broke the ability to offline cpu0
> (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
> ensuring that the (xics) default irq server, will not be 0 when taking
> cpu0 offline.
>
> Also catches a use of irq, when virq should be used (I think that the
> last one).
Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go
back to the drawing board.
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
* Re: [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Kumar Gala @ 2007-10-05 5:18 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: PowerPC dev list
In-Reply-To: <1191535520.28239.2.camel@pasglop>
On Oct 4, 2007, at 5:05 PM, Benjamin Herrenschmidt wrote:
>
>> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>> Subject: [PATCH] [POWERPC] QEIC: Implement pluggable handlers, fix
>> MPIC cascading
>>
>> set_irq_chained_handler overwrites MPIC's handle_irq function
>> (handle_fasteoi_irq) thus MPIC never gets eoi event from the
>> cascaded IRQ. This situation hangs MPIC on MPC8568E.
>>
>> To solve this problem efficiently, QEIC needs pluggable handlers,
>> specific to the underlaying interrupt controller.
>>
>> Patch extends qe_ic_init() function to accept low and high interrupt
>> handlers. To avoid #ifdefs, stack of interrupt handlers specified in
>> the header file and functions are marked 'static inline', thus
>> handlers are compiled-in only if actually used (in the board file).
>> Another option would be to lookup for parent controller and
>> automatically detect handlers, but this will waste text size because
>> of never used handlers.
>>
>> qe_ic_init() also changed in regard to support multiplexed high/low
>> lines as found in MPC8568E-MDS, plus qe_ic_cascade_muxed_mpic()
>> handler implemented appropriately.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> Looks allright, if it also works, then ship it :-)
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Now that this has been ack'd by Ben if you can respin the patch set
we can get these in for 2.6.24
(I assume you are using a UCC as ethernet for test some of the QE
support on 8568?)
- k
^ permalink raw reply
* Re: [PATCH 4/7] [POWERPC] QE pario: support for MPC85xx layout
From: Kumar Gala @ 2007-10-05 5:15 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070925143440.GD5323@localhost.localdomain>
On Sep 25, 2007, at 9:34 AM, Anton Vorontsov wrote:
> 8 bytes padding required to match MPC85xx registers layout.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/qe_lib/qe_io.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c b/arch/powerpc/
> sysdev/qe_lib/qe_io.c
> index e32b45b..d566e89 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe_io.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
> @@ -36,6 +36,9 @@ struct port_regs {
> __be32 cpdir2; /* Direction register */
> __be32 cppar1; /* Pin assignment register */
> __be32 cppar2; /* Pin assignment register */
> +#ifdef CONFIG_MPC85xx
use CONFIG_PPC_85xx
> + u8 pad[8];
> +#endif
> };
- k
^ permalink raw reply
* Fix regression. Make hot unlplug of CPU0 work again.
From: Tony Breeds @ 2007-10-05 3:52 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
Early in the 2.6.23 cycle we broke the ability to offline cpu0
(7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
ensuring that the (xics) default irq server, will not be 0 when taking
cpu0 offline.
Also catches a use of irq, when virq should be used (I think that the
last one).
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Unless there is a problem with this patch, it'd be nice to get it into
2.6.23 :)
arch/powerpc/platforms/pseries/xics.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index f0b5ff1..2fb8fd0 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -837,6 +837,15 @@ void xics_migrate_irqs_away(void)
/* Allow IPIs again... */
xics_set_cpu_priority(cpu, DEFAULT_PRIORITY);
+ /* It would be bad to migrate any IRQs to the CPU we're taking down */
+ if (default_server == cpu) {
+ unsigned int new_server = first_cpu(cpu_online_map);
+
+ default_server = get_hard_smp_processor_id(new_server);
+ printk(KERN_WARNING "%s: default server was %d, reset to %d\n",
+ __func__, cpu, default_server);
+ }
+
for_each_irq(virq) {
struct irq_desc *desc;
int xics_status[2];
@@ -882,7 +891,7 @@ void xics_migrate_irqs_away(void)
/* Reset affinity to all cpus */
desc->chip->set_affinity(virq, CPU_MASK_ALL);
- irq_desc[irq].affinity = CPU_MASK_ALL;
+ irq_desc[virq].affinity = CPU_MASK_ALL;
unlock:
spin_unlock_irqrestore(&desc->lock, flags);
}
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 related
* Re: [PATCH] [POWERPC] update immap_86xx.h for the 8610
From: Kumar Gala @ 2007-10-05 3:24 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4705634A.9070800@freescale.com>
On Oct 4, 2007, at 5:03 PM, Timur Tabi wrote:
> Kumar, can you pull this patch into your 2.6.24 tree? It's needed
> for the 8610.
applied.
- k
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Mark A. Greer @ 2007-10-05 3:08 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071005025930.GA24218@mag.az.mvista.com>
On Thu, Oct 04, 2007 at 07:59:30PM -0700, Mark A. Greer wrote:
> On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote:
> > The zImage is already hardware and
> > firmware specific;
>
> And [potentially] firmware version and zImage size specific.
I meant to add, "which is why it'll be difficult to come up with a
heuristic that will work in all situations."
Mark
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Mark A. Greer @ 2007-10-05 2:59 UTC (permalink / raw)
To: Mark A. Greer, Valentine Barshak, linuxppc-dev
In-Reply-To: <20071005022554.GE25637@localhost.localdomain>
On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote:
> On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> > On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> > > On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> > > > David Gibson wrote:
> > > > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
> >
> > > > Looking deeper at this I've found that currently u-boot thinks that
> > > > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
> > > > defined as (8 << 20)), although all physical memory is identity mapped.
> > > > That's why it puts command line and board info structure as high as
> > > > possible within the first 8MB. This worked fine with uImage, since
> > > > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
> > > > (we need space at the start of the memory to eventually put vmlinux
> > > > image there). So, if unpacked kernel image crosses 8MB boundary, it gets
> > > > damaged by u-boot when it prepares cmd_line and bdinfo. The possible
> > > > workaround for that is to always link zImage at >=8MB base or to have
> > > > 4MB granularity like this:
> > > >
> > > > + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
> > > >
> > > > Reserve at least 64K for u-boot cmd_line and bdinfo.
> > >
> > > Ah. Right. That makes things a bit tricky. Even this 4MB
> > > granularity may not be enough (say, if the vmlinux is < 4MB, but the
> > > zImage has a really big initrd and is > 4MB).
> > >
> > > Except... it shouldn't really be the link address that matters. The
> > > zImage is relocatable, so it should only be the load address specified
> > > in the uImage header which matters. I think that's currently derived
> > > from the link address, but it doesn't have to be.
> >
> > Having the link address jump around depending on the size of the kernel
> > or zImage is wrong IMHO. It just screams "weird can't boot issues."
>
> Hrm. Except we already have that - the zImage is linked at a fixed
> location, and will just not work if the sizes are wrong.
Yes, its an issue now (which is why we're having this discussion) but
at least its predictable ATM. Having it jump around on you because
you happened to set/clear a CONFIG option is worse.
My point is that the address needs to be set manually--no fancy heuristics
or whatever to guess.
> > We need a way to specify exactly where we want the zImage linked no
> > matter what the kernel or zImage size.
> >
> > Also, being able to control the link address (that is, the download
> > address with some firmwares) is not a u-boot specific issue and we
> > shouldn't make a u-boot specific solution.
> >
> > The more general problem is that some firmwares examine the ELF header
> > and download the zImage to address it was linked at. Some firmwares let
> > you override this but some don't and those are the problem ones.
> >
> > We talked about this a bit back in February,
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html
> >
> > In that thread Geoff Levand suggested a config option and running it
> > thru a preprocessor. David Gibson suggested making a replaceable linker
> > script. I suggested passing the value of a config option to the wrapper
> > script which would use objcopy/whatever to change the section addresses
> > in the image (maybe this is what Geoff had in mind, I'm not sure).
> >
> > I still like my idea best. I haven't coded yet it so I don't have a patch
> > but this is what I mean:
> >
> > 1) add a config option (default 4MB) for the link address
> > 2) add a parameter to the wrapper script thru which we pass the value in
> > the config option
> > 3) the wrapper script changes the VMA/LMA to the address specified
> > (objcopy --change-addresses=<some math to get correct incr> ?).
> >
> > I'll code it up in the next day or two unless someone doesn't like the idea.
>
> A config option just doesn't seem right to me, except as a
> special-circumstances hack.
Acutally, I started to hack up the patch and noticed that its already
there. Its 'CONFIG_BOOT_LOAD' which is an "Advanced setup" option
in arch/powerpc/Kconfig (probably migrated from arch/ppc/Kconfig).
Several defconfig's have it set but its not used AFAICS.
> The zImage is already hardware and
> firmware specific;
And [potentially] firmware version and zImage size specific.
> we should be able to figure out workable link and
> load addresses for a specific zImage
I was going to argue with you here until...
> (which might need to be different
> for different zImages produced by the same config).
Oh yeah, I forgot about multiple zImages from the same config. D*mn.
Hmm, I guess I have to think about this more then. (and stop hacking up
the patch I was talking about).
> Of course, the same objection would apply to CONFIG_DEVICE_TREE which
> we have already.
Yep.
Mark
^ 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