[BPI-R4] and SFP

So I would like to return to my S+RJ10 modules. I found out that they are built on Marvell 88X3310P PHY. I even enabled Marvell 10G PHY support when building Openwrt. But I still don’t see this PHY. I know that Aquantia AQR113C has already been added to the assembly. Maybe someone has already done this. Are there any comments on this?

I’m using the build eladwf/openwrt/tree/bpi_r4 I also set irqbalance to balance interrupts on different processor cores from ETH1-2. I don’t see that RSS balances the queues.

You might need to write some quirk for your module. net: sfp: add support for a couple of copper multi-rate modules · torvalds/linux@5859a99 · GitHub

Yes, I’m glad that there might be a solution, but I can’t even imagine how to use it.

The modules work, but I have no idea in what serdes mode. I can connect 100mb-10G but if I connect below 10G I get queue overflow and the transfer speed is limited to 1G. phylink is always 10G. I have the impression that phy does not inform you that you need to slow down, does not send pauses.

I have to enable flow-control on my switch. Although this is not correct, it helps me. It turns out that the queue is controlled by my smart switch.

I got the BPI-R4 now and also have a LuLeey XPON SFP module (LL-XS2510). It was detected out of the box by the OpenWrt version the R4 shipped with. Unfortunately, I can’t test the uplink yet, because my ISP has yet to install the fiber to the building.

Let me know if there is any command I should run with the module or some other information you need to add input to this thread.

I tried but nothing worked with the quirk. The module simply stops starting. Until I give him the command to force MDIX initialization.

I tell him mii-tool -r eth2 and he comes to life.

I stopped fighting with S+RJ10.

I bought XICOM and they are on phy Aquantia AQR113C

They are 10-15 degrees cooler and seem to be fully supported by openwrt.

But there is one peculiarity: in 2024 they changed the name of their modules for DDMI.

In 2023 and earlier they were called

OEM SFP+-T

Now starting in 2024 They are called

OEM SFP-10G-T

Old 2023 and earlier modules did not detect their phy, but this can be fixed.

You just need to add the name of the old module before building. Maybe someone will add this fix to the main build in the future.

[   19.598863] sfp sfp1: module OEM              SFP-10G-T        rev 1    sn CI2401130569     dc 240112
[   19.619594] sfp sfp2: module OEM              SFP+-T           rev 1    sn C2312180155      dc 231218
[   19.640098] hwmon hwmon2: temp1_input not attached to any thermal zone
[   19.666445] hwmon hwmon3: temp1_input not attached to any thermal zone
[   20.239281] mtdblock: MTD device 'ubi' is NAND, please consider using UBI block devices instead.
[   20.251394] mtdblock: MTD device 'bl2' is NAND, please consider using UBI block devices instead.
[   20.268447] md: md0 stopped.
[   20.307591] md0: detected capacity change from 0 to 1937388544
[   21.864184] mtk_soc_eth 15100000.ethernet eth0: Link is Down
[   21.879282] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/internal link mode
[   21.887414] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 10Gbps/Full - flow control rx/tx
[   21.889843] mt7530-mmio 15020000.switch lan1: configuring for phy/internal link mode
[   21.904051] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   21.911104] br-lan: port 1(lan1) entered blocking state
[   21.916362] br-lan: port 1(lan1) entered disabled state
[   21.921827] device lan1 entered promiscuous mode
[   21.930157] mt7530-mmio 15020000.switch lan2: configuring for phy/internal link mode
[   21.938625] br-lan: port 2(lan2) entered blocking state
[   21.943863] br-lan: port 2(lan2) entered disabled state
[   21.949339] device lan2 entered promiscuous mode
[   21.956305] mt7530-mmio 15020000.switch lan3: configuring for phy/internal link mode
[   21.964639] br-lan: port 3(lan3) entered blocking state
[   21.969912] br-lan: port 3(lan3) entered disabled state
[   21.975367] device lan3 entered promiscuous mode
[   21.982319] mt7530-mmio 15020000.switch wan: configuring for phy/internal link mode
[   21.990730] br-lan: port 4(wan) entered blocking state
[   21.995876] br-lan: port 4(wan) entered disabled state
[   22.001567] device wan entered promiscuous mode
[   22.007351] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/10gbase-r link mode
[   22.030559] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/10gbase-r link mode
[   23.549413] EXT4-fs (md0): recovery complete
[   23.553708] EXT4-fs (md0): mounted filesystem with ordered data mode. Quota mode: disabled.
[   48.129729] hwmon hwmon4: temp1_input not attached to any thermal zone
[   48.909538] mtk_soc_eth 15100000.ethernet eth2: PHY [i2c:sfp1:11] driver [Aquantia AQR113C] (irq=POLL)
[   49.919770] hwmon hwmon5: temp1_input not attached to any thermal zone
[   50.699779] mtk_soc_eth 15100000.ethernet eth1: PHY [i2c:sfp2:11] driver [Aquantia AQR113C] (irq=POLL)
[   56.561973] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control rx/tx
[   56.570624] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   57.281984] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 2.5Gbps/Full - flow control rx/tx
[   57.290634] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready

