RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
> -Original Message- > From: Andy Fleming [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 14, 2007 4:30 PM > To: [EMAIL PROTECTED] > Cc: 'Scott Wood'; linuxppc-embedded@ozlabs.org > Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be > configurable > > > On Aug 14, 2007, at 16:01, Joe Hamman wrote: > > > Hi Andy, > >> > >> I still think it should just be a property of the ethernet node. We > >> aren't describing the TBI, we're describing a setting for the > >> ethernet controller's register. > >> > > > > Like this? Do we need to have one for each [EMAIL PROTECTED] > > > Scott and I have been talking, and right now it seems like a better > idea might be to have the TBI address get assigned dynamically, based > on where PHYs aren't. > > It's non-trivial to do (though not difficult), but this way we won't > have to regret creating a bad interface. You just need to look at > the mdio bus, and find out which addresses responded. Then you > create a variable in the gfar_private structure to hold what it gets > set to, and make sure that gfar_configure_serdes uses that value > instead of the TBIPA constant. Sounds like a good plan. I'll try to put something together and post for comments. Thanks, Joe ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
Hi Andy,
> >
> > Is any given board going to have at runtime (i.e. not jumper
> > selectable) both a phy and a tbi (I'm not very familiar with the
> > latter, so I apologize if this is a dumb question). If not, I'd
> > stick with phy-handle and have something in the phy node to
> > indicate that it's tbi.
>
>
> Yes. That will be the more common case. The TBI PHYs are connected
> to the MDIO pins of each TSEC. The TBIPA register defines what
> address it sits on. It is used to configure non MII-style data
> connections, usually to another PHY. For instance, to configure a
> TSEC for SGMII, you first configure the attached TBI to communicate
> with the on-chip SERDES.
>
> While the TBI devices technically all sit on MDIO busses, only the
> TBI PHY connected to the first TSEC will interfere with MDIO
> transactions. I don't think we need to create nodes for each of the
> TBIs. They exist as a secondary part of the ethernet controller, and
> their address is only really important to that controller.
>
> I still think it should just be a property of the ethernet node. We
> aren't describing the TBI, we're describing a setting for the
> ethernet controller's register.
>
Like this? Do we need to have one for each [EMAIL PROTECTED]
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <24000 1000>;
mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <1d 2 1e 2 22 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy1f>;
tbi-address = <0x1e>;
};
Joe
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
> -Original Message-
> From: Scott Wood [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 14, 2007 11:16 AM
> To: Andy Fleming
> Cc: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
> configurable
>
> Andy Fleming wrote:
> > It's actually a per-tsec property. There's not one tbi, there's one
> > per TSEC. The one on TSEC 0 is special in that it can interfere with
> > PHYs on the MDIO bus.
> >
> > So I would suggest making it a property of the ethernet node:
> >
> > [EMAIL PROTECTED] {
> > ...
> > tbipa = <1f>;
> > ...
> > }
>
> "tbipa" isn't likely to pass the Segher test. :-)
>
> If the TBI address is in PHY-space, then it should go in the MDIO bus.
> For the second TSEC, create a second MDIO bus node.
>
How about something like this?
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
phy1f: [EMAIL PROTECTED] {
reg = <1f>;
device_type = "ethernet-phy";
};
phy0: [EMAIL PROTECTED] {
reg = <0>;
device_type = "ethernet-phy";
};
phy1: [EMAIL PROTECTED] {
reg = <1>;
device_type = "ethernet-phy";
};
phy2: [EMAIL PROTECTED] {
reg = <2>;
device_type = "ethernet-phy";
};
tbi1e: [EMAIL PROTECTED] {
reg = <1e>;
device_type = "ethernet-tbi";
};
};
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <24000 1000>;
mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <1d 2 1e 2 22 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy1f>;
tbi-handle = <&tbi1e>;
};
Joe
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
Hi Kumar,
Or do you think it should be added to gianfar_mdio_data? Easier, but does
it belong there?
Thanks,
Joe
> -Original Message-
> From: linuxppc-embedded-
> [EMAIL PROTECTED] [mailto:linuxppc-
> [EMAIL PROTECTED] On Behalf
> Of Joe Hamman
> Sent: Monday, August 13, 2007 10:30 PM
> To: 'Kumar Gala'
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
> configurable
>
>
> > -Original Message-
> > From: Kumar Gala [mailto:[EMAIL PROTECTED]
> > Sent: Monday, August 13, 2007 10:10 PM
> > To: [EMAIL PROTECTED]
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
> > configurable
> >
> >
> > On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
> >
> > > Allow the address of the Ten Bit Interface (TBI) to be changed in the
> > > event of a conflict with another device.
> > >
> > > Signed-off by: Joe Hamman <[EMAIL PROTECTED]>
> > > ---
> > >
> > > Please ignore the last patch - I missed a cut & paste error on the
> > > range
> > > that my testing didn't catch.
> >
> > I think we'd rather this came from the device tree.
> >
> Duh, that makes sense ;-)
>
> Has there been any discussion yet? Maybe something like this:
>
> [EMAIL PROTECTED] {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "mdio";
> compatible = "gianfar";
> reg = <24520 20>;
> phy0: [EMAIL PROTECTED] {
> interrupt-parent = <&mpic>;
> interrupts = ;
> reg = <0>;
> device_type = "ethernet-phy";
> };
> phy1: [EMAIL PROTECTED] {
> interrupt-parent = <&mpic>;
> interrupts = ;
> reg = <1>;
> device_type = "ethernet-phy";
> };
> phy2: [EMAIL PROTECTED] {
> interrupt-parent = <&mpic>;
> interrupts = ;
> reg = <2>;
> device_type = "ethernet-phy";
> };
> phy3: [EMAIL PROTECTED] {
> interrupt-parent = <&mpic>;
> interrupts = ;
> reg = <3>;
> device_type = "ethernet-phy";
> };
> tbi: [EMAIL PROTECTED] {
> reg = <1f>;
> device_type = "ethernet-tbi";
> };
> };
>
> Thanks,
> Joe
>
>
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 13, 2007 10:10 PM
> To: [EMAIL PROTECTED]
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be
> configurable
>
>
> On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
>
> > Allow the address of the Ten Bit Interface (TBI) to be changed in the
> > event of a conflict with another device.
> >
> > Signed-off by: Joe Hamman <[EMAIL PROTECTED]>
> > ---
> >
> > Please ignore the last patch - I missed a cut & paste error on the
> > range
> > that my testing didn't catch.
>
> I think we'd rather this came from the device tree.
>
Duh, that makes sense ;-)
Has there been any discussion yet? Maybe something like this:
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
phy0: [EMAIL PROTECTED] {
interrupt-parent = <&mpic>;
interrupts = ;
reg = <0>;
device_type = "ethernet-phy";
};
phy1: [EMAIL PROTECTED] {
interrupt-parent = <&mpic>;
interrupts = ;
reg = <1>;
device_type = "ethernet-phy";
};
phy2: [EMAIL PROTECTED] {
interrupt-parent = <&mpic>;
interrupts = ;
reg = <2>;
device_type = "ethernet-phy";
};
phy3: [EMAIL PROTECTED] {
interrupt-parent = <&mpic>;
interrupts = ;
reg = <3>;
device_type = "ethernet-phy";
};
tbi: [EMAIL PROTECTED] {
reg = <1f>;
device_type = "ethernet-tbi";
};
};
Thanks,
Joe
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
Allow the address of the Ten Bit Interface (TBI) to be changed in the event of a conflict with another device. Signed-off by: Joe Hamman <[EMAIL PROTECTED]> --- Please ignore the last patch - I missed a cut & paste error on the range that my testing didn't catch. --- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 81ef81c..b4813d9 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2276,6 +2276,14 @@ config GFAR_NAPI bool "NAPI Support" depends on GIANFAR +config GFAR_TBIPA_VALUE + hex "Ten Bit Interface Port Address Value" + depends on GIANFAR + range 0 0x1f + default "0x1f" + help + Select an address that does not conflict with other addresses on the board. + config UCC_GETH tristate "Freescale QE Gigabit Ethernet" depends on QUICC_ENGINE diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index f926905..91ae0d3 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -490,15 +490,15 @@ static void gfar_configure_serdes(struct net_device *dev) /* Initialise TBI i/f to communicate with serdes (lynx phy) */ /* Single clk mode, mii mode off(for aerdes communication) */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT); + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT); /* Supported pause and full-duplex, no half-duplex */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE, + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_ADVERTISE, ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE | ADVERTISE_1000XPSE_ASYM); /* ANEG enable, restart ANEG, full duplex mode, speed[1] set */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE | + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000); } @@ -547,7 +547,7 @@ static void init_registers(struct net_device *dev) gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS); /* Assign the TBI an address which won't conflict with the PHYs */ - gfar_write(&priv->regs->tbipa, TBIPA_VALUE); + gfar_write(&priv->regs->tbipa, CONFIG_GFAR_TBIPA_VALUE); } diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h index d8e779c..0fd1c02 100644 --- a/drivers/net/gianfar.h +++ b/drivers/net/gianfar.h @@ -131,7 +131,6 @@ extern const char gfar_driver_version[]; #define DEFAULT_RXCOUNT16 #define DEFAULT_RXTIME 4 -#define TBIPA_VALUE0x1f #define MIIMCFG_INIT_VALUE 0x0007 #define MIIMCFG_RESET 0x8000 #define MIIMIND_BUSY0x0001 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] tsec: Allow Ten Bit Interface to be configurable
Allow the address of the Ten Bit Interface (TBI) to be changed in the event of a conflict with another device. Signed-off by: Joe Hamman <[EMAIL PROTECTED]> --- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 81ef81c..ba67b3b 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2276,6 +2276,14 @@ config GFAR_NAPI bool "NAPI Support" depends on GIANFAR +config GFAR_TBIPA_VALUE + hex "Ten Bit Interface Port Address Value" + depends on GIANFAR + range 0 0x1f if BFIN_MAC_USE_L1 + default "0x1f" + help + Select an address that does not conflict with other addresses on the board. + config UCC_GETH tristate "Freescale QE Gigabit Ethernet" depends on QUICC_ENGINE diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index f926905..91ae0d3 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -490,15 +490,15 @@ static void gfar_configure_serdes(struct net_device *dev) /* Initialise TBI i/f to communicate with serdes (lynx phy) */ /* Single clk mode, mii mode off(for aerdes communication) */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT); + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT); /* Supported pause and full-duplex, no half-duplex */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE, + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_ADVERTISE, ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE | ADVERTISE_1000XPSE_ASYM); /* ANEG enable, restart ANEG, full duplex mode, speed[1] set */ - gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE | + gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000); } @@ -547,7 +547,7 @@ static void init_registers(struct net_device *dev) gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS); /* Assign the TBI an address which won't conflict with the PHYs */ - gfar_write(&priv->regs->tbipa, TBIPA_VALUE); + gfar_write(&priv->regs->tbipa, CONFIG_GFAR_TBIPA_VALUE); } diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h index d8e779c..0fd1c02 100644 --- a/drivers/net/gianfar.h +++ b/drivers/net/gianfar.h @@ -131,7 +131,6 @@ extern const char gfar_driver_version[]; #define DEFAULT_RXCOUNT16 #define DEFAULT_RXTIME 4 -#define TBIPA_VALUE0x1f #define MIIMCFG_INIT_VALUE 0x0007 #define MIIMCFG_RESET 0x8000 #define MIIMIND_BUSY0x0001 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] Add support for Wind River SBC8641D board
Sorry, I replied to only the first question.
> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 01, 2007 9:18 AM
> To: [EMAIL PROTECTED]
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH] Add support for Wind River SBC8641D board
>
>
> On Jul 31, 2007, at 7:36 PM, Joe Hamman wrote:
>
> > Add support for Wind River's SBC8641D reference board.
>
> Is this a single core or dual core chip?
>
The board I have is single core. I would have to see if I could get access
to a dual core board.
> >
> > Signed-off by: Joe Hamman <[EMAIL PROTECTED]>
> >
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts
> > linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts
> > --- linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts1969-12-31
> > 18:00:00.0 -0600
> > +++ linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts2007-07-31
> > 13:15:15.0 -0500
> > @@ -0,0 +1,160 @@
> > +/*
> > + * SBC8641D Device Tree Source
> > + *
> > + * Copyright 2007 Embedded Specialties, Inc.
> > + * Joe Hamman [EMAIL PROTECTED]
> > + *
> > + * Copyright 2006 Freescale Semiconductor Inc.
> > + *
> > + * This program 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.
> > + */
> > +
> > +
> > +/ {
> > + model = "SBC8641D";
> > + compatible = "mpc86xx";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + PowerPC,[EMAIL PROTECTED] {
> > + device_type = "cpu";
> > + reg = <0>;
> > + d-cache-line-size = <20>; // 32 bytes
> > + i-cache-line-size = <20>; // 32 bytes
> > + d-cache-size = <8000>; // L1, 32K
> > + i-cache-size = <8000>; // L1, 32K
> > + timebase-frequency = <0>; // 33 MHz, from
uboot
> > + bus-frequency = <0>;// From uboot
> > + clock-frequency = <0>; // From uboot
> > + 32-bit;
> > + };
>
> if this is really an 8641D I'd expect a 2nd cpu node.
>
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + reg = < 2000>; // 512M at 0x0
> > + };
> > +
> > + [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + #interrupt-cells = <2>;
> > + device_type = "soc";
> > + ranges = <0 f800 0010>;
> > + reg = ; // CCSRBAR 1M
> > + bus-frequency = <0>;
> > +
> > + [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "mdio";
> > + compatible = "gianfar";
> > + reg = <24520 20>;
> > + phy1f: [EMAIL PROTECTED] {
> > + reg = <1f>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy0: [EMAIL PROTECTED] {
> > + reg = <0>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy1: [EMAIL PROTECTED] {
> > + reg = <1>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy2: [EMAIL PROTECTED] {
> > + reg = <2>;
> > + device_type = "ethernet-phy";
> > + };
> > + };
> > +
> > + [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = &q
RE: [PATCH] Add support for Wind River SBC8641D board
The board supports both single and dual core parts. The board I have is
single core.
> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 01, 2007 9:18 AM
> To: [EMAIL PROTECTED]
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH] Add support for Wind River SBC8641D board
>
>
> On Jul 31, 2007, at 7:36 PM, Joe Hamman wrote:
>
> > Add support for Wind River's SBC8641D reference board.
>
> Is this a single core or dual core chip?
>
> >
> > Signed-off by: Joe Hamman <[EMAIL PROTECTED]>
> >
> > diff -purN -X dontdiff linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts
> > linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts
> > --- linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts1969-12-31
> > 18:00:00.0 -0600
> > +++ linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts2007-07-31
> > 13:15:15.0 -0500
> > @@ -0,0 +1,160 @@
> > +/*
> > + * SBC8641D Device Tree Source
> > + *
> > + * Copyright 2007 Embedded Specialties, Inc.
> > + * Joe Hamman [EMAIL PROTECTED]
> > + *
> > + * Copyright 2006 Freescale Semiconductor Inc.
> > + *
> > + * This program 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.
> > + */
> > +
> > +
> > +/ {
> > + model = "SBC8641D";
> > + compatible = "mpc86xx";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + PowerPC,[EMAIL PROTECTED] {
> > + device_type = "cpu";
> > + reg = <0>;
> > + d-cache-line-size = <20>; // 32 bytes
> > + i-cache-line-size = <20>; // 32 bytes
> > + d-cache-size = <8000>; // L1, 32K
> > + i-cache-size = <8000>; // L1, 32K
> > + timebase-frequency = <0>; // 33 MHz, from
uboot
> > + bus-frequency = <0>;// From uboot
> > + clock-frequency = <0>; // From uboot
> > + 32-bit;
> > + };
>
> if this is really an 8641D I'd expect a 2nd cpu node.
>
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + reg = < 2000>; // 512M at 0x0
> > + };
> > +
> > + [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + #interrupt-cells = <2>;
> > + device_type = "soc";
> > + ranges = <0 f800 0010>;
> > + reg = ; // CCSRBAR 1M
> > + bus-frequency = <0>;
> > +
> > + [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "mdio";
> > + compatible = "gianfar";
> > + reg = <24520 20>;
> > + phy1f: [EMAIL PROTECTED] {
> > + reg = <1f>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy0: [EMAIL PROTECTED] {
> > + reg = <0>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy1: [EMAIL PROTECTED] {
> > + reg = <1>;
> > + device_type = "ethernet-phy";
> > + };
> > + phy2: [EMAIL PROTECTED] {
> > + reg = <2>;
> > + device_type = "ethernet-phy";
> > + };
> > + };
> > +
> > + [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = &qu
[PATCH] Add support for Wind River SBC8641D board
Add support for Wind River's SBC8641D reference board.
Signed-off by: Joe Hamman <[EMAIL PROTECTED]>
diff -purN -X dontdiff linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts
linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts
--- linux-2.6/arch/powerpc/boot/dts/sbc8641d.dts1969-12-31
18:00:00.0 -0600
+++ linux-2.6-esi/arch/powerpc/boot/dts/sbc8641d.dts2007-07-31
13:15:15.0 -0500
@@ -0,0 +1,160 @@
+/*
+ * SBC8641D Device Tree Source
+ *
+ * Copyright 2007 Embedded Specialties, Inc.
+ * Joe Hamman [EMAIL PROTECTED]
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * This program 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.
+ */
+
+
+/ {
+ model = "SBC8641D";
+ compatible = "mpc86xx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // 33 MHz, from uboot
+ bus-frequency = <0>;// From uboot
+ clock-frequency = <0>; // From uboot
+ 32-bit;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = < 2000>; // 512M at 0x0
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <0 f800 0010>;
+ reg = ; // CCSRBAR 1M
+ bus-frequency = <0>;
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ phy1f: [EMAIL PROTECTED] {
+ reg = <1f>;
+ device_type = "ethernet-phy";
+ };
+ phy0: [EMAIL PROTECTED] {
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ phy1: [EMAIL PROTECTED] {
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ phy2: [EMAIL PROTECTED] {
+ reg = <2>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ mac-address = [ 00 E0 0C 00 73 00 ];
+ interrupts = <1d 2 1e 2 22 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy1f>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ mac-address = [ 00 E0 0C 00 73 01 ];
+ interrupts = <23 2 24 2 28 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy0>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC"
MMU on the power pc 860
Hi Cecilia, I'm using visionCLICK 7.9A with the latest visionPROBE DLL. The visionICE II for the 860 requires firmware version 1.5j or later. The debugger, visionCLICK, isn't aware of the translations, so the only requirement is that it is compatible with the firmware. You'll have to contact Wind River regarding an upgrade. Regards, Joe -Original Message- From: Muaddi, Cecilia [mailto:[EMAIL PROTECTED] Sent: Thursday, January 02, 2003 12:11 PM To: 'Joe Hamman' Cc: linuxppc-embedded at lists.linuxppc.org Subject: RE: MMU on the power pc 860 which version of the visionClick you are using? My vision click is version 7.4A, and the firware version for the visionICE II is vn1.5a. When I enter the command you have recommended, I got syntax error >BKM>CF MMU LINUX !ERROR! - [msg31000] Syntax error in message cf mmu linux >BKM>cf mmua !ERROR! - [msg31000] Syntax error in message cf mmua >BKM> !ABORT! - [msg72000] User Command Abort >BKM> -Original Message- From: Joe Hamman [mailto:[EMAIL PROTECTED] Sent: Sunday, December 22, 2002 8:01 PM To: Muaddi, Cecilia Cc: linuxppc-embedded at lists.linuxppc.org Subject: RE: MMU on the power pc 860 The comment on the Vision* tools' MMU support is incorrect. The visionICE II and visionPROBE II support up to four regions of translation. You need to enter the details manually: BKM>CF MMU LINUX BKM>CF MMUA C000 0 FF00 Use the CF MMUL to list the translation table entries currently defined in the tool. You can get the details from WRS. This will allow you to use visionCLICK (or SingleStep w/vision) to debug anything statically linked into the kernel, from address 0 through init. Unless you have specific reasons not to switch, I recommend using the U-Boot bootloader. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Wolfgang Denk Sent: Saturday, December 21, 2002 2:59 PM To: Muaddi, Cecilia Cc: 'linuxppc-embedded at lists.linuxppc.org' Subject: Re: MMU on the power pc 860 in message <885489B3B89FB6449F93E525DF78777F06451E at srvnt506.ALLOPTIC.COM> you wrote: > > I am porting the timeSys Linux to a custom Power PC 860 board. Our board > currently runs > windRiver VxWorks. I have modified the VxWorks bootrom to allow me to > download a motorola > hex record, and I have modified the timeSys bootcode > arch/ppc/boot/mbx/misc.c:decompress_kernel This is the generic Linux bootstrap loader, it has nothing to do with TimeSys. > loaded at: 0040 0040C30C > board data at: 004001C0 004001E4 > relocated to: 0040C0E8 0040C10C > zimage at: 0040C30C 004BC440 > avail ram: 004BD000 0080 ^^ This loos strange to me. Didn't you map RAM to 0x? > I was able to use the VisionICE BDM to single step, and see it does jump to > the address 0, and > begin execute the instruction in kernel/arch/ppc/kernel/head_8xx.S:_start You will not get far with the Vision*; better use a tool that understands the MMU, like the Abatron BDI2000. > I think the MMU TLB setup I have is not exactly correct, since the vxWorks > BOOTROM does not > initialize any MMU registers. Can someone tell me if I need to initialize > the M_TWB register for the MMU should be switched off when starting Linux. > to be the value for this register? My physical memory map consists of RAM > at location 0 to 0x1ff This is not what I see above. > and my IMMR is set to 0x2b00 And this is plain wrong. The IMMR _must_ be mapped above 0xF000. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MMU on the power pc 860
Hi Cecilia, The comment on the Vision* tools' MMU support is incorrect. The visionICE II and visionPROBE II support up to four regions of translation. You need to enter the details manually: BKM>CF MMU LINUX BKM>CF MMUA C000 0 FF00 Use the CF MMUL to list the translation table entries currently defined in the tool. You can get the details from WRS. This will allow you to use visionCLICK (or SingleStep w/vision) to debug anything statically linked into the kernel, from address 0 through init. Unless you have specific reasons not to switch, I recommend using the U-Boot bootloader. Regards, Joe -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Wolfgang Denk Sent: Saturday, December 21, 2002 2:59 PM To: Muaddi, Cecilia Cc: 'linuxppc-embedded at lists.linuxppc.org' Subject: Re: MMU on the power pc 860 Dear Cecilia, in message <885489B3B89FB6449F93E525DF78777F06451E at srvnt506.ALLOPTIC.COM> you wrote: > > I am porting the timeSys Linux to a custom Power PC 860 board. Our board > currently runs > windRiver VxWorks. I have modified the VxWorks bootrom to allow me to > download a motorola > hex record, and I have modified the timeSys bootcode > arch/ppc/boot/mbx/misc.c:decompress_kernel This is the generic Linux bootstrap loader, it has nothing to do with TimeSys. > loaded at: 0040 0040C30C > board data at: 004001C0 004001E4 > relocated to: 0040C0E8 0040C10C > zimage at: 0040C30C 004BC440 > avail ram: 004BD000 0080 ^^ This loos strange to me. Didn't you map RAM to 0x? > I was able to use the VisionICE BDM to single step, and see it does jump to > the address 0, and > begin execute the instruction in kernel/arch/ppc/kernel/head_8xx.S:_start You will not get far with the Vision*; better use a tool that understands the MMU, like the Abatron BDI2000. > I think the MMU TLB setup I have is not exactly correct, since the vxWorks > BOOTROM does not > initialize any MMU registers. Can someone tell me if I need to initialize > the M_TWB register for the MMU should be switched off when starting Linux. > to be the value for this register? My physical memory map consists of RAM > at location 0 to 0x1ff This is not what I see above. > and my IMMR is set to 0x2b00 And this is plain wrong. The IMMR _must_ be mapped above 0xF000. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Use C++ to confuse your enemies; use C to produce stable code. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8260 configuration
To debug Linux with the visionICE or visionPROBE you need to tell the tool that the MMU is translating. Here are the commands I use: BKM>CF MMU LINUX BKM>CF MMUA C000 0 FF00 Use the CF MMUL to list the translation table entries in the tool. Convert the .elf file to generate a symbol file (.ab), set the source path in the debugger, and you can debug all the code through init(). You can try to get WindRiver to help, but they're not too keen on helping non-vxWorks customers. Joe -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Yu Bo-BOYU1 Sent: Wednesday, October 02, 2002 1:10 PM To: 'Flavio Pereira' Cc: linuxppc embedded Subject: RE: 8260 configuration Thanks for your info. I modified est8260.h to map immr to 0xf800_. And the serial port did print out some unreadable stuff and I am very encouraged by this. My serial port setup is the minimal: 9600/8+1/no parity/no flow. Is this correct ? After I halt the processor, I read SRR0 register showing 0xc0153C90. Apparently this is above the 0xc000_ that you indicated. Is that true 0xc000_ is the virtual address as we only have 64M sdram on the board starting 0. [DOC3 Boot]: @ boot device : dbg unit number : 0 processor number : 0 host name: host file name: zImage inet on ethernet (e) : 10.0.0.25:0xff00 host inet (h): 10.0.0.1 user (u) : vx ftp password (pw): vx flags (f): 0x0 target name (tn) : doc3 Attached TCP/IP interface to dbg0. Attaching network interface lo0... done. Loading... 619152 Starting at 0x40... >BKM>GO >RUN> >RUN>halt >BKM>dr srr0 SRR0= C0153C90 >BKM>GO >RUN> >RUN>halt >BKM>dr srr0 SRR0= C0153C7C >BKM>GO >RUN> >RUN> Thanks. Bo -Original Message- From: Flavio Pereira [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 02, 2002 2:23 AM To: Yu Bo-BOYU1 Cc: linuxppc embedded Subject: RE: 8260 configuration Hi Bo 1. Yes the IMMR needs to be configured at least above 0xC000. The kernel executes code at 0xC000, and an IMMR lower that this will cause the kernel to crash as soon as it starts executing code. I recommend that you stay with the default value 0xF000. 2. The start address is fixed to 0x0 3. ? 4. No, not that I know of. 5. Try getting ELDK from the Denx site. (www.denx.de) -Original Message- From: Yu Bo-BOYU1 [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 02, 2002 3:08 AM To: linuxppc embedded Subject: 8260 configuration I am new to embedded linux but I had good experience in vxWorks. Right now I had a custom 8260 board with SMC1 connected to serial port and FCC3 for fast ethernet. I would like to try running linux on this custom board. I downloaded the latest monta vista preview kit 2.1 as my base release. I had boot code ( with vxWorks and it is based on EST8260 bsp) in my custom board already. I decide to download the linux object via tftp. But I have the following questions: 1. Do I have to configure IMMR as 0xF_ or higher. The default configuration in our boot is 0x0F00_ ? Is this a hard requirement or not ? If so, why can't linux init code do so by writing to IMMR+0x101a8 ? 2. How to specify the start address where linux runs when I build the zImage ? 3. When I make xconfig, what configuration I must have in order to run ? I certainly do not need VGA/HARD DISK/PCI (this board does not have pci devices). 4. Is there any good website/paper/documentation about linux for 8260 platform. 5. Can anyone access ftp.leo.org to get ELDK ? I can ping it but I cannot ftp it today. Thanks. Bo ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
