Support for RTL838x based managed switches

I also recently checked out different 10G SFP+ switches and found several $100ish on AliExpress, which could be a nice device. Most are re-branded and basically the same thing. On my short-list was:

At the end I got a Mikrotik though, as OpenWRT support is not available yet and the existing WebGUI seemed a bit lacking, as I heard about a few shortcomings (seems to be firmware related, e.g. you can't seem to mix 2.5G and 10G SFP+)

I too got a 2nd hand Mikrotik (crs305-1g-4s+in) until 10Gb devices are in better shape but I'd still like to look at OpenWRT options. Their web UI is giving me flashbacks to Win95 and Netscape Navigator, whilst the terminal UI is another one of those "we want our own identity so our CLI is totally different to everyone else" projects. But it works.
I guess I am waiting to see if there is a solid design in the 10s of different 10G switches that flooded the market from Hasivo, Horaco etc in recent months.

2 Likes

There is a guy (@musashino above in this thread) who has tried to get OpenWrt running on those xikestore 8300 device but could not complete it as it did not fully boot: Support for RTL838x based managed switches - #2753 by musashino

Perhaps if there are other people joining, I might also get such a device to experiment.

It would be nice to be able to replace the management interface with OpenWrt at some point, if feasible. I don't expect them to release anymore updates and the firmware definitely has some quirks, although it has been stable.

I currently use the Hasivo one I mentioned in my post for both a 2.5 Gb link with PoE+ to my AP and also both the SFP+ ports for 10 Gb (one with a DAC to my router and one with a fiber transceiver connecting to my desktop). In other words, I guess my answer to your question would be "both". :smile:

I think the ones I mentioned should cover most of what's available using the RTL93xx that are also fairly affordable.

@kusmi There is no standard for 2.5 Gb SFP+ as far as I'm aware. There are transceivers that can rate limit down to that speed (normally using pause frames), but 2.5 and 5 Gb are both solely BASE-T speeds since copper cables are where adding them made any sense. I think there are also devices that can somewhat handle it natively, but it shouldn't be expected for SFP+ in general.

1 Like

@olliver did you by any chance invest some time in the SG2210MP :slight_smile:?

Is there any support for cable diagnostics for switches in OpenWRT? RTL838x in particular. Or does that chipset not support cable diags (I didn't check my GS1900-24e before reflashig...)?

1 Like

@dorozyoka did you ever manage to flash the F3 revision? And did it work?
Seems there are indeed different firmware versions between the F and F3 revisions:
afbeelding

D-Links firmware distribution seems kind of a mess, but when looking at their presumable AU department the firmwares are interchangeable? And I found some release notes.

I tried to update the firmware over the WebUI, but as the wiki mentions it is probably expecting an encrypted firmware:

Can't see it in the rtl8380/rtl8382m function description in the datasheet.

1 Like

The OEM firmware does have this feature, accessible from the webinterface for e.g. D-Link, only from the management shell for ZyXEL. The diagnostics are rather crude, though.
OpenWrt does not have this feature so far, it's probably possible, but someone has to do the necessary kernel level development (and much more).

2 Likes

Thanks for the prompt.

Yeah nothing in rtl83xx switches themselves.

But the RTL8218 datasheet has "RTCT" function.

For short, open or impedance mismatch?

Also there's EEE function for detecting cable length? But I haven't seen anything which is like TDR for every pair?

GS1900-24# show cable-diag interfaces all
 Port   |  Speed | Local pair | Pair length | Pair status 
--------+--------+------------+-------------+---------------
    1   |  auto  |    Pair A  |    18.00    | Normal
                      Pair B  |    18.00    | Normal
                      Pair C  |    18.00    | Normal
                      Pair D  |    18.00    | Normal

    2   |  auto  |    Pair A  |     0.82    | Open
                      Pair B  |     0.82    | Open
                      Pair C  |     0.78    | Open
                      Pair D  |     0.77    | Open
[…]
    6   |  auto  |    Pair A  |     8.00    | Normal
                      Pair B  |     8.00    | Normal
                      Pair C  |     8.00    | Normal
                      Pair D  |     8.00    | Normal
[…]

(no, I cannot say anything about the distance units (https://github.com/sre/rust-gs1900/blob/master/src/lib.rs would suggest cm, but that doesn't correspond to the measurements at all, feet would be more realistic, but who would use that) there, but port 1 would really be 5m, port 2 unconnected and port 6 under 1m).

or

is all you get, and the actual cable length in the D-Link case is indeed <50m (it's actually under 1m…).

So that's what's the respective OEM firmwares may give you, anything beyond that would be down to your development abilities and anyone's guess.

2 Likes

Thanks for showing the OEM firmware stuff. Even just knowing the connected/open/short status for each pair is often very useful. Sigh, maybe one day...

1 Like

https://svanheule.net/realtek/maple/feature/rtct

Looks like we have the RTCT register for maple? (I guess it has built in rtl8218 right?)

RTL8306 says RTCT can also do cable length. (Same with rtl8366?, rtl8370 is no ) So maybe even as per above rtl8218 or other phy's can do it too? It's not mentioned in rtl8218/rtl8380 datasheet?

Found an API for rtl8367 on github haha. Will need to do more looking when I have time. But IMO given a proper portable ethernet TDR is like <100AUD. Or just having another switch in the rack purely for TDR purposes it's not a priority. But another cool thing to look into.

I'm thinking that the rtl8218 is on the mdio bus so worst case one can hook up a cheap logic analyser to the pins and do some sniffing on a factory firmware?

edit: what's called RTCT on R8169 just says high impedance detection. So this may not be as generic as one would like in terms of what realtek has under the same name.

edit2:
gs1900-24 I looked on wiki and it's also RTL8218B PHY's? So that gives some good confirmation. I'll have to check as all my (Openwrt capable) switches are H3C/3com/HPE things and will have to have a look at what they have in terms of cable diagnostics.

edit3:
If anyone can find me a phy which actually has a public datasheet regarding cable diagnostics that would be great. 88E1545 public datasheet conveniently doesn't document page 7 in the mdio register map hahaha =P edit4: Microsemi phy's (which is also microchip =P) appear to have register documentation.

1 Like
/* Function Name:
 *      rtk_diag_rtctEnable_set
 * Description:
 *      Start Realtek Cable Tester for ports.
 * Input:
 *      unit      - unit id
 *      pPortmask - the ports for RTCT test
 * Output:
 *      None
 * Return:
 *      RT_ERR_OK
 *      RT_ERR_FAILED
 *      RT_ERR_UNIT_ID      - invalid unit id
 *      RT_ERR_NOT_INIT     - The module is not initial
 *      RT_ERR_NULL_POINTER - input parameter may be null pointer
 * Applicable:
 *      8328, 8389, 8390, 8380
 * Note:
 *      When RTCT starts, the port won't transmit and receive normal traffic.
 */

/* Function Name:
 *      rtk_diag_portRtctResult_get
 * Description:
 *      Get test result of Realtek Cable Tester.
 * Input:
 *      unit        - unit id
 *      port        - the port for retriving RTCT test result
 * Output:
 *      pRtctResult - RTCT result
 * Return:
 *      RT_ERR_OK
 *      RT_ERR_FAILED
 *      RT_ERR_UNIT_ID             - invalid unit id
 *      RT_ERR_NOT_INIT            - The module is not initial
 *      RT_ERR_PORT_ID             - invalid port id
 *      RT_ERR_PHY_RTCT_NOT_FINISH - RTCT not finish. Need to wait a while.
 *      RT_ERR_TIMEOUT             - RTCT test timeout in this port.
 *      RT_ERR_NULL_POINTER        - input parameter may be null pointer
 * Applicable:
 *      8328, 8389, 8390, 8380
 * Note:
 *      (1) If linkType is PORT_SPEED_1000M, test result will be stored in ge_result.
 *          If linkType is PORT_SPEED_10M or PORT_SPEED_100M, test result will be stored in fe_result.
 *      (2) The unit of cable lenght is meter.
 */
3 Likes

I've opened the DGS-1210-10MP F3 and unfortunately it is incompatible with realtek-poe as of now because it uses the RTL8238 PoE controller. :cry:

I didn't install OpenWrt on it yet because I need the PoE functionality.

2 Likes

Thanks. So is that the realtek API documentation? I can't seem to easily find those functions/ code by google.

So do 8328, 8389, 8390 and 8380 platforms I guess have built in phy's?

Search for these functions in the GPL source drops and follow the call stack. E.g. for the RTL8218B this end in:

/* Function Name:
 *      phy_8218b_rtct_start
 * Description:
 *      Start PHY interface RTCT test of the specific port
 * Input:
 *      unit          - unit id
 *      port          - port id
 * Output:
 *      None
 * Return:
 *      RT_ERR_OK     - OK
 *      RT_ERR_FAILED - invalid parameter
 *      RT_ERR_CHIP_NOT_SUPPORTED - chip not supported
 * Note:
 *      None
 */
int32
phy_8218b_rtct_start(uint32 unit, rtk_port_t port)
{
    int32   ret = RT_ERR_FAILED;
    uint32  phyData, fixed_page;
    uint32  speed;

    /* Check the port is link up or not? */
    if ((ret = hal_miim_read(unit, port, PHY_PAGE_0, PHY_STATUS_REG, &phyData)) != RT_ERR_OK)
        return ret;

    phy_common_speed_get(unit, port, &speed);

    if ((phyData & LinkStatus_MASK) && speed != 0)
    {
        /* Configure the GPHY page to copper */
        if ((ret = hal_miim_write(unit, port, 0xa42, 29, 0x0001)) != RT_ERR_OK)
            return ret;

        fixed_page = 0;

        /* get value from CHIP*/
        if ((ret = hal_miim_write(unit, port, fixed_page, 27, 0x8011)) != RT_ERR_OK)
            return ret;
        if ((ret = hal_miim_read(unit, port, fixed_page, 28, &phyData)) != RT_ERR_OK)
            return ret;

        /* enable green feature */
        phyData |= (1 << 9);
        if ((ret = hal_miim_write(unit, port, fixed_page, 27, 0x8011)) != RT_ERR_OK)
            return ret;
        if ((ret = hal_miim_write(unit, port, fixed_page, 28, phyData)) != RT_ERR_OK)
            return ret;

        /* Configure the GPHY page to auto */
        if ((ret = hal_miim_write(unit, port, 0xa42, 29, 0x0000)) != RT_ERR_OK)
            return ret;
    }
    else
    {
        if ((ret = hal_miim_read(unit, port, 0xa42, 17, &phyData)) != RT_ERR_OK)
            return ret;

        phyData |= (1 << RTCT_ENABLE);
        phyData |= (1 << RTCT_CH_A);
        phyData |= (1 << RTCT_CH_B);
        phyData |= (1 << RTCT_CH_C);
        phyData |= (1 << RTCT_CH_D);

        if ((ret = hal_miim_write(unit, port, 0xa42, 17, phyData)) != RT_ERR_OK)
            return ret;
    }

    return ret;
} /* end of phy_8218b_rtct_start */
1 Like

Awesome thanks for the reminder! I completely forgot about that.

edit: ooh just saw that there was an sx220 tarball. Now I want to have another look at SG220 support haha.

edit2:

So it's in phy_8218b.c under sdk/src/hal/phy/. I'm having a read.

Cool so basically the one i'm reading (from the sx220 source drop) if link is up go get the length from the EEE register.
Else go by channel and do more probing to get cable length by RTCT?
Then you check the status bits to see if it's short, open, mismatch short, mismatch open and then line driver (which I assume means line driver status but IDK?)

Not so great units haha:

/* Length = (Index/64)*8ns*(0.2m/ns) = Index/80 (m) = (1.25) * Index (cm) */

But yeah I guess someone who wants to play around with the mdio registers could get it working. I was reading that phytool or mdio-tools would be the way to start?

edit2:
Ok so ethtool looks like it has cable test support? Or there were patches at some point? I'm still reading.

@Timeless Yes, I flashed OpenWRT version 23.05.4 in mid September on the DGS 1210 10MP F3. I used the TFTP method, as described in the wiki (which needed soldering a UART header before).

A few days later, I successfully upgraded to OpenWRT version 23.05.5 through the web interface.

I tested the SFP ports, which work with the cages from 10Gtek (I use the 1 GBit RJ-45 Transceiver modules).

However, PoE does not work. The daemon logs following message:

daemon.warn realtek-poe: Invalid port status packet (port=97)

To be honest, I didn't made further research to that PoE topic, because I didn't need it currently. I figured that I need to configure something, but didn't felt educated enough to stick into it. So thanks for pointing out, that the PoE controller of the DGS-1210-10MP F3 isn't supported currently.

2 Likes

Is there maybe any development on this issue ?

I've just tested the newest snapshot - the GS1900-8HP v1.2 still resets.

Also see https://github.com/openwrt/openwrt/issues/9534