Isn't the RTL8389 one of the models that came before the RTL8380/8390 generation? IIRC there is code for these SoCs in the older SDKs. That being said, I'm not too excited about trying to support these, certainly with the low amount of RAM present. Those old SoCs appear to be even quirkier than the ones we currently try to support. But if @rsalvaterra wants to give it a shot... 
1 Like
The ZyXEL gs1900 series is a rather safe bet, as you don't have to bother about hardware revisions (and even the currently unsupported devices should be easily supportable). However 16 MB flash with dual-boot implies rather small flash sizes, other vendors are more generous (or don't use dual-boot, so more space for the running system). As Borromini implied, the cases are easy to open (standard philips head screws) and the serial console is usable (and often marked/ with a populated header). Some models only come with 64 MB RAM.
The D-Link DGS-1210 series usually has more flash (32 MB), but you have to be very careful to get the right hardware revision (usually F/ G, but always check the OEM firmware first) - sellers usually don't specify this (only hidden on the model plate or a second label near the power plug). Cases are a bit harder to open (taking off the front), the serial header is unpopulated and requires taking off the full width heat sink for soldering (from beneath).
U-Boot is accessible in both cases (TP-Link and HPE lock this down). Models under 28 ports and without PoE tend to be fanless.
2 Likes
I don't even have the hardware… 
Thanks for the summary, ZyXEL GS1900-24HPv2 looks ideal.
Might even upgrade the SPI-NOR on it.
Any quirks when it comes to networking support on it?
You are right, I went through an SDK v2 for the TPLink T2500g-10ts and did find references to the RTL8389 including the entire register definitions. The registers work quite differently from the 8380/8382 and the later SoCs and I guess you would end up writing a specific driver just for that SoC. But then you could also support the RTL8328 which is in dirt-cheap 100MBit switches and seems to be its sibling 
My uses are rather simple, trunk port in, trunk port out - distributing a couple of VLANs (currently 3, more planned) on the different ports (don't have a PoE capable switch yet), this works nicely. Networking quirks itself should be the same for all devices of the rtl838x target, the vendor firmware (the ZyXEL one isn't too bad, the D-Link not quite as nice) probably still has more features available. The biggest quirk for the ZyXEL gs1900 family is the flash size (IMAGE_SIZE := 6976k for kernel+rootfs), if you are looking for more, the D-Link DGS-1210 would be easier.
rtl838x has only basic offloading capabilities, rtl839x and rtl93xx will offer more, once support for these is complete and after the offloading features are added to the drivers.
If you don't need PoE, the GS1900-24E would be a good alternative (45-50 EUR used), getting it supported should be trivial (the GS1900-24HPv2 image probably already works and will only need minimal changes). In general all devices of the realtek target look rather similar, with minimal differences between them (partitioning, GPIOs for reset and friends, port enumeration). Also take a look at https://biot.com/switches/models for inspiration.
The ALLNET ALL8208M is identical to the GS1900-8, just with a different firmware (and single boot, therefore more space available), chances are that the same applies to the ALLNET ALL8316M vs GS1900-16 (it is rtl838x, the similarity is unconfirmed). The supported Netgear switches (GS108Tv3, GS110TPP, GS308T, GS310TP) should also be fine (but here the exact h/w revision matters again).
1 Like
Thanks, I will see whats the availability here in the EU and see what I can actually get.
The D-Link DGS-1210-28P looks interesting due to the 32MB of flash, is the PoE variant supported in OpenWrt as I can only see the non-P model?
Disclaimer: I own the DGS-1210-16 rev G1 and can't speak for the DGS-1210-28P, in general the delta between PoE and non-PoE variants are simple:
- define the second SOC UART, https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/realtek/dts-5.10/rtl8382_zyxel_gs1900-24hp-v2.dts;h=7b6a9a1e7fd38845922bef34732350bf43c884c6;hb=HEAD#l48
- define allowed power levels, https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/realtek/base-files/etc/board.d/02_network;h=58461c9c995f73e3e938dddfc47b678273b50657;hb=c5b44af2fc5ffe620405ccb743b6f4acc461d4de#l50
- include the out-of-tree PoE support package, luars232(?) or realtek-poe, @Borromini should know more about this.
The PoE controller sits on the second UART and gets initialized/ configured that way in userspace.
The situation for the D-Link DGS-1210 devices might be a little more complex, but I'm lacking the details.
1 Like
Thanks, it looks supportable as the 1210-10P model is supported, probably nobody with it added the PoE version.
It just has 2 instead of one PoE controllers, lua-rs232 appears to be used for them
1 Like
The realtek-poe package is the way forward, the Lua implementation was found lacking, realtek-poe is an early (and not final) C implementation. See blogic's submission on Patchwork.
Unfortunately, I don't think that it will get merged, they want a one size fits all solution that won't be arriving anytime soon as nobody can agree on what that is.
Maybe try to add the package to the package feed instead of the core repo or actually add it as the kernel hwmon driver.
No, it won't get merged, I was picking up on @slh's highlighting me as to which was the best PoE daemon to use at the moment. That's the C rewrite of blogic's daemon.
There's been some discussion on this earlier, see this post for comments on the Lua implementation and a follow-up thread on the mailing list here.
General request for people with Zyxel GS1900 switches: I would like to know what the value of bootcmd is in your u-boot environment, if you haven't changed it from the default.
I noticed my GS1900-8 started booting with a factory self-test (bootcmd=cst fcTest;boota), even though I didn't remember it doing that when I purchased it. This self-test takes a while to complete, so it's really noticeable. @Borromini is seeing the same behaviour, and it is causing the watchdog reboot to fail on our devices. Since network only works again once the ethernet driver is loaded, the self-test hangs and we need console access (or a cold boot) to make the device boot correctly again.
Network access in u-boot can be revived by setting the SW_RST bit, but this appears to clear all registers in the switch part. This includes LED management, so this reset can't really be used in the kernel driver.
1 Like
I see similar behaviour with a self-test even before the boot command and I am also not sure that I always had this self-test on the Zyxel XGS1210-12 before I installed OpenWRT in flash:
U-Boot Version V1.0.0.1 (Oct 14 2019 - 17:51:23)
Board: RTL9300 CPU:800MHz LX:175MHz DDR:600MHz
DRAM: 128 MB
SPI-F: MXIC/C22018/MMIO16-1/ModeC 1x16 MB (plr_flash_info @ 83f6a2a4)
Loading 65536B env. variables from offset 0xe0000
Net: Net Initialization Skipped
No ethernet found.
RTCORE Driver Module Initialize
IOAL init
Hardware-profile probe GPIO probe (unit 0): (found)
GPIO Init
RTL8231 probe (unit 0): (found)
RTL8231 init (unit 0)
(XGS1210_12)
Hardware-profile init
GPIO probe (unit 0): (found)
GPIO Init rtl9300_gpio_init had already been initialized!
SPI init (unit 0)
I2C probe (unit 0)
I2C init (unit 0)
RTL8231 probe (unit 0): (found)
RTL8231 init (unit 0)
r9300_rtl8231_init had already been initialized!
NIC probe (unit 0)
Loader RTNIC Driver Module Initialize
IOAL init
RTK Driver Module Initialize
MAC probe (unit 0)
Chip 9302 (found)
MAC init (unit 0)
SMI protocol probe (unit 0)
PHY probe (unit 0)
Chip Construct (unit 0)
Chip Construct
Disable PHY Polling
PHY Reset
MAC Construct
Turn Off Serdes
Serdes Construct
PHY Construct
Turn On Serdes
Enable PHY Polling
Misc
PHY init (unit 0)
Mgmt_dev init (unit 0)
Please wait for PHY init-time ...
============= Factory Test Begin =============
HTP log info get: htpModeIf=1, htpBreakIf=9, hour=133, entry=8195, round=12 !
Note: log addr b4ff0000 flash test addr b4fe0000. Don't overlap with anything!
HTP Test log full!
============= Factory Test End ! =============
RTL9300#
bootcmd is: "bootcmd=boota" which will boot the first half of the flash.
1 Like
Just got a GS1900-8HPv2, here's the u-boot env on it (haven't done anything to it yet):
RTL838x# printenv
baudrate=115200
boardmodel=ZyXEL_GS1900_8HPv2
bootargs=console=ttyS0,115200 mem=64M quiet
bootcmd=cst fcTest; boota
bootdelay=0
ethact=rtl8380#0
ethaddr=D8:EC:E5:61:A6:CD
ipaddr=192.168.1.1
netmask=255.255.255.0
serverip=192.168.1.111
stderr=serial
stdin=serial
stdout=serial
1 Like
Thanks! I seems we won't be able to trust this devices with warm/soft reboots. Luckily, it seems that this device series isn't affected by the PLL-bug, so cold reboots (full SoC reset) still works. They also have a GPIO to perform a hard reset, so really we should use that in the future.
Brand new GS1900-16 and GS1900-24E both have (bootcmd=cst fcTest; boota).
1 Like
Both my GS1900-10HPs have
bootcmd=cst fcTest; boota
1 Like
It looks like USW-Aggregation switch (8x SFP+ 10gb) should be supportable, since it runs an RTL93xx. I was able to get serial, but it requires extensive dissassembly. After soldering header, several unpopulated resistors must be bridged. I am trying to see if it least boots using the Zyxel XGS kernel image from Kobi's fork. Probably I need to understand more on this thread about SFP phy configuration to make networking work.
2 Likes
It does boot successfully from TFTP, naturally networking is not working, since it hasn't been configured at all in the DTS. I'll hack on it, but any pointers would be useful for how to tell the realtek it has 8 SFP+ PHY devices. Cheers!
terminal log of successful boot is here: https://pastebin.com/5uj6rrnZ
EDIT: SOC family is detected as 0. I'm going to hack that to detect as FAMILY_9300, and see what happens.