Bringing support for realtek-poe to mainline OpenWrt

OK, then you can disregard my comment.

This is correct: There is either a TI MAX3232 or SIPEX 3232C that turns the CPU's 3v3 UART into an RS232 capable of handling a wider voltage range. (If you correct the pinout and pierce the front panel, you could even add a DB9 connector.)

1 Like

You will need the serial console, unfortunately. The OEM firmware pokes what looks like a secondary u-boot partition (u-boot-env2 / sys) using setsys; you will want to reuse this part of my commit to change which partition boots by default:

* Since the GS1900-24HP v1 is a dual-partition device, you want to keep the
  OEM firmware on the backup partition for the time being. OpenWrt can
  only be installed in the first partition anyway (hardcoded in the
  DTS). To ensure we are set to boot from the first partition, issue the
  following commands:

  > setsys bootpartition 0
  > savesys

In this case, use (probably) setsys bootpartition 1 to get back into ZyXEL, or just use the whole U-Boot TFTP method:.

Made some more research of my install problem.

  1. I can install the patch on my clean buildroot. And it works.
  2. I can copy the realtek-poe package from the above buildroot and clone a new clean buildroot and past the above realtek-poe folder to the package folder in the new buildroot and it work.
  3. But if I save the realtek-poe folder in the github cloud repo and download a new buildroot with the realtek-poe folder preinstalled in the package folder. Well it builds and installed the realtek-poe package but realtek-poe doesn’t work and it cant be turned on!?

I can’t get why it can’t work from a github download, it is the exactly the same files and setup on all three cases!?

How do I get this package preinstalled in my github repo?

Wondering if the poe_cmd_global_port_enable(0) call is really required?

This makes testing much more annoying than necessary, by toggling power to all attached devices every time the daemon is restarted. I have a setup where my "router" (RPi4) is powered by the switch. Having it lose power for each new test is not an option. Removing the line doesn't seem to break anything for me.

1 Like

I don't think it's strictly required. The question I haven't figured out is if the port settings will stick if modified with the port enabled. As far as keeping ports alive on daemon restart, more finesse is needed. Ideally, we'd query the PoE for the current state, and not touch the settings if they already match the config file.

So yes, we can probably drop the global disable call, but we need something to replace it when changing port settings.

The MCU should stay online as you reset the main SoC.

But, there is a snag: you have to be careful to keep the remote disable GPIO in the right state (is it always connected?), otherwise the PoE may end up being disabled anyway.

My experience on RTL8380M has been that gpios come up as inputs, pulled high. That should solve the concern for current use cases.

Is the Hurricos realtek-poe the repo that we aim to implement to OpenWrt in this forum tread?

It's based on blogic's C implementation, so yes.

@Degenerate Have you already gain serial access on the GS1900-24HP?

The levels are RS-232 not 3,3volt and I had to ditch the breakout cable setup from GS1900 J5 motherboard to DB9 male (ICD10-DSUB-breakout) to null-modem to usb serial DB9 male for a short 3 pin direct connection.

To quote myself...

Its still a little puzzle to figure which corresponding pins on the USB rs232 DSUB but you'll get there by googling default pinouts.

EDIT: I see the pinout in the commit is different, but I did this before there was a commit so please let us know which pinout is correct (5 vs 10)?

* 'J5' RS232 Pinout (dot as pin 1):
  2) SoC RXD
  3) GND
  10) SoC TXD

@hurricos is it possible to host the compiled opkg package on your github release section matching the latest 22.03rc3?

Or does the whole OpenWrt firmware needs to be compiled with specific POE related bits for the GS1900-24HPv1?

I assume that this effort is still making use of the config file created by the ucidef_set_poe in board.d/02_network file. I'm working on support for the ZyXEL GS1900-24EP which has POE only on the first 12 of 24 ports. The current logic for ucidef_set_poe is to call the function with the arguments for the power budget and the lan_list. I'm looking for a good way to limit the lan_list to the first 12 ports. If anyone has any suggestions I would appreciate it.

If we'd switch to sort -n it should list the port numbers normally (ie 1...9 10 11 12 ...) and not 1 10 2 ... like it does now.

Unless we look for another way to hardcode the amount of PoE ports, you could introduce a custom case for that model with sort -n|head -12?

Edit: this is the logic, maybe some variable mangling can suffice. If not, it will have to be split out and handled on a per-device basis.

lan_list=$(ls -1 -v -d /sys/class/net/lan* | xargs -n1 basename | xargs)

1 Like

I've been wondering what the history and purpose of the "poe" node is. There is no consumer for it.

You could use it as-is in realtek-poe, but you really want a nominal budget and a guardband for these BCM controllers. Such info is not in the "poe" node.


Not the biggest of bugs but I found on line 207 (and maybe to many spaces on line 208) the "trailing white space warning" that comes when installing the original patch.

Remove the spaces on line 207 and the installation warning is gone.

I'm also on a GS1900-24HPv1 and I would love to get PoE working. So far, I've compiled your realtek-poe package and installed it, but it doesn't seem to work. The port status is either "Searching" or "unknown", in any case, it doesn't deliver power. Is this the expected behavior thus far?

What poe controller and “in between communication CPU” do you have on the PCB?

That's what I've seen for quite a while on my GS1900-8HP v1. Now it's back to normal, no idea how and why though. Try lowering the PoE budget in your config and see if that works. Does the 24HP v1 have a dual partition layout so you can switch back and forth between OpenWrt and OEM so you can check if the OEM firmware works as advertised?

I've got the same device as the OP, that's why I replied here. I did not disassemble the device, but there should be an STM 32F100 and 6x BCM59111 on the board.

Yes, it has dual-partition design, but I think that I need serial console to switch between the partitions.