AMCC 440EP phy detection
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.
Signature · 5 lines
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
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
Quoted 5 lines · 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_newemacdriver 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.
Feng,
Quoted 1 line
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.
Quoted 15 lines
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 SoftwareQuoted 5 lines · 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_newemacdriver 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.
Signature · 5 lines
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
On Tue, Apr 7, 2009 at 9:32 AM, Eddie Dawydiuk <[email protected]> wrot= e:
Quoted 6 lines
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_newemacdriver was detecting the two phys at address 0 and 1 where we have them wired for addresses 1 and 3. As a resu=
lt
Quoted 3 lines
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
Quoted 2 lines
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
Quoted 1 line
Yosemite board used Micrel KS8721BL phys. =A0I've reviewed the schematic =
and
Quoted 4 lines
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
Quoted 1 line
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.
Quoted 2 lines · Grant Likely
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
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.
Quoted 26 lines · Eddie Dawydiuk
Quoted 17 lines
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_newemacdriver 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.
Signature · 5 lines
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
Hello,
Quoted 1 line
I found the
ibm_newemacdriver(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?
Quoted 28 lines
Quoted 26 lines · Eddie Dawydiuk
Quoted 17 lines
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_newemacdriver 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.
Signature · 5 lines
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
Quoted 11 lines · Eddie Dawydiuk
Quoted 6 lines
I found the
ibm_newemacdriver(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_newemacdriver 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: [email protected]
=====================================================================
Quoted 9 lines · Stefan Roese
Quoted 8 lines · Eddie Dawydiuk
Quoted 6 lines
I found the
ibm_newemacdriver(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
Quoted 7 lines
Quoted 3 lines
on this would you recommend ensuring tx enable is configured properly in the initialization of the
ibm_newemacdriver or the platform initialization?This GPIO multiplexing configuration does not belong into the
ibm_newemacdriver 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.
Quoted 10 lines · Grant Likely
Quoted 8 lines
Quoted 4 lines
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_newemacdriver or the platform initialization?This GPIO multiplexing configuration does not belong into the
ibm_newemacdriver 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
Stefan,
Quoted 1 line
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.
Quoted 1 line
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).
Signature · 5 lines
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