Re: AMCC 440EP phy detection
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 ed...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
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: off...@denx.de = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
On Wed, Apr 8, 2009 at 9:01 AM, Stefan Roese s...@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. 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. Even better is the platform specific boot code (firmware or equivalent) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
On Tue, Apr 7, 2009 at 9:32 AM, Eddie Dawydiuk ed...@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. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
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 ed...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
