Software loopback with phy 88E1116R and marvell MV78100 gbe

Software loopback with phy 88E1116R and marvell MV78100 gbe

[Paolo Minazzi]

Hi to all,
I have written a low level driver for MV78100 arm board.
All works well.
I have built a physical loopback cable to cross rx and tx to test my
driver and all is good.

I have an other board (with imx6).
On this board I was able to put the PHY (micrel) in loopback mode, so
I do not need a physycal loop. All works well.

I tried to do the same things on 88E1116R, setting the but 14 of reg 0.
But If I do it I lose the link, and the test program does not work.
I tried to force the link in software, but seems the controller send
packets but it is not able to receive them.
Is possibile to do such a software loopback on 88E1116R ?

Thanks in advance,
Paolo Minazzi

Re: Software loopback with phy 88E1116R and marvell MV78100 gbe

[Andrew Lunn]

> I tried to do the same things on 88E1116R, setting the but 14 of reg 0.
> But If I do it I lose the link, and the test program does not work.
> I tried to force the link in software, but seems the controller send
> packets but it is not able to receive them.
> Is possibile to do such a software loopback on 88E1116R ?

Hi Paolo

What you are talking about here is MAC loopback. Packets are looped
back at the MAC level. The copper side will be left idle, and so the
link will be lost. This explains why you are seeing link down..

What you might need to do is extend marvell_update_link() to check if
MAC loopback is happening, and if so, say the link is up.

But this is all a bit questionable. How are you setting the PHY into
loopback? I guess the rest of the stack has no idea this is happening,
in particular the phy state machine. What happens when it comes out of
loopback? How is autoneg kicked off.

You might want to think about the big picture, and how this can be
incorporated into ethtool, and phylib. MAC loopback is pretty much
standard, so you should be able to solve this for all PHYs, not just
Marvell.

	     Andrew

Re: Software loopback with phy 88E1116R and marvell MV78100 gbe

[Paolo Minazzi]

On Thu, Feb 23, 2017 at 11:59 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> I tried to do the same things on 88E1116R, setting the but 14 of reg 0.
>> But If I do it I lose the link, and the test program does not work.
>> I tried to force the link in software, but seems the controller send
>> packets but it is not able to receive them.
>> Is possibile to do such a software loopback on 88E1116R ?
>
> Hi Paolo
>
> What you are talking about here is MAC loopback. Packets are looped
> back at the MAC level. The copper side will be left idle, and so the
> link will be lost. This explains why you are seeing link down..

Hi Andrew,
if I understand correctly there are 3 type of loopback.
[1] loopback at the MAC level
[2] loopback at the phy level
[3] loopback with a physical loopback cable

[1] is enabled programming ethernet registers
[2] is enabled programming the PHY
[3] is done at hardware level with a physical loopback cable

> What you might need to do is extend marvell_update_link() to check if
> MAC loopback is happening, and if so, say the link is up.

I agree. For example some driver  (also marvell driver) check the link before
do a TX. If there is not a good link the TX is dropped.
So I have to force link up with a bit in a register (or hacking the
driver) to permit TX.

> But this is all a bit questionable. How are you setting the PHY into
> loopback? I guess the rest of the stack has no idea this is happening,
> in particular the phy state machine. What happens when it comes out of
> loopback? How is autoneg kicked off.

Tried to set the BIT14 of REG0 (LOOPBACK).
Tried also changing BIT12 of REG0 (autoneg anabled and disabled).
Tried to reset the PHY (BIT15 of REG0).
Nothing works,

I have 3 ethernet different card. With 2 of them I can do the software
loopback, both with MAC and PHY loopback.
With marvell gbe I'm not able. There is not MAC loopback (not
documented). There is only PHY loopback.
The physical loopback (with a cable) works correctly.

> You might want to think about the big picture, and how this can be
> incorporated into ethtool, and phylib. MAC loopback is pretty much
> standard, so you should be able to solve this for all PHYs, not just
> Marvell.

It should be,
Paolo

Re: Software loopback with phy 88E1116R and marvell MV78100 gbe

[Andrew Lunn]

On Thu, Feb 23, 2017 at 12:28:10PM +0100, Paolo Minazzi wrote:
> On Thu, Feb 23, 2017 at 11:59 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> I tried to do the same things on 88E1116R, setting the but 14 of reg 0.
> >> But If I do it I lose the link, and the test program does not work.
> >> I tried to force the link in software, but seems the controller send
> >> packets but it is not able to receive them.
> >> Is possibile to do such a software loopback on 88E1116R ?
> >
> > Hi Paolo
> >
> > What you are talking about here is MAC loopback. Packets are looped
> > back at the MAC level. The copper side will be left idle, and so the
> > link will be lost. This explains why you are seeing link down..
> 
> Hi Andrew,
> if I understand correctly there are 3 type of loopback.
> [1] loopback at the MAC level
> [2] loopback at the phy level
> [3] loopback with a physical loopback cable

Plus there is [4] loopback in the other direction. I.E, everything
received on the copper is sent straight back out the copper.

The PHY datasheet often call [2] above MAC loopback, since what is
receives from the MAC it loops back to the MAC. [4] can be called line
loopback, what comes in on the line is looped back to the line.
 
> [1] is enabled programming ethernet registers
> [2] is enabled programming the PHY
> [3] is done at hardware level with a physical loopback cable
> 
> > What you might need to do is extend marvell_update_link() to check if
> > MAC loopback is happening, and if so, say the link is up.
> 
> I agree. For example some driver  (also marvell driver) check the link before
> do a TX. If there is not a good link the TX is dropped.
> So I have to force link up with a bit in a register (or hacking the
> driver) to permit TX.

Try bit 10, register 16 for the Marvell PHY. This should force the
link up.
 
 Andrew