Support for RTL838x based managed switches

svanheule · November 12, 2021, 9:22pm

Thanks! I seems we won't be able to trust this devices with warm/soft reboots. Luckily, it seems that this device series isn't affected by the PLL-bug, so cold reboots (full SoC reset) still works. They also have a GPIO to perform a hard reset, so really we should use that in the future.

RaylynnKnight · November 13, 2021, 9:52am

Brand new GS1900-16 and GS1900-24E both have (bootcmd=cst fcTest; boota).

bmork · November 13, 2021, 12:33pm

Both my GS1900-10HPs have
bootcmd=cst fcTest; boota

65a · November 14, 2021, 10:29pm

It looks like USW-Aggregation switch (8x SFP+ 10gb) should be supportable, since it runs an RTL93xx. I was able to get serial, but it requires extensive dissassembly. After soldering header, several unpopulated resistors must be bridged. I am trying to see if it least boots using the Zyxel XGS kernel image from Kobi's fork. Probably I need to understand more on this thread about SFP phy configuration to make networking work.

65a · November 14, 2021, 10:34pm

It does boot successfully from TFTP, naturally networking is not working, since it hasn't been configured at all in the DTS. I'll hack on it, but any pointers would be useful for how to tell the realtek it has 8 SFP+ PHY devices. Cheers!

terminal log of successful boot is here: https://pastebin.com/5uj6rrnZ

EDIT: SOC family is detected as 0. I'm going to hack that to detect as FAMILY_9300, and see what happens.

eginnc · November 15, 2021, 1:02am

Snapshot is running well on a used Netgear GS308T amazon return I picked up for $30. The default VLAN configuration confused me, but after much forum searching I could reach the device and got it sorted out. OpenWrt with LuCI on a cheap 8 port managed switch - very cool. Thank you for this effort!

In the event this isn't already a known TBD issue (or can't be helped item)...I did notice the port LED's do not function. No impact on the device otherwise, so it matters not. Just a cosmetic item.

65a · November 15, 2021, 1:46am

On USW-Aggregation (RTL9303), forcing SOC family 9300 in current OpenWRT codebase causes mdio probing crash ("kernel paging request"), even if I define nothing in the DTS. I wonder if 9303 has the same number of internal ports as 9302, I'm suspecting maybe that is part of the problem.

anon13997276 · November 15, 2021, 7:24am

