Message-ID: <5AB0CE14.3307.431B163E@Frantisek.Rysanek.post.cz>
Date:   Tue, 20 Mar 2018 10:02:12 +0100
From:   "Frantisek Rysanek" <Frantisek.Rysanek@...t.cz>
To:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

On 18 Mar 2018 at 15:40, Andrew Lunn wrote:
> > I'm not getting an ACK from the SFP, probably because I've got the 
> > address and offset wrong and because I'd better use indirect access.
> > There's some more work awaiting me...
> 
> Try address 0x50.
> 
> i2detect will probe all addresses for you, if you have a standard
> Linux i2c bus.
> 
Thanks for that pointer, that has helped :-)

Not sure if the HW-driven i2c in the i210 works right or not.
It seems to read some garbage instead of MII Dev ID,
and even if I hack that in as a recognized ID, it then
fails at some later stage of init. I have to get back to this later.
After I got the bit-banging I2c to work (see below), the few values 
that I see coming out of the HW-driven i2c are possibly "obtained 
correctly" too.


I've managed to get far enough in the init to make the netdevice
surface in the OS. 
And, at the end of the process, the bit-banging i2c interface also 
appears as /dev/i2c-8 (in my case - after all the graphics DDC busses 
and whatnot).
And, I've modded the existing bit-banging callbacks in igb_main.c,
supposedly written for the i350. I'm wondering if they've ever worked 
right in the first place... I seem to have confirmed my earlier vague 
impression, that the "set" functions would drive the output hard to 
log.1, instead of letting it "float up" based on the pull up resistor
(go high-Z).

[CODE SNIPPET]

static void igb_set_i2c_data(void *data, int state)
{
   struct igb_adapter *adapter = (struct igb_adapter *)data;
   struct e1000_hw *hw = &adapter->hw;
   s32 i2cctl = rd32(E1000_I2CPARAMS);

   /* 
// original version
   if (state)
      i2cctl |= E1000_I2C_DATA_OUT;
   else
      i2cctl &= ~E1000_I2C_DATA_OUT;

   i2cctl &= ~E1000_I2C_DATA_OE_N;

   i2cctl |= E1000_I2C_CLK_OE_N;
   */

// my replacement
   if (state) {
      i2cctl |= E1000_I2C_DATA_OE_N;  // high Z for SDA
      i2cctl |= E1000_I2C_DATA_OUT;   // redundant, but ahh well
   }
   else {
      i2cctl &= ~E1000_I2C_DATA_OE_N; // SDA output active
      i2cctl &= ~E1000_I2C_DATA_OUT;  // log.0 on SDA output
   }

// this stays the same:
   wr32(E1000_I2CPARAMS, i2cctl);
   wrfl();
}

[/CODE SNIPPET]

Same thing for the SCL pin.
The master must drive the bus using an open collector, rather than a 
full totem - so that the slave can have her say (ACK, return data, 
extend the clock maybe). Not sure if the i210's HW i2c master does 
this right, and if it supports all the needed transaction formats 
etc.

After this mod, the user-space i2c progies started to work on 
/dev/i2c-8. I mean - I'd seen activity on the 'scope earlier,
but it was all failures.

I should probably turn this into a patch, but the same is true about 
the rest of what I'm doing to the driver code, and currently it's not 
nice :-) Once I get to the bottom of it (if I ever do) I'll have to 
start over from scratch = from pristine original IGB code, insert the 
needed mods (observing coding style), comment them properly and 
*then* take a diff...


And I got a little further.
I'm attaching two text files, containing the dumps of i2cdetect and 
eeprog (modified by me *not* to exit on error, just try another 
byte). 

The i2cdetect succeeds even with a simple "read byte" transaction 
(just two bytes on the bus).

The "eeprog" uses an SMbus-style indirect read with an 8bit address.
This consists of two low-level i2c transactions: 
"write byte" followed by a "read byte".
The first transaction sets the offset inside the slave, 
the second transaction reads back actual data.

Again I have two SFP's, both of them "3rd-party Chinese", one sold as 
Huawei-compatible, the other one as Cisco-compatible. Not sure to 
what extent this is true :-)

