fec: eth0 keep receiving MII interrupt

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

fec: eth0 keep receiving MII interrupt

3,361件の閲覧回数
hwo
Contributor III

Hi all,

        I have two network cards on board, both are TI DP83848 chip.

The physical connection and layout are quite the same to the doc(imx28_evk_revD_sch.pdf provided by Freescale). Except one chip's physical address is 1, the other one is 3. For some reason, I can't set them to 0 and 1 respectively.

After the kernel booting up, only eth1, namely the PHY chip with address 3 works, and eth0's MAC keeps receiving MII interrupt(MII bit is set in EIR register) whenever the RJ45 is plugged or not.

When trying to ping my Win PC from mx28 side, transmit interrupt can be seen. while receive interrupt can't happen no matter how the ping command executed from both side.

But when changing the two physical addresses to the same (though only one PHY chip can be probed),  the eth0 works. So I think both hardware should be normal.

The connection mode between MAC and PHY is RMII.

Someone knows any possible reasons that cause this issue?

Thanks very much!

-------------------------------------------

cpu: mx287

kernel: 2.6.35.3

ラベル(2)
0 件の賞賛
返信
3 返答(返信)

2,932件の閲覧回数
bpe
NXP Employee
NXP Employee

Repeating MII interrupt means the driver keeps reading or writing on the MII bus. This, to my mind, should never happen.

Anyway, the suggestions are:

1. Use u-Boot mdio command to read and write from/to both your PHYs. Ensure they respond

   correctly.

2. Use Linux ethtool command to inspect your PHY status.

3. Debug your kernel to see why the driver is cycling in MDIO transactions


Have a great day,
Platon

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 件の賞賛
返信

2,932件の閲覧回数
hwo
Contributor III

Thanks for your kind reply, Platon.

I trace the mdio read and write process, which I think is normal. Only repeating mdio read occurs, and it is called by PHY state machine for just changing the physical status between RUNNING and CHANGELINK.

I add a log in the MAC interrupt handler function and read out the contents of EIR register and RDAR register. Turn out to find only MII bit set in EIR and RDAR bit set in RDAR register. So there is room for receiving packets from PHY I think. Why just the MII interrupt shows up, and where's the RXF.

By the way is the CRS_DV signal alone that makes the MAC trigger an RXF interrupt?

One more confusion, eth0 and eth1 both keep a state machine, and do the status changing stuff, why only eth0 has the MII interrupt. According to the description in IMX28RM.pdf, I think the eth1 should also has MII interrupt each time the state machine do the mdio read process.

-----------------------------

Best Regards,

0 件の賞賛
返信

2,932件の閲覧回数
hwo
Contributor III

I capture the packets from pc side, i can see the arp request, and my pc send back the arp reply. The packets bytes are right.

now seems receive process isn't triggered, since mac doesn't see any receive interrupts.

0 件の賞賛
返信