That's not the right fsl,cpm-command for FCC2. You want 0x16200300.
Also, for my similar board, I had to add (for immap at F0000000):
virtual-reg = <0xF0011320
0xF0008500
0xF00113B0>;
But I can't explain why the driver isn't attaching for you. Did you
try it built-in instead of as a module?
-=] Mike [=-
From: Daniel Ng <hidden> Date: 2009-02-19 06:47:24
On Thu, Jan 29, 2009 at 12:16 PM, Mike Ditto [off-list ref] wrote:
But I can't explain why the driver isn't attaching for you. Did you
try it built-in instead of as a module?
Hi Mike et al,
I am trying it built-in at the moment (ie. not as a module).
I've stuck a whole bunch of printks() in. This is what is happening
during boot-up:
1) fs_init() from fs_enet-main.c is called
2) This in turn calls driver_register() with the 'fs_enet' driver
3) This results in a call to bus_add_driver() with the following parameters:
driver = 'fs_enet' driver
bus = 'of_platform' bus
4) Then, driver_attach() is called with 'fs_enet' driver as the parameter
5) driver_attach() calls bus_for_each_dev() with "__driver_attach()"
and the 'of_platform' bus as the relevant parameters
However, __driver_attach() is never called from bus_for_each_dev() ie.
there seems to be no devices on the 'of_platform' bus.
Hence, is there some way to add an appropriate device to the
'of_platform' bus so that __driver_attach() can be called for that
device?
Or, perhaps it is ok for the 'of_platform' bus to have no devices on
it, and so I might be using the wrong bus?? Why would this be?
Or is it something else??
Either way, I still get the following boot error message:
IP-Config: Device `eth0' not found.
-and fs_enet_probe() is NEVER called.
Cheers,
Daniel
From: Scott Wood <hidden> Date: 2009-02-19 18:44:14
On Thu, Feb 19, 2009 at 05:47:22PM +1100, Daniel Ng wrote:
Or, perhaps it is ok for the 'of_platform' bus to have no devices on
it, and so I might be using the wrong bus?? Why would this be?
Or is it something else??
Either way, I still get the following boot error message:
IP-Config: Device `eth0' not found.
-and fs_enet_probe() is NEVER called.
Great, that's helped. Thanks Scott.
Now, I'm seeing these boot messages:
f0010d40:00 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
Previous mailing list discussions suggest that I use the correct PHY,
which I am sure about because my 8272-based board only has the one PHY
ie. PHY0 with reg = <0x0>.
Note the relevant parts of my Device Tree below. Currently, our PHY
attributes eg. 'auto-negotiate' are not changeable, so we aren't
actually using MDC+MDIO even the MDC+MDIO lines exist. Also, the PHY
interrupt line is not wired up. Hence the PHY0 interrupts field is <0
8> (or should it be removed altogether?).
I am usig FCC2.
What might I need to change to get the ethernet driver working?
ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
// FCC2-
reg = <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <33 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <0x16200300>;
};
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <0x10d40 0x14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <5>;
fsl,mdc-pin = <19>;
PHY0: ethernet-phy@0 {
interrupt-parenn = <&PIC>;
interrupts = <0 8>;
reg = <0x0>;
device_type = "ethernet-phy";
};
.
.
.
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <0x10c00 0x80>;
compatible = "fsl,mpc8272-pic", "fsl,cpm2-pic";
};
Cheers,
Daniel
From: Daniel Ng <hidden> Date: 2009-02-25 07:09:34
Hi guys,
I was hoping to have gotten some form of comment by now...
Can anyone help out here, please?
Daniel
On Fri, Feb 20, 2009 at 4:01 PM, Daniel Ng [off-list ref] wrote:
Now, I'm seeing these boot messages:
f0010d40:00 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
Previous mailing list discussions suggest that I use the correct PHY,
which I am sure about because my 8272-based board only has the one PHY
ie. PHY0 with reg =3D <0x0>.
Note the relevant parts of my Device Tree below. Currently, our PHY
attributes eg. 'auto-negotiate' are not changeable, so we aren't
actually using MDC+MDIO even the MDC+MDIO lines exist. Also, the PHY
interrupt line is not wired up. Hence the PHY0 interrupts field is <0
8> (or should it be removed altogether?).
I am usig FCC2.
What might I need to change to get the ethernet driver working?
=A0 =A0 =A0ethernet@11320 {
=A0 =A0 =A0 =A0device_type =3D "network";
=A0 =A0 =A0 =A0compatible =3D "fsl,mpc8272-fcc-enet",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "fsl,cpm2-fcc-enet";
=A0 =A0 =A0 =A0// FCC2-
=A0 =A0 =A0 =A0reg =3D <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
=A0 =A0 =A0 =A0local-mac-address =3D [ 00 00 00 00 00 00 ];
=A0 =A0 =A0 =A0interrupts =3D <33 8>;
=A0 =A0 =A0 =A0interrupt-parent =3D <&PIC>;
=A0 =A0 =A0 =A0phy-handle =3D <&PHY0>;
=A0 =A0 =A0 =A0linux,network-index =3D <0>;
=A0 =A0 =A0 =A0fsl,cpm-command =3D <0x16200300>;
=A0 =A0 =A0};
=A0 =A0 =A0mdio@10d40 {
=A0 =A0 =A0 =A0device_type =3D "mdio";
=A0 =A0 =A0 =A0compatible =3D "fsl,mpc8272ads-mdio-bitbang",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "fsl,mpc8272-mdio-bitbang",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "fsl,cpm2-mdio-bitbang";
=A0 =A0 =A0 =A0reg =3D <0x10d40 0x14>;
=A0 =A0 =A0 =A0#address-cells =3D <1>;
=A0 =A0 =A0 =A0#size-cells =3D <0>;
=A0 =A0 =A0 =A0fsl,mdio-pin =3D <5>;
=A0 =A0 =A0 =A0fsl,mdc-pin =3D <19>;
=A0 =A0 =A0 =A0PHY0: ethernet-phy@0 {
=A0 =A0 =A0 =A0 =A0interrupt-parenn =3D <&PIC>;
=A0 =A0 =A0 =A0 =A0interrupts =3D <0 8>;
=A0 =A0 =A0 =A0 =A0reg =3D <0x0>;
=A0 =A0 =A0 =A0 =A0device_type =3D "ethernet-phy";
=A0 =A0 =A0 =A0};
.
.
.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PIC: interrupt-controller@10c00 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#interrupt-cells =3D <2>;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-controller;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x10c00 0x80>;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc827=
From: Daniel Ng <hidden> Date: 2009-02-27 06:42:00
On Wed, Feb 25, 2009 at 8:25 PM, Mike Ditto [off-list ref] wrote:
Daniel Ng wrote:
quoted
quoted
f0010d40:00 not found
eth0: Could not attach to PHY
These messages are typical of having the wrong GPIO pins in the mdio
node or the wrong MDIO address (reg property) in the ethernet-phy node.
quoted
quoted
Currently, our PHY
attributes eg. 'auto-negotiate' are not changeable, so we aren't
actually using MDC+MDIO even though the MDC+MDIO lines exist.
The driver definitely tries to talk to the PHY using the GPIO pins
and address specified and if it doesn't respond, it won't attach.
Thanks Mike. I pulled out the PHY-dependancies in the fs-enet code and
I'm *almost* there!
Here's the relevant boot output with some additional debug:
fs_init(): start
fs_enet_probe() start
fs_enet_get_stats() start
eth0: fs_enet: 7e:13:12:53:a1:75
fs_enet_probe(): registered. dev: eth0
...
dev_open(): calling dev_activate for dev: lo
dev_open(): finishing for dev: lo
fs_enet_open(): start. dev: eth0
dev_open(): calling dev_activate for dev: eth0
dev_open(): finishing for dev: eth0
fs_enet_get_stats()
IP-Config: Complete:
device=eth0, addr=192.168.1.75, mask=255.255.255.0, gw=255.255.255.255,
host=xxx, domain=, nis-domain=(none),
bootserver=192.168.1.133, rootserver=192.168.1.133, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.133
dev_hard_start_xmit(): start. dev: lo
dev_hard_start_xmit(): about to call c015baa0
dev_hard_start_xmit(): start. dev: lo
dev_hard_start_xmit(): about to call c015baa0
rpcbind: server 192.168.1.133 not responding, timed out
As you can see from the above, the NFS client tries to contact the
server on the lo interface rather than eth0.
This is despite IP-Config reporting 'Complete' for eth0.
If I set the Gateway parameter for the NFS client to 192.168.1.133 I get this:
fs_init(): start
fs_enet_probe() start
fs_enet_get_stats() start
eth0: fs_enet: 7e:13:12:53:a1:75
fs_enet_probe(): registered. dev: eth0
...
dev_open(): calling dev_activate for dev: lo
dev_open(): finishing for dev: lo
fs_enet_open(): start. dev: eth0
dev_open(): calling dev_activate for dev: eth0
dev_open(): finishing for dev: eth0
fs_enet_get_stats()
IP-Config: Gateway not on directly connected network.
Looking up port of RPC 100003/2 on 192.168.1.133
dev_hard_start_xmit(): start. dev: lo
dev_hard_start_xmit(): about to call c015baa0
dev_hard_start_xmit(): start. dev: lo
dev_hard_start_xmit(): about to call c015baa0
rpcbind: server 192.168.1.133 not responding, timed out
-IP-Config complains the Gateway (192.168.1.133) is not on a
directly-connected network, even though the IP address of eth0 is
192.168.1.75/24.
So this implies eth0 is not 100% up.
Would someone be able to suggest why this is so? What else could I do
to check the state of eth0?
Cheers,
Daniel
From: Scott Wood <hidden> Date: 2009-03-04 21:01:05
On Wed, Feb 25, 2009 at 06:09:32PM +1100, Daniel Ng wrote:
On Fri, Feb 20, 2009 at 4:01 PM, Daniel Ng [off-list ref] wrote:
quoted
Now, I'm seeing these boot messages:
f0010d40:00 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
Previous mailing list discussions suggest that I use the correct PHY,
which I am sure about because my 8272-based board only has the one PHY
ie. PHY0 with reg = <0x0>.
Note the relevant parts of my Device Tree below. Currently, our PHY
attributes eg. 'auto-negotiate' are not changeable, so we aren't
actually using MDC+MDIO even the MDC+MDIO lines exist.
Your device tree is telling the kernel that you *are* using those lines. If
they're not connected the way the device tree describes them as being
connected, you'll have to replace it with something that accurately
describes your hardware.
quoted
Also, the PHY interrupt line is not wired up. Hence the PHY0 interrupts
field is <0 8> (or should it be removed altogether?).
If your PHY interrupt is not connected, then you must remove the
"interrupts" property altogether. "0" is a potentially valid interrupt
number.
-Scott