Fun with different Python versions... The gift that never stops giving!
Hello, I'm very interested in OpenWRT being available for the DGS-1210-52. However, all releases I tested so far had different issues which prevented me from using it productively.
I offer the following help to interested developers:
- SSH access as "root" on a fixed IPv4 via port forwarding and/or IPv6.
- Testing of particular things/new releases/snapshots by myself on the machine.
The device has got 48 Gbit ports and 4 shared Gbit/SFP ports.
Hardware revision: F3
CPU: RTL8393 MIPS 34Kc V5.5
Currently installed: SNAPSHOT r26990-06b37a5856
The serial console is attached and can be made available via another machine if needed.
If you want access for development or some testing work being done, or have additional questions, please send e-mail to: freifunk[AT]alte[MINUS]pflasterei[DOT]de.
Christoph
1 Like
Does it mean, we could try snapshot version again and it should work?
I'll try tomorrow (probably; as soon as time allows) and report back, because fireburner told me on XMPP that he had successfully tested ([at least] the things he actually needs) one of the recent versions.
2 Likes
I've just successfully performed an upgrade to "SNAPSHOT r27765-1bd6dda198" via "owut", retaining my old configuration along with installed additional packages.
A quick test has revealed that the bugs preventing me from installing the switch as a replacement for 2 smaller older switches seem to have been resolved.
Those bugs have been (among minor issues I did not yet test):
- In the stable release:
The assignments of internal ports to "lan49" and "lan50" are wrong for this device. In Luci I see a 1GbE connection on "lan49", which is obviously the internal CPU port. A connection on ports "lan49" or "lan50" won't work; no LEDs will light up, nothing is sent or received. All other ports work like expected. "lan49" ā¦ "lan52" are shared GbE/SFP ports. The CPU should have its own 53rd port, and not be mapped to "lan49"; I couldn't figure out yet why "lan50" is "dead" as well. - In the older SNAPSHOT release mentioned above:
Using VLAN tag numbers other than the preconfigured "1" did not work as expected.
However, I did not yet test SFP; the "combo" ports work in copper GbE ethernet mode.
I'm trying to build snapshot 6.6 images for my collection of RTL8380, and my single RTL9something in a drawer somewhere, and I have noticed, that for similar diffconfig the builds for Netgear&HPE switches are consistently smaller than the Zyxel builds, a difference of a full MegaByte.
This can also be seen on Snapshots downloads for rtl838x, 5376KiB for all Netgears, 5440KiB for all HPEs, 6400 for all others.
Looking at the recipes, to me it looks like everybody but Netgear&HPE use GZIP for FW compression, and this leads to images with Luci+LLDP being bigger than the ~8MiB available on the Zyxel GS1900s because of their A/B boot scheme.
Can anybody verify that, and if so, what stands in the way of using better than GZIP? For my Zyxels padjffs also seems to add quite some size, but I have to check that again.
Sorry, just tested again and found out this test was a little misleading.
During the test I had only 2 devices connected, so (after the PHY_INTERFACE_MODE_USXGMII patch) network worked.
So @yolf and others are right. Switching is currently broken on this target.
U-Boot on these devices only supports gzipped images. Using libdeflate we already gained ~250K. For more either provide a patch to make use of lzma-loader or join here: https://github.com/openwrt/openwrt/pull/16442
2 Likes
A port of lzma-loader is in my WiP-Tree for the GS1920-24HP: https://github.com/openwrt/openwrt/commit/6e0a21d3f4030f3f664eb7b97e4d8bbe57e91229
Note that it is modified to allow booting from a second firmware partition.
2 Likes
I had seen that pull request, also before the GZIP/LZMA difference made my FW config not fit into the 8MiB. Thanks for answering my hunch, that Netgear and HPE must then have used a different/newer? u-boot.
Some of the HPE&Netgear devices look identical w.r.t the DTS to some of the GZIP-only models, so couldn't u-boot be updated on the latter type devices?
If we are ready to clobber the partition scheme anyway, what's stopping us from updating the u-boot? I personally don't care about an easy way back to stock, or the ability to quickly cycle between stock and openwrt, but an updated u-boot might be able to also provide that for those who want it, and "buy" us a MegaByte more time before we have to settle on a final solution for the A/B size use/waste?
Btw. Thanks for your work. If you are at Hack.lu this year, I'll happily buy you a beverage or three!
I knew LZMA-loader is used for some other platforms but I thought, there must be either obvious show-stoppers for realtek or just not enough "need" yet for somebody capable to take a swing at it.
Where did you find the '0x4f4b4c49' constant that is specified in the recipe for the GS1920-24HP? Is it different from the GS1900-series?
How could one apply this to the GS1900s? And other GZIP-limited devices?
You also, Thanks a lot for your work, will gladly sponsor your thirst-quenching at hack.lu 2024 too!
Sorry to bother you.
Which one should I test? You have multiple open and I would prefer not to test the wrong one again.
I know we at least have source for XGS1930 and (HPE) 1910 (100mbit, not the marvell ones) and 1920 uboot? I've only had a cursory look at the 1920 uboot source drop.
Bootloader development sounds too hard for me as I don't know how to attach a hardware debugger to these targets =P. I guess worth looking into at some point, we have quite a large bootloader on the HPE switches. As an aside these targets cap out at 32M flash because hardware according to datasheet anyway?
mm. I'm done with my M300 tinkering so I have my RTL8380/RTL8382 back on the bench.
@plappermaul I finally ordered an RTL8393M (JG927A) switch to play around withso I can test anything you want on RTL8393M target? (Took me a while =P)
Start with https://github.com/openwrt/openwrt/pull/16457 and report in the PR your device and if everything works afterwards as before.
2 Likes
Got a JG921A for a desktop switch with PoE (no fans) and the latest snapshot is working well.
Hope the RTL839x is behaving as well, I'll try and get the 48-port switches installed permanently soon once I have a place where I can ignore the fan noise.
I have retrofitted mine with three NF-A4x20. The installation is a bit cumbersome but that makes it whisper quiet. The two fans in the power supply have an JST XH 3 Pin Connector, the fan connected to the mainboard has an JST XH 4 Pin Connector.
Just beware that the stock firmware checks the one fan connected to the mainboard and refuses to enable POE with a fan error. I hooked up the speed signal but I maybe the reported RPM is out of the expected range. I havenĀ“t checked that further thus far.
I did this mod for the single fan on my JG927A, I repinned the Noctua to connect to the JST plug and attached the speed sensor. The JST-XH I took from a 3S lipo balance charging lead extension and I was able to insert the pins from the other end directly into the Noctua fan connector.
Works great but the NF-A4x20 cost about Ā£20 and the entire JG928A switch only cost Ā£30 on eBay, and paying Ā£60 for 3 new fans on a Ā£30 switch is a lot. Maybe if I find a deal on Noctuas.
It would be great if you could elaborate on the default and openwrt fan behaviour on jg927a/jg928a? So it disables PoE if there's a fan failure? That's good to know.
I thought jg928a had two fan levels and jg927a had one? (At least from reading HPE documentation?
I've (now purchased, on the way) some jg927/jg928's so i'll have the full stack of systems with fan so I can hopefully get the fans changed to hwmon for the entire family. Jg922a, jg926a, jg927a, jg928a. Feedback was people also wanted the defaults to be max fans for all of them, which might require changes in the rtl8231 init code again.
At least on jg922a/jg926a. It's a GPIO input so you either have fail or good? I'd need to check with a scope or source / function generator to see what's actually going on though. I just checked the GPIO with stop and go. Didn't attempt to ramp it.