Device reboot can also interrupt PoE delivery on ZyXEL GS1900-24HPv1

[Hurricos]

Upon reboot, at least the ZyXEL GS1900-24HPv1 will reset the MCU, which is annoying as attached PoE devices will reset.

[Hurricos]

Moved from #5.

There is an interesting U-boot command on these ZyXEL switches called cst pinSet/pinGet:

RTL838x# cst pinGet
Usage: cst pinGet <pinNum> 
 pinNum: 0~36

It is (probably) connected to the RTL8231 on the SFP side of the board (as cst pinSet never changes an LED status light).

Behavior:

• pins 0-2 are read-only (do not respond to pinSet)
• pin 3 is default '1', but 1s after accepting a write, it bounces back:

  
  RTL838x# cst pinSet 3 0
  pin3:   0

RTL838x# cst pinGet 3
pin3: 0

RTL838x# cst pinGet 3
pin3: 1

- Running `cst pinSet 5 0` reboots the switch, (pin 3 on `gpio1`, maybe?)
- Appears that the rest of the pins are read-only. This includes "pin 13".

I can open the device and trace these GPIOs a bit to see what U-boot is actually doing here.

I'm not actually with the switch -- doing this remotely now -- but I plan to follow up on this one:

> Let me attempt to invoke a reboot from the OEM FW.

... once I can actually get shell access to the PoE sink (so I can verify it's rebooted when I reboot the ZyXEL switch, as I have no clue how to check link state under ZyXEL's OS).

[Hurricos]

OK, I should probably close this as a WONTFIX: this behavior is mirrored by the OEM FW.

[mrnuke]

Let's at least understand why we CANTFIX/WONTFIX.

The reboot gpio issue

Are you sure pinSet 5 0 is not a restart-gpio? See for example:

https://github.com/openwrt/openwrt/blob/7bf73e270e7f1704b21860712820dcf12b593e91/target/linux/realtek/dts-5.10/rtl8380_engenius_ews2910p.dts#L66-L69

If you are in linux, and set this GPIO to zero, will linux also reboot? Then we probably need to update the DTS.

The PoE cut-off issue

You can check # cat /sys/kernel/debug/gpio to see the GPIOs that linux undestands, and map them to the uboot gpio numbers.

[Hurricos]

If you are in linux, and set this GPIO to zero, will linux also reboot? Then we probably need to update the DTS.

Yes. I mistook the reset key (which is an inbound GPIO for the kernel to read as a reset request) for the reset pin (which is an outbound pin to reset the board).

I thought, "reset should be pin 3 of this GPIO expander", before turning to poke a bit harder:

root@OpenWrt:/sys/devices/platform/rtl8231-gpio/gpiochip1/gpio/gpio456# cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 451-487, parent: platform/rtl8231-gpio, rtl8231, can sleep:
 gpio-454 (                    |reset               ) in  hi ACTIVE LOW
 gpio-464 (                    |poe_enable          ) out hi 
:

I then exported 5 (456), but it was the wrong direction:

root@OpenWrt:/sys/devices/platform/rtl8231-gpio/gpiochip1/gpio/gpio456# grep -e '' *
active_low:0
direction:in
value:1

It's an inbound GPIO, so maybe it was a mapping issue? Let's look at the others:

root@OpenWrt:/sys/class/gpio# seq 451 487 | while read line; do echo $line > exp
ort; done
ash: write error: Resource busy
:
ash: write error: Resource busy
root@OpenWrt:/sys/class/gpio# cat gpio4*/direction
in
in
in
in
in
in
in
in
in
in
in
in
in
in
in
in
in
in
in
in
in
in
in

Uh-oh. They all default to in. Maybe that's just the default. Let's try changing it.

root@OpenWrt:/sys/devices/platform/rtl8231-gpio/gpiochip1/gpio/gpio456# cat dire
ction
in
root@OpenWrt:/sys/devices/platform/rtl8231-gpio/gpiochip1/gpio/gpio456# echo out
 > direction

U-Boot Version: 2.0.0.59413 (Jul 08 2015 - 10:01:00)

CPU:   500MHz
DRAM:  64 MB

The rest is history. So yes, the DTS will need a tweak.

U-boot defaults pin 13 to high, so either the BootROM somehow sets it low, early U-boot sets it low before setting it high again, or there's some other mechanism disabling power (e.g. the MCU resets, or the MCU loses power, or the power sub-board loses power, or there's some other dependency the MCU loses access to).

[mrnuke]

You could put a scope probe or LA probe on the poe-enable line.

[walterav1984]

Can confirm @Hurricos statement that this is also OEM ZyXEL firmware behaviour.

[svanheule]

Uh-oh. They all default to in. Maybe that's just the default.

It is the default. I suppose that could be changed, so the driver doesn't touch the bootloader's pin configuration.