[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Trimarchi]

Hi,
> On Fri, 22 Feb 2008 12:41:17 +0100
> michael  wrote:
> 
> > Add support for Generic PHY in macb.
> > 
> > Signed-off-by: michael 
> 
> What's a "generic PHY"?
> 

> hskinnemoen at dhcp-252-066:~/git/u-boot/master$ grep -r GENERIC_PHY 
> include/configs
> hskinnemoen at dhcp-252-066:~/git/u-boot/master$ 
> 
> >         if (phy_id == 0xffff) {
> > +#if defined (CONFIG_GENERIC_PHY)
> > +               printf("%s: Using the Generic PHY\n", netdev->name);
> > +#else
> >                 printf("%s: No PHY present\n", netdev->name);
> >                 return 0;
> > +#endif
>
When I read to my id u-boot report 0xffff and fail, but
the device works pretty well skipping this testing. 
If I remember linux report the same issue.

I test it on my board and it works well.

Regards Michael







      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Haavard Skinnemoen]

On Fri, 22 Feb 2008 12:27:48 +0000 (GMT)
Michael Trimarchi <trimarchimichael@yahoo.it> wrote:

> When I read to my id u-boot report 0xffff and fail, but
> the device works pretty well skipping this testing. 
> If I remember linux report the same issue.

Is the MII address of your PHY set correctly?

All MII-capable PHYs should have a working PHYSID1 register. If it
doesn't, something is broken.

So I think the CONFIG_GENERIC_PHY name is misleading -- the test is
generic enough as is. CONFIG_BROKEN_PHY would be better, if there's
really no way to get your PHY to behave.

But note that if MDIO communication isn't working, autonegotiation
won't work, and the speed and duplex settings will most likely be
wrong. So I don't think simply #ifdefing out that sanity check is
really going to solve any problems.

Haavard

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[michael]

Hi
Haavard Skinnemoen wrote:
> On Fri, 22 Feb 2008 12:27:48 +0000 (GMT)
> Michael Trimarchi <trimarchimichael@yahoo.it> wrote:
>
>   
>> When I read to my id u-boot report 0xffff and fail, but
>> the device works pretty well skipping this testing. 
>> If I remember linux report the same issue.
>>     
>
> Is the MII address of your PHY set correctly?
>
> All MII-capable PHYs should have a working PHYSID1 register. If it
> doesn't, something is broken.
>
> So I think the CONFIG_GENERIC_PHY name is misleading -- the test is
> generic enough as is. CONFIG_BROKEN_PHY would be better, if there's
> really no way to get your PHY to behave.
>
> But note that if MDIO communication isn't working, autonegotiation
> won't work, and the speed and duplex settings will most likely be
> wrong. So I don't think simply #ifdefing out that sanity check is
> really going to solve any problems.
>
>   
Yes I know but this is the situation:

- dm9161a
- at91sam9260

When I try to read at phy id it reports 0xffff and linux too.
I suppose that can be related to a broken phy. But seems to be
broken on this read. I think that you have more experience,
do you have an idea?

Regards Michael

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Haavard Skinnemoen]

On Fri, 22 Feb 2008 15:05:52 +0100
michael <trimarchi@gandalf.sssup.it> wrote:

> - dm9161a
> - at91sam9260
> 
> When I try to read at phy id it reports 0xffff and linux too.
> I suppose that can be related to a broken phy. But seems to be
> broken on this read. I think that you have more experience,
> do you have an idea?

According to the data sheet, a read from PHYID1 should return 0x0181 on
this particular PHY. So the PHY seems sane enough, but something is not
working as it should.

There can be several reasons why the PHY doesn't respond:
  * The board code specifies the wrong PHY address. If this is the
    case, the PHY will simply not respond to anything.
  * The board code has not set up the MDIO and MDC I/O pins for use
    by the MACB. If so, the CPU won't toggle these lines as it should,
    and it will probably just see floating signals on the input.
  * The MDIO and/or MDC lines aren't connected to the PHY. If so,
    there's really nothing to do about it except modify the driver to
    use fixed settings instead of asking the PHY about the current
    speed/duplex settings.
  * The PHYAD[4:0] pins on the PHY aren't strapped correctly. The state
    of these pins is latched on powerup and determine the PHY address. A
    combination of pull-ups and pull-downs must be used to specify a
    particular address. IIRC address 0 is special, so you probably
    shouldn't pull all of them down.

