Support for RTL838x based managed switches

For Developers
2495

Since I've not shared a status update with ya'll for a while, I think it was time I did.

I've been super busy with a lot of things, but also a few openwrt related things :slight_smile:

Still strugeling to get patches merged in openwrt; taking forever ... 5 months now for a led fix :slight_smile: https://github.com/openwrt/openwrt/pull/11898 so us not on 1250 can also enjoy functioning leds. As I don't want to overload the openwrt devs with 250 patches/20 merge requests at a time, i'm trying to go 'slow' but that's not working either shrug.

So, what I have been doing.
Wrote a i2c-regmap-mux driver, so we can use a syscon-regmap to do the muxing of the I2C bus, this replaces the i2c-mux-rtl9300 driver completely.

Next, I rewrote the i2c driver (i2c-rtl_otto), which replaces i2c-rtl9300 completly. It makes use of regmaps, does the proper device tree thing. I've had to improve regmap's themselves a bit to deal with locking though, so hopefully upstream will accept that.

Both of these drivers, allow (in theory) SPI access when controlled via the SPI-Slave bus the rtl93xx exposes. I haven't tested this yet, as I don't have the hardware, so some bugs might still linger somewhere in endian conversion land, but it should be possible to have an ARM64 bit CPU (little-endian) drive the RTL93xx via SPI (big-endian). Who wants this? Actually the verizon cable modem seems to do that :slight_smile: uses the rtl9301 as a 'traditional' switch chip. So need some help with testing, but that's slowly progressing. The only problem is that the verizon modem doesn't have SFP modules so no useful way to test this (other then, use the driver to set the register, use a known working tool to read back those registers and see if they make sense :p)

