Support for RTL838x based managed switches

Let's try again. :slight_smile:

Is this an assumption or known?

I found an rtl9300.h uboot source which has the following, the key difference being the offsets, plus the masks and bitshifts look identical in nature to what we have now:

// RMA: Reserved Multicast Address (RMA)
#define RTL9300_RMA_MGN_LRN_CTRL_ADDR                   (0x9818)
  #define RTL9300_RMA_MGN_LRN_CTRL_PTP_LRN_OFFSET       (2)
  #define RTL9300_RMA_MGN_LRN_CTRL_PTP_LRN_MASK         (0x1 << RTL9300_RMA_MGN_LRN_CTRL_PTP_LRN_OFFSET)
  #define RTL9300_RMA_MGN_LRN_CTRL_LLDP_LRN_OFFSET      (1)
  #define RTL9300_RMA_MGN_LRN_CTRL_LLDP_LRN_MASK        (0x1 << RTL9300_RMA_MGN_LRN_CTRL_LLDP_LRN_OFFSET)
  #define RTL9300_RMA_MGN_LRN_CTRL_EAPOL_LRN_OFFSET     (0)
  #define RTL9300_RMA_MGN_LRN_CTRL_EAPOL_LRN_MASK       (0x1 << RTL9300_RMA_MGN_LRN_CTRL_EAPOL_LRN_OFFSET)

#define RTL9300_RMA_PORT_BPDU_CTRL_ADDR(port)           (0x981C + (((port >> 4) << 2))) /* port: 0-28 */
  #define RTL9300_RMA_PORT_BPDU_CTRL_ACT_OFFSET(port)   ((port & 0xF) << 1)
  #define RTL9300_RMA_PORT_BPDU_CTRL_ACT_MASK(port)     (0x3 << RTL9300_RMA_PORT_BPDU_CTRL_ACT_OFFSET(port))

#define RTL9300_RMA_PORT_PTP_CTRL_ADDR(port)            (0x9824 + (((port) << 2))) /* port: 0-28 */
  #define RTL9300_RMA_PORT_PTP_CTRL_UDP_ACT_OFFSET      (2)
  #define RTL9300_RMA_PORT_PTP_CTRL_UDP_ACT_MASK        (0x3 << RTL9300_RMA_PORT_PTP_CTRL_UDP_ACT_OFFSET)
  #define RTL9300_RMA_PORT_PTP_CTRL_ETH2_ACT_OFFSET     (0)
  #define RTL9300_RMA_PORT_PTP_CTRL_ETH2_ACT_MASK       (0x3 << RTL9300_RMA_PORT_PTP_CTRL_ETH2_ACT_OFFSET)

#define RTL9300_RMA_PORT_LLDP_CTRL_ADDR(port)           (0x9898 + (((port >> 4) << 2))) /* port: 0-28 */
  #define RTL9300_RMA_PORT_LLDP_CTRL_ACT_OFFSET(port)   ((port & 0xF) << 1)
  #define RTL9300_RMA_PORT_LLDP_CTRL_ACT_MASK(port)     (0x3 << RTL9300_RMA_PORT_LLDP_CTRL_ACT_OFFSET(port))

#define RTL9300_RMA_PORT_EAPOL_CTRL_ADDR(port)          (0x98A0 + (((port >> 4) << 2))) /* port: 0-28 */
  #define RTL9300_RMA_PORT_EAPOL_CTRL_ACT_OFFSET(port)  ((port & 0xF) << 1)
  #define RTL9300_RMA_PORT_EAPOL_CTRL_ACT_MASK(port)    (0x3 << RTL9300_RMA_PORT_EAPOL_CTRL_ACT_OFFSET(port))

It uses the ACT offsets, like those mentioned in the 9310 dev sheet.

@howels can you retest with this commit tip please? (there should be 5 commits to cherry-pick)

Failing this, I think we can try with how 931x does the masks.

Here it is: a second attempt commit tip (8 commits) with some different values from another swcore_rtl9300.h, as per how the 931x does things.


