Hi Sander,

I don't have the GS1900-48 at hand or even my records. I am on vacation and I 
will only
be back in 10 days, we actually got stuck here in quarantine...
You can also test the GPIO access in U-Boot using md.l and mw.l using the the 
indirect
access register. I tested this once for the indirect table access registers and 
that
worked.
But I looked up when the GS1900-48 was released and it was around since at 
least 2013.
I would be surprised if there are _not_ different versions around. We know that 
there
_are_ actually different version with regards to the SoC. They use at least 3 
different
processor generations including different work-arounds necessary. Have a look 
at the
forum on issues with reading non-existing PHYs and the port flooding table, 
which in SoC revisions
< D cannot be read and requires a shadow table (not implemented, since we 
always flood to
all ports, because port isolation overrides this anyway).
On the warning: At least the initial warning came from the lock debugging I 
compiled in,
which is based on Daniel's standard settings. IIRC, the lengthy warning was 
about
sleeping in the wrong context, maybe there was also something about an issue 
with lock
contention.

Cheers,
  Birger


On 24/02/2022 21:19, Sander Vanheule wrote:
On Tue, 2022-02-22 at 23:39 +0100, Birger Koblitz wrote:
Hi,

the information on the external GPIO resetting the board of
the Zyxel GS1900-48 comes from the hardware configuration
reported by the stock firmware. It says:
GS1900# show board
[...]
====== Reset =================
Type: GPIO
GPIO: EXT_5
[...]
Using the rtk gpio commands in u-boot this can be confirmed.

Can you list the commands that you used to test this? My bootloader only supports 
"rtk
network ..." and "cst pinSet ...".


On 22/02/2022 23:00, Sander Vanheule wrote:
On Mon, 2022-02-21 at 21:23 +0100, Birger Koblitz wrote:
Hi,

I just checked with my multimeter, and while the GPIO5 on the RTL8231 does go
high/low
when I set the output high/low from Linux, my device certainly doesn't reset. 
The
other
GPIO lines on the chip do work, since SFP modules are correctly detected.

Birger, just to be sure, can you confirm that your device does reset with GPIO5 
on
the
RTL8231?

Yes, it does.There is a warning, but then it reliably resets. That was why I 
left it
in as is.

I had another hard look at my board, to check if something may be wrong 
physically,
but I
cannot find anything. My device's board looks identical to the pictures on the 
switch
wiki
[1], which I think you uploaded earlier.

There is some reset logic on the board [2], but I cannot figure out how GPIO5 
would be
connected to it electrically. Unless I missed a via connecting to that pin on 
the
RTL8231,
GPIO5 only appears to lead to TP2. GPIO5/TP2 does not appear to be connected
electrically
to any part of the circuit next to SW1. I could add a bodge wire to connect TP2 
to pad
U25:3, but gpio-restart should really work on unmodified hardware.

[1] https://svanheule.net/switches/gs1900-48#board_details
[2] https://svanheule.net/switches/gs1900-48#hard_reset_circuit


Having another look at the source code of gpio-restart, the WARNING-s I 
reported in the
patch's commit message occur at the following points of the GPIO output 
waveform:

      |< 100ms >|< 100 ms >|<   3000 ms   >|< Restart failed
_____|_________|          |_______________|__ [ active ]
_____X         \__________/                   [inactive]
       |        |          |               |
       |        |          |               ^ WARN @ 
drivers/power/reset/gpio-restart.c:46
       |        |          |
       |        |          ^ WARN @ drivers/gpio/gpiolib.c:3098
       |        ^ WARN @ drivers/gpio/gpiolib.c:3098
       |
       ^ Restart should already occur here


If everything is set up correctly, the system should restart before execution 
reaches the
point where a warning can be emitted. If you say that you see a warning (any at 
all),
AFAICT that means gpio-restart is not working.

As they say, the proof of the pudding is in the eating, so I soldered a jumper 
wire
between the RTL8231's GPIO5 pin (U38:25) and the line driven by the hard reset 
button
(U25:3) [https://svanheule.net/switches/gs1900-48#hard_reset_circuit].
As expected from the analysis above, this results in a system rebooting without 
_any_
warning (using an initramfs from yesterday's snapshot builds):

root@OpenWrt:/# reboot
root@OpenWrt:/# [  185.092891] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 
not supported
[  185.101879] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  185.111835] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  185.120484] rtl83xx_fib4_del: found a route with id 1, nh-id 0
[  185.127681] rtl83xx-switch switch@1b000000: unknown nexthop, id 0
[  185.149505] rtl83xx-switch switch@1b000000: unknown nexthop, id 0
[  185.157262] rtl83xx_fib4_del: found a route with id 2, nh-id 0
[  185.164418] rtl83xx-switch switch@1b000000: unknown nexthop, id 0
[  185.173391] rtl83xx_fib4_del: no such gateway: 0.0.0.0
[  185.225492] device lan01 left promiscuous mode
[  185.230976] switch: port 1(lan01) entered disabled state
...
[  187.735562] device lan50 left promiscuous mode
[  187.741075] switch: port 50(lan50) entered disabled state
[  187.794104] in rtl838x_eth_stop
[  187.797945] rtl838x-eth 1b00a300.ethernet eth0: Link is Down
[  188.329431] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  188.337562] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  188.345649] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  188.353736] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  188.543709] rtl83xx_fib4_del: no such gateway: 0.0.0.0
[  188.549982] rtl83xx_fib4_del: no such gateway: 0.0.0.0
[  188.559077] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  188.567226] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  188.576283] rtl83xx_fib4_del: no such gateway: 0.0.0.0
[  188.582679] rtl83xx_fib4_del: no such gateway: 0.0.0.0
[  192.871878] reboot: Restarting system


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

CPU:   750MHz
DRAM:  128 MB
FLASH: 16 MB
Model: ZyXEL_GS1900_48
SN:    S182L05000541


Best,
Sander


_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to