AMCC 440EP phy detection

AMCC 440EP phy detection

[Eddie Dawydiuk]

Hello,

I'm working on a board based on the Yosemite AMCC 440EP eval board. I'm having 
some difficulty getting both network interfaces working. The first problem I 
found is the ibm_newemac driver was detecting the two phys at address 0 and 1 
where we have them wired for addresses 1 and 3. As a result I hardcoded the 
phy-address in the dts file. I then found I was able to receive and send data on 
eth1(phy-address 3) without incident. Although I found eth0 can receive data but 
I see no packets being transmitted(using a packet sniffer) and I see no 
indication from a software standpoint of any transmit failures. We are using 
Micrel KSZ8041FTL phys(RMII mode) where the Yosemite board used Micrel KS8721BL 
phys.  I've reviewed the schematic and it appears both phys are connected 
identically and I've seen this same failure on multiple boards. I thought the 
fact that the driver detected a phy at address 0 might be a clue, but I can't 
make much of the clue. So I thought I'd post this info in the hopes someone else 
might have run into a similar problem or have a suggestion.

-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive 	     | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: AMCC 440EP phy detection

[Feng Kan]

Hi Eddie:
 
Are you able to ping in u-boot? Sounded like you were only pinging in linux.
I would try the mii command in uboot. It seems like it detected the 
phys. Try enable the
loopbacks at the different stages to see if the traffic is returning. 
This excerise is
much easier in uboot than linux.


Feng Kan
AMCC Software

Eddie Dawydiuk wrote:
> Hello,
>
> I'm working on a board based on the Yosemite AMCC 440EP eval board. I'm having 
> some difficulty getting both network interfaces working. The first problem I 
> found is the ibm_newemac driver was detecting the two phys at address 0 and 1 
> where we have them wired for addresses 1 and 3. As a result I hardcoded the 
> phy-address in the dts file. I then found I was able to receive and send data on 
> eth1(phy-address 3) without incident. Although I found eth0 can receive data but 
> I see no packets being transmitted(using a packet sniffer) and I see no 
> indication from a software standpoint of any transmit failures. We are using 
> Micrel KSZ8041FTL phys(RMII mode) where the Yosemite board used Micrel KS8721BL 
> phys.  I've reviewed the schematic and it appears both phys are connected 
> identically and I've seen this same failure on multiple boards. I thought the 
> fact that the driver detected a phy at address 0 might be a clue, but I can't 
> make much of the clue. So I thought I'd post this info in the hopes someone else 
> might have run into a similar problem or have a suggestion.
>
>   

Re: AMCC 440EP phy detection

[Eddie Dawydiuk]

Feng,


> Are you able to ping in u-boot? Sounded like you were only pinging in 
> linux.

We are not using u-boot, we've written a custom bootloader. I see there are a 
few debugging flags in the emac driver I can enable, I'll do that next to look 
into the problem further. Thanks for the response.

> I would try the mii command in uboot. It seems like it detected the 
> phys. Try enable the
> loopbacks at the different stages to see if the traffic is returning. 
> This excerise is
> much easier in uboot than linux.
> 
> 
> Feng Kan
> AMCC Software
> 
> Eddie Dawydiuk wrote:
>> Hello,
>>
>> I'm working on a board based on the Yosemite AMCC 440EP eval board. 
>> I'm having some difficulty getting both network interfaces working. 
>> The first problem I found is the ibm_newemac driver was detecting the 
>> two phys at address 0 and 1 where we have them wired for addresses 1 
>> and 3. As a result I hardcoded the phy-address in the dts file. I then 
>> found I was able to receive and send data on eth1(phy-address 3) 
>> without incident. Although I found eth0 can receive data but I see no 
>> packets being transmitted(using a packet sniffer) and I see no 
>> indication from a software standpoint of any transmit failures. We are 
>> using Micrel KSZ8041FTL phys(RMII mode) where the Yosemite board used 
>> Micrel KS8721BL phys.  I've reviewed the schematic and it appears both 
>> phys are connected identically and I've seen this same failure on 
>> multiple boards. I thought the fact that the driver detected a phy at 
>> address 0 might be a clue, but I can't make much of the clue. So I 
>> thought I'd post this info in the hopes someone else might have run 
>> into a similar problem or have a suggestion.
>>
>>   
> 


-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive 	     | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: AMCC 440EP phy detection

[Grant Likely]