Or it could be something else. Hard to say for sure without seeing the
board code and schematics.

I think that if the macb driver only ever sees 0xffff returned from the
PHY it will probably still work, but it will always run at 100 Mbps
full-duplex. So while your patch appears to work, I suspect it will
fail if you plug your device into a switch or hub that doesn't do 100
Mbps full-duplex.

Haavard

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Schwingen]

Haavard Skinnemoen wrote:
> All MII-capable PHYs should have a working PHYSID1 register. If it
> doesn't, something is broken.
>   
It depends - I am not sure if there are PHYs which simply do not 
implement MDIO, but at least for ethernet switches, such chips do exist.
> So I think the CONFIG_GENERIC_PHY name is misleading -- the test is
> generic enough as is. CONFIG_BROKEN_PHY would be better, if there's
> really no way to get your PHY to behave.
>   
Right. Or CONFIG_PHY_NO_MDIO or something like that. This is in the 
direction of CONFIG_MII_ETHSWITCH which is used eg. by AcTux-2 for this 
purpose.
> But note that if MDIO communication isn't working, autonegotiation
> won't work, and the speed and duplex settings will most likely be
> wrong. So I don't think simply #ifdefing out that sanity check is
> really going to solve any problems.
>   
The chip may do autonegotiation by default, however, the MAC driver 
still needs to know about the negotiated speed/duplex, so unless there 
is some board-specific way to read those (eg. by GPIO pins), only one 
speed/duplex will work and all other modes will be broken. This is 
different from the case with the hardwired ethernet switch - in case of 
the switch, we know that the MII port is always running at 100Mbps, 
full-duplex.

cu
Michael

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Haavard Skinnemoen]

On Fri, 22 Feb 2008 16:05:34 +0100
Michael Schwingen <rincewind@discworld.dascon.de> wrote:

> Haavard Skinnemoen wrote:
> > All MII-capable PHYs should have a working PHYSID1 register. If it
> > doesn't, something is broken.
> >   
> It depends - I am not sure if there are PHYs which simply do not 
> implement MDIO, but at least for ethernet switches, such chips do exist.

Right. We might need to add support for such PHYs, but just disabling
the sanity check is far from enough.

In any case, the dm9161a PHY in question does implement MDIO, so it
really should work without any modifications.

> > So I think the CONFIG_GENERIC_PHY name is misleading -- the test is
> > generic enough as is. CONFIG_BROKEN_PHY would be better, if there's
> > really no way to get your PHY to behave.
> >   
> Right. Or CONFIG_PHY_NO_MDIO or something like that. This is in the 
> direction of CONFIG_MII_ETHSWITCH which is used eg. by AcTux-2 for this 
> purpose.

I think U-Boot needs a common PHY layer like Linux has. IIRC someone
suggested the same thing some time ago. There's no point going around
adding the same special-case code to every ethernet driver in the
tree...

> > But note that if MDIO communication isn't working, autonegotiation
> > won't work, and the speed and duplex settings will most likely be
> > wrong. So I don't think simply #ifdefing out that sanity check is
> > really going to solve any problems.
> >   
> The chip may do autonegotiation by default, however, the MAC driver 
> still needs to know about the negotiated speed/duplex, so unless there 
> is some board-specific way to read those (eg. by GPIO pins), only one 
> speed/duplex will work and all other modes will be broken. This is 
> different from the case with the hardwired ethernet switch - in case of 
> the switch, we know that the MII port is always running at 100Mbps, 
> full-duplex.

Hmm...most switches support autonegotiation don't they? If not, what
happens if you plug in in an old computer with a 10Mbps ethernet board?

But I guess we need something equivalent to CONFIG_FIXED_PHY in Linux...

Haavard

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Schwingen]

Haavard Skinnemoen wrote:
> Right. We might need to add support for such PHYs, but just disabling
> the sanity check is far from enough.
>   
Agreed - in the case of a single MII-connected TP PHY, we really need 
working MDIO (or some replacement). For special cases (100BaseF fiber, 
which is always fixed speed and duplex), some equivalent to Linux' fixed 
phy handling would be needed.

