Haavard Skinnemoen wrote:

Yes, we could do that. But it comes with its own share of problems -- some boards have a too weak pull-up (or none at all) on the MDIO line, so the probing code sometimes thinks it has found a whole bunch of PHYs...

And you have to know which PHY belongs to which MII port - for example, the IXP420 has two MII busses, but only one shared MDIO, so PHY addresses can not be autodetected - you need some kind of board-specific table/code that defines the mapping between PHY addresses and MII busses. Which is basically what we have now, in the form of CONFIG_PHY*_ADDR ;-)

cu Michael

michael wrote:

I add the cycle only for testing and works, now I will take a look to the mii layer in the u-boot and maybe find a better and clean solution if I have spare time.

Did I get that right - you added a loop to check all PHY addresses,and now it works on your board?

If yes, you simply need to define the right PHY address in your board config, and it should work without the loop.

cu Michael

trimarchi@gandalf.sssup.it wrote:

... if I understand the physical address is latched during power on and if the logic is not good maybe it can be latched a different addresss in different session. I like somenthing that permits at software developer to easy search for the physical address.

The "mii info" command (without a PHY address as parameter) does exactly what you need:

=> mii info PHY 0x10: OUI = 0x5043, Model = 0x08, Rev = 0x07, 10baseT, HDX PHY 0x11: OUI = 0x5043, Model = 0x08, Rev = 0x07, 10baseT, HDX PHY 0x12: OUI = 0x5043, Model = 0x08, Rev = 0x07, 10baseT, HDX PHY 0x13: OUI = 0x5043, Model = 0x08, Rev = 0x07, 100baseT, FDX PHY 0x14: OUI = 0x5043, Model = 0x08, Rev = 0x07, 10baseT, HDX PHY 0x15: OUI = 0x0000, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x16: OUI = 0x0000, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x17: OUI = 0x0000, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x18: OUI = 0x0001, Model = 0x20, Rev = 0x02, 10baseT, HDX PHY 0x19: OUI = 0x0001, Model = 0x20, Rev = 0x02, 10baseT, HDX PHY 0x1A: OUI = 0x0001, Model = 0x20, Rev = 0x02, 10baseT, HDX PHY 0x1B: OUI = 0x0001, Model = 0x20, Rev = 0x02, 10baseT, HDX PHY 0x1C: OUI = 0x0001, Model = 0x20, Rev = 0x02, 10baseT, HDX PHY 0x1D: OUI = 0x0001, Model = 0x20, Rev = 0x02, 10baseT, HDX PHY 0x1E: OUI = 0x0000, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00, 10baseT, HDX

Now which of these should the autodetect code pick? (hint: 0x13 is wrong, even if it is the only one that shows a 100Mbps link). Also, this really is a board with working MDIO, with correct pullups, so no "ghost" PHYs in the list.

cu Michael

On Sun, Feb 24, 2008 at 7:30 AM, trimarchi@gandalf.sssup.it wrote:

Hi

Quoting Michael Schwingen rincewind@discworld.dascon.de:

...

If yes, you simply need to define the right PHY address in your board config, and it should work without the loop.

... if I understand the physical address is latched during power on and if the logic is not good maybe it can be latched a different addresss in different session. I like somenthing that permits at software developer to easy search for the physical address.

That's not a very good solution. If the logic is bad, that's an actual hardware bug. If you can't guarantee the PHY will have the intended address, then if you have more than one PHY, you'll have no way of knowing which one is connected to which ethernet controller. Also, if they can end up at arbitrary addresses, you can get an address conflict, and then you're hosed. In other words, you might be ok with doing such a workaround during bringup, but it's not a guaranteed workaround for a production system. Get your hardware designer to not screw up the address latching

And, speaking from experience, you can run into a large number of problems with trying to search for the PHY:

* There's no ordering requirement. I've seen boards where they put the PHYs for my four controllers at 17, 1, 2, 3 * If you have multiple *types* of controller on the same bus, even if you have the right internal order, you now need to guarantee that the drivers are initialized in the right order. For example, I have a processor that has two tsec-style controllers and two ucc_geth-style controllers. They share the same MDIO bus, so the order could be tsec, tsec, ucc, ucc. Or it could be ucc, ucc, tsec, tsec. I forget which one it actually is, but the important thing is that whichever way it is, the other way is perfectly reasonable. Any scanning algorithm that would work one way (assuming you had some way of telling other drivers that you were using the PHYs you found) would fail the other way. * The number of PHYs may not be one-to-one for the controllers. For instance, I have a board with 4 ethernet controllers. It has the option of using either the 4 normal PHYs, or 4 SGMII PHYs. Which ones they use are selected by a switch. However, all eight PHYs are on the bus. If I scanned, I would find the normal PHYs first, and that would be wrong if I'm in SGMII mode.

In short (I know, too late), there is not a reliable way to determine the address of a controller's PHY dynamically. There are a number of instances where it works, but there's no requirement on the hardware designers to allow any such scheme to work in the future. To me, this means the PHY address must be knowable ahead of time.

Andy