Broadcom PoE control protocol

On the Broadcom PoE 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 MCU firmware used to manage the BCM59121 PSE controllers supports two port mapping modes:

• One-to-one mapping of device port number, i.e. the value on the front of the device, and the PSE controller's power output. This allows 2-pair power modes where the PSE connections don't match the ordering of SoC/front panel ports.
• Mapping of device port number to a pair of power outputs on one PSE controller. This allows 4-pair power modes, where two outputs will now map to a port.

Simple port mapping uses a look-up table mapping port numbers to PSE controller power outputs. To use this feature, pair mapping cannot be enabled. To configure the port mapping, use the Set port map enable and Set port mapping commands.

Pair mapping must use a more complicated mapping to match the required PSE controller outputs to a port number. The paired outputs _must_ be located on the same PSE controller. With pair mapping enabled, returned port power values will now be the sum of the power provided by both outputs. This feature is not yet well understood.

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. 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.

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

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

• ID: 00
• Request: [port] [enable]
• Reply: [error]

Enable or disable a port, by setting the "administrative status". A port can be always off, use load detection before powering the port, or provide permanent power to the output.

• ID: 02
• Request: [enable]
• Reply: [error]

Enable or disable port mapping. If pair mapping is already enabled, 'error' will be non-zero. See also Set port mapping.

• ID: 03
• Request: { [port] [reset] }
• Reply: { [port] [error] }

Issue a port reset. This will restart the PSE controller output(s) and start the device detection if the port is enabled.

• ID: 05
• Request: [clear]
• Reply: [error]

Clear the accumulators that keep track of the port counters. See Get port counters for a list of values that will be reset to 0 for all ports, when this command is issued.

• ID: 06
• Request: [enable]
• Reply: [error]

Convenience call to enable or disable all ports simultaneously. Has the same effect as enabling or disabling the port one by one.

• ID: 07
• Request: [high_power]
• Reply: [error]

Configure the maximum power budget that can be assigned to any single port, in case a user-specified power budget is set. 802.3at devices should use 02 for high_power, which corresponds to the maximum power for a class 4 PD.

• ID: 0a
• Request: [uvlo] [ddflag] [ovlo] [p3]
• Reply: [error]

• ID: 0b
• Request: [pre_alloc] [powerup_mode] [disconnect_order] FF FF FF FF FF [gb_hysteresis]
• Reply: [error]

Power budget accounting modes: "pre-allocated" or "actual usage". If 'pre_alloc' is set to 1, the switch will calculate the used power from the maximum power a port can use. When the switch's power is set to 60W, this means only two 30W devices could be connected. If 'pre_alloc' is set to 0, the switch will allow for over-assigning power budget. For a power budget of 60W, this means e.g. five devices could be with a power limit set to 30W, as long as the total power draw does not exceed the 60W.

• ID: 0e
• Request: [port] [b1] [b2] [b3] [b4] [b5] [b6] [b7]
• Reply: empty

• ID: 10
• Request: { [port] [detection_type] }
• Reply: { [port] [error] }

• ID: 11
• Request: { [port] [classification] }
• Reply: { [port] [error] }

• ID: 13
• Request: { [port] [disconnect] }
• Reply: { [port] [error] }

Select the port disconnect detection type. Most likely this selects DC or AC disconnect detection, as defined by the PoE standards. No firmware has been seen to allow modification of this parameter, all reporting a value of DC-disconnect.

• ID: 15
• Request: { [port] [limit_type] }
• Reply: { [port] [error] }

• ID: 16
• Request: { [port] [power_limit] }
• Reply: { [port] [error] }

• ID:17
• Request: [mode]
• Reply: [error]

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

Configure power budget available to all ports combined. 'total_power' gives the absolute maximum amount of power the PSE controller should deliver. 'guard_band' is the spare power budget. If at some point the total power draw from the PSE controller exceeds (total_power - guard_band), the PSE controller will start shutting devices down. Valid pse_ctrl index numbers must be smaller than the number of controllers reported by Get extended device config.

• ID: 19
• Request: { [port] [pair] }
• Reply: { [port] [error] }

Select the power pair to use for the requested port(s). Note that is only makes sense to set this if it's actually possible to use the alternative power pair.

• ID: 1a
• Request: { [port] [priority] }
• Reply: { [port] [error] }

When the switch's assigned power budget is exceeded, powered devices must be switched off. The order in which this happens, can be managed by setting the port priority. Low priority devices will be switched of before normal priority devices, etc.

• 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 802.3at devices from Ubiquiti. 802.3bt modes are most likely not supported on pre-802.3bt hardware.

• ID: 1d
• Request: { [port] [pse_output] }
• Reply: { [port] [error] }

Configure the mapping of port numbers to PSE output numbers. The PSE outputs are indexed by (8×A_PSE + N), where A_PSE is the PSE index, ranging from 0 to 11, and N is the N-th output on the PSE controller, ranging from 0 to 7. The "easiest" way to figure out the port mapping, is to get this from the vendor firmware. Alternative, one can sniff the serial traffic to see what values are set.

• ID: 20
• Request: (empty)
• Reply: [mode] [max_ports] [port_map] [device_id] [version] [mcu_type] [system_status] [version_ext]

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