>> The chip may do autonegotiation by default, however, the MAC driver 
>> still needs to know about the negotiated speed/duplex, so unless there 
>> is some board-specific way to read those (eg. by GPIO pins), only one 
>> speed/duplex will work and all other modes will be broken. This is 
>> different from the case with the hardwired ethernet switch - in case of 
>> the switch, we know that the MII port is always running at 100Mbps, 
>> full-duplex.
>>     
>
> Hmm...most switches support autonegotiation don't they? If not, what
> happens if you plug in in an old computer with a 10Mbps ethernet board?
>   
The switches support autonegotiation on the TP ports. The internal MII 
port which connects them to the CPU/MAC is usually run at fixed 100Mbps 
full-duplex.

If the switch has MDIO, you can quary the status of the external PHYs - 
however, from the point of the MAC driver, that is useless, you need to 
assume that the MII link is always up, since there is no autonegotiation 
on the MII bus.

Older switches (I have worked with the Marvell M88E6050) do not even 
have MDIO - the MII runs fixed, and the TP ports can either 
autonegotiate, or can be set to fixed 10/100/halfduplex operation using 
strapping pins.

cu
Michael

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Ben Warren]

Haavard Skinnemoen wrote:
> On Fri, 22 Feb 2008 16:05:34 +0100
> Michael Schwingen <rincewind@discworld.dascon.de> wrote:
>
>   
>> Haavard Skinnemoen wrote:
>>     
>>> All MII-capable PHYs should have a working PHYSID1 register. If it
>>> doesn't, something is broken.
>>>   
>>>       
>> It depends - I am not sure if there are PHYs which simply do not 
>> implement MDIO, but at least for ethernet switches, such chips do exist.
>>     
>
> Right. We might need to add support for such PHYs, but just disabling
> the sanity check is far from enough.
>
> In any case, the dm9161a PHY in question does implement MDIO, so it
> really should work without any modifications.
>
>   
>>> So I think the CONFIG_GENERIC_PHY name is misleading -- the test is
>>> generic enough as is. CONFIG_BROKEN_PHY would be better, if there's
>>> really no way to get your PHY to behave.
>>>   
>>>       
>> Right. Or CONFIG_PHY_NO_MDIO or something like that. This is in the 
>> direction of CONFIG_MII_ETHSWITCH which is used eg. by AcTux-2 for this 
>> purpose.
>>     
>
> I think U-Boot needs a common PHY layer like Linux has. IIRC someone
> suggested the same thing some time ago. There's no point going around
> adding the same special-case code to every ethernet driver in the
> tree...
>
>   
Yeah, that's me. I'm working on porting the Linux PHY driver over, but 
have had next to no time in the past few months (had to find a new job 
etc...) I hope to seriously get back into it in the next few days, with 
a goal of the next U-boot release for an initial spin.
>>> But note that if MDIO communication isn't working, autonegotiation
>>> won't work, and the speed and duplex settings will most likely be
>>> wrong. So I don't think simply #ifdefing out that sanity check is
>>> really going to solve any problems.
>>>   
>>>       
>> The chip may do autonegotiation by default, however, the MAC driver 
>> still needs to know about the negotiated speed/duplex, so unless there 
>> is some board-specific way to read those (eg. by GPIO pins), only one 
>> speed/duplex will work and all other modes will be broken. This is 
>> different from the case with the hardwired ethernet switch - in case of 
>> the switch, we know that the MII port is always running at 100Mbps, 
>> full-duplex.
>>     
>
> Hmm...most switches support autonegotiation don't they? If not, what
> happens if you plug in in an old computer with a 10Mbps ethernet board?
>
>   
Some do and some don't. Typically when you connect to a switch via RvMII 
the data rate is set by strap pins or over the control plane, which can 
be MDIO, SPI, or whatever.
> But I guess we need something equivalent to CONFIG_FIXED_PHY in Linux...
>
>   
Yeah
> Haavard
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>   

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Trimarchi]