i2cdetect has found three i2c slaves (identical layout in both SFP's) 
at addresses 0x50, 0x51 and 0x56.
What are they? EEPROM, DDM and "MDIO over i2c" ?
The SFP's likely lack a proper SFP MSA data structure.

The second SFP ("Cisco-compatible") behaves somewhat special at 0x56. 

eeprog just calls the "SMbus read 1 byte from offset at slave" 
iteratively across the "space of offsets".
I.e. every offset gets an independent transaction, 1 byte long.
Now... if I unleash this iteration unto i2c slave 0x56, then every 
other byte (every odd byte = every odd offset) ends up in a 
"transaction error".
I had to hack eeprog to just ignore these errors and print XX instead 
of data in the hex dump.

I went on to investigate further - I tried reading single bytes.
If I start at an even offset, such as 0 or 8, and I read that single 
offset (byte) twice, i.e. two separate and complete SMbus 
transactions, that succeeds, the two values returned are different 
from each other, and I can read another offset without an error.
But, if I read an offset just once, and then try a different offset, 
I get an error on the second offset. And even/odd offsets don't 
really matter - I can read an odd offset just fine, as long as I read 
any/every offset *twice*.

And, it gets more interesting if I look at the 'scope.
I'm attaching some screenshots of the failed transaction.

As already briefly mentioned, the healthy SMbus "read byte" 
transaction consists of two separate i2c sub-transactions:

[START][7bit slave addr][WRITE][ACK][REPST][8bit offset][ACK][STOP]
[START][7bit slave addr][READ][ACK][REPST][8bit data][NAK][STOP]

The error (if I break the rule that I have to read every offset 
twice) looks like this: 

[START][7bit slave addr][WRITE][ACK] [8bit offset][NAK][STOP]
(and the second sub-transaction is not attempted by the master).

= already the first sub-transaction gets NACKed.

This kind of rings a bell, in that the MII PHY registers are 16 bits 
each. Is this a plausible correlation?

This is making me wonder if I should use some other transaction 
format. Read one more byte? There's a transaction called "SMBus read 
word" which does exactly that. 
Except that "read word" wouldn't do, I cannot read another byte after 
a NAK. Same thing with "SMBus read block data". Apparently the
appropriate transaction style is hardwired in the slave, the master
cannot "force" the slave to use a particular transaction style.
Not within that one transaction (maybe somehow "out of band").

Does this make sense as some sort of proprietary standard 
(Cisco, if I should take the vendor's label at face value),
or is this likely some "3rd-party innovation thinko", not worth
implementing?

Frank

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  i2c-detect.txt
     Date:  20 Mar 2018, 6:50
     Size:  1459 bytes.
     Type:  Text

Download attachment "i2c-detect.txt" of type "Application/Octet-stream" (1459 bytes)

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  eeprog.txt
     Date:  20 Mar 2018, 6:49
     Size:  7631 bytes.
     Type:  Text

Download attachment "eeprog.txt" of type "Application/Octet-stream" (7631 bytes)

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  SFP2_1st_subtrans_bad.png
     Date:  20 Mar 2018, 9:32
     Size:  65532 bytes.
     Type:  Unknown

Download attachment "SFP2_1st_subtrans_bad.png" of type "Application/Octet-stream" (65532 bytes)

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  SFP2_1st_subtrans_OK.png
     Date:  20 Mar 2018, 9:29
     Size:  63141 bytes.
     Type:  Unknown

Download attachment "SFP2_1st_subtrans_OK.png" of type "Application/Octet-stream" (63141 bytes)

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  SFP2_whole_trans_bad.png
     Date:  20 Mar 2018, 9:25
     Size:  65050 bytes.
     Type:  Unknown

Download attachment "SFP2_whole_trans_bad.png" of type "Application/Octet-stream" (65050 bytes)

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  SFP2_whole_trans_OK.png
     Date:  20 Mar 2018, 9:23
     Size:  68852 bytes.
     Type:  Unknown

Download attachment "SFP2_whole_trans_OK.png" of type "Application/Octet-stream" (68852 bytes)

Powered by blists - more mailing lists