On Tue, Apr 7, 2009 at 9:32 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrot=
e:
> Hello,
>
> I'm working on a board based on the Yosemite AMCC 440EP eval board. I'm
> having some difficulty getting both network interfaces working. The first
> problem I found is the ibm_newemac driver was detecting the two phys at
> address 0 and 1 where we have them wired for addresses 1 and 3. As a resu=
lt
> I hardcoded the phy-address in the dts file. I then found I was able to
> receive and send data on eth1(phy-address 3) without incident. Although I
> found eth0 can receive data but I see no packets being transmitted(using =
a
> packet sniffer) and I see no indication from a software standpoint of any
> transmit failures. We are using Micrel KSZ8041FTL phys(RMII mode) where t=
he
> Yosemite board used Micrel KS8721BL phys. =A0I've reviewed the schematic =
and
> it appears both phys are connected identically and I've seen this same
> failure on multiple boards. I thought the fact that the driver detected a
> phy at address 0 might be a clue, but I can't make much of the clue. So I
> thought I'd post this info in the hopes someone else might have run into =
a
> similar problem or have a suggestion.

Phy address 0 is the broadcast address.  All phys will usually respond
to address 0 accesses.  Off the top of my head, It sounds like one PHY
is responding to addresses 0 & 1, and the other phy isn't responding
at all.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: AMCC 440EP phy detection

[Stefan Roese]

On Tuesday 07 April 2009, Grant Likely wrote:
> Phy address 0 is the broadcast address.  All phys will usually respond
> to address 0 accesses.

Not all. Some (e.g. LXT971) can be used at this address. But you're correct,  
it's definitely a bad idea to use 0 as an PHY address.

Not sure how the Micrel reacts here. The datasheet could help...

Best regards,
Stefan

Re: AMCC 440EP phy detection

[Eddie Dawydiuk]

Hello,

Thanks for the suggestions :)

I found the ibm_newemac driver(2.6.29) makes the assumption that the bootloader 
has already configured the tx enable pin as it is a multiplexed pin. 
Unfortuantley I am not using U-Boot and our minimal bootloader does not do this. 
  After finding tx enable was never asserting for Eth0 a quick user space 
program verified tx enable was configured as a GPIO pin.

> On Tue, Apr 7, 2009 at 9:32 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrote:
>> Hello,
>>
>> I'm working on a board based on the Yosemite AMCC 440EP eval board. I'm
>> having some difficulty getting both network interfaces working. The first
>> problem I found is the ibm_newemac driver was detecting the two phys at
>> address 0 and 1 where we have them wired for addresses 1 and 3. As a result
>> I hardcoded the phy-address in the dts file. I then found I was able to
>> receive and send data on eth1(phy-address 3) without incident. Although I
>> found eth0 can receive data but I see no packets being transmitted(using a
>> packet sniffer) and I see no indication from a software standpoint of any
>> transmit failures. We are using Micrel KSZ8041FTL phys(RMII mode) where the
>> Yosemite board used Micrel KS8721BL phys.  I've reviewed the schematic and
>> it appears both phys are connected identically and I've seen this same
>> failure on multiple boards. I thought the fact that the driver detected a
>> phy at address 0 might be a clue, but I can't make much of the clue. So I
>> thought I'd post this info in the hopes someone else might have run into a
>> similar problem or have a suggestion.
> 
> Phy address 0 is the broadcast address.  All phys will usually respond
> to address 0 accesses.  Off the top of my head, It sounds like one PHY
> is responding to addresses 0 & 1, and the other phy isn't responding
> at all.
> 
> g.
> 


-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive 	     | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: AMCC 440EP phy detection

[Eddie Dawydiuk]

Hello,

> I found the ibm_newemac driver(2.6.29) makes the assumption that the 
> bootloader has already configured the tx enable pin as it is a 
> multiplexed pin. Unfortuantley I am not using U-Boot and our minimal 
> bootloader does not do this.  After finding tx enable was never 
> asserting for Eth0 a quick user space program verified tx enable was 
> configured as a GPIO pin.

I would like to eventually submit our changes for upstream support. Based on 
this would you recommend ensuring tx enable is configured properly in the 
initialization of the ibm_newemac driver or the platform initialization?