Hi,
----- Messaggio originale -----
> Da: Haavard Skinnemoen <hskinnemoen@atmel.com>
> A: Michael Trimarchi <trimarchimichael@yahoo.it>
> Cc: Michael Schwingen <rincewind@discworld.dascon.de>; u-boot-users at lists.sourceforge.net
> Inviato: Venerd? 22 febbraio 2008, 17:08:56
> Oggetto: Re: [U-Boot-Users] [PATCH] Add support for Generic PHY in macb
> 
> On Fri, 22 Feb 2008 16:02:13 +0000 (GMT)
> Michael Trimarchi  wrote:
> 
> > > In any case, the dm9161a PHY in question does implement MDIO, so it
> > > really should work without any modifications.
> > >   
> > Maybe we can add the for cycle like in linux to check the phy addr?
> 
> 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...
> 
> Haavard
>
But the u-boot user may to choice to use the automatic detection, based on
phy_id mask and stop the search on the first one, or somenthing like this.

Michael

 




      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Ben Warren]

Michael Trimarchi wrote:
> Hi,
> ----- Messaggio originale -----
>   
>> Da: Haavard Skinnemoen <hskinnemoen@atmel.com>
>> A: Michael Trimarchi <trimarchimichael@yahoo.it>
>> Cc: Michael Schwingen <rincewind@discworld.dascon.de>; u-boot-users at lists.sourceforge.net
>> Inviato: Venerd? 22 febbraio 2008, 17:08:56
>> Oggetto: Re: [U-Boot-Users] [PATCH] Add support for Generic PHY in macb
>>
>> On Fri, 22 Feb 2008 16:02:13 +0000 (GMT)
>> Michael Trimarchi  wrote:
>>
>>     
>>>> In any case, the dm9161a PHY in question does implement MDIO, so it
>>>> really should work without any modifications.
>>>>   
>>>>         
>>> Maybe we can add the for cycle like in linux to check the phy addr?
>>>       
>> 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...
>>
>> Haavard
>>
>>     
> But the u-boot user may to choice to use the automatic detection, based on
> phy_id mask and stop the search on the first one, or somenthing like this.
>
> Michael
>   
I don't follow why you'd want to do this.  As Andy, Haavard and others 
have pointed out, you can't probe for PHY addresses because quite often 
multiple ports will share an MDIO bus, and also it's unreliable at 
best.  Anybody who writes U-boot code needs to know the details of his 
or her board, and PHY addresses are always fixed in hardware.  There may 
be some reason to make them dynamic, but I can't imagine why.

regards,
Ben

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Trimarchi]

Hi

----- Messaggio originale -----
> Da: Haavard Skinnemoen <hskinnemoen@atmel.com>
> A: Michael Schwingen <rincewind@discworld.dascon.de>
> Cc: Michael Trimarchi <trimarchimichael@yahoo.it>; u-boot-users at lists.sourceforge.net
> Inviato: Venerd? 22 febbraio 2008, 16:34:03
> Oggetto: Re: [U-Boot-Users] [PATCH] Add support for Generic PHY in macb
> 
> On Fri, 22 Feb 2008 16:05:34 +0100
> Michael Schwingen  wrote:
> 
> > Haavard Skinnemoen wrote:
> > > All MII-capable PHYs should have a working PHYSID1 register. If it
> > > doesn't, something is broken.
> > >   
> > It depends - I am not sure if there are PHYs which simply do not 
> > implement MDIO, but at least for ethernet switches, such chips do exist.
> 
> Right. We might need to add support for such PHYs, but just disabling
> the sanity check is far from enough.
> 
> In any case, the dm9161a PHY in question does implement MDIO, so it
> really should work without any modifications.
> 
Maybe we can add the for cycle like in linux to check the phy addr?

Michael





      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Haavard Skinnemoen]

On Fri, 22 Feb 2008 16:02:13 +0000 (GMT)
Michael Trimarchi <trimarchimichael@yahoo.it> wrote:

> > In any case, the dm9161a PHY in question does implement MDIO, so it
> > really should work without any modifications.
> >   
> Maybe we can add the for cycle like in linux to check the phy addr?

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

Haavard

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Schwingen]

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

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[michael]

Hi,

Haavard Skinnemoen wrote:
> On Fri, 22 Feb 2008 16:02:13 +0000 (GMT)
> Michael Trimarchi <trimarchimichael@yahoo.it> wrote:
>
>   
>>> In any case, the dm9161a PHY in question does implement MDIO, so it
>>> really should work without any modifications.
>>>   
>>>       
>> Maybe we can add the for cycle like in linux to check the phy addr?
>>     
>
> 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...
>   
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.

