Not sure if I'm the right person to answer this.
But are there any differences we need to put in the dts at all? Except for the board layout, the hardware seems to be the same?
The more I look at it the more it looks like, yes. this v1 is running the latest firmware (September 2020), and the v1 came onto the market around 2013 or 2014. I just figured out the RAM chip and it's 128 MiB as well, so just like the v2 and the 10HP.
Only question left would be if a firmware upgrade from the OEM interface (if it ever gets to that) would differentiate between v1 and v2? Would that warrant split out DTSes? Or is that a problem that can be tackled when it presents itself? 
1 Like
Ah, yes. HPE played Mikrotik game.
Anyway, that's some good news, I would be grateful if you'd share your findings here, when you're done. I'd very much like to get in touch with them as well. Or you could possibly also mention JG537A while at that 
Not sure though if the people you're discussing with would be right for "ex-Aruba" hardware like my J9980A, but.. who knows. It introduces itself this way:
HPE OfficeConnect Switch 1820 24G J9980A, PT.02.09, Linux 3.6.5, U-Boot 2012.10-00116 (Jul 30 2014 - 10:52:01)
So for me it looks like a worthy candidate for porting. Same goes for Netgear S3300-28X, one of which I also have, but enough of this offtopic, they're not Realtek devices.
The OEM firmware is shared between all(?) the different GS1900 models, even the ones with more ports and therefore another SoC variant. So creating shared upgrade packages should not be a problem.
By experimenting a bit I found that the ZyXEL OEM firmware upgrade prcess checks three parts of the image:
-
the U-Boot image magic must be that special 0x83800000
-
the four letter hardware identifier must match one of the versions in the list at the end of the image
-
The new version must be larger than some pre-configured minimum version (this refers only to the version number in the appended support-list - the version in the image header is not checked)
Note: the boot loader does not validate any of this on the ZyXELs. Not even the magic. This list is only relevant for flashing from the OEM UI.
The last check seems to match version numbers found in the (binary only) boardconf.ko module in the OEM firmware. My GS1900-10HP insists that the version must be 2.10 or greater. This matches the strings we can dump from board_conf.ko:
GS1900-10HP
RTL8380M
V2.10(AAZI.0)
V2.60(AAZI.2)
GS1900-10HP
V1.0.
The two entries for the 8HP variants both have the same four letter id, but seem to specific different minimum versions:
GS1900-8HP
RTL8380M
V1.00(AAHI.0)
V2.60(AAHI.2)
GS1900-8HP
V1.0.
GS1900-8HP
RTL8380M
V2.10(AAHI.0)
V2.60(AAHI.2)
GS1900-8HP
V2.0.
This means that any image claiming to be version 2.10 or higher and supporting "AAHI" will be flashable from OEM on both 8HP revisions. I believe the fact that they reused this code on both revisions is a strong indication that the hardware differences are mostly irrelevant to software.
We probably need to make the ZyXEL four letter id a device variable so we can create initramfs images which only will be flashable on matching hardware, since we (most likely) will end up producing different images for models with a different set of ports etc. But we can derive that map from the string dump of board_conf.ko so that won't be a problem.
4 Likes
Yeah, sent in a patch set this morning but I think I should rewrite the Makefile part like the DGS-1210 series.
Thanks for the insights!
There is news from the hacking front: We have managed to get the Zyxel XGS1210-12 to run experimentally under OpenWRT. The switch has 8 x 1GBit ports, 2 x 2.5GBit ports and 2 SFP+ cages for up to 10GBit.
So far all the Ethernet ports work, including the 2.5 Gig ports. The 10GBit SFP+ ports are work in progress:
[ 1022.703251] rtl838x-switch 0.switch lan9: phy link up qsgmii/2.5Gbps/Full
The XGS-1210 uses an RTL9302B SoC. These SoCs are part of the RTL9300 Series of Realtek SoCs which are the modern siblings of the RTL838X SoCs . They provide up to 28 10GBit ports. Work has also already started on the 9310X Series of SoCs and we have manged to boot a Zyxel XS1930-10 with an RTL9313 SoC. The RTL931X SoCs are the newer siblings of the 839X SoCs from Realtek and allow to have up to 56 10GBit ports.
We are also working hard to mainline the driver code and patches have been sent to the various Linux subsystem lists to get the initial support for the 838x and 839x SoCs in. In parallel we will update the drivers in OpenWRT to support the new SoCs and devices.
14 Likes
Cool stuff 
Just got access to a TRENDnet TPE-082WS. Created a page on wikidevi and also on biot.com. My photo of the board is almost identical to the photo of the D-Link DGS-1210-10P. The only noticeable difference is the TRENDnet has 256MB of RAM instead of 128MB. Serial pins are populated and I was able to access U-Boot (2011.12). Show flash information shows the following:
Partition Used Available Use%
Boot 1310720 0 0
Image1 13365280 790496 94
Image2 13365280 790496 94
FileSystem 319488 3612672 8
I will be working on a DTS file using the D-Link DGS-1210-10P as a base.
3 Likes
Has anyone tested how much throughput the realtek chips can handle to route between different subnets?
This cannot be answered properly at this time. The RTL838X based devices will certainly be slow as the single core MIPS CPU at 500MHz is not very powerful and there is no L3 offloading. Not even the Ethernet driver has been optimized for performance. The RTL839x based devices have a newer 34Kc CPU but the drivers do not yet make use of the hyperthreading, nor is the Ethernet driver optimized. It might even be possible to do simple offloading of routing between subnets, but this has not been investigated fully so far. The RTL9300 based devices such as the the Zyxel XGS1210 can do L3 offloading and should be able to route between subnets at wirespeed, same for the RTL931X based switches (e.g. Zyxel 1930-10). However, this has not been implemented, yet.
2 Likes
Thanks, but the question was targeted on the current state of this target with software routing and probably with enabled software offloading.
If anyone has tested this so far or will do tests in the future, I'm interested in the results how good it's now.
My first PoE AP arrived yesterday, so far I'm just testing PoE 'stability' on my GS1900-10HP (AP isn't in use yet).
# ubus call poe info
{
"ports": [
"2.6W",
"off",
"off",
"off",
"off",
"off",
"off",
"off"
],
"power_budget": "77W",
"power_consumption": "2.6W"
}
EAP235-Wall has been up for over 12h now. Will keep an eye on it.
2 Likes
I have the Zyxel GPL source drop for XGS1210-12 if people need it. Appears to be a 3.18.24 based Linux kernel.
I'm curious to mod it to make the 10G SFP+ ports support 2.5G SFP GPON.
Hi Liz, thanks for the interest in helping with this, very much appreciated!
To start with, look into the SDK code of the GPL sources and locate dal_longan_construct.c this contains the init code for the SerDes (also SDS) of the RTL930X SoCs. Note that this SoC family is code-named Longan, ignore all the other trees (physical) in the source code. In our tree (figurative, latest code here: https://github.com/bkobl/openwrt/tree/master), locate the rtl930x_mdio_reset function and have a look at how it initializes the SerDes and does a mapping between MAC-numbers and PHY numbers as well as MDIO busses (called SMI). Locate also rtl9300_sds_power() to see what is there. Maybe a first task would be to find a concept of how to put that mapping into a .dts so it can be changed, there are a couple of TODO marks as pointers? Finally you need to add initialization code into rtl83xx-phy.c. Look at rtl9300_sds_rst(). The table there actually refers to registers, 0x0194 actually is RTL9300_SDS_MODE_SEL_0_ADDR, see swcore_rtl9300.h in the SDK. To make the 10GBit ports work, you need to figure out what needs to go into rtl9300_configure_serdes() from dal_longan_construct.c
Have fun!
Guys, a question about manipulating the u-boot variables on the GS1900-10HP - if i use fw_setsys to change the boot partition to 1 (OEM firwmare), is that persistent, and will it keep booting to the ZyXEL firmware until I manipulate the u-boot settings again? Or is this just a one-time boot to partition 1 and will it then revert to partition 0 again?
Asking because I haven't gotten the serial up on the 8HP and I'm hoping to be able to test @bmork's factory image patch this without it 
# fw_printsys|grep bootpartition
bootpartition=0
It's persistent. The only way you can set it temporarily is using serial to access the u-boot shell.
1 Like
Alright thanks. Will need a bit more time then. I'll report back on your patch set.
Does anyone have any idea what chip is intended for the solder mask at U17 on the DGS-1210-10P or U25 on the DGS-1210-28P? This chip would allow mounting an RJ45 at J7 on the 10P or J17 on the 28P to provide an RJ45 serial console. The front panels on both models already provide a slot in the metal for the port!
On biot.com wiki page 'Hardware owners and quirks' does anyone know what the columns for "3/4 byte addr mode" and "Needs PLL reset" are referring to?
There used to be a confusing situation with regards to how the flash was being read either in 3 or 4 byte mode and the PLL (frequency) of the flash access on RTL838X SoCs. Strangely settings done during boot of the switch will not be reset properly by a software-triggered reset of the SoC. Because this is very device dependent we needed to collect information and try out different strategies with different devices, because at some point during development were were fixing one device and breaking another. Now this is understood and the code in OpenWRT takes care of this automatically, so you can ignore those columns.
3 Likes