#define RTL9300_RMA_MGN_LRN_CTRL_ADDR                   (0x9E78)
  #define RTL9300_RMA_MGN_LRN_CTRL_PTP_LRN_OFFSET       (2)
  #define RTL9300_RMA_MGN_LRN_CTRL_PTP_LRN_MASK         (0x1 << RTL9300_RMA_MGN_LRN_CTRL_PTP_LRN_OFFSET)
  #define RTL9300_RMA_MGN_LRN_CTRL_LLDP_LRN_OFFSET      (1)
  #define RTL9300_RMA_MGN_LRN_CTRL_LLDP_LRN_MASK        (0x1 << RTL9300_RMA_MGN_LRN_CTRL_LLDP_LRN_OFFSET)
  #define RTL9300_RMA_MGN_LRN_CTRL_EAPOL_LRN_OFFSET     (0)
  #define RTL9300_RMA_MGN_LRN_CTRL_EAPOL_LRN_MASK       (0x1 << RTL9300_RMA_MGN_LRN_CTRL_EAPOL_LRN_OFFSET)

#define RTL9300_RMA_PORT_BPDU_CTRL_ADDR(port)           (0x9E7C + (((port / 10) << 2))) /* port: 0-28 */
  #define RTL9300_RMA_PORT_BPDU_CTRL_ACT_OFFSET(port)   ((port % 0xA) * 3)
  #define RTL9300_RMA_PORT_BPDU_CTRL_ACT_MASK(port)     (0x7 << RTL9300_RMA_PORT_BPDU_CTRL_ACT_OFFSET(port))

#define RTL9300_RMA_PORT_PTP_CTRL_ADDR(port)            (0x9E88 + (((port) << 2))) /* port: 0-28 */
  #define RTL9300_RMA_PORT_PTP_CTRL_UDP_ACT_OFFSET      (2)
  #define RTL9300_RMA_PORT_PTP_CTRL_UDP_ACT_MASK        (0x3 << RTL9300_RMA_PORT_PTP_CTRL_UDP_ACT_OFFSET)
  #define RTL9300_RMA_PORT_PTP_CTRL_ETH2_ACT_OFFSET     (0)
  #define RTL9300_RMA_PORT_PTP_CTRL_ETH2_ACT_MASK       (0x3 << RTL9300_RMA_PORT_PTP_CTRL_ETH2_ACT_OFFSET)

#define RTL9300_RMA_PORT_LLDP_CTRL_ADDR(port)           (0x9EFC + (((port / 10) << 2))) /* port: 0-28 */
  #define RTL9300_RMA_PORT_LLDP_CTRL_ACT_OFFSET(port)   ((port % 0xA) * 3)
  #define RTL9300_RMA_PORT_LLDP_CTRL_ACT_MASK(port)     (0x7 << RTL9300_RMA_PORT_LLDP_CTRL_ACT_OFFSET(port))

#define RTL9300_RMA_PORT_EAPOL_CTRL_ADDR(port)          (0x9F08 + (((port / 10) << 2))) /* port: 0-28 */
  #define RTL9300_RMA_PORT_EAPOL_CTRL_ACT_OFFSET(port)  ((port % 0xA) * 3)
  #define RTL9300_RMA_PORT_EAPOL_CTRL_ACT_MASK(port)    (0x7 << RTL9300_RMA_PORT_EAPOL_CTRL_ACT_OFFSET(port))
1 Like

Thanks for that. Will be away for a while but can test next week.

1 Like

Unfortunately both those commit series appear to exhibit the same behaviour as before. Is there any debug logging I can enable to provide assistance here?

I'm short of ideas here. We know the write process works fine. The .h file gives some confidence we have the right addresses, and also to some degree, how and what we write. I suppose some print info for the buffer pre and post write might assist. Perhaps we need to incorporate the enum value part as used in 931x where 0-5 are statically assigned values before the switch statement.

Take this commit for a spin. (You may need to fix a compile error).

Can confirm that the ONTI ONT-S508CL-8S is identical to the XikeStor SKS8300-8X. I couldn't resist and got myself one from the link provided by @buz. Received it today. Read too many horror stories about the power supply, so replaced that with a generic 12V/3A one I already had. The switch came with a DB9 to RJ45 cable for console. The pinout is Cisco, so any Cisco console cable will also work. Including the modern ones with a built-in USB RS232 adapter. Allows you to drop the bulky DB9-connectors - assuming we all connect this to a USB port in the end.

The SKS8300-8X OpenWrt initramfs booted without an issue, using the procedure documented in

