This is an old revision of the document!

PoE management

On RTL8380 and RTL8390 switches based on Realtek's development boards, power over ethernet is usually not managed directly the SoC itself, but by an intermediate microcontroller. This microcontroller in turn talks to a PoE power sourcing equipment (PSE) controller chip. The Realtek platform supports both a Broadcom based, and a Microsemi based implementation. A daemon running on the OS will poll the controller to manage the PoE ports and inform about their status.

The PSE controllers will always be in the PoE power domain, which needs to be isolated from the SoC to protect it from external PoE faults. This means that the PoE controller will talk to either the SoC or PSE controller through a pair of optocouplers or isolators. Be aware of this when probing the control signals on the PoE hardware.

Vendor Device SoC Management IC PSE controller PoE FW version PoE standard support
Cisco SG220-26P RTL8382M Microsemi PD69100 PD69108 (?) n/a 802.3at
D-Link DGS-1210-10P F1 RTL8380M Nuvoton M0516 (?) BMC59121 802.3at
Netgear GS110TPP v1 RTL8380M Nuvoton M0516 BCM59121 802.3at
Netgear GS710TUP Nuvoton M0518 BMC59121 ×2 802.3bt
Netgear GS728TP v2 RTL8391M Nuvoton M0516 BCM59121 ×3 802.3at
TP-Link T1600G-52PS RTL8393 - TI TPS23861PW ×12 802.3at
Trendnet TPE-1620WS RTL8382M Nuvoton BCM59121 ×2 802.3at
Zyxel GS1900-10HP RTL8380M STM 32F100 BCM59121 (BCM59121), (BCM59101) 802.3at
Zyxel GS1920-24HP STM 32F100 BMC59111 ×6 802.3at

On the Broadcom platform, an intermediate microcontroller is used to managed a Broadcom PSE controller, like the BCM59121. Although more than one microcontroller type is used over different products, they all appear to use the same serial protocol. The high level control and status commands between the microcontroller and SoC use the SoC's secondary UART. The UART connection between the SoC and microcontroller typically uses a 19200 baud, 8n1 connection. Communication between the microcontroller and the Broadcom chip uses Broadcom Serial Control (BSC), an I2C dialect.

The SoC controls the PoE controller as a slave device. A request frame is sent, to which the controller must respond. Request and reply frames are always 12 bytes long. They start with a command and a frame identifier. Frame IDs are usually sequential, but this is not required. After the 2-byte header, are 9 bytes of data. Finally the frame is terminated by a checksum, which is the sum of the preceding bytes, modulo 256. If not all data bytes are used, the data is padded with ff.

Offset |         +0 |         +1 |         +2 |         +3 |
   0x0 | Command    | Frame ID   | Data[0:2]             ...
   0x4 | Data[2:6]                                       ...
   0x8 | Data[6:9]                            | Checksum   |

Normally, the reply must contain the same command and frame ID bytes. If a request error was detected, a number of special reply commands may be returned, listed in the overview table below.

Below is a list of commands used by switches of multiple vendors. Port indices are 1-based. Unless noted otherwise, every field listed in brackets consists of one byte. Longer fields use big-endian encoding.

ID Description Request format Reply format Comment
00 Set port enabled [port] [00=disabled, 01=enabled] Disable command must be repeated
02 ??? [01] Sent during initialisation
03 Set port power [port] [00=off, 01=on]
06 ??? [01] Sent during initialisation
07 ??? [02]
0a ??? 3 bytes
0e Set pair mapping 8 bytes [error]
0b Set extended config
10 Set detection type
15 Set power limit type
16 Set port power budget
17 Set power management mode
18 Set global power budget
1a Set port priority [port] [priority=0-3] Priority 3 is highest, 0 is lowest
1c Set port power-up mode
1d Set relative port priority [port] [priority] {[port] [priority] …} port/value can be repeated for multiple ports
20 Get system info
21 Get port status
22 Get port counters
23 Get power statistics
25 Get port config
26 Get power limits [??:1] [??:8]
27 Get power management mode
28 Get all port status
2a Get port overview
2b Get extended config -
30 Get port measurements
41 ??? 5 bytes
43 ??? [??:7] [00]
af Bootloader mode n/a Controller is still booted in bootloader mode, and is requesting a FW image
e0 MCU management varies varies Special commands to manage the MCU firmware
fd Request incomplete n/a An incomplete request was received
fe Request checksum n/a Request frame checksum was incorrect
ff Not ready n/a Controller was not ready to respond

Set extended config

  • ID: 0b
  • Request: [pre_alloc] [powerup_mode] [ext_param_3] FF FF FF FF FF [ext_param_8]
  • Reply: [error]

Command is described as “Power Management Ext config” in Ubiquiti firmware.

Field Size Description
pre_alloc 1 Always 01 on Netgear
powerup_mode 1 00=simultaneous power-up
01=staggered power-up
02 (on Netgear FW v1.8)
ext_param_3 1 Always 00
ext_param_8 1 Ignored if FF, otherwise stored by the MCU (FW v1.8)

Set detection type

  • ID: 10
  • Request: { [port] [detection_type] }
  • Reply: { [port] [error] }
Field Size Description
port 1 0-based port index
detection_type 1 01=Legacy (Netgear)
02=IEEE 802
05='Wide range' (Zyxel)

Set power limit type

  • ID: 15
  • Request: { [port] [limit_type] }
  • Reply: { [port] [error] }
Field Size Description
port 1 0-based port index
limit_type 1 01=class based
02=user limit (see 'Set power limit')

Set port power budget

  • ID: 16
  • Request: { [port] [power_limit] }
  • Reply: { [port] [error] }
Field Size Description
port 1 0-based port index
power_limit 1 Power budget in units of 0.2W

Set power management mode

  • ID:17
  • Request: [mode]
  • Reply: [error]
Field Size Description
mode 1 01=static (Netgear)
02=dynamic (Netgear)
04 (Ubiquiti)

Set global power budget

  • ID: 18
  • Request: [port] [total_power] [guard_band]
  • Reply: [port] [error]

Configure power budget available to all ports combined. 'total_power' gives the absolute maximum amount of power the PSE should deliver. 'guard_band' is the spare power budget. If at some point the total power draw from the PSE exceeds (total_power - guard_band), the PoE controller will start shutting devices down.

Field Size Description
port 1 Port index number
total_power 2 Total power the PoE switch can deliver to all ports. In units of 0.1W.
guard_band 2 Power budget that should not be allocated to devices, but used a buffer in case of overload. In units of 0.1W.

Set port power-up mode

  • ID: 1c
  • Request: [port] [mode]
  • Reply: [port] [error]

Descriptions for port modes 0-3 come from the Netgear firmware. Modes 3, 5 are used by Ubiquiti.

Field Size Description
port 1 Index of port to configure
mode 1 00=802.3af

Get system info

  • ID: 20
  • Request: (empty)
  • Reply: [mode] [max_ports] [port_map] [device_id] [version] [mcu_type] [system_status] [version_ext]
Field Size Description
mode 1
max_ports 1 Maximum number of supported ports
port_map 1 Lowest bit indicates port mapping is set
device_id 2 e011=BCM59011
version 1 PoE firmware version, see also 'version_ext'. Full firmware version is 'version.version_ext'
mcu_type 1 00=“ST Micro ST32F100”
01=“Nuvoton M05xx LAN
02=“ST Micro STF030C8”
03=“Nuvoton M058SAN”
04=“Nuvoton NUC122”
system_status 1 System status flags
version_ext 1 Extended firmware version, see also 'version'

Get port status

  • ID: 21
  • Request: [port]
  • Reply: [port] [state] [err_type] [class_info] [pd_type] [mpss_mask] [power_mode] [chan_pwr] [pd_alt]

Field names and values derived from Ubiquiti firmware.

Field Size Description
port 1 Port index number
state 1 00=Disabled
03=Test mode
05=Other fault
err_type 1
class_info 1
pd_type 1 00=None
02=Pre-standard PD
03=Ext detection range
mpss_mask 1
power_mode 1 00=2-pair 15W
01=2-pair 30W
02=4-pair 30W
03=4-pair 60W
04=4-pair 15W
05=4-pair 90W
06=2-pair 45W
chan_pwr 1 00=Both down
01=Primary up
02=Alternative up
03=Both up
pd_alt 1 00=PD None
01=Shared PD
02=Separate PD
03=Unknown PD

Get port counters

  • ID: 22
  • Request: [port] [reset]
  • Reply: [port] [overload] [short] [denied] [mps_absent] [invalid_signature]

Returns the error counters for the requested port. Since these counter are only 1 byte in size, e.g. invalid_signature can overflow quite quickly if no device is connected to the port. A larger counter should be stored in the management daemon to keep track of the counter totals, and the reset flag should be set to clear the MCU counters after reading.

Field Size Description
port 1 Port index number
reset 1 Reset counters after reading
overload 1 Number of times the port failed due to overload
short 1 Number of times the port failed due to a short-circuit
denied 1 Number of times the port was denied power
mps_absent 1 Number of times the MPS was absent
invalid_signature 1 Number of times the port was polled, but no device was found