Detailed port status. A port status summary can also be obtained with Get all port status, which packs a number of value returned by this command in one byte. When the port state is "delivering power" or "requesting power", the fault type field will just be copy of the class info field in FW v1.x.

• 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.

• ID: 23
• Request: (empty)
• Reply: [consumed] [budget] [b3] [high_power] ff ff [gb_hysteresis]

• ID: 25
• Request: [port]
• Reply: [port] [enabled] [auto_powerup] [detection_type] [classification_enable] [disconnect] [pair]

• ID: 26
• Request: [port]
• Reply: [port] [powerup_mode] [power_limit_type] [power_budget] [priority] [primary_pse_output] [secondary_pse_output] [primary_power_limit]

• ID: 27
• Echo: echo byte or [pse]
• Request: [pse] or none
• Reply: [mode] [power_limit_0] [guard_band_0] [power_limit_1] [guard_band_1]

On Ubiquiti switches, the request data is a single byte, hardcoded to 07.

On firmware version v1.6 and up, this command has been butchered up to replace the echo byte with a data byte, allowing for a response with 10 bytes instead of 9.

• 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. The short_status return value has three bit fields: <[7] [6 5 4] [3 2 1 0]>. Note that the meaning of bit 6:4 depends on the status returned by the lower nibble. If the port is delivering (or requesting) power, this field will contain the PoE device class. If the port has experienced a fault, this field will contain the fault type.

• ID: 29
• Request: { [pse_output] 01 }
• Reply: { [pse_output] [consumed_power] }

Request the currently consumed power for a number of PSE outputs. The returned value is expressed in units of 0.2W, so the value fits in one byte. See Get port measurements to read the port power instead of the PSE output power.

• ID: 2a
• Request: [first_port]
• Reply: [first_port] {[short_status]}

Deprecated, use Get all port status.

Return the short status for eight ports, starting at the requested port.

• ID: 2b
• Request: (emtpy)
• Reply: [ext_param_0] [pre_alloc] [powerup_mode] [disconnect] [ddflag] [ovlo] [num_pse] [ext_param_7] [ext_param_8]

• ID: 2c
• Request: none
• Reply: 8 bytes

Returns a system-wide mask in the first data byte. The second byte contains an OR-ed status returned for all PSE output channels. All other bytes are set to zero. The system-wide mask can be set by command 0d.

• ID: 2d
• Request: none
• Reply: 6 status bytes

• ID: 30
• Request: [port]
• Reply: [port] [voltage] [current] [temperature] [power]

• ID: 41
• Request: [enable] [interface] [shift_order] [port_led_count] [off] [req] [err] [on] [blink_override]
• Reply: [error]

Configure the MCU to manage the PoE status LEDs of the network ports. The fields 'off', 'req(uesting)', 'err(or)', and 'on' contain packed bitmasks: <[B] [S] 0 0 0 0 [m m]>:

• m: LED mask. Each bit corresponds to the physical output level to the connected LED. If only one LED per port is present, only the lower bit is used.
• B: blink flag. If this bit is set, the LED will blink when the corresponding port state is active. Only valid for 'req' and 'err'
• S: switch flag. If this bit is set, and two LEDs are available per port, the set bit is used to indicate the high power ("2-pair 30W") mode, i.e. a 802.3at PD. The other bit is then used to indicate the low-power ("2-pair 15W") mode. In 4PPoE mode both LED bits are set.

The LED mask bits are written out directly to hardware, so you will have to take into account the physical layout of the LEDs. If for example two LEDs are in an anti-parallel configuration, both the 00 and 11 values for the LED mask will result in no output being shown, as there would be no voltage difference across the LEDs. This is often the case with the bi-color LEDs used in RJ45 sockets.

• ID: 42
• Request: empty
• Reply: [enable] [interface] [shift_order] [port_led_count] [off] [req] [err] [on] [blink_override]

Get the PoE status LED configuration for the network ports. See Set port LED config for the field details.

• ID: 43
• Request: [sys_ok] [in_gb] [out_of_gb] [exceeds_ps] [out_of_gb_off_delay] [exceeds_ps_off_delay] [map_enable]
• Reply: [error]

Configure the MCU to manage the PoE system status LED.

• ID: 44
• Request: empty
• Reply: [sys_ok] [in_gb] [out_of_gb] [exceeds_ps] [out_of_gb_off_delay] [exceeds_ps_off_delay] [map_enable]

Get PoE system status LED configuration. See Set system LED config for the field details.

• ID: 48
• Request: [port_offset] {[led_index]}
• Reply: [error]

If port PoE LEDs are managed by the MCU, and the order of LEDs does not match the port numbers on the device, a port PoE LED mapping can be set.

This command allows to set the mapping, eight ports at a time. The port offset must be a multiple of 8, otherwise this value will be rounded down by the MCU. The eight following bytes then respresent the LED index corresponding to (port_offset), (port_offset+1)…

By default, the MCU will initialise the port mapping such that the LED indices equal the port index numbers.

• ID: 49
• Request: [port_offset]
• Reply: [port_offset] {[led_index]}

Read the port PoE LED mapping, eight ports at a time. See Set port LED map.

The port offset must be a multiple of 8, otherwise this value will be rounded down by the MCU. The eight following bytes then respresent the LED index corresponding to (port_offset), (port_offset+1)…

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]

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).