Hi,
at the moment such a device is not supported by OWRT. The problem is the SFP+ port, which does not work on the RTL930x, and which turned out to be harder than thought. I have been working on that intermittently since spring. I am quite amazed that the SFP+ port on your device works under u-boot. That would open up the road to compare the configuration of a port configured by u-boot with one that OWRT configures and fixing that until it matches. I assume you are talking about this device: https://store.ui.com/collections/unifi-network-switching/products/unifi-switch-aggregation
Could you post information about how the serial needs to be connected (physically)? Could you also ask Ubiquity for the GPL source code? We need to understand how the 8 SFP+ modules are connected to the internal SerDes and PHYs. There is not a real difference in how the 9302 (on the XGS devices) and the 9303 works, the difference is how the MII lines are connecting the internal SerDes, which needs to be matched by configuring some hardware registers. To give you an idea, the following is the configuration of the XGS 1210-12 from system/include/hwp/hw_profiles/xgs1210_12.c in their GPL package (see biot's wiki pages for the source):

static hwp_swDescp_t xgs1210_12_swDescp = {

    .chip_id                    = RTL9302B_CHIP_ID,
    .swcore_supported           = TRUE,
    .swcore_access_method       = HWP_SW_ACC_MEM,
    .swcore_spi_chip_select     = HWP_NOT_USED,
    .nic_supported              = TRUE,

    .port.descp = {
        { .mac_id =  0, .attr = HWP_ETH,   .eth = HWP_GE,    .medi = HWP_COPPER, .sds_idx = 0, .phy_idx = 0,        .smi = 0,        .phy_addr =  0,        .led_c = 0,        .led_f = 0,       .led_layout = SINGLE_SET,},
        { .mac_id =  1, .attr = HWP_ETH,   .eth = HWP_GE,    .medi = HWP_COPPER, .sds_idx = 0, .phy_idx = 0,        .smi = 0,        .phy_addr =  1,        .led_c = 0,        .led_f = 0,       .led_layout = SINGLE_SET,},
        { .mac_id =  2, .attr = HWP_ETH,   .eth = HWP_GE,    .medi = HWP_COPPER, .sds_idx = 0, .phy_idx = 0,        .smi = 0,        .phy_addr =  2,        .led_c = 0,        .led_f = 0,       .led_layout = SINGLE_SET,},
        { .mac_id =  3, .attr = HWP_ETH,   .eth = HWP_GE,    .medi = HWP_COPPER, .sds_idx = 0, .phy_idx = 0,        .smi = 0,        .phy_addr =  3,        .led_c = 0,        .led_f = 0,       .led_layout = SINGLE_SET,},
        { .mac_id =  4, .attr = HWP_ETH,   .eth = HWP_GE,    .medi = HWP_COPPER, .sds_idx = 0, .phy_idx = 0,        .smi = 0,        .phy_addr =  4,        .led_c = 0,        .led_f = 0,       .led_layout = SINGLE_SET,},
        { .mac_id =  5, .attr = HWP_ETH,   .eth = HWP_GE,    .medi = HWP_COPPER, .sds_idx = 0, .phy_idx = 0,        .smi = 0,        .phy_addr =  5,        .led_c = 0,        .led_f = 0,       .led_layout = SINGLE_SET,},
        { .mac_id =  6, .attr = HWP_ETH,   .eth = HWP_GE,    .medi = HWP_COPPER, .sds_idx = 0, .phy_idx = 0,        .smi = 0,        .phy_addr =  6,        .led_c = 0,        .led_f = 0,       .led_layout = SINGLE_SET,},
        { .mac_id =  7, .attr = HWP_ETH,   .eth = HWP_GE,    .medi = HWP_COPPER, .sds_idx = 0, .phy_idx = 0,        .smi = 0,        .phy_addr =  7,        .led_c = 0,        .led_f = 0,       .led_layout = SINGLE_SET,},
        { .mac_id = 24, .attr = HWP_ETH,   .eth = HWP_2_5GE, .medi = HWP_COPPER, .sds_idx = 1, .phy_idx = 1,        .smi = 1,        .phy_addr =  8,        .led_c = 1,        .led_f = 1,       .led_layout = SINGLE_SET,      .phy_mdi_pin_swap = 1,},
        { .mac_id = 25, .attr = HWP_ETH,   .eth = HWP_2_5GE, .medi = HWP_COPPER, .sds_idx = 2, .phy_idx = 2,        .smi = 2,        .phy_addr =  9,        .led_c = 1,        .led_f = 1,       .led_layout = SINGLE_SET,      .phy_mdi_pin_swap = 1,},
        { .mac_id = 26, .attr = HWP_ETH,   .eth = HWP_XGE,   .medi = HWP_SERDES, .sds_idx = 3, .phy_idx = HWP_NONE, .smi = HWP_NONE, .phy_addr = HWP_NONE,  .led_c = 2,        .led_f = 2,       .led_layout = SINGLE_SET,},
        { .mac_id = 27, .attr = HWP_ETH,   .eth = HWP_XGE,   .medi = HWP_SERDES, .sds_idx = 4, .phy_idx = HWP_NONE, .smi = HWP_NONE, .phy_addr = HWP_NONE,  .led_c = 2,        .led_f = 2,       .led_layout = SINGLE_SET,},
        { .mac_id = 28, .attr = HWP_CPU,   .eth = HWP_NONE,  .medi = HWP_NONE,   .sds_idx = HWP_NONE, .phy_idx = HWP_NONE, .smi = HWP_NONE, .phy_addr =  HWP_NONE, .led_c = HWP_NONE, .led_f = HWP_NONE,.led_layout = HWP_NONE,  },
        { .mac_id = HWP_END },
    },  /* port.descp */
   .serdes.descp = {
        [0] = { .sds_id = 2, .mode = RTK_MII_XSGMII,   .rx_polarity = SERDES_POLARITY_NORMAL, .tx_polarity = SERDES_POLARITY_NORMAL },
        [1] = { .sds_id = 6, .mode = RTK_MII_HISGMII,  .rx_polarity = SERDES_POLARITY_NORMAL, .tx_polarity = SERDES_POLARITY_NORMAL },
        [2] = { .sds_id = 7, .mode = RTK_MII_HISGMII,  .rx_polarity = SERDES_POLARITY_NORMAL, .tx_polarity = SERDES_POLARITY_NORMAL },
        [3] = { .sds_id = 8, .mode = RTK_MII_10GR,     .rx_polarity = SERDES_POLARITY_NORMAL, .tx_polarity = SERDES_POLARITY_NORMAL },
        [4] = { .sds_id = 9, .mode = RTK_MII_10GR,     .rx_polarity = SERDES_POLARITY_NORMAL, .tx_polarity = SERDES_POLARITY_NORMAL },
        [5] = { .sds_id = HWP_END },
    }, /* serdes.descp */

    .phy.descp = {
        [0] = { .chip = RTK_PHYTYPE_RTL8218D,       .mac_id = 0,  .phy_max = 8 },
        [1] = { .chip = RTK_PHYTYPE_RTL8226,        .mac_id = 24, .phy_max = 1 },
        [2] = { .chip = RTK_PHYTYPE_RTL8226,        .mac_id = 25, .phy_max = 1 },
        [3] = { .chip = HWP_END },
    },   /* .phy.descp */

The above is the information needed for the .dts. It is also possible to extract it from the firmware binary, the RTL9303_CHIP_ID/RTL9303_CHIP_ID_8XG (0x9303xxxx) is a very nice marker to find that structure in the binary, but the source would be cool.
Birger

svanheule · November 15, 2021, 9:15am

I added it to the device table on the wiki

The firmware for this switch is SDK v3 based (Linux kernel 3.18), so they should be able to provide a nice GPL archive.

Edit: Interesting mix of module licenses:

ghash-generic.ko license=GPL
defdb.ko license=Realtek Semiconductor Corp.
i2c-mux-rtl9300.ko license=GPL
gcm.ko license=GPL
l2g_isg.ko license=Realtek Semiconductor Corp.
l2g_macvlan.ko license=Realtek Semiconductor Corp.
ctr.ko license=GPL
sha256_generic.ko license=GPL
l2g_dai.ko license=Realtek Semiconductor Corp.
gf128mul.ko license=GPL
ksi.ko license=Realtek Semiconductor Corp.
ubnt_common.ko license=Proprietary
crypto_null.ko license=GPL
mac_snooping.ko license=Proprietary
seqiv.ko license=GPL
l2g_lldp.ko license=Realtek Semiconductor Corp.
l2g_dhcp.ko license=Realtek Semiconductor Corp.
l2g_lacp.ko license=Realtek Semiconductor Corp.
l2g_stp.ko license=Realtek Semiconductor Corp.
rtdrv.ko license=GPL
net.ko license=Realtek Semiconductor Corp.
l2g_igmp.ko license=Realtek Semiconductor Corp.
board_conf.ko license=GPL
l2g_voice_vlan.ko license=Realtek Semiconductor Corp.
mac_filter.ko license=Proprietary
i2c-rtl9300.ko license=GPL
hmac.ko license=GPL
osal.ko license=GPL
board.ko license=Realtek Semiconductor Corp.
ubnthal.ko license=Proprietary
l2g_authmgr.ko license=Realtek Semiconductor Corp.
custom.ko license=Realtek Semiconductor Corp.
rtcore.ko license=GPL
ski.ko license=Realtek Semiconductor Corp.
rtk.ko license=GPL

anon13997276 · November 15, 2021, 4:12pm

Indeed, all the RTL SoC drivers are GPL: rtk.ko, rtcore.ko, rtdrv.ko, i2c-rtl9300.ko.
I would really like that GPL source code

65a · November 15, 2021, 4:44pm

Serial instructions (ice cube tray recommended for screw organization)

Remove outer rear outer casing.
Remove top heat sink
Remove board standoffs
Remove front plate
Remove board standoffs obscured by front plate frame (swing out of way)
Remove CPU heatsink
Gently (checking for any other standoffs) peel board off of the SFP+ heat pads and under-CPU heat pads. Minimize board flexion.
Solder 4 pin header southeast of CPU, ports being northwest
Bridge (at least) the two empty resistor pads near the middle pins of 4-pin. I took ground from chassis, but I think the other pads enable 3v3 and GND.
Repaste CPU and reassemble

The good news is that SSH works on out of box devices, so a working firmware could be flashed without requiring this. I have no idea what protocol is used to talk to the touch screen board, but it uses 8+ wires (SPI? Parallel?) and the touch screen board has an STM32 of some kind.

65a · November 15, 2021, 4:45pm

@anon13997276 are there any registers I can dump (either from uboot or elsewhere) that could help understand the config? I'll request GPL at some point soon.

anon13997276 · November 15, 2021, 5:04pm

The configuration of the SMI (mdio) bus and the mapping of port to MAC happens all in rtl838x_eth.c:rtl930x_mdio_reset(). Any registers in there would be great to know. That routine would normally set them from the .dts, now we need to figure out a .dts that fills them correctly.
The base address of all the registers is 0xbb000000 to which e.g. RTL930X_SMI_PORT0_5_ADDR (found in mach-rtl83xx.h, 0xcb80) is added. So to read out the content of that register you would do in u-boot:
md.l 0xbb00cb80
We also need to understand which GPIOs are used for the I2C used to control the SFP modules. If there is a "show tech-support" command in Ubuiquities console interface, this will show the configuration. Otherwise you need to figure that out from OpenWRT by putting in SFP modules in different ports and look at GPIO status, which might show at least the SFP-present pin being set plus maybe the LOS status (pull out the fibre/remote sfp module).
Once you have an I2C setting for an SFP module and a guessed .dts, try disabling anything in the phy configuration code so that we continue to use the one done in u-boot (the configuration of the SerDes registers in there would also be cool), and maybe, maybe if we are lucky this will make the SFP port work.

65a · November 15, 2021, 5:20pm

I will take a look at the firmware binaries later, I also wonder if I can't pull a DTB out of the update (I've been able to do this on other ubi hw) and convert to DTS for inspection.

uboot> # md.l 0xbb00cb80
bb00cb80: 0a418820 16a4a0e6 2307b9ac 2f6ad272    .A. ....#.../j.r
bb00cb90: 000deb38 00000000 00f00000 00000000    ...8............
bb00cba0: 00000000 00000000 00000000 00000000    ................
bb00cbb0: 001fa435 0107ffe0 0127ffe9 0167ffea    ...5.....'...g..
bb00cbc0: 00000000 00000000 00000000 00000000    ................
bb00cbd0: 00000000 00000000 00000000 00000000    ................
bb00cbe0: 00000000 00000000 00000000 00000000    ................
bb00cbf0: 00000000 00000000 00000000 00000000    ................
bb00cc00: 01053658 aaaaaaaa 00aaaaaa 0a400a80    ..6X.........@..
bb00cc10: 0a200a01 02010bff 02200280 c0008000    . ....... ......
bb00cc20: 0a800b00 80000a01 0a200b80 00000000    ......... ......
bb00cc30: 00000000 00000000 00000000 0fffffff    ................
bb00cc40: 0fffffff 0fffffff 00000000 00000000    ................
bb00cc50: 00000000 00000000 00000000 00000000    ................
bb00cc60: 00000000 00000000 00000000 00000000    ................
bb00cc70: 00000000 00000000 00000000 00000000    ................

anon13997276 · November 15, 2021, 7:00pm

Thanks!
Could you also print out 0xbb00ca00 and following 0x10 registers, please?
The Realtek drivers do not use a dts, you will not find anything in the Ubiquity FW.

65a · November 15, 2021, 7:26pm

uboot> # md.l 0xbb00cb80
bb00cb80: 0a418820 16a4a0e6 2307b9ac 2f6ad272    .A. ....#.../j.r
bb00cb90: 000deb38 00000000 00f00000 00000000    ...8............
bb00cba0: 00000000 00000000 00000000 00000000    ................
bb00cbb0: 001fa435 0107ffe0 0127ffe9 0167ffea    ...5.....'...g..
bb00cbc0: 00000000 00000000 00000000 00000000    ................
bb00cbd0: 00000000 00000000 00000000 00000000    ................
bb00cbe0: 00000000 00000000 00000000 00000000    ................
bb00cbf0: 00000000 00000000 00000000 00000000    ................
bb00cc00: 01053659 aaa9aaa9 0055a9a9 00000000    ..6Y.....U......
bb00cc10: 00000000 00000000 00000000 00000000    ................
bb00cc20: 00000000 0000ffff 0a010ba0 00000000    ................
bb00cc30: 00000000 00000000 00000000 0f110101    ................
bb00cc40: 0f110101 0f110101 00000000 00000000    ................
bb00cc50: 00000000 00000000 00000000 00000000    ................
bb00cc60: 00000000 00000000 00000000 00000000    ................
bb00cc70: 00000000 00000000 00000000 00000000    ................
uboot> # 0xbb00ca00
bb00ca00: 0f885500 000000cc 55550000 00ffaaaa    ..U.....UU......
bb00ca10: 00000000 00000259 001fa434 00000194    .......Y...4....
bb00ca20: 00000194 00000194 00000194 00000194    ................
bb00ca30: 00000194 00000194 00000194 00000194    ................
bb00ca40: 00000194 00000194 00000194 00000194    ................
bb00ca50: 00000194 00000194 00000194 00000194    ................
bb00ca60: 00000194 00000194 00000194 00000194    ................
bb00ca70: 00000194 00000194 00000194 00000194    ................
bb00ca80: 00000194 00000194 00000194 00000217    ................
bb00ca90: 0f110101 00000000 00000000 00000000    ................
bb00caa0: 00000000 00000000 00000000 00000000    ................
bb00cab0: 00000000 00000000 00000000 00000000    ................
bb00cac0: 00000000 00000000 00000000 00000000    ................
bb00cad0: 00000000 00000000 00000000 00000000    ................
bb00cae0: 00000000 00000000 00000000 00000000    ................
bb00caf0: 00000000 00000000 00000000 00000000    ................

(redid first, couldn't remember if I did rtk network on yet)

By the way, here are the rtk commands supported. I see some nice format strings in the strings output from uboot, will need to see if I can trigger them somehow. The OEM bootlog shows I2C MUXed to the SFP+s via the main i2c on chip. Still digging through strings, considering some ghidra on the uboot

rtk     - Realtek commands
rtk network on
        - Enable the networking function
rtk netowkr off
        - Disable the networking function
rtk testmode [mode] [port]
        - Set default value for specific testing
rtk ext-devInit [unit] [deviceAddress]
        - set RTL8231 MDC address
rtk ext-pinGet [unit] [pinNum]
        - get external 8231 GPIO pin status
rtk ext-pinSet [unit] [pinNum] [status]
        - set external 8231 GPIO pin status
rtk i2c init sw [i2c_dev_id] [sck_dev] [sck_pin] [sda_dev] [sda_pin] [8/16 access type] [chipid] [delay] [rtl8231_addre
ss (for Ext-GPIO only)] [read_type 0~1]
        - create a i2c group and init
rtk i2c init hw [i2c_dev_id] [intf_id 0~1 for HW] [sda_pin] [8/16 access type] [chipid] [freq 0~3] [read_type 0~1]
        - create a i2c group and init
rtk i2c read [i2c_dev_id] [reg]
rtk i2c write [i2c_dev_id] [reg] [data]
rtk pinGet [pinNum]
        - get internal GPIO pin status
rtk pinSet [pinNum] [status]
        - set internal GPIO pin status
rtk ledtest [unit] [port] [led_index]
        - led test
rtk show hw_profile_list
        - show the current all supported hw_profile list
rtk phytestmode unit mode port channel
        - Set PHY into test mode; channel: 1=A,2=B,3=C,4=D,0=None
rtk boardid
        - Get board model id
rtk boardid id
        - Set board model id
rtk boardmodel
        - Get board model
rtk boardmode <str>model
        - Set board model
rtk 10g UNIT PORT [none | fiber10g | fiber1g | fiber100m | dac50cm | dac100cm | dac300cm]        - Set 10g port media
rtk phymmd get [unit] [port] [addr] [reg]
rtk phymmd set [unit] [port] [addr] [reg] [data]
        - Get/Set PHY mmd register
rtk sdsreg get [unit] [sdsId] [page] [reg]
rtk sdsreg set [unit] [sdsId] [page] [reg] [data]
        - Get/Set MAC serdes register

anon13997276 · November 15, 2021, 11:04pm

The registers decode to the following:

RTL930X_SMI_PORT0_5_ADDR:
Port 0: PHY-Addr 0, Port 1: PHY-Addr 1, ... , Port 27: PHY-Addr 27

RTL930X_SMI_PORT0_15_POLLING_SEL:
Port  0 - 7 : use SMI-Bus 0
Port  8 - 15: SMI-Bus 1
Port 16 - 23: SMI-bus 2
Port 24 - 27: SMI-bus 3

RTL930X_SMI_GLB_CTRL:
Bits 16-19: SMI-Bus 3 uses Clause 45
Bits 20-23: SMI-Bus 3 is being polled

RTL930X_SMI_MAC_TYPE_CTRL
Ports 0-3 use Type 0 (SFP+)
Ports 4-7 use Type 3 (Gigabit Ethernet)
Ports 8-11 use Type 0 (SFP+)
Ports 12-15 use Type 3 (Gigabit Ethernet)
Ports 16-27 use Type 0 (SFP+)

Unfortunately, this means that ports 0-3, 8-11 and 16-23 could all be used for the SFP+ modules.
So we need to figure out which SerDes are being set up. For this we need the content of registers
(see rtl83xx-phy.c:rtl9300_sds_rst())
0xbb000194, 0xbb0002a0, 0xbb0002a4 and 0xbb000198
That should help to figure out how port (MAC) numbers to SerDes ID are being mapped. This is defined by the wiring on the board and not any registers, so the hint should be how the respective SerDes are being configured (for 10G/SFP+ hopefully).

65a · November 16, 2021, 1:35am

Register dumps are here: https://pastebin.com/fKkCjPc5
EDIT: better paste

Some other notes.

The touchscreen ST32 is controlled via a JSON-like protocol over ttyS1. I assume the other lines (there are ~16) are GPIO or similar.

The OEM firmware only presents a single eth0 interface. I do see kernel messages when ports are filled and removed.

The SFP+ is visible on i2c in port 1 in both i2c bus 0 and i2c bus 100. I think the i2c multiplexer is basically swapping around what is seen on bus 0, but for port 1, i2c bus 0 would work without understanding the multiplexer.

There is an NXP PCA9555A GPIO expander on the board. I don't know if this is the MUX, or is related to the touchscreen signalling. I could not find it on i2c-0 (or the MUXed 100-107)

anon13997276 · November 16, 2021, 6:25am

From the SerDes configuration registers we learn that there are 8 SerDes (2-9) configured for 10G Base-R, i.e. SFP+ at 10GBit fibre:

RTL9300_SDS_MODE_SEL_0:
SerDes 0: 0x1f (Off)
SerDes 1: 0x1f (Off)
SerDes 2: 0x1a (10G Base-R)
SerDes 3: 0x1a (10G Base-R)

Reg RTL9300_SDS_MODE_SEL_1_ADDR:
SerDes 4: 0x1a (10G Base-R)
SerDes 5: 0x1a (10G Base-R)
SerDes 6: 0x1a (10G Base-R)
SerDes 7: 0x1a (10G Base-R)

Reg RTL9300_SDS_MODE_SEL_2_ADDR:
SerDes 8: 0x1a (10G Base-R)
SerDes 9: 0x1a (10G Base-R)

Reg RTL9300_SDS_MODE_SEL_3_ADDR:
SerDes 10: 0x1f (Off)
SerDes 11: 0x1f (Off)

This leaves the question about which MAC is connected to which SerDes. I do not think it is possible to read this out of registers, but I guess it is either MAC 0 or 16 use SerDes 2. Since Port 16 connects to a PHY#16 on SMI 3, my bet is on Port 16. This should allow you to make a .dts. If you disable any code that initializes the SerDes, then OWRT could work.

65a · November 16, 2021, 5:12pm

Something like this? or EXTERNAL_SFP_PHY? Or hand write the blocks?

&ethernet0 {
	mdio: mdio-bus {
		compatible = "realtek,rtl838x-mdio";
		regmap = <&ethernet0>;
		#address-cells = <1>;
		#size-cells = <0>;

		INTERNAL_PHY(16)
		INTERNAL_PHY(17)
		INTERNAL_PHY(18)
		INTERNAL_PHY(19)
		INTERNAL_PHY(20)
		INTERNAL_PHY(21)
		INTERNAL_PHY(22)
		INTERNAL_PHY(23)
	};

	
};

&switch0 {
	ports {
		#address-cells = <1>;
		#size-cells = <0>;

		SWITCH_PORT(16, 1, internal)
		SWITCH_PORT(17, 2, internal)
		SWITCH_PORT(18, 3, internal)
		SWITCH_PORT(19, 4, internal)
		SWITCH_PORT(20, 5, internal)
		SWITCH_PORT(21, 6, internal)
		SWITCH_PORT(22, 7, internal)
		SWITCH_PORT(23, 8, internal)

		port@28 {
			ethernet = <&ethernet0>;
			reg = <28>;
			phy-mode = "internal";
			fixed-link {
				speed = <1000>;
				full-duplex;
			};
		};
	};
};

EDIT: this crashes the same as previous images with all sds 93xx functions stubbed. https://pastebin.com/Ex9e425R I think I need to read about mdio more.

EDIT: Found it! There's a spurious call to the mdio func in common.c "to stop traffic if already configured". Removing this boots with an eth0 device (I currently have just one c45 sfp phy configured with media not specified). Can pass traffic, but negotiated at 1GBase-T on copper, when it is a 10GBase-T SFP...ah ok, this is because port27 is specified this way. I'm not sure what the OEM fixed link to dsa was