MPC8568E-MDS related patches
Subsystems (5)
cover MPC8568E-MDS related patches
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,
Signature · 4 lines
Anton Vorontsov email: [email protected] backup email: [email protected] irc://irc.freenode.net/bd2
A message that is not in the archive (sent off-list or not yet received): 20071005174015.GA11016-bi+AKbBUZKY6gyzm1THtWbp2dZbC/[email protected]
PATCH 7/7 spi_mpc83xx: allow use on any processors with QUICC Engine
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.
---
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(-)
drivers/spi/Kconfig +7 -6
@@ -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"
Signature · 1 line
1.5.0.6
PATCH 1/7 mpc85xx_mds: select QUICC_ENGINE
In reply to Anton Vorontsov--- arch/powerpc/platforms/85xx/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/powerpc/platforms/85xx/Kconfig +1 -1
@@ -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
Signature · 1 line
1.5.0.6
PATCH 2/7 QEIC: Implement pluggable handlers, fix MPIC cascading
In reply to Anton Vorontsovset_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.
--- 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(-)
arch/powerpc/platforms/83xx/mpc832x_mds.c +1 -1
@@ -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 */ }
arch/powerpc/platforms/83xx/mpc832x_rdb.c +1 -1
@@ -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 */ }
arch/powerpc/platforms/83xx/mpc836x_mds.c +1 -1
@@ -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 */ }
arch/powerpc/platforms/85xx/mpc85xx_mds.c +1 -1
@@ -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 */ }
arch/powerpc/sysdev/qe_lib/qe_ic.c +7 -22
@@ -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); } }
include/asm-powerpc/qe_ic.h +67 -1
76 lines not on this page · raw message
Signature · 1 line
1.5.0.6
PATCH 3/7 QE pario: support for MPC85xx layout
In reply to Anton Vorontsov8 bytes padding required to match MPC85xx registers layout.
--- arch/powerpc/sysdev/qe_lib/qe_io.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
arch/powerpc/sysdev/qe_lib/qe_io.c +3 -0
@@ -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 ;
Signature · 1 line
1.5.0.6
PATCH 4/7 mpc8568mds: update dts to be able to use UCCs
In reply to Anton Vorontsov1. 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;
--- arch/powerpc/boot/dts/mpc8568mds.dts | 22 +++++++++++----------- 1 files changed, 11 insertions(+), 11 deletions(-)
arch/powerpc/boot/dts/mpc8568mds.dts +11 -11
@@ -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 {
Signature · 1 line
1.5.0.6
PATCH 5/7 mpc85xx_mds: reset UCC ethernet properly
In reply to Anton VorontsovApart 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.
--- arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28 ++++++++++++++++------------ 1 files changed, 16 insertions(+), 12 deletions(-)
arch/powerpc/platforms/85xx/mpc85xx_mds.c +16 -12
@@ -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); }
Signature · 1 line
1.5.0.6
PATCH 6/7 mpc8568mds.dts: fix PCI/PCIe nodes
In reply to Anton VorontsovCommit 5bece127f0666996ca90772229e00332a34e516c tried to fix PCI/PCIe nodes, but actually it broke them even harder. ;-)
--- arch/powerpc/boot/dts/mpc8568mds.dts | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
arch/powerpc/boot/dts/mpc8568mds.dts +4 -4
@@ -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 {
Signature · 1 line
1.5.0.6
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
Hello.
Quoted 2 lines · Anton Vorontsov
Commit
5bece127f0666996ca90772229e00332a34e516ctried 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... :-/
Quoted 32 lines
Signed-off-by Anton Vorontsov <[email protected]>arch/powerpc/boot/dts/mpc8568mds.dts +3
-3@@ -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 = <
arch/powerpc/boot/dts/mpc8568mds.dts line 465
Quoted 8 lines
arch/powerpc/boot/dts/mpc8568mds.dts +1
-1@@ -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
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
Quoted 8 lines · Sergei Shtylyov
Hello.
Quoted 2 lines · Anton Vorontsov
Commit
5bece127f0666996ca90772229e00332a34e516ctried 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
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
In reply to Sergei ShtylyovQuoted 8 lines · Sergei Shtylyov
Hello.
Quoted 2 lines · Anton Vorontsov
Commit
5bece127f0666996ca90772229e00332a34e516ctried 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?
Nope. PCI's ranges = <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci" that started using of_translate_address() for ranges, and of_translate_address() will not work if PCI placed in the SOC node. Not sure if that patch applied or not, though.
Good luck,
Signature · 4 lines
Anton Vorontsov email: [email protected] backup email: [email protected] irc://irc.freenode.net/bd2
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
Quoted 11 lines · Anton Vorontsov
Quoted 9 lines · Sergei Shtylyov
Hello.
Quoted 2 lines · Anton Vorontsov
Commit
5bece127f0666996ca90772229e00332a34e516ctried 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?
Quoted 6 lines
Nope. PCI's ranges = <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci" that started using
of_translate_address()for ranges, andof_translate_address()will not work if PCI placed in the SOC node. Not sure if that patch applied or not, though.
I'm confused, what's the actual issue with PCI that this patch addresses?
- k
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
Hello Kumar,
Quoted 23 lines · On Fri, 5 Oct 2007 15:58:00 -0500 Kumar Gala wrote:
=20
On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
=20Quoted 13 lines · Sergei Shtylyov
Quoted 9 lines
Hello.
Quoted 2 lines · Anton Vorontsov
Commit
5bece127f0666996ca90772229e00332a34e516ctried to fix PCI/PCIe nodes, but actually it broke them even harder. ;-)Of course. But shouldn't those be the subnoses of the "soc" =20
type node?Nope. PCI's ranges =3D <>; isn't in the SOC address space.
Quoted 7 lines
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add =20 64-bit
phys addr support to 32-bit pci" that started using =20of_translate_address()
for ranges, andof_translate_address()will not work if PCI placed =20 in the
SOC node. Not sure if that patch applied or not, though.
Quoted 4 lines
=20
I'm confused, what's the actual issue with PCI that this patch =20 addresses?
=20
=46rom what I can see, move of the PCI node out of the SoC node, inspired by = the recent flame talk about it :)
I guess pretty soon, we'll have "proper" ranges parsing for pci, that does = of_translate_address() and requires
either tuned-up parent ranges, or residing outside of the SoC node, this is=
the reason...
Quoted 5 lines
- k
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--=20
Sincerely, Vitaly
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
In reply to Kumar GalaQuoted 13 lines · Kumar Gala
Quoted 10 lines · Anton Vorontsov
Quoted 8 lines · Sergei Shtylyov
Hello.
Quoted 2 lines · Anton Vorontsov
Commit
5bece127f0666996ca90772229e00332a34e516ctried 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?
Quoted 8 lines
Quoted 6 lines
Nope. PCI's ranges = <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci" that started using
of_translate_address()for ranges, andof_translate_address()will not work if PCI placed in the SOC node. Not sure if that patch applied or not, though.I'm confused, what's the actual issue with PCI that this patch addresses?
Which patch? Valentine's or mine under the subject? Don't know about the former, but mine patch is pretty obvious: your commit 5bece127f0666996ca90772229e00332a34e516c moved PCI nodes out of soc node, but you forgot to change regs = <>, thus instead of e000a000/e0008000, kernel used a000/8000 for accessing PCI ccsr registers.
Signature · 4 lines
Anton Vorontsov email: [email protected] backup email: [email protected] irc://irc.freenode.net/bd2
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
Quoted 22 lines · Anton Vorontsov
Quoted 21 lines · Kumar Gala
Quoted 17 lines · Anton Vorontsov
Quoted 9 lines · Sergei Shtylyov
Hello.
Quoted 2 lines · Anton Vorontsov
Commit
5bece127f0666996ca90772229e00332a34e516ctried 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?Nope. PCI's ranges = <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci" that started using
of_translate_address()for ranges, andof_translate_address()will not work if PCI placed in the SOC node. Not sure if that patch applied or not, though.
Quoted 7 lines
Quoted 1 line
I'm confused, what's the actual issue with PCI that this patch addresses?
Which patch? Valentine's or mine under the subject? Don't know about the former, but mine patch is pretty obvious: your commit
5bece127f0666996ca90772229e00332a34e516cmoved PCI nodes out of soc node, but you forgot to change regs = <>, thus instead of e000a000/e0008000, kernel used a000/8000 for accessing PCI ccsr registers.
Yeah, I see that bug now. It looks like I wasn't getting my new .dts on the board. Will fixup that issue in my patch.
- k
Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
Quoted 11 lines
Quoted 8 lines
Which patch? Valentine's or mine under the subject? Don't know about the
former, but mine patch is pretty obvious: your commit5bece127f0666996ca90772229e00332a34e516cmoved PCI nodes out of soc node,
but you forgot to change regs = <>, thus instead of e000a000/e0008000, kernel used a000/8000 for accessing PCI ccsr registers.Yeah, I see that bug now. It looks like I wasn't getting my new .dts on the board. Will fixup that issue in my patch.
Ok, I've tested my updated tree and it works for PCIe with the fix to the .dts
- k
Quoted 7 lines · Anton Vorontsov
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.
I've applied patches 1-5 however I'm not able to get UCC enet working on my board. Is there something special that has to be done? (I've got the card standalone, no MDS backplane).
I'm using the 1.3.0-rc2 u-boot w/o any modifications.
Also, I tried a PCIe e1000 card w/the .dts that's in my tree and that works w/o any issue.
- k
Quoted 5 lines · Kumar Gala
Quoted 2 lines · Anton Vorontsov
Hello Kumar,
Quoted 8 lines
Quoted 5 lines
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.
I've applied patches 1-5 however I'm not able to get UCC enet working on my board.
I wonder how you managed to boot it w/o sixth (PCI) patch in this patch set, for me board hanged w/o it.
Quoted 2 lines
Is there something special that has to be done? (I've got the card standalone, no MDS backplane).
Nothing special, from what I can remember. Though, double checking switches on the board might help.
Also, .config and bootlog would help.
Quoted 1 line
I'm using the 1.3.0-rc2 u-boot w/o any modifications.
1.2.0-g60174746 here.
Quoted 2 lines
Also, I tried a PCIe e1000 card w/the .dts that's in my tree and that works w/o any issue.
Strange enough. I'd say it's impossible with your current tree. Maybe you've used some stale dtb? Because dts is seriously broken as now, and I can't believe that it worked for you. ;-)
Thanks,
Signature · 4 lines
Anton Vorontsov email: [email protected] backup email: [email protected] irc://irc.freenode.net/bd2
Quoted 28 lines · Anton Vorontsov
Quoted 5 lines · Kumar Gala
Quoted 2 lines · Anton Vorontsov
Hello Kumar,
Quoted 8 lines
Quoted 5 lines
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.
I've applied patches 1-5 however I'm not able to get UCC enet working on my board.
I wonder how you managed to boot it w/o sixth (PCI) patch in this patch set, for me board hanged w/o it.
Quoted 2 lines
Is there something special that has to be done? (I've got the card standalone, no MDS backplane).
Nothing special, from what I can remember. Though, double checking switches on the board might help.
Also, .config and bootlog would help.
Quoted 1 line
I'm using the 1.3.0-rc2 u-boot w/o any modifications.
Quoted 8 lines
1.2.0-g60174746 here.
Quoted 2 lines
Also, I tried a PCIe e1000 card w/the .dts that's in my tree and that works w/o any issue.
Strange enough. I'd say it's impossible with your current tree. Maybe you've used some stale dtb? Because dts is seriously broken as now, and I can't believe that it worked for you. ;-)
Ignore me. Using the updated dtb makes things work. I need to double check PCIe but UCC geth appears to function now.
- k