Re: mge, mii/e1000phy

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.

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

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

Thanks,
Kristof

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