Get power statistics

  • ID: 23
  • Request: (empty)
  • Reply: [consumed] [budget] [s3]
Field Size Description
consumed 2 Total consumed power, in units of 0.1W
budget 2 Total power budget, in units of 0.1W
s3 2

Get port config

  • ID: 25
  • Request: [port]
  • Reply: [port] [enabled] [b2] [detection_type] [power_allocation] [b5] [priority]
Field Size Description
port 1 Port index number
enable 1 Indicates if the port is enabled
b2 1
detection_type 1 Port detection type, see Set detection type
power_allocation 1 Power allocation in units of 0.2W
b5 1
priority 1 Port priority, see Set port priority

Get power management mode

  • ID: 27
  • Request: varies, see description
  • Reply: [mode] [s0] [s1] [s2] [s3]

On Ubiquiti switches, the request data is a single byte, hardcoded to 07. On Netgear switches (FW v1.8), the request data is empty, but the echo byte is used as a port index number.

Field Size Description
mode 1 Power management mode. See Set power management mode
s0 2 FW v1.8 only
s1 2 FW v1.8 only
s2 2 FW v1.8 only
s3 2 FW v1.8 only

Get all port status

  • ID: 28
  • Request: {[port] 01}
  • Reply: {[port] [short_status]}

This command provides a quick way to poll the status of all ports. Multiple port statuses are requested simultaneously by repeating the 2-byte request for each port of interest.

Field Size Description
port 1 Port index number
short_status 1 Bit fields with status <7 6 5 4 3 2 1 0>
bit[7]: unknown, set when this port has delivered power
bit[6:4]: device class (?)
bit[3:0]: power delivery status, see 'state' from Get port status

Get extended config

  • ID: 2b
  • Request: (emtpy)
  • Reply: [ext_param_0] [pre_alloc] [powerup_mode] [ext_param_3] [ext_param_4] [ext_param_5] [ext_param_6] [ext_param_7] [ext_param_8]
Field Size Description
ext_param_0 1
pre_alloc 1
powerup_mode 1
ext_param_3 1 Related to power management like pre_alloc, powerup_mode
ext_param_4 1
ext_param_5 1
ext_param_6 1
ext_param_7 1
ext_param_8 1 3 LSB are flags

Get port measurements

  • ID: 30
  • Request: [port]
  • Reply: [port] [voltage] [current] [temperature] [power]
Field Size Description
port 1 Port index number
voltage 2 Measured supplied voltage, in units of 64.45mV
current 2 Measured current, in units of 1mA
temperature 2 Measured temperature, in units of 0.1°C (to be confirmed)
power 2 Measured power, in units of 0.1W

MCU management

The frame format used for regular commands, does not apply to MCU management frames. Some control commands are formatted as a regular frame, but with the echo field used as a subcommand: e0 [subcommand] [9 data bytes] [checksum]

Extended command Payload data format Description
e0 40 no payload Check firmware CRC and reset MCU.
e0 80 [offset] {data} Write MCU image data bytes {data} at address offset (16 bit, big endian). {data} can vary in length.
e0 c0 10 bytes: all-ff frame with checksum Clear MCU image. The application image is erased to prepare for a new image to be uploaded.
e0 e0 10 bytes: all-ff frame with checksum Clear config. Only seen in Ubiquiti.
e0 f0 10 bytes: all-ff frame with checksum Save config. Only seen in Ubiquiti.

To flash a new MCU firmware, follow the following procedure:

  1. Clear the MCU image with a e0 c0 command.
  2. Verify the MCU is requesting a new image, by polling e.g. system info and checking the reply command to be af
  3. Write the new MCU image with the e0 80 command. The MCU replies with an af frame when the data was written successfully.
  4. After writing all data, request a CRC check and reset the MCU with a e0 40 command. If the firmware write was successful, the MCU will run in application mode, instead of bootloader mode.

In Netgear and Zyxel firmwares, the MCU write payload length is 8 bytes, to match the normal 12 byte frame size. In Ubiquiti firmware, the payload length is 20 bytes, possibly to speed up MCU flashing. Ubiquiti sends a shorter final frame if the MCU firmware length was not a multiple of 20. Other firmwares assume the FW length is a multiple of 8 bytes, so may send trailing garbage in the last frame (but probably won't).

Like the Broadcom platform, the Microsemi PoE platform also uses a combination of a SoC-PSE bridge as controller, and PSE management ICs to control the power to the PoE devices.

  • software/poe_management.1603989904.txt.gz
  • Last modified: 2020/10/29 16:45
  • by svanheule