Our custom board design diverged from the LS1012a Freedom reference board in that we have an eMMC on SDHC controller 1 and therefore need to configure pin 75 to SDHC1_VSEL (rather than GPIO1[23]). We moved this signal to pin 122 (GPIO1[13]).
Pin 122 is not connected to anything on the Freedom board. The LS1012A RM says the bit 424-425 RCW value of "11" is "GPIO1[13], RESET_REQ_B". We did not change RESET_REQ_B so I left this unchanged. Note: the CodeWarrior IDE RCW configuration tool indicates that "11" is reserved (and not what it how it mux's these pins.
However, I am unable to locate where in the code GPIO1[23] is utilized to reset the Ethernet PHYs and our PHYs appear to be held in reset.
Can anyone point me to the code I need to study/modify?
Thanks!
.Tim
Solved! Go to Solution.
u-boot/eth.c at b3f98d438eefd1b355efdec0b50af5813ff8d0e1 · qoriq-open-source/u-boot · GitHub
procedure "ls1012afrdm_reset_phy"
u-boot/eth.c at b3f98d438eefd1b355efdec0b50af5813ff8d0e1 · qoriq-open-source/u-boot · GitHub
procedure "ls1012afrdm_reset_phy"
ufedor -
Thank you for the pointer. I was able to modify the mask to use the correct GPIO line. That enabled one of the two PHYs. Where I was getting:
Net: PFE class pe firmware
PFE tmu pe firmware
pfe_configure_serdes 0
Could not get PHY for PFE_MDIO: addr 2
phy_connect failed
pfe_configure_serdes 1
Could not get PHY for PFE_MDIO: addr 1
phy_connect failed
No ethernet found.
I am now getting:
Net: PFE class pe firmware
PFE tmu pe firmware
pfe_configure_serdes 0
pfe_configure_serdes 1
Could not get PHY for PFE_MDIO: addr 1
phy_connect failed
pfe_eth0
Similarly, in Linux the error has changed from:
libphy: PHY ls1012a-0:02 not found
pfe 4000000.pfe eth0: phy_connect() failed
pfe 4000000.pfe eth0: pfe_eth_init_one: pfe_phy_init() failed
to:
libphy: PHY ls1012a-0:01 not found
pfe 4000000.pfe eth1: phy_connect() failed
pfe 4000000.pfe eth1: pfe_eth_init_one: pfe_phy_init() failed
It could be more convenient to create new question for the software debugging issue.
We subsequently identified an issue in the schematics that was causing one of the PHYs to have an incorrect address. We are now able to work with both Ethernet connections.
Thank you for following up.