Open Hurricos opened 2 years ago
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:
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).
OK, I should probably close this as a WONTFIX: this behavior is mirrored by the OEM FW.
Let's at least understand why we CANTFIX/WONTFIX.
Are you sure pinSet 5 0
is not a restart-gpio? See for example:
If you are in linux, and set this GPIO to zero, will linux also reboot? Then we probably need to update the DTS.
You can check # cat /sys/kernel/debug/gpio
to see the GPIOs that linux undestands, and map them to the uboot gpio numbers.
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).
You could put a scope probe or LA probe on the poe-enable line.
Can confirm @Hurricos statement that this is also OEM ZyXEL firmware behaviour.
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.
Upon reboot, at least the ZyXEL GS1900-24HPv1 will reset the MCU, which is annoying as attached PoE devices will reset.