[U-Boot] Question: Information regarding MII and PHY
Hi All,
I'm looking at adding a new Gigabit Ethernet driver (Realtek RTL8211CL) to U-Boot. The datasheet, in addition to register descriptions, mentions MII/GMII and PHY support (but not much on the specifics). Now in U-Boot there appears to be a common set of code relating to PHY and MII. There appears to be a mix of Ethernet drivers that use MII/PHY and drivers that do not, but I cannot seems to quite get me head around it all. One weird thing is that there does not appear to be any granular inclusion of PHY drivers - /include/config_phylib_all_drivers.h defines them all when CONFIG_PHYLIB is defined, but I could not find any boards that defined just one PHY driver. I also cannot find how MII/PHY functions interact with PCI for PCI based cards.
In short, I'm very confused - Can anyone give me any pointers to how it all fits together
Thanks,
Graeme
Hello again,
On Thu, Sep 22, 2011 at 11:20 AM, Graeme Russ graeme.russ@gmail.com wrote:
I'm looking at adding a new Gigabit Ethernet driver (Realtek RTL8211CL) to U-Boot. The datasheet, in addition to register
OK, the RTL8211CL is just the transceiver (PHY?) - The MAC is actually part of an Intel PCH (Platform Controller Hub). From what I can gather MII is the standard interface between the MAC (Intel PCH) and the transceiver/PHY (RTL8211CL) (they actually communicate using RGMII - Reduced Gigabit Media Independent Interface)
descriptions, mentions MII/GMII and PHY support (but not much on the specifics). Now in U-Boot there appears to be a common set of code relating to PHY and MII. There appears to be a mix of Ethernet drivers that use MII/PHY and drivers that do not, but I cannot seems to quite get me head around it all. One weird thing is that there does not appear to be any granular inclusion of PHY drivers - /include/config_phylib_all_drivers.h defines them all when CONFIG_PHYLIB is defined, but I could not find any boards that defined just one PHY driver. I also cannot find how MII/PHY functions interact with PCI for PCI based cards.
I now see why there is no relationship between MII/PHY and PCI as they are not connected to the PCI bus - Communication with the PHY is done through the MAC. So is it the case that 'PHY Drivers' in U-Boot provide access to the PHY (Transceiver) _through_ the MAC and in order to use the PHY drivers, the MAC driver (i.e. the Ethernet driver) needs to provide hooks to pass PHY requests from U-Boot over the (RG)MII interface?
Or am I even more confused?
In short, I'm very confused - Can anyone give me any pointers to how it all fits together
Thanks,
Graeme
On Wednesday, September 21, 2011 23:12:44 Graeme Russ wrote:
On Thu, Sep 22, 2011 at 11:20 AM, Graeme Russ wrote:
descriptions, mentions MII/GMII and PHY support (but not much on the specifics). Now in U-Boot there appears to be a common set of code relating to PHY and MII. There appears to be a mix of Ethernet drivers that use MII/PHY and drivers that do not, but I cannot seems to quite get me head around it all. One weird thing is that there does not appear to be any granular inclusion of PHY drivers - /include/config_phylib_all_drivers.h defines them all when CONFIG_PHYLIB is defined, but I could not find any boards that defined just one PHY driver. I also cannot find how MII/PHY functions interact with PCI for PCI based cards.
I now see why there is no relationship between MII/PHY and PCI as they are not connected to the PCI bus - Communication with the PHY is done through the MAC. So is it the case that 'PHY Drivers' in U-Boot provide access to the PHY (Transceiver) _through_ the MAC and in order to use the PHY drivers, the MAC driver (i.e. the Ethernet driver) needs to provide hooks to pass PHY requests from U-Boot over the (RG)MII interface?
i believe this is correct. the intention is to be like Linux where you've got a driver for the MAC, and you've got drivers for the PHYs, and the MAC driver provides the hooks for the PHY layer to access what it needs.
not all drivers have been converted to the PHY abstraction, and we don't have a requirement atm for that.
there's also a bit of a mess as we try to move to the Linux phylib code ... another area that needs a bit of TLC. -mike
Hi Mike,
On Fri, Sep 23, 2011 at 8:21 AM, Mike Frysinger vapier@gentoo.org wrote:
On Wednesday, September 21, 2011 23:12:44 Graeme Russ wrote:
On Thu, Sep 22, 2011 at 11:20 AM, Graeme Russ wrote: I now see why there is no relationship between MII/PHY and PCI as they are not connected to the PCI bus - Communication with the PHY is done through the MAC. So is it the case that 'PHY Drivers' in U-Boot provide access to the PHY (Transceiver) _through_ the MAC and in order to use the PHY drivers, the MAC driver (i.e. the Ethernet driver) needs to provide hooks to pass PHY requests from U-Boot over the (RG)MII interface?
i believe this is correct. the intention is to be like Linux where you've got a driver for the MAC, and you've got drivers for the PHYs, and the MAC driver provides the hooks for the PHY layer to access what it needs.
not all drivers have been converted to the PHY abstraction, and we don't have a requirement atm for that.
there's also a bit of a mess as we try to move to the Linux phylib code ... another area that needs a bit of TLC.
I tried to port the Intel PCH GBe driver last night without much luck. Just trying to satisfy the data structure requirements (let alone the support functions) brings in a rediculous amount of extraneous Linux header files (pretty much the entire TCP/IP stack definitions). I think I'll abandon the direct approach and try to pick out the init, Tx and Rx functions piece by piece.
I'll have a look at phylib while I'm at it, but I doubt that I'll be able to have time to properly figure it at atm
I suppose that is why Wolfgang would like a network custodian
Regards,
Graeme
Hi Mike,
On Fri, Sep 23, 2011 at 8:21 AM, Mike Frysinger vapier@gentoo.org wrote:
On Wednesday, September 21, 2011 23:12:44 Graeme Russ wrote:
On Thu, Sep 22, 2011 at 11:20 AM, Graeme Russ wrote:
[snip]
i believe this is correct. the intention is to be like Linux where you've got a driver for the MAC, and you've got drivers for the PHYs, and the MAC driver provides the hooks for the PHY layer to access what it needs.
not all drivers have been converted to the PHY abstraction, and we don't have a requirement atm for that.
there's also a bit of a mess as we try to move to the Linux phylib code ... another area that needs a bit of TLC.
OK, I just saw another thread (phylib: reset mii bus only if reset handler is registered) which raises a question in my head as to how I should provide PHY support for a brand-spakin' new driver
Is there any documentation on how I should build a new MAC and PHY driver from scratch (i.e. what is the official network driver API)
Regards,
Graeme
On Thu, Sep 22, 2011 at 6:27 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Mike,
On Fri, Sep 23, 2011 at 8:21 AM, Mike Frysinger vapier@gentoo.org wrote:
On Wednesday, September 21, 2011 23:12:44 Graeme Russ wrote:
On Thu, Sep 22, 2011 at 11:20 AM, Graeme Russ wrote:
[snip]
i believe this is correct. the intention is to be like Linux where you've got a driver for the MAC, and you've got drivers for the PHYs, and the MAC driver provides the hooks for the PHY layer to access what it needs.
not all drivers have been converted to the PHY abstraction, and we don't have a requirement atm for that.
there's also a bit of a mess as we try to move to the Linux phylib code ... another area that needs a bit of TLC.
OK, I just saw another thread (phylib: reset mii bus only if reset handler is registered) which raises a question in my head as to how I should provide PHY support for a brand-spakin' new driver
Is there any documentation on how I should build a new MAC and PHY driver from scratch (i.e. what is the official network driver API)
There's not really any documentation for phylib at the moment, except the header files. There aren't a lot of examples for mdio buses at the moment, but it's straightforward:
1) Call mdio_alloc() to create a new bus object 2) Fill in the name, then read, write, and reset functions, and set bus->priv to whatever context structure you want 3) Call mdio_register(bus)
For an example, see drivers/net/fsl_mdio.c
A PHY driver is not much more complicated, and there are many examples.
Then, in the ethernet driver, you will need to call:
phy_connect() to declare the connection between your MAC and the PHY phy_config() to initialize the PHY
When the MAC is ready to deal with traffic, you call phy_startup()
When the MAC is being shut down (the close function), you call phy_shutdown()
Andy
Hi Andy
On Fri, Sep 23, 2011 at 9:36 AM, Andy Fleming afleming@gmail.com wrote:
On Thu, Sep 22, 2011 at 6:27 PM, Graeme Russ graeme.russ@gmail.com wrote:
[snip]
Is there any documentation on how I should build a new MAC and PHY driver from scratch (i.e. what is the official network driver API)
There's not really any documentation for phylib at the moment, except the header files. There aren't a lot of examples for mdio buses at the moment, but it's straightforward:
- Call mdio_alloc() to create a new bus object
- Fill in the name, then read, write, and reset functions, and set
bus->priv to whatever context structure you want 3) Call mdio_register(bus)
For an example, see drivers/net/fsl_mdio.c
A PHY driver is not much more complicated, and there are many examples.
Then, in the ethernet driver, you will need to call:
phy_connect() to declare the connection between your MAC and the PHY phy_config() to initialize the PHY
When the MAC is ready to deal with traffic, you call phy_startup()
When the MAC is being shut down (the close function), you call phy_shutdown()
Thanks for the explanation - I'll have a look tonight
A couple of quick questions regarding network drivers...
1) Was it the case that the Linux phylib was 'tight' enough to bring straight into U-Boot, or was a new phylib written for U-Boot? 2) The Linux network driver framework (at least now) is so massive that porting a network driver over is practically impossible. Is the U-Boot network driver framework similar in any way to the Linux framework such that I can take relevant portions of code straight from a Linux driver, or is it a case of carefully picking out the relevant bits and stitching together a entirely new beast? 3) Any idea what would be one of the most recent network drivers added from scratch to U-Boot that would serve as a 'style guide' for my new driver?
Thanks and Regards,
Graeme
On Thursday, September 22, 2011 20:17:33 Graeme Russ wrote:
- The Linux network driver framework (at least now) is so massive that porting a network driver over is practically impossible. Is the U-Boot network driver framework similar in any way to the Linux framework such that I can take relevant portions of code straight from a Linux driver, or is it a case of carefully picking out the relevant bits and stitching together a entirely new beast?
the net drivers in u-boot tend to be pretty thin because we're single threaded. so the Linux drivers are good to see it setting up the hardware registers, but that's about it.
- Any idea what would be one of the most recent network drivers added from scratch to U-Boot that would serve as a 'style guide' for my new driver?
look at doc/README.drivers.eth. this should cover the eth layer (not PHY). -mike
On Thu, Sep 22, 2011 at 7:17 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Andy
On Fri, Sep 23, 2011 at 9:36 AM, Andy Fleming afleming@gmail.com wrote:
On Thu, Sep 22, 2011 at 6:27 PM, Graeme Russ graeme.russ@gmail.com wrote:
[snip]
Is there any documentation on how I should build a new MAC and PHY driver from scratch (i.e. what is the official network driver API)
There's not really any documentation for phylib at the moment, except the header files. There aren't a lot of examples for mdio buses at the moment, but it's straightforward:
- Call mdio_alloc() to create a new bus object
- Fill in the name, then read, write, and reset functions, and set
bus->priv to whatever context structure you want 3) Call mdio_register(bus)
For an example, see drivers/net/fsl_mdio.c
A PHY driver is not much more complicated, and there are many examples.
Then, in the ethernet driver, you will need to call:
phy_connect() to declare the connection between your MAC and the PHY phy_config() to initialize the PHY
When the MAC is ready to deal with traffic, you call phy_startup()
When the MAC is being shut down (the close function), you call phy_shutdown()
Thanks for the explanation - I'll have a look tonight
A couple of quick questions regarding network drivers...
- Was it the case that the Linux phylib was 'tight' enough to bring
straight into U-Boot, or was a new phylib written for U-Boot?
Much of the code was copied straight over. But the interface is *slightly* different to account for the non-persistence of network connections in u-boot. Basically, I merged "config_aneg" and "config_init", and made "read_status" into "startup", and left out the power saving and interrupt stuff. This was done for simplicity, but it may make sense at this early stage to get closer to the Linux interface.
- The Linux network driver framework (at least now) is so
massive that porting a network driver over is practically impossible. Is the U-Boot network driver framework similar in any way to the Linux framework such that I can take relevant portions of code straight from a Linux driver, or is it a case of carefully picking out the relevant bits and stitching together a entirely new beast?
It's very different. And most Linux ethernet drivers are going to be filled with Linux-specific things (like sk_buffs). The U-Boot API is very simple (open, close, tx, rx, no interrupts). Any driver can serve as a simple example. As Mike said, just use the Linux driver to get a sense of what registers to write, and how to set up your rings.
Andy
On Wed, Sep 21, 2011 at 8:20 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi All,
I'm looking at adding a new Gigabit Ethernet driver (Realtek RTL8211CL) to U-Boot. The datasheet, in addition to register descriptions, mentions MII/GMII and PHY support (but not much on the specifics). Now in U-Boot there appears to be a common set of code relating to PHY and MII. There appears to be a mix of Ethernet drivers that use MII/PHY and drivers that do not, but I cannot seems to quite get me head around it all. One weird thing is that there does not appear to be any granular inclusion of PHY drivers - /include/config_phylib_all_drivers.h defines them all when CONFIG_PHYLIB is defined, but I could not find any boards that defined just one PHY driver. I also cannot find how MII/PHY functions interact with PCI for PCI based cards.
config_phylib_all_drivers gets included by the PowerPC config header, only if CONFIG_TSEC_ENET is defined. We did that because the TSEC driver operated on many platforms already, and almost all of the drivers added by the initial patches were taken from the tsec driver. Rather than go through the platforms, one by one, and add the PHY CONFIG option to them, we made the TSEC automatically enable them all. And that's only if PHYLIB *isn't* defined.
Interestingly, you seem to be right about noone configuring any of the individual PHYs. Or even PHYLIB. I'm guessing that code is all sitting in various custodial trees, waiting to be pulled.
Anyway, it's very simple. Add this to the config file of your board:
#define CONFIG_PHYLIB #define CONFIG_PHY_<FOO>
It's best not to overthink the connection between MII and PHY. Sometimes the term "mii" is used ...vaguely. The term MDIO is better, but also has overtones of the 10G-specific management interface.
Andy
participants (3)
-
Andy Fleming -
Graeme Russ -
Mike Frysinger