As mentioned, expanded regmap to support 'transaction locking' (normally, regmap can lock each individual register access, but if you want to write a few registers, with a start and end lock, you still have to manually lock things (and usually disable regmap locking). This is fine, until you need to 'share' this regmap with other devices (syscon), and now you can't. With this change, regmap has a transaction lock,

Added above support to syscon ;p

Added multiple SDA outputs, with a single SCL line to the i2c-gpio driver. This is good for those bit-banged switches, which should replace whatever i2c driver rtl83xx is using.

Added presence detection quirk for devices that lack the MOD-DEF0 GPIO. (Yes there are vendors that don't think this is useful). Linux however treats this as a 'fixed module' e.g. solderd to the board. IF you however have at least one other GPIO, the LOS gpio, we can use that (and the eeprom) to see if a module was inserted/removed anyway. This will probably not work if you have an actual lost signal, while inserting, but on signal recovery, it should behave as the first insertion. Nothing is perfect, but this is the best we can do.

Re-did MDIO support in the SFP driver. The patches that where there, worked, but where complex (with uneeded shared code) and didn't support all cases. They should now. With the new i2c driver, that was properly tested (and debugged, which took forever) I got all mdio cases that I could test working properly. Both in reading and writing (and yes, I overwritten my eeprom in my SFP a few times :p)

And while hacking the SFP driver, some cleanups and fixes, cause, why not :slight_smile:

And to help with testing, I had to fix/improve busybox's i2c utils as well. These patches are already on their way upstream: http://lists.busybox.net/pipermail/busybox/2023-May/090326.html

I think that's pretty much it for now. So where are these changes? Well the kernel ones, will find their way into the openwrt drivers, but I used a seperate kernel tree to develop (much!) faster. So all patches hare here:

The dts changes are in my local openwrt branch, which I'm not gonna push just yet. Not because I want to keep them secret, but because my wip branch is based on openwrt (as it always has been) and I need to cleanup that kernel tree a little bit so I can export the patches and move them into my openwrt tree. Here's the diff though :wink: https://paste.debian.net/1279965/

Anyway, next things I'm gonna do, is see if we can move the whole realtek stuff out of openwrt (wtf what?!) yeah, talking to openwrt management, this is for now the better approach, to move forward a little bit faster hopefully. So will see if that's even possible with the crap we have right now.

Regardless, I would still need some help in getting stuff moving, by reviewing and getting stuff merged. If we do 5 patches per 5 months; then it'll take 250 / 5 * 5 = 250 months e.g. 20 years before all the patches are finally merged :slight_smile:

9 Likes
2496

I was able to restore my XGS1250-12, thanks to @Borromini and your hints. Also did some testing and unfortunately I'm not able to ping any host from XGS1250-12 using the image I've built based on the realtek-wip branch (79a9364d87). Do I have to use a different target profile (XGS1250-12_vendor), when configuring the build?

I get this output on the serial console:

[  155.218568] rtl9300_read_status: Port 27, SerDes is 9
[  155.224238] rtl9300_read_status got SDS mode 1f
[  156.258569] rtl9300_read_status: Port 27, SerDes is 9
[  156.264241] rtl9300_read_status got SDS mode 1f
[  156.510054] rtl930x_phylink_mac_config port 24, mode 0, phy-mode: usxgmii, speed 1000, link 1
[  156.519624] rtl930x_phylink_mac_config SDS is 6
[  156.524693] rtl83xx-switch lexra-bus0:switch@1b000000 lan9: Link is Up - 1Gbps/Full - flow control rx/tx
[  156.534906] rtl930x_switch_irq link faults: 09ffff00
[  156.535410] switch0: port 9(lan9) entered blocking state
[  156.540762] rtl930x_switch_irq RX symbol errors: 000001c4
[  156.552819] switch0: port 9(lan9) entered forwarding state
[  156.560628] rtl930x_phylink_mac_config port 24, mode 0, phy-mode: usxgmii, speed 1000, link 1
[  156.570267] rtl930x_phylink_mac_config SDS is 6
[  157.298569] rtl9300_read_status: Port 27, SerDes is 9
[  157.304245] rtl9300_read_status got SDS mode 1f
[  158.338568] rtl9300_read_status: Port 27, SerDes is 9
[  158.344240] rtl9300_read_status got SDS mode 1f
[  159.378567] rtl9300_read_status: Port 27, SerDes is 9
[  159.384235] rtl9300_read_status got SDS mode 1f
[  160.418568] rtl9300_read_status: Port 27, SerDes is 9
[  160.424239] rtl9300_read_status got SDS mode 1f
2497

Great to hear you got it going again. You did use the rtk network on hack on the u-boot command line?

2498

Two 'known bugs' (even on master). Network setup only works once. E.g. by default, it will come up with a static IP of 192.168.1.1; if this (on your network) works normally, it should ping. (I test things with iperf3). If dhcp is needed, u-boot bootargs 'ip=dhcp' can be set, or, during boot when the software is generating the dropbear key, you can quickly type uci set network.lan.proto=dhcp. When dropbear finishes and the network startup script continues, it will do a dhcp request.

As borromor says, rtk network on is required before doing anything (from u-boot).

2499

I used a Pomona 5250 and CH341a programmer to download the bricked firmware, cleared out the partition which contains the kernel and flashed the modified firmware image. After that I restored the original firmware using the httpd method. Finally I flashed the initramfs image and used the rtk network on hack, to get a uboot shell and used tftp to load my custom image =>

tftpboot 0x84f00000 192.168.1.2:openwrt-realtek-rtl930x-zyxel_xgs1250-12-initramfs-kernel.bin
bootm

I also pulled the latest changes on the realtek-wip branch, but the build fails with this error:

drivers/clk/realtek/clk-rtl83xx.c: In function 'rtcl_init_sram':
drivers/clk/realtek/clk-rtl83xx.c:825:33: error: unused variable 'pdev' [-Werror=unused-variable]
  825 |         struct platform_device *pdev = NULL;
      |                                 ^~~~
cc1: all warnings being treated as errors
make[8]: *** [scripts/Makefile.build:289: drivers/clk/realtek/clk-rtl83xx.o] Error 1
make[7]: *** [scripts/Makefile.build:552: drivers/clk/realtek] Error 2
make[6]: *** [scripts/Makefile.build:552: drivers/clk] Error 2
make[5]: *** [Makefile:1906: drivers] Error 2

Will try again later today.

2500

I documented my Trendnet TEG-S750, made a backup of the entire flash chip using soic clips and collected a bunch of information from the stock firmware before proceeding to ymodem boot the mainline xgs1250 snapshot image, which worked fine(ish).
The mainline image boots fine and I'm getting a link led on the other side, even without rtk network on, but the network isn't working yet, which isn't hugely surprising as it's not an xgs1250-12, after all.

Next I tried building and booting @Olliver's dev/realtek-wip branch using the mainline xgs1250 config but either something went wrong in my build or something was funky at the time when I made the checkout as that image has lots of Illegal instruction messages during boot as well as when interacting with it, e.g. issuing commands on the shell. I'm also not getting a link light.

Next step will be to build current mainline master using the xgs1250 config and check if that works as well as the official build. If not then I'll need to dig more into what's going on with my build. If that's working fine then I'll try a newly updated realtek-wip branch.

Do any of y'all have other recommendations? I'm also trying to document what I'm doing in a github repo and automate steps so it's easy to reproduce, as I found that instructions were a little hard to come by at times.

2501

yeah, they enabled WERROR as default build option now; I fixed those yesterday. Trying to troubleshoot something before pushing something again though;

yep; had the same, which was a bug in the combination of openwrt with my tree. (I tried for a while to use mips34 as CPU arch) but apparently, that is not valid; and actually broken in openwrt. So I reverted that change, but that was a while ago.

Do you have a commit for your DTS so I can add it to my tree?

2502

that was a while ago

Quite possible that's the reason, then. I was on a8bf48e15c which I had checked out on May 8. The mainline build worked, so I'll pull your branch again and build that. Thank you for the pointer!

I haven't made a DTS yet but will post it when I have it.

2503

might not work atm :slight_smile: i'm fixing some stuff right now. I'll post when I have a working build again. Hopefully with some testing I can push something to -dev again to have a little more stable reference point.

Should be a copy/paste job for the most part. Trivial to say the least :slight_smile:

1 Like
2504

might not work atm

Ah yes, I'm getting

Applying /home/dtw/src/openwrt-realtek-build/openwrt/target/linux/realtek/patches-5.15/300-mips-add-rtl838x-platform.patch using plaintext:
patching file arch/mips/Kconfig
Hunk #3 succeeded at 2049 (offset 21 lines).
patching file arch/mips/generic/Kconfig
patch: **** malformed patch at line 91:         help
2505

yeah, that 300 patch is always so annoying :frowning: anyway, i just pushed something, and I'm compiling it myself right now :slight_smile:

note; that I'm not getting traffic through atm; investigating where the breakage is

2506

Excellent, will give it a shot as well.

note; that I'm not getting traffic through atm; investigating where the breakage is

That is the "port isolation" bug mentioned previously?
As soon as I have a working build I'll happily help bisect.

2507

The build is working again :slight_smile: I've pushed it.

Sadly no, I had a patch that removed the 'fixed-link' node from the Ethernet node, because I wanted to avoid duplication between port28 and Ethernet. I did not see any where that was parsing this information from the Ethernet node, or subsystems doing that; but they did :stuck_out_tongue:

The 'port isolation bug is still there, so not something bisectable sadly.

Anyway, took me a while to find it (as I was sure this was working in the past). I still have to 'split and clean' my 'replace patches' commit; but other then that, it should be functional.

I also added a preliminary DTS to my tree. Testing welcome :slight_smile:

What is interesting to note, it seems to be a rebranded edimax device (

edimaxSystemInit():140,Edimax System Init

from your dumps). I couldn't find the real matching Edimax though;

Secondly, the configuration from the realtek SDK (hopefully) should be:

RTL9303_2x84892_1x84891

though I haven't checked if it actually existed, or edimax just followed Realtek naming.

Finally, important is that your dump contains some of the serdes-link configuration information :wink: But apparently 5 and 7 are 'configured' which is odd (though possible); oth, it looks like the broadcom phy just gets 2 USXGMII links, so 1 link per phy .. logical.

What I don't know, if the MDIO addressing on the PHY's is sequential (like a lot of vendors do) or they reset the counter on each mdio bus. Also I don't know which MDIO busses are being used.

For the leds, I assume (the labeling on the front is a bit confusing) that the left led is solid green/orange depending on the link (10g or anything else) and the green led on the right is blinking on activity. If I got it wrong, we can dump it from linux quite easily (devmem 0x1b00cc00 up until 0x1b00cc5c). You might get it from u-boot after rtk network on, but only if u-boot sets it up.

Oth, it doesn't look like your switch has the 'standard' RTL8231 so this might not be accurate at all :wink: and need to be fixed in another way ... I saw the GPIO lines you said where for the activity led, but where are the traces for the link modes? Your pictures a a little too blury. But my guess is, this is a different design not matching what we do elsewhere. I would not be supprised btw, that the speed leds are connected to the broadcom PHY actually! But why not the activity led ...?

The system led is another curiosity. looks like its a dual-color led; so we have the normal gpio0 but also gpio1 ...

2508

Oh wow I see you went deep on this! I appreciate you adding the DTS and digging through the blurry pictures. I only just found out that macro photos on my phone aren't all that great... I uploaded a closer shot of the ports, maybe those two lines are going to the LEDs. The bottom has no visible traces going to the LEDs.

I tried booting it just now and it produced a few stack traces during boot, with no link. So far only upstream has had link.

I'm still finding my way around and will need to go and do some reading up on hardware fundamentals to make sense of the second part of your post. How would I go about exploring the MDIO busses? Is that even a productive thing to do while there's no link, which I take is PHY only?

The system LED at least is showing a happy heartbeat :slight_smile: And as far as the left LED is concerned, your assumption is correct that those are green/orange solid and indeed it will turn on in u-boot even without rtk network on. During u-boot startup the console prints

Chip found!!! Initializing PHY....
interface_config_set
interface_config_set kr_enable=0, usx_enable=1, usx_autoneg=1,
Chip found!!! Initializing PHY....
interface_config_set
interface_config_set kr_enable=0, usx_enable=1, usx_autoneg=1,
Chip found!!! Initializing PHY....
interface_config_set
interface_config_set kr_enable=0, usx_enable=1, usx_autoneg=1,
Chip found!!! Initializing PHY....
interface_config_set
interface_config_set kr_enable=0, usx_enable=1, usx_autoneg=1,
Chip found!!! Initializing PHY....
interface_config_set
interface_config_set kr_enable=0, usx_enable=1, usx_autoneg=1,

and with each initialized PHY the corresponding left LED goes into green (10G) mode. Sounds like they are controlled by the PHY.

I couldn't find the real matching Edimax though;

It does look a little like a 5-port version of the XGS-5008, but I don't know how far similarities go.

2509

If you look at your PCB, you'll also see an EM number, which seems to indicate edimax :slight_smile: I found that one too; but that's an 8 port with a different power connector. I'm sure edimax has an identical PCB version ... or they OEMed it :stuck_out_tongue:

As for the rest; yeah; exploration is key :slight_smile:

First, we see some name clashes on the leds; that's my bad, I've added a name, lets see if it picks that up. the sys-led should have two colors; one that 'rapidly blinks during u-boot' before anything really; probably in green. Amber should be a heartbeat active when linux boots.

[    2.539990] rtl83xx-switch lexra-bus0:switch@1b000000 lan1 (uninitialized): PHY [mdio-bus:08] driver [Generic Clause 45 PHY] (irq=POLL)
[    2.549225] rtl83xx-switch lexra-bus0:switch@1b000000: Link is Up - 1Gbps/Full - flow control off

tells us that at least one mdio address is correct :stuck_out_tongue:

but you say there is no link? Could be that the mdio address/bus is wrong for the connected device. You can remove/insert the cable in the port to see if it changes state. But other then that, it's just trying various combinations in rtl9300,smi-address = <2 0>;

The first number is the MDIO bus number, and we have 4 total (0 - 3). If you look at the pinout, https://svanheule.net/switches/rtl93xx you might be able to gage what is what. The second number, can be anything really; you configure the PHY with one (sometimes via resistors for example), and then often the second PHY within the same package will have n + 1. Sometimes, vendors will number them all sequentially (e.g. phy 0 - phy 4), sometimes they'd restart counting if they are on unique mdio busses. Experimentation and exploration :slight_smile: And looking very closely to the PCB's traces helps.

The stack trace seems to be caused by something in the phy_statemachine. Probably because it can't find a PHY there (or the phy is miss-identified) idk.

Second stack trace is, again, phy related, phy_stop.

The others are all phy related too; 4 state machine stack traces if I count right; also, 4 PHY's with errors :slight_smile:

Idally, you'd overlay the two PCB sides to trace out stuff; Like I've done here https://www.svanheule.net/switches/zyxel_xgs1210_series I think I even did a gif somewhere, where it phases between the layers :slight_smile: It's not hard, just frustrating to get it just right (even with blurry pics). In the gimp you can use unified transform tool. First flip one layer to make it the same orientation; then massage the layer until it fits. Playing with transparency helps.

image
image730×1214 63.9 KB
for example I found an interesting connection to U10. There's 4 pins going to it; and the final gpio's are for a second I2C controller. I would not be supprised if this feeds into a TPM, 2 wires for i2c; 2 for GPIO (enable, reset or something, we'd have to see the pinout for the TPM).

Looking further, we see in the above image, that the input of serdes 8 and 9 are terminated (so they don't generate any noise), which is good; means we can ignore those.

Next I see is that serdes 7 and 6 go to lan5 and 4; and serdes 5 and 4 go to lan 3 and 2. lan 1 seems to be fed by serdes 3. Considering how little I can see :stuck_out_tongue:

I think I got the order wrong of lan1 - lan5 :stuck_out_tongue: will reupload with that fixed.

MDIO0 seems to feed into lan1, and I can't see the mdio bus for the other ones. However, I do see some via's where it branches off, so I suppose all PHY's feed off the same mdio?
For the MDIO addresses, you can try to check the datasheets for those broadcom's, if they have a pinout, we can determine the address from the pull-ups downs.

(the image isn't nicely aligned, i'm on my laptop right now with a small screen and a touchpad)

image
image1639×988 246 KB

I'll do a better one if needed. I did for the funsies :stuck_out_tongue:
teg-s750-merged
teg-s750-merged1920×1580 343 KB

I pushed these guesses to my repo; but i'd be good if it doesn't work to do the legwork with the pics :slight_smile: I'm reasonably confident now though :stuck_out_tongue: (I should have looked at the pics in detail before :smiley:

2 Likes
2510

Pulled the latest changes and tried to run the build again. It fails with the following error:

/home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/linux-5.15.112/scripts/dtc/dtc -O dtb -i../dts-5.15/ -Wno-unit_address_vs_reg -Wno-simple_bus_reg -Wno-unit_address_format -Wno-pci_bridge -Wno-pci_device_bus_num -Wno-pci_device_reg -Wno-avoid_unnecessary_addr_size -Wno-alias_paths -Wno-graph_child_address -Wno-graph_port -Wno-unique_unit_address   -o /home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/image-rtl9301_whitelabel_ws-sw-24p-4s_r1_v1.1_vendor.dtb /home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/image-rtl9301_whitelabel_ws-sw-24p-4s_r1_v1.1_vendor.dtb.tmp
rm -f /home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/image-rtl9301_whitelabel_ws-sw-24p-4s_r1_v1.1_vendor.dtb.tmp
mips-openwrt-linux-musl-cpp -nostdinc -x assembler-with-cpp  -I/home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/linux-5.15.112/arch/mips/boot/dts -I/home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/linux-5.15.112/arch/mips/boot/dts/include -I/home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/linux-5.15.112/include/ -undef -D__DTS__  -o /home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/image-rtl9302b_zyxel_xgs1010-12.dtb.tmp ../dts-5.15/rtl9302b_zyxel_xgs1010-12.dts
/home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/linux-5.15.112/scripts/dtc/dtc -O dtb -i../dts-5.15/ -Wno-unit_address_vs_reg -Wno-simple_bus_reg -Wno-unit_address_format -Wno-pci_bridge -Wno-pci_device_bus_num -Wno-pci_device_reg -Wno-avoid_unnecessary_addr_size -Wno-alias_paths -Wno-graph_child_address -Wno-graph_port -Wno-unique_unit_address   -o /home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/image-rtl9302b_zyxel_xgs1010-12.dtb /home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/image-rtl9302b_zyxel_xgs1010-12.dtb.tmp
../dts-5.15/rtl9302b_zyxel_xgs1210-12.dts:11.13-25.4: ERROR (phandle_references): /sfp0: Reference to non-existent node or label "pinmux_a10_gpio11"

../dts-5.15/rtl9302b_zyxel_xgs1210-12.dts:11.13-25.4: ERROR (phandle_references): /sfp0: Reference to non-existent node or label "pinmux_b11_gpio12"

../dts-5.15/rtl9302b_zyxel_xgs1210-12.dts:11.13-25.4: ERROR (phandle_references): /sfp0: Reference to non-existent node or label "pinmux_a11_gpio13"

../dts-5.15/rtl9302b_zyxel_xgs1210-12.dts:11.13-25.4: ERROR (phandle_references): /sfp0: Reference to non-existent node or label "pinmux_b12_gpio14"

../dts-5.15/rtl9302b_zyxel_xgs1210-12.dts:27.13-41.4: ERROR (phandle_references): /sfp1: Reference to non-existent node or label "pinmux_a12_gpio15"

../dts-5.15/rtl9302b_zyxel_xgs1210-12.dts:27.13-41.4: ERROR (phandle_references): /sfp1: Reference to non-existent node or label "pinmux_b13_gpio16"

ERROR: Input tree has errors, aborting (use -f to force output)
make[5]: *** [Makefile:101: /home/minion/source/openwrt/build_dir/target-mips_24kc_musl/linux-realtek_rtl930x/image-rtl9302b_zyxel_xgs1010-12.dtb] Error 2
make[5]: Leaving directory '/home/minion/source/openwrt/target/linux/realtek/image'
make[4]: *** [Makefile:21: install] Error 2
make[4]: Leaving directory '/home/minion/source/openwrt/target/linux/realtek'
make[3]: *** [Makefile:11: install] Error 2
make[3]: Leaving directory '/home/minion/source/openwrt/target/linux'
time: target/linux/install#14.33#4.01#18.10
    ERROR: target/linux failed to build.
make[2]: *** [target/Makefile:30: target/linux/install] Error 1
make[2]: Leaving directory '/home/minion/source/openwrt'
make[1]: *** [target/Makefile:24: /home/minion/source/openwrt/staging_dir/target-mips_24kc_musl/stamp/.target_install] Error 2
make[1]: Leaving directory '/home/minion/source/openwrt'
make: *** [/home/minion/source/openwrt/include/toplevel.mk:231: world] Error 2
2511

that's good to know; I wonder why I didn't get that; but you don't need to build all targets; just build your own, which should hopefully build fine.

2512

Hm. I had only selected my target platform using make menuconfig - and initiated the build using make. Did I miss something? I'm fairly new to openwrt :grimacing:
Here is an excerpt of my .config file:

CONFIG_TARGET_realtek=y
# CONFIG_TARGET_rockchip is not set
# CONFIG_TARGET_archs38 is not set
# CONFIG_TARGET_omap is not set
# CONFIG_TARGET_uml is not set
# CONFIG_TARGET_zynq is not set
# CONFIG_TARGET_x86 is not set
# CONFIG_TARGET_realtek_rtl838x is not set
# CONFIG_TARGET_realtek_rtl839x is not set
CONFIG_TARGET_realtek_rtl930x=y
# CONFIG_TARGET_realtek_rtl931x is not set
# CONFIG_TARGET_MULTI_PROFILE is not set
# CONFIG_TARGET_realtek_rtl930x_Default is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_ezu_next-7255gh_a2 is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_ezu_next-7255gh_a2_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_fullriver_fr-s3128gt-370p2_v1.1 is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_fullriver_fr-s3128gt-370p2_v1.1_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_hrui_swtg3424s is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_hrui_swtg3424s_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_hasivo_f1100w-8splus is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_hasivo_f1100w-8splus_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_hasivo_s1100wp-8gt-se is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_hasivo_s1100wp-8gt-se_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_hasivo_s600wp-5gt-se is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_hasivo_s600wp-5gt-se_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_horaco_zx-swtg3424s_v1.1 is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_horaco_zx-swtg3424s_v1.1_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_mestechs_msg9424 is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_mestechs_msg9424_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_tp-link_tl-st1008f_v2.0 is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_tp-link_tl-st1008f_v2.0_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_trendnet_teg-s750 is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_trendnet_teg-s750_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_ubiquiti-usw-aggregation is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_ubiquiti-usw-aggregation_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_whitelabel_ws-sw-24p-4s_r1_v1.1 is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_whitelabel_ws-sw-24p-4s_r1_v1.1_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_zyxel_xgs1010-12 is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_zyxel_xgs1010-12_vendor is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_zyxel_xgs1210-12 is not set
# CONFIG_TARGET_realtek_rtl930x_DEVICE_zyxel_xgs1210-12_vendor is not set
CONFIG_TARGET_realtek_rtl930x_DEVICE_zyxel_xgs1250-12=y
# CONFIG_TARGET_realtek_rtl930x_DEVICE_zyxel_xgs1250-12_vendor is not set
CONFIG_HAS_SUBTARGETS=y
CONFIG_HAS_DEVICES=y
CONFIG_TARGET_BOARD="realtek"
CONFIG_TARGET_SUBTARGET="rtl930x"
CONFIG_TARGET_PROFILE="DEVICE_zyxel_xgs1250-12"
CONFIG_TARGET_ARCH_PACKAGES="mips_24kc"
2513

Thank you for all the investigative work!
I ran into the same problem as @deremos, but I just pulled the previous dts for the 1250, 1210, and 1010 again and that allowed me to build (oddly having broken dts for other devices seemed to also break building my device only).

I did change the default-trigger for the leds to default-off and set reg = <24> for phy24, I think there was a typo. The good news is that the MDIO ports you found are correct, and it now lists lan1 through lan5! It does however also stubbornly insist that there's a link on lan1 (and turns on the gpio-controlled led for that port), even if there's nothing plugged in. No link on the other side, independently of which port I'm plugged into. Boot log with stack traces for phys here. I'll go play around with it some more as well.

I also built upstream and changed the 1250's dts to my Trendnet's and while that behaves quite similarly in that it shows the same stack traces and doesn't itself see a link, I did get link on the other side (log here).

2514

Sorry for breaking my WIP build again :smiley: the name does share this though :stuck_out_tongue:
I'm now cleaning up my 'replace patches' commit; hence the breakage. I thought it was still working.

Anyway, I'll hope to get through this today; so I can push a working branch with the new i2c, spf and gpio drivers. Once that is in, in a normal way, I'll do some more trouble shooting for ya'll.

What was the typo?

This is the fun stuff, Is there nothing plugged in at all? I think it's the PHY that relays status. Could also be that we still have something miss-configured. But can you actually plug in cables and see status changes on any of the ports? Can you actually get a working link?