[U-Boot] Question: Information regarding MII and PHY

[U-Boot] Question: Information regarding MII and PHY

[Graeme Russ]

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

[U-Boot] Question: Information regarding MII and PHY

[Graeme Russ]

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

[U-Boot] Question: Information regarding MII and PHY

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110922/16378280/attachment.pgp 

[U-Boot] Question: Information regarding MII and PHY

[Graeme Russ]

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

[U-Boot] Question: Information regarding MII and PHY

[Graeme Russ]

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

[U-Boot] Question: Information regarding MII and PHY

[Andy Fleming]

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

[U-Boot] Question: Information regarding MII and PHY

[Andy Fleming]

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

[U-Boot] Question: Information regarding MII and PHY

[Graeme Russ]

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:
>
> 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()

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

[U-Boot] Question: Information regarding MII and PHY

[Mike Frysinger]

On Thursday, September 22, 2011 20:17:33 Graeme Russ wrote:
> 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?

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.

> 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?

look at doc/README.drivers.eth.  this should cover the eth layer (not PHY).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110922/9e755ee1/attachment.pgp 

[U-Boot] Question: Information regarding MII and PHY

[Andy Fleming]

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:
>>
>> 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()
>
> 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?


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.


> 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?

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