Where in the LS1012a-Freedom code is GPIO_RST_B controlled?

[timhammer]

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

[ufedor · Accepted solution]

u-boot/eth.c at b3f98d438eefd1b355efdec0b50af5813ff8d0e1 · qoriq-open-source/u-boot · GitHub 

procedure "ls1012afrdm_reset_phy"

[timhammer]

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

[ufedor]

It could be more convenient to create new question for the software debugging issue.

[timhammer]

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.