Open j4cbo opened 7 months ago
Have you already tried to capture a trace of the UART commands issued by the stock firmware? If port pairing is configured on every boot, you should be able to see the related commands being issued.
It's also possible that the port/pair mapping is placed in non-volatile storage on the control MCU. In this case, it might be harder to find out what's going on. However, given that you haven't gotten the 802.3bt mode to work yet, I suspect pair mapping is configured every time at start-up.
I've reverted back to the stock firmware for now and taken a trace of the UART commands with a Saleae Logic. As expected it's at 19200 baud. Power was applied to the switch at t=0, and an 802.3bt device was connected at about t=181 and removed at about t=203; this device would fault-loop with OpenWrt but powers up properly with the stock firmware. Decoded output here: https://gist.github.com/j4cbo/aa9c4923b846003d79c3db781f17799d
Things that I've noticed in that log:
Also, this switch puts the PoE microcontroller in the same power domain as the main SoC. There's an i2c isolator (Skyworks Si8600) between the PoE micro and the BCM59121s, plus an additional signal that goes through an optocoupler, perhaps an interrupt or fault flag. I don't have a pinout for the BCM59121 so I can't tell exactly what it's for.
Here's the very hacky decoder script I used.
Two things discovered poking around more:
37.109: TX: 0x3C 0x8E 0x03 0xFF 0x00 0x00 0x01 0x00 0x00 0x01 0xFF 0xCD
37.117: RX: 0x3C 0x8E 0x03 0x00 0x48 0x00 0x48 0x00 0x00 0x00 0xFF 0x5C
67.323: TX: 0x3C 0xB9 0x03 0xFF 0x00 0x00 0x01 0x00 0x00 0x01 0xFF 0xF8
67.337: RX: 0x3C 0xB9 0x03 0x00 0x48 0x00 0x48 0x00 0x00 0x00 0xFF 0x87
97.509: TX: 0x3C 0xE4 0x03 0xFF 0x00 0x00 0x01 0x00 0x00 0x01 0xFF 0x23
97.517: RX: 0x3C 0xE4 0x03 0x00 0x48 0x00 0x48 0x00 0x00 0x00 0xFF 0xB2
The first byte after the sequence number corresponds to the port (this was with a device on port 3, zero-indexed), I haven't identified the rest yet.
Also, when configuring 802.3bt ports with command 0x16, the stock firmware sends a value of 0x96 (150) which would normally mean 30 watts rather than 60. I guess this is per-pair, or the scale is changed to units of 0.4 watts, since otherwise it wouldn't fit in a byte.
- The response to 0x2b "Get extended device config" sets num_pse to 2, which matches the 2 BCM59121 chips on the board. However, the firmware sends 0x18 "Set global power budget" eight times with pse_ctrl = 0 through 7.
That's our main suspect. This exact behavior is introduced in commit f1677d9 ( realtek-poe: Add PSE ID quirk for Zyxel GS1900-24HP-v1"). Might be as simple as adding the GS110TUP device id to config_apply_quirks().
Once there, it would be interesting to compare realtek-poe setup commands to vendor FW.
Power was applied to the switch at t=0, and an 802.3bt device was connected at about t=181 and removed at about t=203;
I don't see the vendor FW do anything special when the device is plugged in. 0x2x commands are periodic "inquiries", not configuration changes.
I'm working on getting OpenWrt up on my Netgear GS110TUP, which has four 30-watt ports and four 60-watt 802.3bt ports. I've sent a core OpenWrt PR (https://github.com/openwrt/openwrt/pull/14275) and am starting to look at PoE support. After generating a config file with the code in https://github.com/Hurricos/realtek-poe/pull/31 , basic 802.3af/at functionality and reading status with
ubus call poe info
work as expected, but my 802.3bt device isn't powering up properly.Looking at https://svanheule.net/switches/software/broadcom_poe_control_protocol I see that support for paired ports "is not yet well understood". What can I do to help? :)