Bringing support for realtek-poe to mainline OpenWrt

walterav · 2022-06-15T08:20:14.076Z

Looking at the ubus output it really does detect something, as soon as a POE device gets plugged in the status changes from Searching to unknown when swapping a device from port 3 to port 5.

$ cat /etc/config/poe
config global
	option budget	'170'

config port
	option enable	'1'
	option id	'1'
	option name	'lan1'
	option poe_plus	'1'
	option priority	'2'

config port
        option enable	'1'
        option id	'2'
        option name	'lan2'
        option poe_plus '1'
        option priority '2'

config port
        option enable	'1'
        option id	'3'
        option name	'lan3'
        option poe_plus '1'
        option priority '2'

config port
        option enable	'1'
        option id	'4'
        option name	'lan4'
        option poe_plus '1'
        option priority '2'

config port
        option enable   '1'
        option id       '5'
        option name     'lan5'
        option poe_plus '1'
        option priority '2'

config port
        option enable   '1'
        option id       '6'
        option name     'lan6'
        option poe_plus '1'
        option priority '2'

config port
        option enable   '1'
        option id       '7'
        option name     'lan7'
        option poe_plus '1'
        option priority '2'

config port
        option enable   '1'
        option id       '8'
        option name     'lan8'
        option poe_plus '1'
        option priority '2'

$ ubus call poe info
{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 170.000000,
	"consumption": 0.000000,
	"ports": {
		"lan1": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan2": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan3": {
			"priority": 2,
			"mode": "PoE+",
			"status": "unknown"
		},
		"lan4": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan5": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan6": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan7": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan8": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		}
	}
}

$ ubus call poe info
{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 170.000000,
	"consumption": 0.000000,
	"ports": {
		"lan1": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan2": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan3": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan4": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan5": {
			"priority": 2,
			"mode": "PoE+",
			"status": "unknown"
		},
		"lan6": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan7": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan8": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		}
	}
}

Borromini · 2022-06-15T08:23:30.811Z

Yes, that's something I saw on my GS1900-8HP v1 frequently as well with the older codebase.

walterav · 2022-06-15T08:43:00.456Z

Port 9-16 with following config (guess that I have to change OPTION ID aswell) show Disabled or Other fault instead of Searching and inconsistent of being which port. As in having port 15 connected shows port 9 as unknown... and port 9 connected shows port 9 as fault...

$ /etc/init.d/poe restart
$ cat /etc/config/poe
config global
	option budget	'170'

config port
	option enable	'1'
	option id	'9'
	option name	'lan9'
	option poe_plus	'1'
	option priority	'2'

config port
        option enable	'1'
        option id	'10'
        option name	'lan10'
        option poe_plus '1'
        option priority '2'

config port
        option enable	'1'
        option id	'11'
        option name	'lan11'
        option poe_plus '1'
        option priority '2'

config port
        option enable	'1'
        option id	'12'
        option name	'lan12'
        option poe_plus '1'
        option priority '2'

config port
        option enable   '1'
        option id       '13'
        option name     'lan13'
        option poe_plus '1'
        option priority '2'

config port
        option enable   '1'
        option id       '14'
        option name     'lan14'
        option poe_plus '1'
        option priority '2'

config port
        option enable   '1'
        option id       '15'
        option name     'lan15'
        option poe_plus '1'
        option priority '2'

config port
        option enable   '1'
        option id       '16'
        option name     'lan16'
        option poe_plus '1'
        option priority '2'

ubus call poe info
{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 170.000000,
	"consumption": 0.000000,
	"ports": {
		"lan9": {
			"priority": 2,
			"mode": "PoE",
			"status": "Other fault"
		},
		"lan10": {
			"priority": 2,
			"mode": "PoE",
			"status": "Disabled"
		},
		"lan11": {
			"priority": 2,
			"mode": "PoE",
			"status": "Disabled"
		},
		"lan12": {
			"priority": 2,
			"mode": "PoE",
			"status": "Disabled"
		},
		"lan13": {
			"priority": 2,
			"mode": "PoE",
			"status": "Disabled"
		},
		"lan14": {
			"priority": 2,
			"mode": "PoE",
			"status": "Disabled"
		},
		"lan15": {
			"priority": 2,
			"mode": "PoE",
			"status": "Disabled"
		},
		"lan16": {
			"priority": 2,
			"mode": "PoE",
			"status": "Disabled"
		}
	}
}

