Re: How to bring up fs_enet on 2.6.27?

Re: How to bring up fs_enet on 2.6.27?

[Mike Ditto]

Daniel Ng <daniel.ng1234@gmail.com> wrote:
> Should the device just be available as 'eth2', so that I can do
> 'ifconfig eth2 192.168.1.33'?

It will be eth0 if you have no other network devices.

>         // FCC2-
>         reg = <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
>         fsl,cpm-command = <0x12000300>;

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 [=-

Re: How to bring up fs_enet on 2.6.27?

[Daniel Ng]

On Thu, Jan 29, 2009 at 12:16 PM, Mike Ditto <mditto@consentry.com> 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

Re: How to bring up fs_enet on 2.6.27?

[Scott Wood]

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.
> 

See this thread:
http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068467.html

-Scott

Re: How to bring up fs_enet on 2.6.27?

[Daniel Ng]

On Fri, Feb 20, 2009 at 5:44 AM, Scott Wood <scottwood@freescale.com> wrote:
> See this thread:
> http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068467.html
>

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

Re: How to bring up fs_enet on 2.6.27?

[Daniel Ng]

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 <daniel.ng1234@gmail.com> 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=
2-pic", "fsl,cpm2-pic";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> Cheers,
> Daniel
>

Re: How to bring up fs_enet on 2.6.27?

[Mike Ditto]

Daniel Ng wrote:
>> Now, I'm seeing these boot messages:
>>
>> f0010d40:00 not found
>> eth0: Could not attach to PHY

Daniel,

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.

>> Currently, our PHY
>> attributes eg. 'auto-negotiate' are not changeable, so we aren't
>> actually using MDC+MDIO even 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.

>> Also, the PHY
>> interrupt line is not wired up. Hence the PHY0 interrupts field is <0
>> 8> (or should it be removed altogether?).

The mdio driver works without interrupts.  I have no interrupt-parent
or interrupts properties on my ethernet-phy node.

					-=] Mike [=-

Re: How to bring up fs_enet on 2.6.27?

[Daniel Ng]

On Wed, Feb 25, 2009 at 8:25 PM, Mike Ditto <mditto@consentry.com> wrote:
> Daniel Ng wrote:
>>> 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.
>
>>> 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

Re: How to bring up fs_enet on 2.6.27?

[Scott Wood]

On Wed, Feb 25, 2009 at 06:09:32PM +1100, Daniel Ng wrote:
> On Fri, Feb 20, 2009 at 4:01 PM, Daniel Ng <daniel.ng1234@gmail.com> 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 = <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.

> > 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

Re: How to bring up fs_enet on 2.6.27?

[Daniel Ng]

Thanks for your help so far Laurent-

On Wed, Jan 28, 2009 at 8:50 PM, Laurent Pinchart
<laurentp@cse-semaphore.com> wrote:
>
> Make sure FS_ENET_HAS_FCC is set in your kernel configuration.

Yep, I've done that...

>
> [snip]
>
>> The fs_enet probe() function doesn't seem to get called (I had put a
>> panic() in it). Should it?
>
> Yes it should.

Ok, so it isn't being called. What code calls the fs_enet probe()
function? What could be the reason why this isn't being called? ie. do
I need to set something else?

Should the device just be available as 'eth2', so that I can do
'ifconfig eth2 192.168.1.33'?

Cheers,
Daniel

Re: How to bring up fs_enet on 2.6.27?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Hi Daniel,

On Wednesday 28 January 2009 06:04:11 Daniel Ng wrote:
> Hi,
>
> I'm trying to bring the primary Ethernet interface up on my 8272-based
> board running 2.6.27.
>
> Previously, I had this same hardware working with 2.6.14 using the
> following driver:
>
> linux-2.6.14/arch/ppc/8260_io/fcc_enet.c
>
> This doesn't exist anymore in 2.6.27. From reading the code comments,
> I think the new driver I should be using is:
>
> linux-2.6.27/drivers/net/fs_enet/fs_enet-main.c

That's right.

> The PHY is an Intel LXT972. I have selected the closest-matching
> Kernel config option 'LXT970'.
>
> The primary ethernet uses FCC2.

Make sure FS_ENET_HAS_FCC is set in your kernel configuration.

[snip]

> The fs_enet probe() function doesn't seem to get called (I had put a
> panic() in it). Should it?

Yes it should.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

How to bring up fs_enet on 2.6.27?

[Daniel Ng]

Hi,

I'm trying to bring the primary Ethernet interface up on my 8272-based
board running 2.6.27.

Previously, I had this same hardware working with 2.6.14 using the
following driver:

linux-2.6.14/arch/ppc/8260_io/fcc_enet.c

This doesn't exist anymore in 2.6.27. From reading the code comments,
I think the new driver I should be using is:

linux-2.6.27/drivers/net/fs_enet/fs_enet-main.c

The PHY is an Intel LXT972. I have selected the closest-matching
Kernel config option 'LXT970'.

The primary ethernet uses FCC2.

Here are the relevant boot messages:

OF: ** translation for device /soc@f0000000 **
OF: bus is default (na=3D1, ns=3D1) on /
OF: translating address: f0000000
OF: reached root node
OF: ** translation for device /soc@f0000000/cpm@119c0/muram@0/data@0 **
OF: bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0/muram@0
OF: translating address: 00000000
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0
OF: walking ranges...
OF: default map, cp=3D0, s=3D10000, da=3D0
OF: parent translation for: 00000000
OF: with offset: 0
OF: one level translation: 00000000
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000
OF: no ranges, 1:1 translation
OF: parent translation for: 00000000
OF: with offset: 0
OF: one level translation: 00000000
OF: parent bus is default (na=3D1, ns=3D1) on /
OF: walking ranges...
OF: default map, cp=3D0, s=3D53000, da=3D0
OF: parent translation for: f0000000
OF: with offset: 0
OF: one level translation: f0000000
OF: reached root node
OF: ** translation for device /soc@f0000000/cpm@119c0/muram@0/data@0 **
OF: bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0/muram@0
OF: translating address: 00000000
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0
OF: walking ranges...
OF: default map, cp=3D0, s=3D10000, da=3D0
OF: parent translation for: 00000000
OF: with offset: 0
OF: one level translation: 00000000
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000
OF: no ranges, 1:1 translation
OF: parent translation for: 00000000
OF: with offset: 0
OF: one level translation: 00000000
OF: parent bus is default (na=3D1, ns=3D1) on /
OF: walking ranges...
OF: default map, cp=3D0, s=3D53000, da=3D0
OF: parent translation for: f0000000
OF: with offset: 0
OF: one level translation: f0000000
OF: reached root node
OF: ** translation for device /soc@f0000000/cpm@119c0/muram@0/data@0 **
OF: bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0/muram@0
OF: translating address: 00009800
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0
OF: walking ranges...
OF: default map, cp=3D0, s=3D10000, da=3D9800
OF: parent translation for: 00000000
OF: with offset: 9800
OF: one level translation: 00009800
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000
OF: no ranges, 1:1 translation
OF: parent translation for: 00000000
OF: with offset: 9800
OF: one level translation: 00009800
OF: parent bus is default (na=3D1, ns=3D1) on /
OF: walking ranges...
OF: default map, cp=3D0, s=3D53000, da=3D9800
OF: parent translation for: f0000000
OF: with offset: 9800
OF: one level translation: f0009800
OF: reached root node
hpxred_setup_arch(), finished
arch: exit
....
Kernel command line: root=3D/dev/nfs rw
nfsroot=3D192.168.1.8:/tftpboot/192.168.1.75/ro
otfs ip=3D192.168.1.75:192.168.1.8::255.255.255.0:hpx800:eth2:off
mtdparts=3Dflash:256K
(uboot),128K(env1),128K(env2),1536K(linux1),6144K(root1),4096K(app1),1536K(=
linux2),
6144K(root2),4096K(app2),1536K(usr),-(usb) panic=3D1 console=3DttyCPM0
mem=3D32M usbid=3D1
hpxred_pic_init()
irq: Allocated host of type 2 @0xc03163a0
hpxred_pic_init(), finished
PID hash table entries: 128 (order: 7, 512 bytes)
time_init: decrementer frequency =3D 16.500000 MHz
time_init: processor frequency   =3D 330.000000 MHz
clocksource: timebase mult[f26c9b2] shift[22] registered
clockevent: decrementer mult[439] shift[16] cpu[0]
Console: colour dummy device 80x25
cpm_uart_init_port()
OF: ** translation for device /soc@f0000000/cpm@119c0/serial@11a00 **
OF: bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0
OF: translating address: 00011a00
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000
OF: no ranges, 1:1 translation
OF: parent translation for: 00000000
OF: with offset: 11a00
OF: one level translation: 00011a00
OF: parent bus is default (na=3D1, ns=3D1) on /
OF: walking ranges...
OF: default map, cp=3D0, s=3D53000, da=3D11a00
OF: parent translation for: f0000000
OF: with offset: 11a00
OF: one level translation: f0011a00
OF: reached root node
OF: ** translation for device /soc@f0000000/cpm@119c0/serial@11a00 **
OF: bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0
OF: translating address: 00008000
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000
OF: no ranges, 1:1 translation
OF: parent translation for: 00000000
OF: with offset: 8000
OF: one level translation: 00008000
OF: parent bus is default (na=3D1, ns=3D1) on /
OF: walking ranges...
OF: default map, cp=3D0, s=3D53000, da=3D8000
OF: parent translation for: f0000000
OF: with offset: 8000
OF: one level translation: f0008000
OF: reached root node
of_irq_map_one: dev=3D/soc@f0000000/cpm@119c0/serial@11a00, index=3D0
 intsize=3D2 intlen=3D2
of_irq_map_raw:
par=3D/soc@f0000000/interrupt-controller@10c00,intspec=3D[0x00000028 0x
00000008...],ointsize=3D2
of_irq_map_raw: ipar=3D/soc@f0000000/interrupt-controller@10c00, size=3D2
 -> addrsize=3D1
 -> got it !
