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:
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.
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.
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.
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.
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.
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
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!
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.
This will be for an RS232 transciever. You'll have to determine the pin layout first (input signals, output signal, where those capacitors connect to...). Then, if you're lucky, you may be able to find the actual part that matches this layout. See for example these 16-pin RS232 transceivers from maxim integrated. The RS232 transceivers that I've seen up to now, are pin compatible clones of maxim parts, but I think the packages were smaller.
A quick update: The patch with the support for the RTL9300-based SoCs such as the ZyXEL XGS-1210-12 was merged at the beginning of the this week into OpenWRT/master. The patch also contained some other interesting things to play with:
there is now full support also for RTL839x-based SoCs, such as the 48-port ZyXEL GS1900-48
Quality of Service and Rate Control went in with a default configuration, if you mark ethernet frames as high priority before sending them to the switch, then they should get precedence automatically on a congested outgoing line. This has not been tested at all, so if anyone wants to test-drive this... There is a debugfs-based interface for playing around with configuration settings for this, too but to start with you don't need that.
There are no specific device .dts for any 9300 or 8390-based switches in owrt/master, but you can find them in the current development master at https://github.com/bkobl/openwrt
There is another interesting piece of new code, which allows to enable Energy Efficient Ethernet in that dev-tree, too. Since this seems to be an interoperability thing, it would be cool if people would test it. The energy savings can be considerable, going down from about 0.6 Watts per port to 0.2 watts, which is not only going to make your equipment less hot, save on your energy bill but also will be nice for the climate (use "ethtool --set-eee lanX eee on" to test).
And there is also progress on the mainlining front. We are hopeful to get the first set of patches into the next Linux kernel release.
Finally, development on the L3 routing offloading has started, don't hold your breath yet, but at least the first step has been done.
Looking through the code I'm not able to find anything regarding PoE configuration/setup. How is the difference between a switch supporting PoE and one that doesn't support PoE defined/configured? I have both a DGS-1210-10 and a DGS-1210-10P, it appears that the DTS contains no information regarding PoE. I also have a DGS-1210-28P and a DGS-1210-28MP which differ greatly in the PoE budget. Where would that difference be configured/set?