EDIT:

Port 17-24 renaming same option-id as 9-16, keeps all ports in Disabled state. So only port 9 behaves differently... using this config?

svanheule · 2022-06-15T09:01:57.676Z

walterav:

TX -> 0x2a 0x16 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x38
RX -> 0x2a 0x16 0x00 0x11 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0xc1

Maybe it has something to do with how the port status is requested? A port index of 0xff isn't valid, but there still appears to be a reply. The all-zero reply from from port 0 is also odd (if the port isn't actually set as disabled, that is)

walterav · 2022-06-15T09:11:53.615Z

Current findings are inline with @hurricos except I didn't read anything about how port 9 or higher functions in his situation.

I do have to say that I use "pseudo" POE devices currently a Mikrotik Hex-POE(rb960pgs) or Ubiquite AC MESH(uap-ac-m) which commonly work with dumb/passive POE and lower voltage as well. They do however auto power on by POE and work by running the ZyXEL OEM 2.70 firmware.

Later today I try a real 802.3af POE device Netgear WNDAP360.

walterav · 2022-06-15T09:27:09.136Z

Maybe @bmork his findings on enabling POE on 1900-10HP which uses slightly different BCM59121 vs BCM59111 (24HP/8HP) may give insight, however the GPIO pins he mentions are not available anymore:

bmork · 2022-06-15T10:32:28.632Z

walterav:

however the GPIO pins he mentions are not available anymore:

That's because there is a gpio-hog in the dts, which just enables the poe by default now. But maybe they have used a different pin or somehting like that?

Borromini · 2022-06-15T11:03:08.525Z

Whipped up a little script to loop over all the lanX interfaces to populate /etc/config/poe, since by default only lan1 is set:

#!/bin/sh

# Scriptlet to populate /etc/config/poe based on available lanX port naming.
# Drawback: SFP ports are included too if they are named lanX.

for _PORT in $(uci get network.lan_vlan.ports)
do
    uci add poe port
    uci set poe.@port[-1].enable='1'
    uci set poe.@port[-1].id="${_PORT/lan/}"
    uci set poe.@port[-1].name="$_PORT"
    uci set poe.@port[-1].poe_plus='1'
    uci set poe.@port[-1].priority='2'
done

uci commit poe

Might help if we rename SFP ports to something else than lanX so for PoE purposes we can make an easy distinction. But that involves DTS changes as well AFAIK.

With @mrnuke's latest code, it seems to work okay here on my GS1900-8HP v1 with 22.03 HEAD, 2 PoE+ clients. @walterav My GS1900-8HP v1 has two older BCM59111KMLG controllers, my GS1900-10HP has the newer BCM59121B0KMLG.

# ubus call poe info
{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 65.000000,
	"consumption": 6.700000,
	"ports": {
		"lan1": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Delivering power",
			"consumption": 3.500000
		},
		"lan2": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan3": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Disabled"
		},
		"lan4": {
			"priority": 2,
			"mode": "Legacy",
			"status": "Searching"
		},
		"lan5": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Disabled"
		},
		"lan6": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan7": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Delivering power",
			"consumption": 3.300000
		},
		"lan8": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"

walterav · 2022-06-15T11:07:00.392Z

If building and running a custom OpenWrt build with this gpio-hog removed from the DTS will this automatically bring back a list of GPIO pins you had and worth triggering by manually echo 1 to it?

github.com

openwrt/openwrt/blob/master/target/linux/realtek/dts-5.10/rtl8380_zyxel_gs1900.dtsi

// SPDX-License-Identifier: GPL-2.0-or-later

#include "rtl838x.dtsi"

#include <dt-bindings/input/input.h>
#include <dt-bindings/gpio/gpio.h>