But I can't get the 10GBase-T SFP+ I used for tftp to work in OpenWrt. The other end says it has link, and the panel LED says 10g, but the interface says NO-CARRIER and ethtool reports:

root@OpenWrt:~# ethtool lan1
Settings for lan1:
        Supported ports: [ TP    MII     FIBRE ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: external
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

Toggling interface down and up gives:

root@OpenWrt:~# ifconfig lan1 down
[ 5024.852049] switch: port 1(lan1) entered disabled state
root@OpenWrt:~# ifconfig lan1 up
[ 5027.459967] rtl83xx-switch switch@1b000000 lan1: configuring for inband/10gbase-r link mode
[ 5027.570149] rtl93xx_phylink_mac_config port 0, mode 2, phy-mode: 10gbase-r, speed -1, link 0
[ 5027.681428] rtl93xx_phylink_mac_config SDS is 2
[ 5027.741039] rtl9300_sds_rst 31
[ 5027.921976] rtl9300_phy_enable_10g_1g 1gbit phy: 00001140
[ 5027.994045] rtl9300_phy_enable_10g_1g 1gbit phy enabled: 00001140
[ 5028.075374] rtl9300_phy_enable_10g_1g 10gbit phy: 00002040
[ 5028.148607] rtl9300_phy_enable_10g_1g 10gbit phy after: 00002040
[ 5028.228771] rtl9300_phy_enable_10g_1g set medium: 00000002
[ 5028.302049] rtl9300_phy_enable_10g_1g set medium after: 00000002
[ 5028.401189] rtl9300_serdes_setup: Configuring RTL9300 SERDES 2
[ 5028.480006] rtl9300_serdes_mac_link_config: registers before 00000000 00001a03
[ 5028.579154] rtl9300_serdes_mac_link_config: registers after 00000000 00001803
[ 5028.673135] rtl9300_force_sds_mode: SDS: 2, mode 28
[ 5028.737343] rtl9300_force_sds_mode --------------------- serdes 2 forcing to 1a ...
[ 5029.149679] rtl9300_force_sds_mode --------------------- serdes 2 forced to 1a DONE
[ 5029.552180] rtl9300_sds_10g_idle WARNING: Waiting for RX idle timed out, SDS 2
[ 5029.647359] start_1.1.1 initial value for sds 2
[ 5029.763908] end_1.1.1 --
[ 5029.797129] start_1.1.2 Load DFE init. value
[ 5029.855324] end_1.1.2
[ 5029.885102] start_1.1.3 disable LEQ training,enable DFE clock
[ 5029.972761] end_1.1.3 --
[ 5030.006009] start_1.1.4 offset cali setting
[ 5030.063036] end_1.1.4
[ 5030.092827] start_1.1.5 LEQ and DFE setting
[ 5030.161856] end_1.1.5
[ 5030.200625] start_1.2.1 ForegroundOffsetCal_Manual
[ 5030.267675] end_1.2.1
[ 5030.278695] start_1.2.3 Foreground Calibration
[ 5030.377943] rtl9300_do_rx_calibration_2_3: fgcal_gray: 29, fgcal_binary 19
[ 5030.469566] rtl9300_do_rx_calibration_2_3: end_1.2.3
[ 5030.534974] start_1.4.1
[ 5030.758552] end_1.4.1
[ 5030.790635] start_1.4.2
[ 5030.830438] vth_set_bin = 7
[ 5030.862553] vth_set_bin = 7
[ 5030.900248] Vth Maunal = 0
[ 5031.052761] Tap0 Sign : +
[ 5031.088310] tap0_coef_bin = 31
[ 5031.123713] tap0 manual = 0
[ 5031.169884] end_1.4.2
[ 5031.206610] start_1.5.2
[ 5031.314291] end_1.5.2
[ 5031.367352] rtl9300_do_rx_calibration: SDS enabled
[ 5031.534300] 8021q: adding VLAN 0 to HW filter on device lan1
root@OpenWrt:~# [ 5031.873901] sfp sfp-p1: module FS               SFP-10G-T        rev      sn F2220644072      dc 220824  
[ 5036.035087] sfp sfp-p1: mdiobus scan returned -EIO

Any hnts? I will try with fibre instead, but copper is a bit easier to work with on my laptop :wink:

EDIT: yes, 1gig fibre (SX) worked fine:

root@OpenWrt:~# ethtool lan1
Settings for lan1:
        Supported ports: [ FIBRE ]
        Supported link modes:   1000baseX/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: external
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Link detected: yes

Thought I had some spare SR SFP+ around too, but must have imagined that. Doesn't matter I guess. This is enough to be able to debug the 10GBase-T issue eventually. Now on to backup the OEM firmware first.

3 Likes

Hey guys! I started working on a port for two tp-link devices.
TL-ST1008F:

  • randomly reboots
  • original uboot works, and port works fine as well
  • sfp ports work with marvell 10G modules
  • trying to get my 2.5G realtek ones as well

TL-ST5008:

  • original u-boot is pretty locked down, but can be exploited to run any code
  • u-boot port works fine
  • firmware is signed and encrypted, created a script to decrypt it.
  • has 8xRTL8261N phys
  • with driver from MTK code base link up and speed auto negotiation works, but that's it

the hwp looks like this, i suspect the issue related to that:



    .serdes.descp = {
        [0] = { .sds_id = 2, .mode = RTK_MII_USXGMII_10GSXGMII,  .rx_polarity = SERDES_POLARITY_NORMAL, .tx_polarity = SERDES_POLARITY_CHANGE },
        [1] = { .sds_id = 3, .mode = RTK_MII_USXGMII_10GSXGMII,  .rx_polarity = SERDES_POLARITY_CHANGE, .tx_polarity = SERDES_POLARITY_NORMAL },
        [2] = { .sds_id = 4, .mode = RTK_MII_USXGMII_10GSXGMII,  .rx_polarity = SERDES_POLARITY_NORMAL, .tx_polarity = SERDES_POLARITY_CHANGE },
        [3] = { .sds_id = 5, .mode = RTK_MII_USXGMII_10GSXGMII,  .rx_polarity = SERDES_POLARITY_CHANGE, .tx_polarity = SERDES_POLARITY_NORMAL },
        [4] = { .sds_id = 6, .mode = RTK_MII_USXGMII_10GSXGMII,  .rx_polarity = SERDES_POLARITY_NORMAL, .tx_polarity = SERDES_POLARITY_CHANGE },
        [5] = { .sds_id = 7, .mode = RTK_MII_USXGMII_10GSXGMII,  .rx_polarity = SERDES_POLARITY_CHANGE, .tx_polarity = SERDES_POLARITY_NORMAL },
        [6] = { .sds_id = 8, .mode = RTK_MII_USXGMII_10GSXGMII,  .rx_polarity = SERDES_POLARITY_NORMAL, .tx_polarity = SERDES_POLARITY_CHANGE },
        [7] = { .sds_id = 9, .mode = RTK_MII_USXGMII_10GSXGMII,  .rx_polarity = SERDES_POLARITY_CHANGE, .tx_polarity = SERDES_POLARITY_NORMAL },
        [8] = { .sds_id = HWP_END },
    }, /* serdes.descp */

Any other device experiences the random reboot issue?

Edit: I see no errors what so ever on uart when it reboots.

2 Likes

Random reboots can usually be attributed to the hardware watchdog kicking in.

Thank you for playing lab rat! I am getting one, for starters I guess I will play with DACs though.

Since I do not have any 10G copper transceivers on hand, I am open to suggestions as to which ones would be helpful to try.

Not sure I would recommend any at all with this switch. Unless you add some cooling to the sfp slots.

Without any traffic, since it doesn't actually work:

root@OpenWrt:~# grep . /sys/class/hwmon/hwmon4/temp1_*
/sys/class/hwmon/hwmon4/temp1_crit:80000
/sys/class/hwmon/hwmon4/temp1_crit_alarm:0
/sys/class/hwmon/hwmon4/temp1_input:71227
/sys/class/hwmon/hwmon4/temp1_label:temperature
/sys/class/hwmon/hwmon4/temp1_lcrit:-10000
/sys/class/hwmon/hwmon4/temp1_lcrit_alarm:0
/sys/class/hwmon/hwmon4/temp1_max:75000
/sys/class/hwmon/hwmon4/temp1_max_alarm:0
/sys/class/hwmon/hwmon4/temp1_min:-5000
/sys/class/hwmon/hwmon4/temp1_min_alarm:0

The link is up and running at 10000Mb/s according to the other end, so the phy is probably doing something. And the switch is located in an unventilated closet resulting in ~30 °C ambient. But still... 71 °C without moving a bit. That's hot

And it's even a rather low power 30m one:

FWIW, the 1gig SX fibre SFP temperature was ~50 °C in port 1 while measuring the above in port 8

I think it's related to some networking issues, due to plugging in an sfp often triggers it. But also happens when i just leave the switch connected to the network. However it never happen when i had nothing plugged in, just turned on. The weird part is that I see no kernel panic on the uart.

Which modules are needed for hwmon support here?

The sfp driver has hwmon support by default as long as the global CONFIG_HWMON is enabled. And it is for all the realtek targets. You don't need anything else to read the sfp sensors. The sensor value is also part of the "eeprom" dump from ethtool, so you can also use that to monitor sfp temperatures.

Don't think we've implemented hwmon/thermal zone support for the SoCs yet? But I might revive my old code unless someone beats me to it, now that I have a device where is matters. Or, well, not. It's still mostly for curiousity since there's no fan to control. And the sfp sensors

2 Likes

That does not sound too positive, maybe I will stick to 2.5gbit for now. Or run without cover and add a fan nearby, it will live in an utility closet anyhow...

I don't have any of those, so I haven't tested. But I believe they also need some sort of driver support in the form of SERDES tuning for different lenghts etc. Do you know for sure that it will work? If not, then I suggest having at least one set of simple fibre sfps to make sure you have some way to connect when running OpenWrt.

SX (1gig multimode) is verified to work. LX (single mode) should not make any difference. I assume 10gig SR and LR also will be fine, but I haven't tested this yet.

I see that @musashino has tested at least these (from the pull request), so SR testing seems to be covered:

[    9.404158] sfp sfp-p1: module OEM              SFP-10G-SR       rev 02   sn CS105NB8461      dc 231107
[    9.892379] sfp sfp-p8: module OEM              GLC-SX-MMD      rev e   sn CSCGE2L16705     dc 210109

Anything else and you're still in the experimental area....

Based on the mdio bus error from the sfp driver, 1gig copper will most likely fail too. There's something very weird with the sfp driver mdio configuration here. Too many mdio buses:

root@OpenWrt:~# ls -l /sys/class/mdio_bus
lrwxrwxrwx    1 root     root             0 Jan  1  1970 fixed-0 -> ../../devices/platform/Fixed MDIO bus.0/mdio_bus/fixed-0
lrwxrwxrwx    1 root     root             0 Jan  1  1970 mdio-bus -> ../../devices/platform/1b00a300.ethernet/mdio_bus/mdio-bus
lrwxrwxrwx    1 root     root             0 Jan  1  1970 realtek-aux-mdio -> ../../devices/platform/1b000000.switchcore/1b000000.switchcore:mdio-aux/mdio_bus/realtek-aux-mdio
lrwxrwxrwx    1 root     root             0 Jan  1  1970 rtl838x slave mii-0 -> ../../devices/platform/switch@1b000000/mdio_bus/rtl838x slave mii-0
lrwxrwxrwx    1 root     root             0 Feb  4 03:02 smbus:sfp-p1 -> ../../devices/platform/sfp-p1/mdio_bus/smbus:sfp-p1
lrwxrwxrwx    1 root     root             0 Feb  4 03:02 smbus:sfp-p8 -> ../../devices/platform/sfp-p8/mdio_bus/smbus:sfp-p8

This is with

[    9.034360] sfp sfp-p1: module FiberStore       SFP1G-SX-85      rev      sn D87B2312464      dc 171202  
[41265.303956] sfp sfp-p8: module FS               SFP-10G-T        rev      sn F2220644072      dc 220824

Having an mdio bus for the fibre sfp is a bit unexpected. Where did that come from? Both of these are readable, but the phy-ids don't make any sense. There's still some connection to the real-world since we see something on 0x16 for the sfp with a phy:

root@OpenWrt:~# mdio smbus:sfp-p1
 DEV      PHY-ID  LINK
0x00  0x00ff00ff  up
0x01  0x00ff00ff  up
0x02  0x00ff00ff  up
0x03  0x00ff00ff  up
0x04  0x00ff00ff  up
0x05  0x00ff00ff  up
0x06  0x00ff00ff  up
0x07  0x00ff00ff  up
0x08  0x00ff00ff  up
0x09  0x00ff00ff  up
0x0a  0x00ff00ff  up
0x0b  0x00ff00ff  up
0x0c  0x00ff00ff  up
0x0d  0x00ff00ff  up
0x0e  0x00ff00ff  up
0x0f  0x00ff00ff  up
0x10  0x00070000  up
0x11  0x00ce0000  down
0x12  0x00ff00ff  up
0x13  0x00ff00ff  up
0x14  0x00ff00ff  up
0x15  0x00ff00ff  up
0x16  0x00ff00ff  up
0x17  0x00ff00ff  up
0x18  0x00ff00ff  up
0x19  0x00ff00ff  up
0x1a  0x00ff00ff  up
0x1b  0x00ff00ff  up
0x1c  0x00ff00ff  up
0x1d  0x00ff00ff  up
0x1e  0x00ff00ff  up
0x1f  0x00ff00ff  up
root@OpenWrt:~# mdio smbus:sfp-p8
 DEV      PHY-ID  LINK
0x00  0x00ff00ff  up
0x01  0x00ff00ff  up
0x02  0x00ff00ff  up
0x03  0x00ff00ff  up
0x04  0x00ff00ff  up
0x05  0x00ff00ff  up
0x06  0x00ff00ff  up
0x07  0x00ff00ff  up
0x08  0x00ff00ff  up
0x09  0x00ff00ff  up
0x0a  0x00ff00ff  up
0x0b  0x00ff00ff  up
0x0c  0x00ff00ff  up
0x0d  0x00ff00ff  up
0x0e  0x00ff00ff  up
0x0f  0x00ff00ff  up
0x10  0x00070010  up
0x11  0x00f60000  down
0x12  0x00ff00ff  up
0x13  0x00ff00ff  up
0x14  0x00ff00ff  up
0x15  0x00ff00ff  up
0x16  0x00000006  down
0x17  0x00ff00ff  up
0x18  0x00ff00ff  up
0x19  0x00ff00ff  up
0x1a  0x00ff00ff  up
0x1b  0x00ff00ff  up
0x1c  0x00ff00ff  up
0x1d  0x00ff00ff  up
0x1e  0x00ff00ff  up
0x1f  0x00ff00ff  up

Trying to read from the bus named "mdio-bus" results in -EIO:

root@OpenWrt:~# mdio mdio-bus
ERROR: Unable to read status (-5)

Maybe that's what the sfp driver ends up doing too?

Strange, my 10G-baset SFP+ doesn't show hwmon data. I'll double check the flags on the build.
Is it possible that some SFP+ don't support hwmon?

[86340.313528] sfp sfp-p8: module QSFPTEK          QT-SFP-10G-T     rev 03   sn QT6241210634     dc 241211  
[86352.004322] rtl83xx-switch switch@1b000000 lan8: Link is Up - 10Gbps/Full - flow control off
[86352.115702] switch: port 8(lan8) entered blocking state
[86352.184544] switch: port 8(lan8) entered forwarding state

root@XikeStor:~# ls /sys/class/hwmon/
root@XikeStor:~# 

EDIT - looks like I had assumed DOM support was present on all of these 10gbase-T SFP+ but seems that's not the case.

Note: maximum power supplies of the ports on SKS8300-8X (but may be known):

port 1 2 3 4 5 6 7 8
max (W) 2.9 1.5 1.5 2.0 2.0 1.5 1.5 2.9

total: 15.8 W

2 Likes

Fixed the issue. It was my psu.
weirdly enough it was working fine with the original firmware.

The general consensus seems that DACs are the most widely supported - even notorious 'we-do-not-allow-other-sfp' companies usually work with DACs just fine. I've seen similar issues with my BPI R4 - the DAC to my dumb switch just works, the FS single mode fiber to my ISP has been needing force_link ever since the netif upgrade in summer...

Seeing that the SFP-10G-SR is a Cisco item, I'll order one of each Cisco coded 1G (good enough for the 1G hosts :wink: and cooler) and 10G copper transceivers from AE and hope for the best :slight_smile:

I'm trying to add support for an LGS328C. Based on the boot logs it seems to be using a NAND chip. I take it this is unsupported?

If it's not in OpenWrt, upstream has a driver for the SNAND controller:

1 Like