>> On Tue, Apr 7, 2009 at 9:32 AM, Eddie Dawydiuk <eddie@embeddedarm.com> 
>> wrote:
>>> Hello,
>>>
>>> I'm working on a board based on the Yosemite AMCC 440EP eval board. I'm
>>> having some difficulty getting both network interfaces working. The 
>>> first
>>> problem I found is the ibm_newemac driver was detecting the two phys at
>>> address 0 and 1 where we have them wired for addresses 1 and 3. As a 
>>> result
>>> I hardcoded the phy-address in the dts file. I then found I was able to
>>> receive and send data on eth1(phy-address 3) without incident. 
>>> Although I
>>> found eth0 can receive data but I see no packets being 
>>> transmitted(using a
>>> packet sniffer) and I see no indication from a software standpoint of 
>>> any
>>> transmit failures. We are using Micrel KSZ8041FTL phys(RMII mode) 
>>> where the
>>> Yosemite board used Micrel KS8721BL phys.  I've reviewed the 
>>> schematic and
>>> it appears both phys are connected identically and I've seen this same
>>> failure on multiple boards. I thought the fact that the driver 
>>> detected a
>>> phy at address 0 might be a clue, but I can't make much of the clue. 
>>> So I
>>> thought I'd post this info in the hopes someone else might have run 
>>> into a
>>> similar problem or have a suggestion.
>>
>> Phy address 0 is the broadcast address.  All phys will usually respond
>> to address 0 accesses.  Off the top of my head, It sounds like one PHY
>> is responding to addresses 0 & 1, and the other phy isn't responding
>> at all.
>>
>> g.
>>
> 
> 


-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive 	     | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: AMCC 440EP phy detection

[Stefan Roese]

On Wednesday 08 April 2009, Eddie Dawydiuk wrote:
> > I found the ibm_newemac driver(2.6.29) makes the assumption that the
> > bootloader has already configured the tx enable pin as it is a
> > multiplexed pin. Unfortuantley I am not using U-Boot and our minimal
> > bootloader does not do this.  After finding tx enable was never
> > asserting for Eth0 a quick user space program verified tx enable was
> > configured as a GPIO pin.
>
> I would like to eventually submit our changes for upstream support. Based
> on this would you recommend ensuring tx enable is configured properly in
> the initialization of the ibm_newemac driver or the platform
> initialization?

This GPIO multiplexing configuration does not belong into the ibm_newemac 
driver since it is very platform/board specific. The platform code is 
definitely a better place.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de
=====================================================================

Re: AMCC 440EP phy detection

[Grant Likely]

On Wed, Apr 8, 2009 at 9:01 AM, Stefan Roese <sr@denx.de> wrote:
> On Wednesday 08 April 2009, Eddie Dawydiuk wrote:
>> > I found the ibm_newemac driver(2.6.29) makes the assumption that the
>> > bootloader has already configured the tx enable pin as it is a
>> > multiplexed pin. Unfortuantley I am not using U-Boot and our minimal
>> > bootloader does not do this. =A0After finding tx enable was never
>> > asserting for Eth0 a quick user space program verified tx enable was
>> > configured as a GPIO pin.
>>
>> I would like to eventually submit our changes for upstream support. Base=
d
>> on this would you recommend ensuring tx enable is configured properly in
>> the initialization of the ibm_newemac driver or the platform
>> initialization?
>
> This GPIO multiplexing configuration does not belong into the ibm_newemac
> driver since it is very platform/board specific. The platform code is
> definitely a better place.

Even better is the platform specific boot code (firmware or equivalent)

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: AMCC 440EP phy detection

[Stefan Roese]

On Wednesday 08 April 2009, Grant Likely wrote:
> >> I would like to eventually submit our changes for upstream support.
> >> Based on this would you recommend ensuring tx enable is configured
> >> properly in the initialization of the ibm_newemac driver or the platform
> >> initialization?
> >
> > This GPIO multiplexing configuration does not belong into the ibm_newemac
> > driver since it is very platform/board specific. The platform code is
> > definitely a better place.
>
> Even better is the platform specific boot code (firmware or equivalent)

Ack. We usually do all this setup in U-Boot. But as I understand Eddie, he is 
using a custom bootloader.

Eddie, btw: Why are you not using U-Boot?

Best regards,
Stefan

Re: AMCC 440EP phy detection

[Eddie Dawydiuk]

Stefan,

> Ack. We usually do all this setup in U-Boot. But as I understand Eddie, he is 
> using a custom bootloader.

Correct, I'll put this code in the platform initialization. Thanks for the 
suggestions everyone.

> Eddie, btw: Why are you not using U-Boot?

At Technologic Systems, one of our design goals for all of our products is to 
achieve a very quick boot time(under 2 seconds to a shell prompt). We then 
provide a user space utility to boot another linux kernel, this allows our 
customers to use Linux as a bootloader. We boot to an initial ramdisk then use a 
linuxrc script as a replacement for a typical bootloader(e.g. U-Boot). In the 
background we can then mount a large filesystem with Debian installed. In my 
opinion it works out quite nicely in that one can use our boards as more of an 
appliance(apply power and it's on, rather than waiting for a computer to boot).

-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive 	     | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com