Perhaps these devices follow a pattern similar to the D-Link DGS-1210 series where early versions used the Marvell SOC and then a Broadcom SOC and finally the Realtek RTL838x SOC. I've noticed early versions of the TRENDnet TPE switches also switched from Marvell to Realtek without changing the base model number (i.e. just using a different Version #).
I've added the HPE 1910 series to the wiki because I encountered the model numbers in my 1920's firmware. Comparing it to your list of model number, the fast ethernet models would be Realtek-based, while the gigabit ethernet models (1910-xxG) would be Marvell based. I'll update the wiki.
1910-8 Switch JG536A
1910-8-PoE+ Switch JG537A
1910-24 Switch JG538A
1910-24-PoE+ Switch JG539A
1910-48 Switch JG540A
Thanks. Makes sense. I didn't think HPE played the D-Link game, so I expected different model numbers for different hardware. But splitting parts of the family with or without a "G" fits the bill. FWIW, the "JGxxxxx" part numbers are very useful as unique hardware identifiers.
@anon13997276 @bmork I'm looking at getting a ZyXEL GS1900-10HP myself. From the wiki entry it looks like there's no soldering involved, just connecting a serial cable? Do you guys have any step by step flash instructions you could share?
Thanks!
I have not flashed the Zyxel GS1900-10HP as I am still booting sometimes the OEM firmware for comparison. So far only initramfs. But I am 100% sure just doing sysupgrade from within the initramfs will work. The switch is very well supported: PoE works, the SFP ports are supported directly by the Linux kernel SFP modules. Getting into initramfs is also straightforward: attach serial cable, interrupt OEM boot to get into u-boot, issue "rtk network on" and boot via tftp as mentioned already in the forum. If there is any issue I'll help.
2 Likes
Correct, no soldering required. You don't even need to open it. The pin header is angled, and there is a matching hole in the case. The pinout in the wiki is correct.
Installation instructions as @anon13997276 mentioned:
rtk network on
tftpboot 0x84f00000 192.168.1.150:openwrt-rtl838x-zyxel_gs1900-10hp-initramfs-kernel.bin
bootm
and then sysupgrade.
One additional note: The vendor firmware splits flash in dual partitions. OpenWrt will only be able to install and boot from the first of these, due to the fixed "firmware" partition in the DTS. So if you want to keep the vendor firmware on the other partition, which can be very useful while testing, then you have to make sure this is installed in the second one.
The active partition is selected by the "bootpartition" variable in the second u-boot environment. It can probably be manipulated from OpenWrt using the standard u-boot tools. Or from the u-boot prompt with e.g
setsys bootpartition 0
savesys
There is also a "boota" macro which will let you set the next boot partition and boot it in one go:
boota 0
Note that this will save the bootpartition variable to flash, making the selection persistent. For an occasional vendor firmware boot it might be useful to keep OpenWrt as default, only temporarily switch to the other one with
setsys bootpartition 1
boot
This will not change the persistent selection.
It might be possible to make OpenWrt support the dual boot scheme to some degree, but I don't see how this can be done without any risk. OpenWrt will then need to figure out the partition for the rootfs at runtime. The only information available will be the bootpartition variable, which does not necessarily match the currently booting system as described above. Or analyzing the contents of the two partitions. But if both contation the same Openwrt installation and the bootpartition variable was changed in RAM only, then the guesswork will fail. So I believe we are actually better off with a strict rule saying that OpenWrt must use the first partition.
This issue is not a problem for the vendor firmware because it only writes to shared config partitions, except when upgrading of course.
In case anyone wondered about my sudden silence after all the noise I made on this subject: I had to put the GS1900-10HP into service, and ended up using vendor firmware for now due to the problems with duplicate packets when mixing tagged and untagged ports. And it's installed in a location without any real console possibility (only accessible via fiber terminated in the GS1900-10HP). But I have ordered a Netgear GS108Tv3 for further experiments with this OpenWrt target 
3 Likes
Thanks! I thought I saw kobi say he fixed a duplicate packet issue - that wasn't the one you were experiencing then?
Could very well be. It's been a few days since I had to stop my testing. I noticed some promising patches since then.
I am hoping to get the GS108Tv3 by Monday and continue the testing then.
Sounds like a wonderful target for OpenWRT. The datasheet says "Cloud Manageent ... Specifically for these 2 new models, additional features were added for full flexibility: Single Sign-On registration for firmware and security updates and warranty entitlement.". It would be great if you could share your findings on biot's wiki.
I think we got a good way forward with the VLANs. One conclusion was that the individual ports need MAC-addresses for STP to work properly, which was one reason for duplicate packets. It would be great to try again.
1 Like
I would need write access there then..
For the curious: Got the GS108Tv3 yesterday. Got the basics running. The Netgear cloud stuff is frightening, but still optional. They require you to register for an unlock key to get unrestricted local web management. But you are always allowed to do local firmware updates, so it's actually possible to convert to OpenWrt without registering and without console (eventually). I tested uploading OpenWrt using the Netgear web gui. This sort of works, but the upload is limited to the size given by the uImage header so it will only work with the initramfs images. Still allows a console-less conversion in two steps.
The boot loader verifies image magic, and the magic is non-standard. So mtdsplit must also be updated to make this switch run OpenWrt from flash. I'm wondering if we shouldn't just put a few parameters in the DTS for mtdsplit? Seems unnecessary complicated to have to patch it for every one of these devices with unique magic.
Console is available on J1. Header must be soldered. There is a Kensington Security Slot in the case right behind J1 - just the right size hole for a console cable. Note that the header must be angled or very low profile if you want to use it with the case lid on.
The VLAN issues are pretty much the same, unfortunately. Most stuff works, but there are some problems if you mix tagged and untagged. But this means that I do have a nice testing ground. If I only knew where to start....
1 Like
Are you using VLAN-filtering or just bridging VLAN interfaces?
One point to start is to check whether the current driver code does the same with regards to VLAN setup as the GPL-dropped SDK code does. You can find that code linked from biot's wiki. The vlan configuration for the 8x is done in this file: dal/maple/dal_maple_vlan.c . For 9x replace maple with cypress.
Something I don't understand with regards to the SoC is that there are inner and outer PVIDs. Currently they are both set to the same PVID. But maybe that is wrong, have a look at rtl838x_vlan_add() being called by the DSA layer for what is being done.
Does the Realtek trailer tag has a reason field? i.e. the reason why it is forwarded to CPU.
No, because this is what DSA uses and it would not know what to do with it, but the Realtek CPU-Tag has such a field. Have a look at rtl838x_hw_receive(). Reason codes are listed at https://biot.com/switches/description_of_the_rtl_socs
Then you'd better use the reason field to set skb->offload_fwd_mark in tagger_rcv() accordingly, otherwise you will see some duplicated frames.
skb->offload_fwd_mark = 1 means the frame is already forwarded/flooded by the HW so the Linux bridge won't forward/flood it again.
1 Like
Thanks for the tip. I will investigate.
I am using VLAN-filtering. That's what UCI wants, and the behaviour most users expect too, I believe.
FWIW, the filtering does not make any differenct wrt tagging as long as the driver sets configure_vlan_while_not_filtering. Which it should do (all new DSA drivers should according to docs), but does not yet.
Thanks. Yes, I noticed the inner/outer PVID thing and had a hard time visualizing that. Does not really compute in my head. If you add 5 SVLANs to a port, then each of those could have a distinct inner PVID in theory. Or not? Imagine that each of those SVLANs represent trunks from other switches.
For now, I'll stick to the really simple stuff and pretend there is at most one PVID configured on a port
Looking at https://lkml.org/lkml/2020/9/23/154
things still seem to be in a lot of flux with regards to DSA and VLAN filtering.
Thanks a lot for that pointer! I just tried it, and the duplicates are gone. (BTW, I believe we should create a dedicated tagger instead of conditionally modifying the existing "trailer" tag. That is never going to fly upstream.)
The only problem is that the packets going away were the tagged ones, so now nothing works 
But at least it makes sense. I exported the RTL838X_VLAN_PORT_PB_VLAN registers in debugfs to experiment with different settings there. Problem was that no matter what I did, it didn't change anything at all. Not even the VID. Which I could not explain until now. But of course: The VID I saw in the tagged frames came from the bridge code and not from the switch hardware.
So the problem is reduced to figuring out how to make RTL838X_VLAN_PORT_PB_VLAN do something useful. Will try to decipher the pasta mess now