2011-04-07 19:58:39     Reading the Status of Ethernet MAC TXCLK and RXCLK

Document created by Aaronwu Employee on Aug 26, 2013
Version 1Show Document
  • View in full screen mode

2011-04-07 19:58:39     Reading the Status of Ethernet MAC TXCLK and RXCLK

Pawel Pastuszak (CANADA)

Message: 99661   

 

Hello,

 

 

 

I have an odd request i would like to monitor the TXCLK or RXCLK to see it still active? At least i couldn't see anyway to do this in the bfin_mac.c driver so i asking which register value can i read to determine if there is and valid clock or RXCLK/TXCLK?

 

 

 

Note this is for BF537 rev 3.

 

 

 

Thanks,

 

Pawel

QuoteReplyEditDelete

 

 

2011-04-07 20:16:01     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Mike Frysinger (UNITED STATES)

Message: 99662   

 

for development or production ?

 

the former is trivial to do with /sys/kernel/debug/blackfin/ and the Debug MMRs kconfig option:

  docs.blackfin.uclinux.org/doku.php?id=linux-kernel:debug

QuoteReplyEditDelete

 

 

2011-04-07 20:30:22     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Pawel Pastuszak (CANADA)

Message: 99663   

 

For production,  let me give you little bit more background i have an  5 port switch and the link from the switch to the cpu has an relay and in production and secure mode the relay is disable which cuts the clock's to the switch and i trying to monitor for secure reason i want to monitor the state of the clock lines.

QuoteReplyEditDelete

 

 

2011-04-07 21:37:46     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Mike Frysinger (UNITED STATES)

Message: 99664   

 

so you want to set the pins to GPIO inputs and read their levels ?  once the bfin_mac driver has started up, you wont be able to do that since they get reserved as peripherals.

 

do you need to just sense it once at boot ?  or sense it every once in a while at runtime ?  for boot, you could add to your board code some logic to grab the pin as a GPIO, read the levels, and then save the result in a variable before releasing the pin for the bfin_mac driver to grab ...

 

i'm not terribly familiar with the emac block, but i dont think you can read either CLK on the fly via the peripheral itself.

 

what about the PHYs ?  can you poke them over the MII bus ?  that should be doable at runtime with the bfin_mac driver loaded and active ...

QuoteReplyEditDelete

 

 

2011-04-07 21:52:56     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Pawel Pastuszak (CANADA)

Message: 99666   

 

I would like to read the status of the line are runtime probe it every couple mintues while i need still to have bfin_mac working.

 

The problem at looking at PHY is that on the Marvell switch the goes to the CPU you can determine if there is valid status because it run's in MII mode.

 

Note the Line that are hook up to the relay are:

 

PH5_ETH_MII_TXCLK

 

PH0_ETH_MII_TXD0

 

PH1_ETH_MII_TXD1

 

PH2_ETH_MII_TXD2

 

PH3_ETH_MII_TXD4

 

PH5_ETH_MII_TXDEN

 

PH13_ETH_MII_RXCLK

 

PH8_ETH_MII_RXD0

 

PH9_ETH_MII_RXD1

 

PH10_ETH_MII_RXD2

 

PH11_ETH_MII_RXD3

 

PH12_ETH_MII_RXDV

 

PH15_ETH_MII_CRS

 

PH7_ETH_MII_COL

 

 

 

What i look for is detect if the clock goes down or maybe an error happing on the bus when the line go dead what would happen to the RX intrrupt would an Error be raised/set? If so that would be something i can read saying error and then when link get restored back and the error get clear... any thoughts?

 

 

 

Pawel

QuoteReplyEditDelete

 

 

2011-04-07 22:02:39     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Mike Frysinger (UNITED STATES)

Message: 99667   

 

iow, all the emac mii pins run to the relay.  so it looks like:

cpu <-> relay <-> switch <-> phys

 

i dont know if there are any status bits which could be used to differentiate between dead clock and general transmit/receive errors.  so watching those statistics would be susceptible to general packet errors.

 

i'm not sure if there is an answer here that involves software only.  what if you additionally ran one of the clocks to an unused GPIO pin ?  you could then independently read that pin at any time.

QuoteReplyEditDelete

 

 

2011-04-07 22:14:07     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Pawel Pastuszak (CANADA)

Message: 99668   

 

Yes that correct.

 

cpu <-> relay <-> switch <-> phys

 

I tried  generating a RAW Socket RARP and it does seems to generate an error but it also cause the blackfin to uses 50% cpu because it timing out and then latter after time i get odd behavouirs with the socket ~  20 mintues after running  at 1 mintue per send the ARAP the socket goes dead and sendto fails and never recovers till you close and reopen the socket.

 

So this is also why i am going to plan b now.

 

Now the GPIO idea sounds great but i am 100% sure hardware guys will not allow me to change the hardware design at this point is little bit late.

 

 

 

 

 

Pawel

QuoteReplyEditDelete

 

 

2011-04-07 22:20:17     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Mike Frysinger (UNITED STATES)

Message: 99670   

 

well, it seems like a no brainer ... the hardware team nowadays exist to make software integration simpler.  if your product sucks because you're forced to expend an inordinate of overhead in software to workaround deficiencies in the hardware, then the hardware should be fixed.

 

i can ask some people if they have any ideas.

 

i'm guessing that you want to keep userspace connections alive ?  so bringing down the interface isnt an acceptable solution ?

QuoteReplyEditDelete

 

 

2011-04-07 22:30:37     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Pawel Pastuszak (CANADA)

Message: 99671   

 

That would be great.

 

 

 

Yes i do need the interface to be still up in userspace, the solution of check could be in kernel or user space if kernel i would just  create and userspace access method not a big deal.

 

Yes that correct bring up and down the inferface is not acceptiable because i also monitor the phy ports because trafic is running on the switch but it's not allowed to talk to the cpu.

 

 

 

Pawel

QuoteReplyEditDelete

 

 

2011-04-07 22:48:34     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Mike Frysinger (UNITED STATES)

Message: 99673   

 

when i suggested reading the PHY, it wasnt so much literally reading the PHY.  it was to get traffic onto the MII bus.

 

so if there's a known PHY and a simple status register you could quickly read when the relay is up, but you'll get a timeout when the relay is down, i think that satisfies your informational demand.

 

ethtool for example should be able to query PHY registers directly from userspace.  you can see what ioctl's that uses by stracing it.

QuoteReplyEditDelete

 

 

2011-04-07 23:09:16     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Pawel Pastuszak (CANADA)

Message: 99674   

 

I believe reading the PHY register's uses MDIO and MDC lines which are not on the relay. Which means it works all the time.

QuoteReplyEditDelete

 

 

2011-04-11 14:30:02     Re: Reading the Status of Ethernet MAC TXCLK and RXCLK

Mike Frysinger (UNITED STATES)

Message: 99761   

 

the BF537 has an undocumented feature, at least on PORT F.  even in peripheral mode, the lines can be sensed by simply reading the PORTF data register.  some people use this hack to sense the level of SPORT pins while using the pins in peripheral mode.

 

you could have a try with the PORTH data register and see if it works too.

Attachments

    Outcomes