irq: irq_create_mapping(0xc03163a0, 0x28)
irq: -> using host @c03163a0
irq: -> obtained virq 40
cpm2_pic_host_map(40, 0x28)
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
cpm_uart_request_port()
CPM uart[=FEDentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 29564k/32768k available (2636k kernel code, 3204k reserved,
104k data, 129k
 bss, 120k init)
...
kobject: 'fs_enet' (c1810900): kobject_add_internal: parent: 'module',
set: 'module'
....
bus: 'mdio_bus': add driver LXT970
kobject: 'LXT970' (c1817900): kobject_add_internal: parent: 'drivers',
set: 'driver
s'
LXT970: Registered new driver
bus: 'mdio_bus': add driver LXT971
kobject: 'LXT971' (c1817960): kobject_add_internal: parent: 'drivers',
set: 'driver
s'
LXT971: Registered new driver
Registering platform device 'Fixed MDIO bus.0'. Parent at platform
device: 'Fixed MDIO bus.0': device_add
kobject: 'Fixed MDIO bus.0' (c1946470): kobject_add_internal: parent:
'platform', s
et: 'devices'
bus: 'platform': add device Fixed MDIO bus.0
Fixed MDIO Bus: probed
bus: 'of_platform': add driver mdio-gpio
kobject: 'mdio-gpio' (c18179c0): kobject_add_internal: parent:
'drivers', set: 'dri
vers'
....
bus: 'of_platform': add driver fs_enet
kobject: 'fs_enet' (c1817a80): kobject_add_internal: parent:
'drivers', set: 'drive
rs'
bus: 'of_platform': add driver fsl-bb-mdio
kobject: 'fsl-bb-mdio' (c1817ae0): kobject_add_internal: parent:
'drivers', set: 'd
rivers'
....
IP-Config: Device `eth2' not found.
driver_probe_done: probe_count =3D 0


The fs_enet probe() function doesn't seem to get called (I had put a
panic() in it). Should it?

I also tried searching for 'eth0' and 'eth1' but got the same result.
'eth2' was what I used with 2.6.14.


Here's the relevant parts of the Device Tree:

  soc@f0000000 {
    #address-cells =3D <1>;
    #size-cells =3D <1>;
    device_type =3D "soc";
    compatible =3D "fsl,mpc8272", "fsl,pq2-soc";
    ranges =3D <0x0 0xf0000000 0x53000>;

    // Temporary -- will go away once kernel uses ranges for get_immrbase()=
.
    reg =3D <0xf0000000 0x53000>;

    cpm@119c0 {
      #address-cells =3D <1>;
      #size-cells =3D <1>;
      #interrupt-cells =3D <2>;
      compatible =3D "fsl,mpc8272-cpm", "fsl,cpm2";
      reg =3D <0x119c0 0x30>;
      ranges;

      muram@0 {
        #address-cells =3D <1>;
        #size-cells =3D <1>;
        ranges =3D <0x0 0x0 0x10000>;

        data@0 {
          compatible =3D "fsl,cpm-muram-data";
          reg =3D <0x0 0x2000 0x9800 0x800>;
        };
      };

      brg@119f0 {
        compatible =3D "fsl,mpc8272-brg",
                     "fsl,cpm2-brg";
        reg =3D <0x119f0 0x10 0x115f0 0x10>;
        clock-frequency =3D <0>;
      };

      serial@11a00 {
        device_type =3D "serial";
        compatible =3D "fsl,mpc8272-scc-uart",
                     "fsl,cpm2-scc-uart";
        reg =3D <0x11a00 0x20 0x8000 0x100>;
        interrupts =3D <40 8>;
        interrupt-parent =3D <&PIC>;
        fsl,cpm-brg =3D <0>;
        fsl,cpm-command =3D <0x800000>;
      };

      ethernet@11320 {
        device_type =3D "network";
        compatible =3D "fsl,mpc8272-fcc-enet",
                     "fsl,cpm2-fcc-enet";
        // FCC2-
        reg =3D <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
        local-mac-address =3D [ 00 00 00 00 00 00 ];
        interrupts =3D <33 8>;
        interrupt-parent =3D <&PIC>;
        phy-handle =3D <&PHY0>;
        linux,network-index =3D <0>;
        fsl,cpm-command =3D <0x12000300>;
      };

      mdio@10d40 {
        device_type =3D "mdio";
        compatible =3D "fsl,mpc8272ads-mdio-bitbang",
                     "fsl,mpc8272-mdio-bitbang",
                     "fsl,cpm2-mdio-bitbang";
        reg =3D <0x10d40 0x14>;
        #address-cells =3D <1>;
        #size-cells =3D <0>;
        fsl,mdio-pin =3D <5>;
        fsl,mdc-pin =3D <19>;

        PHY0: ethernet-phy@0 {
          interrupt-parenn =3D <&PIC>;
          interrupts =3D <23 8>;
          reg =3D <0x0>;
          device_type =3D "ethernet-phy";
        };

     };

  };

    PIC: interrupt-controller@10c00 {
      #interrupt-cells =3D <2>;
      interrupt-controller;
      reg =3D <0x10c00 0x80>;
      compatible =3D "fsl,mpc8272-pic", "fsl,cpm2-pic";
    };

  };


Cheers,
Daniel