Regards Michael

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Schwingen]

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

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[trimarchi at gandalf.sssup.it]

Hi
Quoting Michael Schwingen <rincewind@discworld.dascon.de>:

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

Regards Michael


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Schwingen]

trimarchi at 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

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[trimarchi at gandalf.sssup.it]

Quoting Michael Schwingen <rincewind@discworld.dascon.de>:

> trimarchi at 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.

Ok, thanks

Regards Michael


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Andy Fleming]

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

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Trimarchi]

Hi,
----- Messaggio originale -----
> Da: Haavard Skinnemoen <hskinnemoen@atmel.com>
> A: Michael Trimarchi <trimarchimichael@yahoo.it>
> Cc: michael <trimarchi@gandalf.sssup.it>; u-boot-users at lists.sourceforge.net
> Inviato: Venerd? 22 febbraio 2008, 13:52:09
> Oggetto: Re: [U-Boot-Users] [PATCH] Add support for Generic PHY in macb
> 
> On Fri, 22 Feb 2008 12:27:48 +0000 (GMT)
> Michael Trimarchi  wrote:
> 
> > When I read to my id u-boot report 0xffff and fail, but
> > the device works pretty well skipping this testing. 
> > If I remember linux report the same issue.
> 
> Is the MII address of your PHY set correctly?
> 
> All MII-capable PHYs should have a working PHYSID1 register. If it
> doesn't, something is broken.
> 
> So I think the CONFIG_GENERIC_PHY name is misleading -- the test is
> generic enough as is. CONFIG_BROKEN_PHY would be better, if there's
> really no way to get your PHY to behave.
> 
> But note that if MDIO communication isn't working, autonegotiation
> won't work, and the speed and duplex settings will most likely be
> wrong. So I don't think simply #ifdefing out that sanity check is
> really going to solve any problems.
> 
> Haavard
>
Yes I know but this is the situation:

- dm9161a
- at91sam9260 

When I try to read at phy id it reports 0xffff and linux too.
I suppose that can be related to a broken phy. But seems to be
broken on this read. I think that you have more experience,
do you have an idea?

Regards Michael






      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Michael Trimarchi]

Hi,
> 
> >         if (phy_id == 0xffff) {
> > +#if defined (CONFIG_GENERIC_PHY)
> > +               printf("%s: Using the Generic PHY\n", netdev->name);
> > +#else
> >                 printf("%s: No PHY present\n", netdev->name);
> >                 return 0;
> > +#endif
> 
> You mean a PHY that isn't actually hooked up?
> 
The CONFIG_GENERIC_PHY is not u-boot option currently.
This patch is a proposal.

Regards Michael





      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[michael]

Add support for Generic PHY in macb.

Signed-off-by: michael <trimarchi@gandalf.sssup.it>

---
 drivers/net/macb.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 9c98338..2a6fc5d 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -330,8 +330,12 @@ static int macb_phy_init(struct macb_device *macb)
        /* Check if the PHY is up to snuff... */
        phy_id = macb_mdio_read(macb, MII_PHYSID1);
        if (phy_id == 0xffff) {
+#if defined (CONFIG_GENERIC_PHY)
+               printf("%s: Using the Generic PHY\n", netdev->name);
+#else
                printf("%s: No PHY present\n", netdev->name);
                return 0;
+#endif
        }

        status = macb_mdio_read(macb, MII_BMSR);
--

[U-Boot-Users] [PATCH] Add support for Generic PHY in macb

[Haavard Skinnemoen]

On Fri, 22 Feb 2008 12:41:17 +0100
michael <trimarchi@gandalf.sssup.it> wrote:

> Add support for Generic PHY in macb.
> 
> Signed-off-by: michael <trimarchi@gandalf.sssup.it>

What's a "generic PHY"?

hskinnemoen at dhcp-252-066:~/git/u-boot/master$ grep -r GENERIC_PHY include/configs
hskinnemoen at dhcp-252-066:~/git/u-boot/master$ 

>         if (phy_id == 0xffff) {
> +#if defined (CONFIG_GENERIC_PHY)
> +               printf("%s: Using the Generic PHY\n", netdev->name);
> +#else
>                 printf("%s: No PHY present\n", netdev->name);
>                 return 0;
> +#endif

You mean a PHY that isn't actually hooked up?

Haavard