/ {
	aliases {
		led-boot = &led_sys;
		led-failsafe = &led_sys;
		led-running = &led_sys;
		led-upgrade = &led_sys;
	};

	memory@0 {
		device_type = "memory";
		reg = <0x0 0x8000000>;
	};

This file has been truncated. show original

		compatible = "realtek,rtl8231-gpio";
		#gpio-cells = <2>;
		gpio-controller;
		indirect-access-bus-id = <0>;

		poe_enable {
			gpio-hog;
			gpios = <13 GPIO_ACTIVE_HIGH>;
			output-high;
		};
	};

walterav · 2022-06-15T11:44:13.215Z

Nice to see your progress on the 8HP but are you still using your earlier released realtek-poe package or already a newer compiled one?

md5sum Downloads/realtek-poe_2022-05-29-b07fbee9-1_mips_4kec.ipk 
4d1978aea888b73f6ff45b4e3a36001a

Borromini · 2022-06-15T12:02:34.874Z

This is the one I compiled this morning and have put up for download.

# opkg list-installed|grep realtek-poe
realtek-poe - 2022-05-29-b07fbee9-1

mrnuke · 2022-06-15T14:59:33.580Z

svanheule:

walterav:
TX -> 0x2a 0x16 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x38
RX -> 0x2a 0x16 0x00 0x11 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0xc1
Maybe it has something to do with how the port status is requested? A port index of 0xff isn't valid, but there still appears to be a reply. The all-zero reply from from port 0 is also odd (if the port isn't actually set as disabled, that is)

That request looks okay to me:

Hey, can I have request=0x2a, sequence id = 0x16, port = 0x00 ?
Sure, here's request=0x2a, sequence id = 0x16, port = 0x00:
- port 0 is 0x11
- port 1 is 0x10
- et cetera.

svanheule · 2022-06-15T18:26:15.720Z

Right, I should learn to read my own documentation:

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

The reply format was apparently documented incorrectly. Fixed that, and also updated the name of the first byte to first_port to make the sequence more obvious.

mrnuke · 2022-06-15T19:33:39.798Z

I think I figured out why the status shows as "unknown". It fixes the reporting, but not the power delivery aspect:

github.com

GitHub - Hurricos/realtek-poe at mrnuke-ufo-bug

mrnuke-ufo-bug

Contribute to Hurricos/realtek-poe development by creating an account on GitHub.

I've spotted found a few more realtek-poe bugs for devices with more than 8 ports. I would advise only testing the first 8 ports for the time being

@hurricos, should we start a matrix of which devices work/don't work, and what version of realtek-poe makes them happy?

svanheule · 2022-06-15T19:50:10.584Z

FWIW, the "get port status" command has enum status value 0x3 listed as "Test mode". If wonder if that corresponds to the classification stage, if that isn't already covered by "Searching".

Borromini · 2022-06-15T20:32:50.356Z

Tested with the latest commits on the GS1900-8HP v1. Output below. Seems a bit hit and miss though, with the package I compiled this morning, the switch (which I powercycled multiple times today) came up with just one PoE+ client out of two. Seems all good again now.

Updated 2022-06-15-b07fbee9 package here.

# ubus call poe info
{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 65.000000,
	"consumption": 7.100000,
	"ports": {
		"lan1": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Delivering power",
			"consumption": 3.400000
		},
		"lan2": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan3": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan4": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan5": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan6": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Disabled"
		},
		"lan7": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Delivering power",
			"consumption": 3.900000
		},
		"lan8": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		}
	}
}

mrnuke · 2022-06-15T20:43:42.753Z

Borromini:

Updated 2022-06-15-b07fbee9 package here.

Do you know how to make github build packages automatically?

Borromini · 2022-06-15T20:47:30.401Z

No, I don't. I just upload the packages from my local 22.03 buildroot. There should be a few community members familiar with GitHub's actions though...

Tested on my production GS1900-10HP in the meantime as well, only has PoE+ enabled on the first four ports. Looking good there as well.

walterav · 2022-06-16T20:01:06.869Z

Using your latest package I still get unknown in the POE status is that correct that its missing @mrnuke his patches?

mrnuke · 2022-06-16T20:10:00.788Z

Which ports show "unknown" ?