finally got flow control working on 2.5G and now he understands that this is not 10G

root@OpenWrt:~# ethtool eth1
Settings for eth1:
        Supported ports: [  ]
        Supported link modes:   100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
                                1000baseKX/Full
                                10000baseKX4/Full
                                10000baseKR/Full
                                2500baseT/Full
                                5000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
                                1000baseKX/Full
                                10000baseKX4/Full
                                10000baseKR/Full
                                2500baseT/Full
                                5000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
                                             2500baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 2500Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 17
        Transceiver: external
        MDI-X: Unknown
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

UPD: I changed the name on the module now I don’t need the quirk. Old name

OEM+-T

I changed its name to

OEM-10G-T

and now it works normally.

[ 2627.204270] sfp sfp1: module OEM              SFP-10G-T        rev 1    sn C2312180155      dc 231218
[ 2627.244145] hwmon hwmon2: temp1_input not attached to any thermal zone
[ 2653.565434] hwmon hwmon3: temp1_input not attached to any thermal zone
[ 2654.355229] mtk_soc_eth 15100000.ethernet eth2: PHY [i2c:sfp1:11] driver [Aquantia AQR113C] (irq=POLL)
[ 2683.518830] sfp sfp1: module removed

All information is in this post. https://forum.banana-pi.org/t/i2csfp-sfp-debugging-via-i2c/17761?u=vasya

Here is the executable file you can run directly on the BPI-R4

i2csfp.tar.gz (298,4 КБ)

root@OpenWrt:/tmp$ ./i2csfp /dev/i2c-3 eepromfix -V OEM -N SFP-10G-T

Hi, Can you share i2cdetect and i2cdump result of your stick? I also have a aqr113c stick but not sure if it is supported by rollball protocol.

root@OpenWrt:~# i2cdetect -y 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- 56 -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --

root@OpenWrt:~# i2cdump -y 3 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 03 04 07 10 00 00 00 00 00 00 00 06 67 00 00 00    ????.......?g...
10: 08 02 00 1e 4f 45 4d 20 20 20 20 20 20 20 20 20    ??.?OEM
20: 20 20 20 20 00 00 00 00 53 46 50 2b 2d 54 20 20        ....SFP+-T
30: 20 20 20 20 20 20 20 20 31 20 20 20 03 52 00 ef            1   ?R.?
40: 00 1a 00 00 43 32 33 31 32 31 38 30 31 35 35 20    .?..C2312180155
50: 20 20 20 20 32 33 31 32 31 38 20 20 68 f0 03 c5        231218  h???
60: 9f 00 11 8b 92 9a 79 ea 33 1c 5b 64 fd 3f 03 53    ?.????y?3?[d???S
70: 31 e2 d9 00 00 00 00 00 00 00 00 00 49 8a 37 2e    1??.........I?7.
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
root@OpenWrt:~# i2cdump -y 3 0x51
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 5f 00 ce 00 5a 00 d3 00 8c a0 75 30 88 b8 79 18    _.?.Z.?.??u0??y?
10: 1d 4c 01 f4 19 64 03 e8 4d f0 06 30 3d e8 06 f2    ?L???d??M??0=???
20: 2b d4 00 c7 27 10 00 df 00 00 00 00 00 00 00 00    +?.?'?.?........
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
40: 00 00 00 00 3f 80 00 00 00 00 00 00 01 00 00 00    ....??......?...
50: 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 f1    ?...?...?......?
60: 1d f3 82 b3 0b b8 13 88 00 00 00 00 00 00 02 00    ????????......?.
70: 00 40 00 00 00 40 00 00 00 00 00 ff ff ff ff 00    .@...@..........
80: 43 4f 55 49 41 38 4e 43 41 41 31 30 2d 32 34 31    COUIA8NCAA10-241
90: 35 2d 30 33 56 30 33 20 01 00 46 00 00 00 00 c6    5-03V03 ?.F....?
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 aa aa    ..............??
c0: 53 46 50 2d 31 30 47 2d 53 52 20 20 20 20 20 20    SFP-10G-SR
d0: 20 20 20 20 33 32 00 00 00 00 00 00 00 00 00 35        32.........5
e0: 1e 28 2e 2e 31 34 29 36 00 00 00 00 00 00 00 00    ?(..14)6........
f0: 00 00 00 00 00 66 00 00 ff ff ff ff 00 00 00 00    .....f..........
root@OpenWrt:~# i2cdump -y 3 0x56
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 20 40 00 02 31 c3 1c 12 60 31 00 9a e0 00 00 09     @.?1???`1.??..?
10: b3 01 00 00 00 00 40 fc 00 00 00 00 31 c3 1c 12    ??....@?....1???
20: 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 00    ...........?....
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
root@OpenWrt:~#

Thanks, seems my stick doesn’t support rollball protocol.:disappointed:

This does not depend on the module, if phy AQR113C everything should work. Repeat the steps that I described above, add your module to the assembly. My old

XICOM OEM SFP+-T

module also did not work with rollball until I added it.

I’m using the official openwrt. GitHub - openwrt/openwrt: This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git.

Here’s something else I would check.

[  104.599519] mtk_soc_eth 15100000.ethernet eth2: PHY [i2c:sfp1:11] driver [Aquantia AQR113C] (irq=POLL)
[ 2096.301865] sfp sfp1: module removed

Removing a module no longer causes a bunch of errors.

I’m having also a BPI R4 issue with SFP, but kinda specific:

I’m using 2.5G RJ45 SFP modules, as they are less power-hungry compared to SFP+ modules. On Openwrt master based on kernel 6.1, everything is fine. But, as I saw @dangowrt implemented many tricks in later kernel versions, I thought moving to 6.6 (the experimental kernel) was a good thing. Unfortunately, this doesn’t seem to be the case:

[   17.713196] sfp sfp2: module OEM              SFP-2G5          rev 1.0  sn 2G522112324218   dc 220801  
[   17.722600] mtk_soc_eth 15100000.ethernet eth1: unsupported SFP module: no common interface modes
[   17.742752] sfp sfp1: module OEM              SFP-2G5          rev 1.0  sn 2G522112324218   dc 220801  
[   17.752156] mtk_soc_eth 15100000.ethernet eth2: unsupported SFP module: no common interface modes

and the SFP modules no longer work :frowning: using 6.1 kernel, there is no issue:

[   17.390409] sfp sfp1: module OEM              SFP-2G5          rev 1.0  sn 2G522112324218   dc 220801  
[   17.399828] mtk_soc_eth 15100000.ethernet eth2: switched to inband/2500base-x link mode
[   17.419104] sfp sfp2: module OEM              SFP-2G5          rev 1.0  sn 2G522112324218   dc 220801  
[   17.428526] mtk_soc_eth 15100000.ethernet eth1: switched to inband/2500base-x link mode

Has anyone heard of something like this?

I compiled the vanilla openwrt 6.6 kernel with debug and driver debug options, and booted it with “debug ignore_loglevel”. The result is here: verbose_dmesg.txt (259,4 KB)

Anybody who sees what’s going wrong on 6.6 kernels?

I know on R3, inband does not work at 2500base-x. I’m not sure if this is the same for R4.

If so, then it needs to be disabled, using some patch. There are different versions of patches for this problem. So you may want to check if appropriate patches are present in the fork you are using, if R4 also needs inband disabled…

do you accidentally know a patch which does so? I can add it to the patches-to-be-applied-for-6.6 and try whether it works

I guess this needs to be resolved first…

What module are you using?

My SFP module is Aocclink SFP-2.5G-T RJ-45, I can read the details using ethtool:

ethtool --module-info eth1
        Identifier                                : 0x03 (SFP)
        Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x00 0x40 0x00 0x00
        Transceiver type                          : FC: Twisted Pair (TP)
        Encoding                                  : 0x01 (8B/10B)
        BR, Nominal                               : 3100MBd
        Rate identifier                           : 0x00 (unspecified)
        Length (SMF,km)                           : 0km
        Length (SMF)                              : 0m
        Length (50um)                             : 0m
        Length (62.5um)                           : 0m
        Length (Copper)                           : 0m
        Length (OM3)                              : 0m
        Laser wavelength                          : 0nm
        Vendor name                               : OEM
        Vendor OUI                                : 00:00:00
        Vendor PN                                 : SFP-2G5
        Vendor rev                                : 1.0
        Option values                             : 0x00 0x18
        Option                                    : TX_FAULT implemented
        Option                                    : TX_DISABLE implemented
        BR margin, max                            : 0%
        BR margin, min                            : 0%
        Vendor SN                                 : 2G522112324218
        Date code                                 : 220801

this is exactly the same for 6.1 and 6.6 kernels. However, the ethtool eth1 is different:

6.1 kernel:

ethtool eth1
Settings for eth1:
        Supported ports: [ FIBRE ]
        Supported link modes:   2500baseX/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  2500baseX/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 2500Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: no

on 6.6:

ethtool eth1
Settings for eth1:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
                                10000baseT/Full
                                2500baseX/Full
                                1000baseKX/Full
                                10000baseKX4/Full
                                10000baseKR/Full
                                1000baseX/Full
                                10000baseCR/Full
                                10000baseSR/Full
                                10000baseLR/Full
                                10000baseLRM/Full
                                10000baseER/Full
                                2500baseT/Full
                                5000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10000baseT/Full
                                10000baseKX4/Full
                                10000baseKR/Full
                                10000baseCR/Full
                                10000baseSR/Full
                                10000baseLR/Full
                                10000baseLRM/Full
                                10000baseER/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Auto-negotiation: on
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: no

Yet another Vendor PN string. Could you try help me see if this is also a rtl8221b behind rollball?:I’m working on upstream patch and collected already 4 modules that have a rtl8221b behind rollball

i2cdetect -l

Then:

i2cdump -y <bus-nr-found>

Then

i2cdump -y <bus-nr-found> 0x56

If it is rtl8221b behind rollball, your kernel may already have a quirk or fixup for the OEM SFP-2.5G-T. Just add the same for your OEM SFP-2G5.

I’m not sure the output is what you’d expect it to be, but here you go:

i2cdetect -l
i2c-0   i2c             i2c-mt65xx                              I2C adapter
i2c-1   i2c             i2c-mt65xx                              I2C adapter
i2c-2   i2c             i2c-1-mux (chan_id 0)                   I2C adapter
i2c-3   i2c             i2c-1-mux (chan_id 1)                   I2C adapter
i2c-4   i2c             i2c-1-mux (chan_id 2)                   I2C adapter
i2c-5   i2c             i2c-1-mux (chan_id 3)                   I2C adapter
root@meshnode-9946:/# i=0; while [ $i != 6 ]; do echo dumping $i; i2cdump -y $i;
 i2cdump -y $i 0x56; i=$(($i+1)); done
dumping 0
Error: No address specified!
Usage: i2cdump [-f] [-y] [-r first-last] [-a] I2CBUS ADDRESS [MODE [BANK [BANKREG]]]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x08 - 0x77, or 0x00 - 0x7f if -a is given)
  MODE is one of:
    b (byte, default)
    w (word)
    W (word on even register addresses)
    s (SMBus block, deprecated)
    i (I2C block)
    c (consecutive byte)
    Append p for SMBus PEC
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
dumping 1
Error: No address specified!
Usage: i2cdump [-f] [-y] [-r first-last] [-a] I2CBUS ADDRESS [MODE [BANK [BANKREG]]]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x08 - 0x77, or 0x00 - 0x7f if -a is given)
  MODE is one of:
    b (byte, default)
    w (word)
    W (word on even register addresses)
    s (SMBus block, deprecated)
    i (I2C block)
    c (consecutive byte)
    Append p for SMBus PEC
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
10: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
20: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
30: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
40: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
50: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
60: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
70: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
80: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
90: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
a0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
b0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
c0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
d0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
e0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
f0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
dumping 2
Error: No address specified!
Usage: i2cdump [-f] [-y] [-r first-last] [-a] I2CBUS ADDRESS [MODE [BANK [BANKREG]]]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x08 - 0x77, or 0x00 - 0x7f if -a is given)
  MODE is one of:
    b (byte, default)
    w (word)
    W (word on even register addresses)
    s (SMBus block, deprecated)
    i (I2C block)
    c (consecutive byte)
    Append p for SMBus PEC
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
dumping 3
Error: No address specified!
Usage: i2cdump [-f] [-y] [-r first-last] [-a] I2CBUS ADDRESS [MODE [BANK [BANKREG]]]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x08 - 0x77, or 0x00 - 0x7f if -a is given)
  MODE is one of:
    b (byte, default)
    w (word)
    W (word on even register addresses)
    s (SMBus block, deprecated)
    i (I2C block)
    c (consecutive byte)
    Append p for SMBus PEC
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
10: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
20: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
30: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
40: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
50: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
60: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
70: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
80: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
90: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
a0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
b0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
c0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
d0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
e0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
f0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
dumping 4
Error: No address specified!
Usage: i2cdump [-f] [-y] [-r first-last] [-a] I2CBUS ADDRESS [MODE [BANK [BANKREG]]]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x08 - 0x77, or 0x00 - 0x7f if -a is given)
  MODE is one of:
    b (byte, default)
    w (word)
    W (word on even register addresses)
    s (SMBus block, deprecated)
    i (I2C block)
    c (consecutive byte)
    Append p for SMBus PEC
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
10: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
20: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
30: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
40: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
50: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
60: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
70: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
80: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
90: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
a0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
b0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
c0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
d0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
e0: 11 79 01 0c 0d 41 00 00 00 02 00 00 00 00 00 a0    ?y???A...?.....?
f0: 00 00 00 00 00 00 00 00 00 00 00 82 00 00 00 00    ...........?....
dumping 5
Error: No address specified!
Usage: i2cdump [-f] [-y] [-r first-last] [-a] I2CBUS ADDRESS [MODE [BANK [BANKREG]]]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x08 - 0x77, or 0x00 - 0x7f if -a is given)
  MODE is one of:
    b (byte, default)
    w (word)
    W (word on even register addresses)
    s (SMBus block, deprecated)
    i (I2C block)
    c (consecutive byte)
    Append p for SMBus PEC
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

Sorry, it should have been:

 i=0; while [ $i != 6 ]; do echo dumping $i; i2cdetect -y $i; i2cdump -y $i 0x56; i=$(($i+1)); done

But anyway, at 0x56 none of the expected results indeed :frowning: