[U-Boot-Users] MII / RMII

[U-Boot-Users] MII / RMII

[Guennadi Liakhovetski]

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 at denx.de

[U-Boot-Users] MII / RMII

[Ben Warren]

Hi Guennadi,

Guennadi Liakhovetski wrote:
> 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?
>
>   
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.
> 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.
>
>   
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

[U-Boot-Users] MII / RMII

[Haavard Skinnemoen]

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

[U-Boot-Users] MII / RMII

[Ulf Samuelsson]

tor 2007-11-29 klockan 19:51 +0100 skrev Guennadi Liakhovetski:
> 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
> 

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?
> 
> 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
-- 
Best Regards
Ulf Samuelsson

[U-Boot-Users] MII / RMII

[Ben Warren]

Ulf Samuelsson wrote:
> tor 2007-11-29 klockan 19:51 +0100 skrev Guennadi Liakhovetski:
>   
>> 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
>>
>>     
>
> 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

[U-Boot-Users] MII / RMII

[Ulf Samuelsson]

> Ulf Samuelsson wrote:
>> tor 2007-11-29 klockan 19:51 +0100 skrev Guennadi Liakhovetski:
>>   
>>> 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
>>>
>>>     
>>
>> 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 at 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

[U-Boot-Users] MII / RMII

[Andy Fleming]

On 11/29/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>
> tor 2007-11-29 klockan 19:51 +0100 skrev Guennadi Liakhovetski:
> > 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
> >
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080107/f40b014e/attachment.htm 

[U-Boot-Users] MII / RMII

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot-Users] MII / RMII

[Ben Warren]

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