Thanks for the info. That exactly matches my observations when I developed https://github.com/openwrt/openwrt/pull/19491 Th 5G SerDes have no issues and are setup properly. So you can ignore the 10G SerDes setup part for now.
Regarding the fiber ports on the RTL8214FC. The above sequence should be required to get fiber working. IIRC especially this is needed to get link up on the frontend side.
/* set fiber SerDes RX to negative edge */
phy_modify_paged(patchphy, 0x8, 0x17, BIT(14), 0);
I’ve seen a number of merge requests regarding the rtl839x, but I can’t quite make sense of the current state.
Is this stable enough for daily usage? Does PoE work? What remains to be done?
Networking should be mostly fine for now, except the plain 1000Base-X/SGMII setup is still missing. This affects devices which have the SFP ports directly SerDes-driven in contrast to other devices which use a RTL8214FC.
From that perspective, it should be stable (no guarantee though, OpenWrt isn't marketed as high-available or whatever). PoE only works for specific devices, not e.g. on GS1920-24GP e.g.
Port LEDs also don't work on it's own, only when there's a bootloader that does pre-config.
I've been running an HP 1920-48G-PoE (JG928A) for a year or so on OpenWRT and it's been great, there was a problem with PoE RAM usage earlier in 2025 but it's fixed now and has been driving a bunch of APs with no problems. Uptime is currently 25 weeks.
Since you posted specifically in this thread: PoE does not work due to a missing management driver.
Correct - if you want PoE on OpenWRT switches currently then looks for something supported by the realtek-poe driver. The HP switches I mentioned are a good choice but I think the older GS1900 from Zyxel also has PoE enabled (I have a non-PoE GS1900).
Thanks. I was hoping Poe was already working. Is anyone actively working on that management driver? I find it quite hard to find these things in the openwrt tree.
No. Check out the following issue in the realtek-poe repository:
This is a situation where a new upstream pse Linux driver is likely going to be the nicest way forward. It probably still needs some upstream framework changes (in addition to the driver itself), but I think it's the right direction.
I'm not so sure. The PSE chips are managed by a MCU and the switch is talking to this MCU, not to the PSE chips. And the protocol is the same as for the serial MCUs, only the transport is different. Yes, the fact that it's i2c makes it more suitable as kernel nodule.
With https://github.com/blocktrron/poemgr we have another userspace utility for PoE. Originally being intended for some Ubiquiti device, it now also support Realtek stuff. Plasmacloud PSX28 + RTL8239. This device has an MCU that the SoC talks with, via I2C.
To be honest, both realtek-poe and poemgr are weird to me, the usability is not as straightforward as it should be and extending for new devices seems to be a burden everytime. Since the discussion about i2c in realtek-poe hasn't progressed in any way, and poemgr seems rather hacky, those are the wrong horses to bet on.
With the PSE-PD framework there will be a unified interface (I suppose also one that is well thought out). Should be rather irrelevant what the framework talks with, either directly with a PSE device or some MCU, in the end it's just a device on an I2C/SMBus bus or serial device you talk to with some kind of protocol.
Hello all. Iam trying to get openwrt run on a GS1920-24 v1 (non-hp), gs1920-24hp v1 initramfs image boots fine network works, leds seem to work, but when i flash the loader and the sysupgrade image with mtd write and restart all i get is.
ootbase Version: V1.00 | 03/21/2014 09:53:55
DRAM calibration...PASSED
RAM: Size = 131072 Kbytes
DRAM POST: Testing: 131072K
OK
DRAM Test SUCCESS !
rt-loader
Running on RTL8392M rev B (6290) SoC with 128 MB
Relocate 15984 bytes from 0x80014000 to 0x87fa0000
Searching for uImage starting at 0xb4210000 ...
Kernel uImage not found
halt system
Reloaded official zyxel firmware made sure it is set to boot from 1st slot tried to install it again but ended up with the following again. Maybe this switch have different partition layout?
That's an issue with variables within that image Makefile. I noticed it recently too but actually missed that this also affects the GS1920 devices. The FLASH_ADDR variable isn't handled per device definition and the last definition is used.
It's always possible that snapshot images do not work. The partition layout is not the problem since rt-loader is already running. Something looks broken from the image builder side.
I take responsibility for this, and offer this as a fix. Hopefully the commit message explain the issue properly. To be fair, Claude helped here because I don't fully see through the Makefile details.
Ah well, not having added FLASH_ADDR to DEVICE_VARS is probably more my fault as I introduced it, IIRC. Since the GS1920-24HP was the only device using it, this was no problem.
Thanks for the quick fix!
Thanks guys. Going to test in a bit, checked partitions meanwhile with atmp (seems like it is pretty much the same as the HP version (have an extra RomDir2A line).
ROMIO image start at b40b0000
code version:
code start: 80014000
code length: 381B44
memMapTab: 22 entries, start = b40e0000, checksum = E323
$RAM Section:
0: BootExt(RAMBOOT), start=80014000, len=30000
1: BootData(RAM), start=80044000, len=4000
2: RasCode(RAMCODE), start=80048000, len=1AB8000
3: RasData(RAM), start=81b00000, len=6400000
4: BootExtA(RAMBOOT), start=80014000, len=30000
5: RasCodeA(RAMCODE), start=80048000, len=1AB8000
$ROM Section:
6: BootBas(ROMIMG), start=b4000000, len=20000
7: DbgArea(ROMIMG), start=b4020000, len=10000
8: RomDir2(ROMDIR), start=b4030000, len=80000
9: BootExt(ROMIMG), start=b40b0030, len=2FFD0
10: MemMapT(ROMMAP), start=b40e0000, len=2000
11: termcap(ROMIMG), start=b40e2000, len=400
12: RomDefa(ROMBIN), start=b40e2400, len=80000
(Compressed)
Version: RAS GS1920, start: b40e2430
Length: 80000, Checksum: 1BC5
Compressed Length: 254F, Checksum: 543B
13: RasCode(ROMBIN), start=b4162400, len=64DC00
(Compressed)
Version: GS1920, start: b4162430
Length: 15E6E4C, Checksum: A50C
Compressed Length: 2CF743, Checksum: DE1E
14: LogArea1(ROMIMG), start=b47c0000, len=20000
15: LogArea2(ROMIMG), start=b47e0000, len=20000
16: RomDir2A(ROMDIR), start=b4830000, len=80000
17: BootExtA(ROMIMG), start=b48b0030, len=2FFD0
18: MemMapTA(ROMMAP), start=b48e0000, len=2000
19: termcapA(ROMIMG), start=b48e2000, len=400
20: RomDefaA(ROMBIN), start=b48e2400, len=80000
(Compressed)
Version: RAS GS1920, start: b48e2430
Length: 80000, Checksum: 1BC5
Compressed Length: 254F, Checksum: 543B
21: RasCodeA(ROMBIN), start=b4962400, len=64DC00
(Compressed)
Version: GS1920, start: b4962430
Length: 14A3C10, Checksum: AA2C
Compressed Length: 29C50D, Checksum: 75E3
The partition map on the GS1920-24HP v1 is not persistent across image versions. In my experience, the crucial part is just the location of the loader (i.e. BootExt), the rest can be mapped as required.
After applying the patch it created images that can boot. 
Thanks again.