Re: mge, mii/e1000phy

On Wed, Sep 23, 2009 at 08:41:54PM +0200, Kristof Provost wrote:
> On 2009-09-22 16:53:50 (-0700), Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
> > On Tue, Sep 22, 2009 at 11:10:18PM +0200, Kristof Provost wrote:
> > > I've been trying to get CURRENT running on a TS-7800 [1].
> > > It's based around a Marvell Orion SoC, with a Marvell 88E1118 PHY.
> > > 
> > > It boots and tries to do bootpc_init. This fails because there are no
> > > packets coming in or going out. 
> > > 
> > > A few thing's I've noticed:
> > >  - The PHY is misdetected as an 88E1116. Changing sys/dev/mii/miidevs so
> > >    it's detected as the 88E1118 it really is doesn't help.
> > 
> > Please show me the output of "devinfo -rv | grep phy".
> > 
> A little difficult as I need networking to get the root file system.
> Instead I've got the content of the PHY ID 1 & 2 registers:
> mii_id1: 0x0141, mii_id2: 0x0e11
> This seems to translate to a mii_model of 0x21, which corresponds to a
> 'Marvell 88E1116 Gigabit PHY' according to sys/dev/mii/miidevs.
> 

I'm pretty sure the device id for 88E1116 PHY is 0x21. Do you see
printed model number 88E1118 on your hardware? If so I have no idea
why Marvell use the same device id. Do you have access to 88E1118 
HY data sheet?

> > >  - sys/dev/mii/e1000phy.c appears to contain a bug:
> > >    e1000phy_reset performs a switch on MII_MODEL(esc->mii_model) while
> > >    the rest of the code just uses esc->mii_model. This seems to be wrong
> > >    as the cases for 1118 (or 1116) are not triggered. Changing this also
> > >    doesn't appear to help.
> > 
> > It's not a bug. First, I have to see your PHY id to know why you
> > think so.
> > 
> The switch on line 251 in e1000phy.c [1] is the only place the MII_MODEL
> macro is used. The rest of the file (even in an earlier switch in the 
> same function) uses esc->mii_model directly. I've also confirmed the code 
> falls into the default case instead of the case MII_MODEL_MARVELL_E1116 
> as I'd expect (because it detects the PHY as an E1116).
> 
> The esc->mii_model value is already translated by MII_MODEL on line 147.
> 

Ah, you're right, mii_model was already translated. Thanks for
pointing out.

> > >  - Forcing the mge driver to IFM_100_TX (in mge_set_port_serial_control)
> > >    does work. The system manages to acquire a DHCP address. 
> > 
> > Would you also show me the output of "ifconfig -m mge0"?
> > 
> What are you looking for? I can't run ifconfig obviously, but I can
> probably extract the required information with a few strategic printfs.
> 

I wanted to know advertised PHY capabilities as mge(4) explicitly
disabled 1000baseT/half-duplex mode in driver layer. But MV88F5182
data sheet said it supports 1000baseT/half-duplex mode.

> > I'm not author of mge(4) so I'm not familiar with mge(4). But it
> > seems that mge(4) lacks link state change handler. Normally NICs
> > are required to reprogram MAC to match resolved speed/duplex/
> > flow-control of link when it know it established a valid link which
> > is notified from mii(4).
> > 
> If that's the case I'd expect the driver not to work on my Sheevaplug
> either. The only difference I see is the PHY.
> 

Could be, but if you manually set media it reinitializes PHY and it
will call mge_ifmedia_upd() which in turn reinitializes the
controller. I guess this is workaround in mge(4).

> Thanks,
> Kristof
> 
> [1] http://svn.freebsd.org/viewvc/base/head/sys/dev/mii/e1000phy.c?annotate=196366