From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qy0-f21.google.com (mail-qy0-f21.google.com [209.85.221.21]) by ozlabs.org (Postfix) with ESMTP id 22A5ADDD04 for ; Fri, 20 Feb 2009 16:00:31 +1100 (EST) Received: by qyk14 with SMTP id 14so3082196qyk.9 for ; Thu, 19 Feb 2009 21:00:30 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <3A45394FD742FA419B760BB8D398F9ED246F06@zch01exm26.fsl.freescale.net> <2a27d3730902182319i2c59d68dk98e7975714f80549@mail.gmail.com> Date: Fri, 20 Feb 2009 00:00:30 -0500 Message-ID: <1c641bc80902192100w2c46a447ued43a6b98b877676@mail.gmail.com> Subject: Re: Newby trying to get Ethernet going on MPC83xx series device. From: Michael Bergandi To: Dushara Jayasinghe Content-Type: multipart/alternative; boundary=00c09fa2195d32582f04635288a8 Cc: "linuxppc-dev@ozlabs.org" , Aggrwal Poonam-B10812 , Timur Tabi List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --00c09fa2195d32582f04635288a8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dushara, Sorry, I'm a late comer here, but I might have an idea. First off, I don't see below what kernel version you are using? I may have missed it somewhere. > The devices are successfully probed, but I'm getting this error on the > debug console: > > [ 7.119389] mdio@24520:00 not found > [ 7.161370] eth0: Could not attach to PHY > [ 7.209600] IP-Config: Failed to open eth0 > [ 7.258879] IP-Config: Device `eth0' not found. I have similar output on my MPC8313E RDB. In my case, eth0 shared lines with the external USB OTG and its PHY. I modified the resister banks on the board that essentially cuts off the interrupt to the eth0 PHY. So, I don't expect it to find it. Here is the kernel output at init time: 24520:01 not found eth0: Could not attach to PHY My mdio & Ethernet nodes are as follows (commenting out device_type below is > an experiment) > > mdio@24520 { > /*device_type = "mdio";*/ > compatible = "fsl,gianfar-mdio"; > #address-cells = <1>; > #size-cells = <0>; > reg = <24520 20>; Hmm, well, the first thing I catch is this is an old dts format. Depending on your kernel version, you may want to comply with the dts v1 spec. The v1 spec is much more strict on the format of the values that are provided for the properties. ex. reg = <0x24520 0x20> makes it very clear that these values are hex, not decimal. You will notice this ambiguity below with the 'interrupts' properties. Are the values decimal or hex? Turns out that the values are hex. You will find dts version specifier " /dts-v1/; " at the top or just before the root node in any dts file that meets the v1 spec. > > phy0: ethernet-phy@0 { > interrupt-parent = <&ipic>; > interrupts = <3 8>; > reg = <0>; > device_type = "ethernet-phy"; > }; > phy1: ethernet-phy@1 { > interrupt-parent = <&ipic>; > interrupts = <3 8>; > reg = <1>; > device_type = "ethernet-phy"; > }; > }; Are you sure both PHY's use interrupt 3? I would think not. enet0: ethernet@24000 { > cell-index = <0>; > device_type = "network"; > model = "TSEC"; > compatible = "gianfar"; > reg = <24000 1000>; > local-mac-address = [ 00 00 00 00 00 00 ]; > interrupts = <20 8 21 8 22 8>; > interrupt-parent = <&ipic>; > phy-handle = <&phy0>; > linux,network-index = <0>; > }; > > enet1: ethernet@25000 { > cell-index = <1>; > device_type = "network"; > model = "TSEC"; > compatible = "gianfar"; > reg = <25000 1000>; > local-mac-address = [ 00 00 00 00 00 00 ]; > interrupts = <23 8 24 8 25 8>; > interrupt-parent = <&ipic>; > phy-handle = <&phy1>; > linux,network-index = <1>; > phy-connection-type = "gmii"; > }; Finally, I don't know which silicon rev that you are using, but I have seen the enet0 and enet1 interrupts swapped. As in the very latest silicon may have the interrupt lines switched between them. You can find a statement to that affect on this list somewhere. I am using a revB MPC8313E and I specify the interrupts as you have them here. However, the dts file for the mpc8313erdb in the 2.6.28 kernel has them reversed. Presumably for a revC chip. ex. enet0: ethernet@24000 { ... interrupts = <23 8 24 8 25 8>; ... }; enet1: ethernet@25000 { ... interrupts = <20 8 21 8 22 8>; ... }; > BTW, I assume CCing all those who replied to me is accepted/expected > conduct or should I avoid this and just write to the list? Yes, you should cc those who have replied. It is expected --- well, at least by me. Also is top posting ok? I haven't figured out how to enable '>' on bloody > Microsoft Outlook, for incoming plain text messages. I'm a little new to this list, but in general top posting is frowned upon. Unfortunately, I can't help you with the Outlook problem. I can tell you that not being able to determine what part of a message came when is extremely annoying. I hope you find a fix for it. Or, you could try Thunderbird :) Mike --00c09fa2195d32582f04635288a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dushara,

Sorry, I'm a late comer here, but I might have an id= ea.  First off, I don't see below what
kernel version you are = using? I may have missed it somewhere.


The devices are successfully probed, but I'm getting this error on the = debug console:

[    7.119389] mdio@24520:00 not found
[    7.161370] eth0: Could not attach to PHY
[    7.209600] IP-Config: Failed to open eth0
[    7.258879] IP-Config: Device `eth0' not found.

I have similar output on my MPC8313E RDB. In my case, eth0 share= d lines with the external USB OTG and its PHY. I modified the resister bank= s on the board that essentially cuts off the interrupt to the eth0 PHY. So,= I don't expect it to find it. Here is the kernel output at init time:<= br>
24520:01 not found
eth0: Could not attach to PHY


My mdio & Ethernet nodes are as follows (commenting out device_type bel= ow is an experiment)

               mdio@24520 {
                    &nbs= p;  /*device_type =3D "mdio";*/
                    &nbs= p;  compatible =3D "fsl,gianfar-mdio";
                    &nbs= p;  #address-cells =3D <1>;
                    &nbs= p;  #size-cells =3D <0>;
                    &nbs= p;  reg =3D <24520 20>;

Hmm, well, the firs= t thing I catch is this is an old dts format. Depending on your kernel vers= ion, you
may want to comply with the  dts v1 spec. The v1 spec is = much more strict on the format of the values
that are provided for the properties.

ex. reg =3D <0x24520 0x20&= gt; makes it very clear that these values are hex, not decimal.

You= will notice this ambiguity below with the 'interrupts' properties.= Are the values decimal or hex?
Turns out that the values are hex. You will find dts version specifier &quo= t; /dts-v1/; " at the top or just before
the root node in any dts = file that meets the v1 spec.



                    &nbs= p;  phy0: ethernet-phy@0 {
                    &nbs= p;          interrupt-parent =3D <&ipic>= ;
                    &nbs= p;          interrupts =3D <3 8>;
                    &nbs= p;          reg =3D <0>;
                    &nbs= p;          device_type =3D "ethernet-phy&quo= t;;
                    &nbs= p;  };
                    &nbs= p;  phy1: ethernet-phy@1 {
                    &nbs= p;          interrupt-parent =3D <&ipic>= ;
                    &nbs= p;          interrupts =3D <3 8>;
                    &nbs= p;          reg =3D <1>;
                    &nbs= p;          device_type =3D "ethernet-phy&quo= t;;
                    &nbs= p;  };
               };
 
Are you sure both PHY's use interrupt 3? I would thin= k not.
 

               enet0: ethernet@240= 00 {
                    &nbs= p;  cell-index =3D <0>;
                    &nbs= p;  device_type =3D "network";
                    &nbs= p;  model =3D "TSEC";
                    &nbs= p;  compatible =3D "gianfar";
                    &nbs= p;  reg =3D <24000 1000>;
                    &nbs= p;  local-mac-address =3D [ 00 00 00 00 00 00 ];
                    &nbs= p;  interrupts =3D <20 8 21 8 22 8>;
                    &nbs= p;  interrupt-parent =3D <&ipic>;
                    &nbs= p;  phy-handle =3D <&phy0>;
                    &nbs= p;  linux,network-index =3D <0>;
               };

               enet1: ethernet@250= 00 {
                    &nbs= p;  cell-index =3D <1>;
                    &nbs= p;  device_type =3D "network";
                    &nbs= p;  model =3D "TSEC";
                    &nbs= p;  compatible =3D "gianfar";
                    &nbs= p;  reg =3D <25000 1000>;
                    &nbs= p;  local-mac-address =3D [ 00 00 00 00 00 00 ];
                    &nbs= p;  interrupts =3D <23 8 24 8 25 8>;
                    &nbs= p;  interrupt-parent =3D <&ipic>;
                    &nbs= p;  phy-handle =3D <&phy1>;
                    &nbs= p;  linux,network-index =3D <1>;
                    &nbs= p;  phy-connection-type =3D "gmii";
               };

Finally, I don't know which silicon rev that you are using, but I = have seen the enet0 and enet1 interrupts swapped.
 
As in the v= ery latest silicon may have the interrupt lines switched between them. You = can find a statement to that
affect on this list somewhere. I am using a revB MPC8313E and I specify the= interrupts as you have them here.
However, the dts file for the mpc831= 3erdb in the 2.6.28 kernel has them reversed. Presumably for a revC chip.
ex.
enet0: ethernet@24000 {
...
     = ;   interrupts =3D <23 8 24 8 25 8>;
...
};

en= et1: ethernet@25000 {
...
        = interrupts =3D <20 8 21 8 22 8>;
...
};



BTW, I assume CCing all those who replied to me is accepted/expected conduc= t or should I avoid this and just write to the list?

Y= es, you should cc those who have replied. It is expected --- well, at least= by me.
 

Also is top posting ok? I haven't figured out how to enable '>&#= 39; on bloody Microsoft Outlook, for incoming plain text messages.

I'm a little new to this list, but in general top posting = is frowned upon. Unfortunately, I can't help you with the Outlook probl= em.
I can tell you that not being able to determine what part of a message came= when is extremely annoying. I hope you find a fix
for it. Or, you could= try Thunderbird :)

Mike
--00c09fa2195d32582f04635288a8--