Hi.
Thinking about this.
The YT8821 datasheet says it supports C22 and C45, but if 0x56 is read only, it makes no sense at all. Making C22 read only, makes C45 over C22 fail to work also. I have also tested C45 over I2C with the YT8821 and the YT8821 does not detect the requests as C45, and interprets them as C22.
ROLLBALL also does not work with the YT8821 as far as my testing has shown (my testing could be flawed). I donât have a PHY that is know to work with ROLLBALL to compare against.
On the BPI-R3 we are bit banging the I2C. What if we changed the DTS to say it was an MDIO GPIO instead, and tried to bit bang MDIO instead of I2C ? Has anyone tried that?
The module has an accompanying ic that does i2c to mdio translation towards the phy. Probably this same ic also implements the function of the i2c eeprom.
* address size contents description
* ------- ---- -------- -----------
* 0x80 1 CMD 0x01/0x02/0x04 for write/read/done
* 0x81 1 DEV Clause 45 device
* 0x82 2 REG Clause 45 register
* 0x84 2 VAL Register value
For a read transaction, do you:
write devad to 0x81
write reg to 0x82/0x83
write ROLLBALL_CMD_READ(2) to 0x80.
poll read 0x80 until you read ROLLBALL_CMD_DONE(4)
read value from 0x84/0x85
The question then becomes how many of the above can be combined into a single i2c_transfer?
If you have multple msg in a transfer, the I2C has a choice to do S at the start, and Sr between msg, or R/S between msg.
My guess is that you write devad and reg in one transfer.
write ROLLBALL_CMD_READ in another transfer. (if you combine devad, reg and ROLLBALL_CMD_READ in a single transfer, can it be in a single msg, or need to be two msg in the transfer?
the poll read in another transfer.
0x56 registers do change, as the cable link negotiates to different speeds, the appropriate MII registers change.
But, 0x56 is fixed at being read only from the CPU I2C side, and thus prevent C45 over C22 MMD access and also prevents YT8821 vendor specific access over MII 0x1E,0x1F regs.
Great find! That will help limiting the number of quirks/fixups needed for all the diffferent OEM Vendor PN strings of the RollBall modules The password is the same on the other âknown.to be rollballâ modules.
It may be exactly the same mcu, but only a few different settings (on page 3?)
The driver of the YT8821 however uses only C22 commands. So my guess here is that the sfp-module-mcu does the same. This is probably why rollball does not work (as expected), as it is C45 only.
The mcu itself, probably is a general md32 or similar mcu, but we barely know what itâs programmed to do.
I am working on a tool to use on sfp modules via i2c. You can tryout all different protocols directly from commandline. I will add extracting the password and setting the vendor info to this tool. This will make it easier to change only that and minimize the chances of making an error.
It is compiled statically, so you can run it from anywhere.
I have written similar tools but not quite ready for upload. I try out C22, C45, C45overC22, ROLLBALL from a userland app, as its easier to discover stuff that way, rather than rebuilding linux kernels.
I have not looked into how to do i2c bus lock from userland yet. Is there a IOCTL for that, that automatically unlocks on device close?
I also have written a SFP password scanning tool and was doing that in the hope it might help with 0x56 write access. Fortunately, I found the âcswwâ password just looking at me from the bottom of 0x51 page 3, so that saved me a few days scanning.
Me too, brute force attack is in the tool. But I was running 0x0 to 0xff, where I should have limited to readable characters, then I would have found it already.
The tool is practically finished, but I just try it out first thoroughly, before setting the repo public.
The functions so far are:
Usage: i2csfp I2CBUS command ...
I2CBUS is i2c bus device name (/dev/i2c-x)
Command one of:
eeprom
byte
c22m Clause 22 MARVELL
c22r Clause 22 ROLLBALL at 0x56 (read-only?)
c45 Clause 45
rollball Rollball protocol (Clause 45)
rollball22 Rollball protocol (Clause 22) NOT FUNCTIONAL!!!
rbpassword Extract Rollball eeprom password
bruteforce
i2csfp I2CBUS eeprom [-p PASSWORD] [-e EXTCC] [-v VDNAME] [-n VDPN]
-p PASSWORD specify password, without this option uses rbpassword
-V VDNAME specify vendor name
-N VDPN specify vendor pn
-E EXTCC specify extended cc
i2csfp I2CBUS byte read|write [-v] BUS-ADDRESS REGISTER [VALUE]
-v verify write
BUS-ADDRESS is an integer 0x00 - 0x7f
REGISTER is an integer 0x00 - 0x7f
VALUE is an integer 0x00 - 0xff
i2csfp I2CBUS c22m read|write BUS-ADDRESS REGISTER [VALUE]
BUS-ADDRESS is an integer 0x00 - 0x7f
REGISTER is an integer 0x00 - 0x1f
VALUE is an integer 0x00 - 0xffff
i2csfp I2CBUS c22r read|write BUS-ADDRESS REGISTER [VALUE]
BUS-ADDRESS is an integer 0x00 - 0x7f
REGISTER is an integer 0x00 - 0x1f
VALUE is an integer 0x00 - 0xffff
i2csfp I2CBUS c45 read|write BUS-ADDRESS DEVAD REGISTER [VALUE]
BUS-ADDRESS is an integer 0x00 - 0x7f
DEVAD is an integer 0x00 - 0x1f
REGISTER is an integer 0x00 - 0xffff
VALUE is an integer 0x00 - 0xffff
i2csfp I2CBUS rollball read|write DEVAD REGISTER [VALUE]
DEVAD is an integer 0x00 - 0x1f
REGISTER is an integer 0x00 - 0xffff
VALUE is an integer 0x00 - 0xffff
i2csfp I2CBUS rbpassword
i2csfp I2CBUS bruteforce [-p] [MIN] [MAX]
Runs brute force attack on sfp module
-p specify password to start with (last 2 bytes zeroed)
-E specify which attack: 1 (09x50) or 2 (0x56), default 1
MIN is the first byte to try 0x00 - 0xff, default 0x00
MAX is the last byte to try 0x00 - 0xff, default 0xff
