Posting on behalf of customer
Related to the previous post we were able to get the second PHY working by changing the Ti CPSW driver (cpsw.c) in u-boot. Although this workaround is not ideal it did allow them to get things working. It also raised more questions.
We noticed that the “active_slave” parameter in the “mac” object of the device tree file controlled which PHY was initialized. It defaults to 0, allowing the first PHY to work. Changing it to 1 allows the second PHY to work but stops the first PHY from working. Based on this observation they went into the CPSW driver and changed places which initialized only the active slave to initialize all slaves. This changed allowed us to see both PHYs in u-boot and allowed both PHYs to work once the Linux Kernel had booted.
But, we were unable to get the Linux Kernel to initialize the slaves/PHYs properly and they were only able to do this in u-boot.
So, this work around has generated several questions:
- Why do we have to have u-boot call init on each PHY?
- Why doesn’t the Linux driver initialize the PHY correctly?
- Are we missing DTS entries that would cause the Linux driver to initialize the PHYs?
Can TI provide any additional pointers on above