[U-Boot-Users] MII / RMII
Hi,
1. Does it make sense at all to define CONFIG_RMII without defining CONFIG_MII? The question is meant not really theoretical as in what meaning RMII has, rather how the macro CONFIG_RMII is supposed to be used? For example, tests like
#if defined(CONFIG_MII) && defined(CONFIG_RMII)
isn't checking for CONFIG_MII redundant?
2. cpu/at32ap/at32ap7000/gpio.c also tests CONFIG_RMII. at32ap is an AVR32 CPU and this macro is only defined in a few MPC8XX configurations, so, this test doesn't seem to make much sense in the current tree.
3. drivers/qe/uec_phy.c tests CONFIG_RMII_MODE, which doesn't occur anywhere else in the tree. The driver is enabled in some MPC85xx and MPC83xx configs.
4. drivers/macb.c tests for "RMII or MII mode" by jest checking
#ifdef CONFIG_RMII ... #else ... #endif
i.e., not for
#elif defined CONFIG_MII
This driver is only enabled in include/configs/atstk1002.h, which is also an AVR32 config, and it neither defines MII nor RMII.
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D.
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
Hi Guennadi,
Guennadi Liakhovetski wrote:
Hi,
- Does it make sense at all to define CONFIG_RMII without defining
CONFIG_MII? The question is meant not really theoretical as in what meaning RMII has, rather how the macro CONFIG_RMII is supposed to be used? For example, tests like
#if defined(CONFIG_MII) && defined(CONFIG_RMII)
isn't checking for CONFIG_MII redundant?
I wouldn't say it's redundant, but that's only because I think both are stupid. Neither of these CONFIGs should be generalized, since they are inherently hardware dependent. RMII vs. MII is a data plane hardware decision, and the only relevant software is typically a small amount of code that sets a register in the Ethernet controller for the proper bus.
- cpu/at32ap/at32ap7000/gpio.c also tests CONFIG_RMII. at32ap is an AVR32
CPU and this macro is only defined in a few MPC8XX configurations, so, this test doesn't seem to make much sense in the current tree.
- drivers/qe/uec_phy.c tests CONFIG_RMII_MODE, which doesn't occur
anywhere else in the tree. The driver is enabled in some MPC85xx and MPC83xx configs.
- drivers/macb.c tests for "RMII or MII mode" by jest checking
#ifdef CONFIG_RMII ... #else ... #endif
i.e., not for
#elif defined CONFIG_MII
This driver is only enabled in include/configs/atstk1002.h, which is also an AVR32 config, and it neither defines MII nor RMII.
Yeah, see how the meaning is interpreted differently by each controller driver? CONFIG_RMII and CONFIG_MII make about as much sense as Wookies on Endor. It would be better to have:
CONFIG_MACB_MODE_MII and CONFIG_MACB_MODE_RMII etc.
Add multiple interfaces with different connections (e.g. controller 1 is connected MII and controller 2 is RMII) and then what?
Something else I've noticed: Almost everywhere that CONFIG_MII is tested, it's done like this:
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
Looks like maybe something's not needed...
Anyway, the entire Ethernet driver structure is ripe for a refactoring, to use a cheesy software engineering term. Since it's becoming very common to have more than one Ethernet controller on a board, I think we need to move more toward defining features on a per-port basis.
Thanks Guennadi
Guennadi Liakhovetski, Ph.D.
regards, Ben
On Thu, 29 Nov 2007 15:31:51 -0500 Ben Warren bwarren@qstreams.com wrote:
Yeah, see how the meaning is interpreted differently by each controller driver? CONFIG_RMII and CONFIG_MII make about as much sense as Wookies on Endor. It would be better to have:
CONFIG_MACB_MODE_MII and CONFIG_MACB_MODE_RMII etc.
Add multiple interfaces with different connections (e.g. controller 1 is connected MII and controller 2 is RMII) and then what?
Good point. I'll see if I can add an "is_rmii" parameter to macb_eth_initialize() instead. This function is called from board code, so there shouldn't be any problems to figure out what the parameter should be.
Btw, I've been looking around in the tree lately as well. Why do we need four(!) SPI APIs?
Haavard
tor 2007-11-29 klockan 19:51 +0100 skrev Guennadi Liakhovetski:
Hi,
- Does it make sense at all to define CONFIG_RMII without defining
CONFIG_MII? The question is meant not really theoretical as in what meaning RMII has, rather how the macro CONFIG_RMII is supposed to be used? For example, tests like
I think that if you use an Ethernet and need to differentiate between MII and RMII they should be mutually exclusive. You either define CONFIG_RMII OR CONFIG_MII but not both. If you have a PHY on the chip, then you do not define any of the two. MII uses more pins and maybe different pins, so a port for a CPU should differentiate. If only RMII is supported by existing boards, then the driver could be written in a sloppy way and hardwire the RMII configuration without using CONFIG_RMII. Did not check the drivers so I can't tell.
#if defined(CONFIG_MII) && defined(CONFIG_RMII)
isn't checking for CONFIG_MII redundant?
- cpu/at32ap/at32ap7000/gpio.c also tests CONFIG_RMII. at32ap is an AVR32
CPU and this macro is only defined in a few MPC8XX configurations, so, this test doesn't seem to make much sense in the current tree.
- drivers/qe/uec_phy.c tests CONFIG_RMII_MODE, which doesn't occur
anywhere else in the tree. The driver is enabled in some MPC85xx and MPC83xx configs.
- drivers/macb.c tests for "RMII or MII mode" by jest checking
#ifdef CONFIG_RMII ... #else ... #endif
i.e., not for
#elif defined CONFIG_MII
This driver is only enabled in include/configs/atstk1002.h, which is also an AVR32 config, and it neither defines MII nor RMII.
Thanks Guennadi
Guennadi Liakhovetski, Ph.D.
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Ulf Samuelsson wrote:
tor 2007-11-29 klockan 19:51 +0100 skrev Guennadi Liakhovetski:
Hi,
- Does it make sense at all to define CONFIG_RMII without defining
CONFIG_MII? The question is meant not really theoretical as in what meaning RMII has, rather how the macro CONFIG_RMII is supposed to be used? For example, tests like
I think that if you use an Ethernet and need to differentiate between MII and RMII they should be mutually exclusive. You either define CONFIG_RMII OR CONFIG_MII but not both. If you have a PHY on the chip, then you do not define any of the two.
Not quite. I've argued that both CONFIG_MII and CONFIG_RMII are pointless, but if they did have a purpose it would be to set up the link between a MAC and a PHY on the MAC side. The bottom line is that if CONFIGs like this are going to be used for hardware initialization they need to be much more specific.
regards, Ben
Ulf Samuelsson wrote:
tor 2007-11-29 klockan 19:51 +0100 skrev Guennadi Liakhovetski:
Hi,
- Does it make sense at all to define CONFIG_RMII without defining
CONFIG_MII? The question is meant not really theoretical as in what meaning RMII has, rather how the macro CONFIG_RMII is supposed to be used? For example, tests like
I think that if you use an Ethernet and need to differentiate between MII and RMII they should be mutually exclusive. You either define CONFIG_RMII OR CONFIG_MII but not both. If you have a PHY on the chip, then you do not define any of the two.
Not quite. I've argued that both CONFIG_MII and CONFIG_RMII are pointless, but if they did have a purpose it would be to set up the link between a MAC and a PHY on the MAC side. The bottom line is that if CONFIGs like this are going to be used for hardware initialization they need to be much more specific.
You need to know which PHY you are going to use, and you need to know if you are going to connect using RMII or MII so you need to have some kind of configuration. Once the configuration for MII/RMII is known, then each chip driver will have a very few things which can vary.
I think the pin multiplexing is the key thing that could be controlled by these things.
Each chip will have limited
regards, Ben
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
On 11/29/07, Ulf Samuelsson ulf@atmel.com wrote:
tor 2007-11-29 klockan 19:51 +0100 skrev Guennadi Liakhovetski:
Hi,
- Does it make sense at all to define CONFIG_RMII without defining
CONFIG_MII? The question is meant not really theoretical as in what meaning RMII has, rather how the macro CONFIG_RMII is supposed to be
used?
For example, tests like
I think that if you use an Ethernet and need to differentiate between MII and RMII they should be mutually exclusive. You either define CONFIG_RMII OR CONFIG_MII but not both. If you have a PHY on the chip, then you do not define any of the two. MII uses more pins and maybe different pins, so a port for a CPU should differentiate.
I'm a little late to this, but I feel I should make sure people are aware that CONFIG_MII and CONFIG_RMII are not, in this case, two different options for the same concept. CONFIG_MII is the option you enable to allow MII Management operations to be done. It should *probably* be called CONFIG_MDIO. You'll see this problem all over the place. MII is the name for the data interface between a PHY and a 10/100 ethernet controller. MDIO is the management interface for MII-compliant PHYs. But it's frequently called the MII Management interface.
RMII is a different data interface for PHYs, but it uses the same MDIO interface.
So I believe if you see: #if defined(CONFIG_MII) && defined(CONFIG_RMII), what you are seeing is a check for global mii management capability as well as board-specific reduced interface selection.
As to whether one or more of these definitions is poorly named, I leave that as an exercise for the reader. ;)
Andy
On Tuesday 08 January 2008, Andy Fleming wrote:
I think that if you use an Ethernet and need to differentiate between MII and RMII they should be mutually exclusive. You either define CONFIG_RMII OR CONFIG_MII but not both. If you have a PHY on the chip, then you do not define any of the two. MII uses more pins and maybe different pins, so a port for a CPU should differentiate.
I'm a little late to this, but I feel I should make sure people are aware that CONFIG_MII and CONFIG_RMII are not, in this case, two different options for the same concept. CONFIG_MII is the option you enable to allow MII Management operations to be done. It should *probably* be called CONFIG_MDIO.
Yes, this would be good. Anyone interested in fixing up a patch for this?
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Stefan Roese wrote:
On Tuesday 08 January 2008, Andy Fleming wrote:
I think that if you use an Ethernet and need to differentiate between MII and RMII they should be mutually exclusive. You either define CONFIG_RMII OR CONFIG_MII but not both. If you have a PHY on the chip, then you do not define any of the two. MII uses more pins and maybe different pins, so a port for a CPU should differentiate.
I'm a little late to this, but I feel I should make sure people are aware that CONFIG_MII and CONFIG_RMII are not, in this case, two different options for the same concept. CONFIG_MII is the option you enable to allow MII Management operations to be done. It should *probably* be called CONFIG_MDIO.
Yes, this would be good. Anyone interested in fixing up a patch for this?
I think it's a noble idea, but probably a can of worms in practice. The use of the term 'MII' is rampant, for example we have 'mii' commands, and 'bbmii' commands. These both really concern MDIO, but I doubt we want to change them.
The real culprit is RMII. As Andy has pointed out, RMII is a data plane alternative to MII, but shares the MDIO control plane. RMII is a hardware configuration, and as such is 'set and forget' and highly implementation-specific. Having a global CONFIG_RMII makes no sense. If anything, CONFIG_RMII should be changed to stuff like CONFIG_TSEC_RMII_2 etc. (a quickly made-up example with no grounding in reality), where the hardware binding is obvious.
regards, Ben
participants (7)
-
Andy Fleming -
Ben Warren -
Ben Warren -
Guennadi Liakhovetski -
Haavard Skinnemoen -
Stefan Roese -
Ulf Samuelsson