The manual of at least some of the GS1900-XXXX models states:
Note: The Rev. information is not shown on the back label of the A1 hardware version of
GS1900 Series models.
The manual of at least some of the GS1900-XXXX models states:
Note: The Rev. information is not shown on the back label of the A1 hardware version of
GS1900 Series models.
Do you know what these values mean? Is there a reference somewhere? Do these also work on other Netgear devices like the GS110TPP?
Shouldn't the above be added to the device recipe for (at least that) realtek switch Openwrt? Because I agree, this is a much nicer solution than having a flat unrestricted layer2 from U-boot until Openwrt VLAN setup.
Yes. The register descriptions are at https://svanheule.net/realtek/
I was too lazy to go through the docs and just used the values that were set when booting with rtk network on
. You can read from the files to get the current values.
It depends on the hardware configuration if they work on other devices, I wouldn't count on it.
Extracted from the above link, the registers break down as follows:
VAL NAME LSB BITS DESCRIPTION
LED_GLB_CTRL
0 RESERVED 31 1
0 BLINK_TIME_SEL_2 30 1
1 ASIC_CFG_8231 29 1
0 BUZZER_CMD 28 1
7 BUZZER_FREQ_SEL 25 3
1 BUZZER_SEL 24 1
0 BLINK_TIME_SEL 22 2
7 EXT_8231_GPIO_EN_2_0 19 3
0 LED_LOAD_EN 18 1
1 SYS_LED_MODE 16 2 Blink rate 1024ms
0 SYS_LED_EN 15 1 Enable (mux GPIO A0)
6 STEP2_PWR_ON_LED_2_0 12 3
5 STEP1_PWR_ON_LED_2_0 9 3
0 COMBO_PORT_MODE 7 2 No combo ports present; one and only one set of LEDs per port
0 LED_MDC_DUTY_SEL 6 1
3 P27_24_LED_MASK_SEL 3 3 Should always match LED_MASK_SEL_2_0
3 LED_MASK_SEL_2_0 0 3 Two active LEDs
LED_MODE_CTRL
0 RESERVED 30 2
31 P27_24_LED2_MODE_SEL 25 5 Disabled
0 P27_24_LED1_MODE_SEL 20 5 Link/Act
0 P27_24_LED0_MODE_SEL 15 5 Link/Act
31 P23_0_LED2_MODE_SEL 10 5 Disabled
15 P23_0_LED1_MODE_SEL 5 5 Link/Act 100M/10M
10 P23_0_LED0_MODE_SEL 0 5 Link/Act 1G
LED_MODE_SEL
0 RESERVED 4 28
1 PWR_ON_BLINK_SEL 2 2
0 LED_MODE_SEL 0 2 Bi-color scan
LED_P_EN_CTRL
0 RESERVED 28 4
0x000ff00 LED_P_EN_27_0 0 28 Set to a bit 1 to enable the LED output for the corresponding port.
I just went to check on my Netgear GS110TPP, and then on my other switches: I don't have the /sys/kernel/debug/
folder in my compiles. Otherwise I would have posted, if the values for the GS110TPP differ.
Maybe you disabled support for debugfs in your build or debugfs is not mounted (or mounted elsewhere)?
The call to mount
contains this output on my main switch (custom snapshot build) and on my main router (OpenWrt 23.05.2 stable)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
Yes, whoops, I had forgotten, that I had put
# CONFIG_KERNEL_DEBUG_FS is not set
# CONFIG_KERNEL_DEBUG_INFO is not set
# CONFIG_KERNEL_DEBUG_KERNEL is not set
into one of my template diffconfig blocks for my home "production" snapshot builds. My bad, sorry for the detour.
Btw, can somebody clarify, if the L3 HW offload and Bonding will be available for RTL83XX 6.1 onwards, and not only for RTL93XX. This comment on github by svanheule suggests (to me) that 83XX is capable of (some|limited) HW L3 offload.
To my understanding, the code in OpenWrt does not support that (yet). Why do you think it might be available with 6.1?
Happy New Year ya'll.
I'm sad to see, so little progress has been made here during my absence I'm suprised that the realtek target hasn't been removed yet from openwrt
Good job on fixing that mac address bug though! I think it was biting me at some point too, and you guys even got @Ansuel to participate in this thread
I'm not sure if I'll be doing any work here, I have a 4 paper weights in my closet, but collaboration needs to improve quite a bit I suppose. My stalled branches/Merge requests should still be good for the most part though
I have a couple of HPE OfficeConnect 1920 switches:
It doesn't look like either of them are supported yet.
I've done a bit of minor OpenWRT devel in the past (fixing some devicetree faults on a PowerPC based TP Link AP), and also some minor kernel device driver dev. I'm reasonably handy with a soldering iron, and have done a bit of microcontroller bare metal dev so could probably get JTAG working if there are board headers.
Any tips for getting started? Is there value in getting the GPL sources from HPE (or H3C if easier)? I haven't been able to find those online anywhere...
@janh has working patches for the JG927A - see here. I use it as my main switch for quite some time now - just search this thread.
Thanks - I'd previously used the forum search ("in all topics and posts") for JG927A, but it looks like the search results only show the first matching post in each thread, so I missed those ("in all topics and posts" could perhaps do with some UI rework!). I'll give that branch a spin to start off with...
I've tried a long time ago, both with HPE and H3C, and got nowhere. Something tells me they aren't going to get more cooperative as time goes by...
The sources we've collected over time are at available at https://svanheule.net/switches/gpl_source_drops
Thanks. HPE now have a web page requesting that you snail mail them $10 addressed to their legal department (I have a letter drafted and a relative who lives in the US who will probably post it), so if it might be useful I'm happy to try...
I'm working on a port to GS110TUP, which is very similar to GS110TPP, and have noticed some odd behavior... when my switch is connected to the rest of my network only by port 9 (on a QSGMII PHY) and nothing else is connected to the switch, it tends to reboot randomly, on the order of every few hours. Sometimes it'll last a full day but rarely much more than that. There's no error or panic message on the UART, it's just suddenly back in U-Boot.
This reproduces with the factory firmware as well, but it doesn't happen if I have devices connected to one of the first 8 ports (the onboard PHYs).
Has anyone else seen this behavior, or can someone with a GS110TPP try to reproduce this? Do I have marginal hardware or is there some kind of undocumented watchdog?
Hello everyone,
I have now received my Zyxel GS1900-10HP (A1).
I have installed the initramfs-kernel.bin using the OEM Easy installation. However, the device is now booting into an undefined state for me.
PWR is lit, SYS is not lit, port activity is displayed.
The switch is behind another router and is not assigned an IP, communication from the computer (via switch) to the router is possible.
An arp -a on the router only shows me the IP of the computer. The last known IP (with stock firmware) cannot be pinged. SSH to switch is impossible.
Presumably I now have to use the serial console?
Is it true that the PIN assignment is different from the one printed on the device (according to the OpenWRT wiki page)?
Do I only connect Tx, Rx, GND and the power supply or what do I have to consider?
Best regards and many thanks!
which version?
The default management address should be 192.168.1.1/24 like any other OpenWrt device.
what do you mean? The pinout is
Pins are from top to bottom Vcc(3.3V), TX, RX and GND.
as stated on https://svanheule.net/switches/gs1900-10hp . This matches the print on the board ("VCC SOUT SIN GND").
only connect Tx, Rx, GND to a USB adapter. The adapter is powered by the USB bus. You should make sure the IO voltage of the adapter is 3.3V.
Thank you for your fast reply.
Latest 23.05.2
You're right but, the device does not provide a DHCP Server. I doesn't get an IP-Adress if I'm connected without the router.
The first part of https://openwrt.org/toh/zyxel/gs1900-10hp#serial
And i doesn't power the switch?
Greetings.
That's right. It's a switch, not a router. You can add whatever packages and configuration you want later, but you'll need to use a static address in the same subnet for the initial bootstrapping.
Weird. I've used https://svanheule.net/switches/gs1900-10hp as a reference and can't remember having any issues with that (I have a permanent console connection on both my GS1900-10HPs). But serial labelling can be confusing, so who knows. The first thing to try if it doesn't work is swapping TX and RX.
It's too cold to go out in the garage to check right now. Or I'm too lazy..
Yes, you'll power the switch. Usually after connecting the serial console so that you can capture the boot sequence from the beginning.