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

Ben Warren biggerbadderben at gmail.com
Tue Feb 26 02:23:29 CET 2008


Haavard Skinnemoen wrote:
> On Fri, 22 Feb 2008 16:05:34 +0100
> Michael Schwingen <rincewind at 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
>
>   





More information about the U-Boot mailing list