Heh you are ahead of me, I still haven't tested it sorry for that.
But the lexra thing is just the name of the bus that holds our timer (clock-source) so I must have made a typo somewhere. I'll double check. + reg = <0x31800200 0x10>,
that's deff. wrong I'll push a fix. But I won't be testing all my changes till tomorrow.
I would expect as much. Afaik it's just an external phy, be it optical or copper based, doesn't matter much? Idk. I have yet to experiment with these things
Yeah, I found that one too, and some other errata. I'm rebasing in some local changes for now (though the diff is shrinking) and there were some other DTS which needed minor fixes and the SOC := line missing in a makefile, but thanks both you and @olliver for the clock line, didn't see that one.
Works now, but the fixed-link wrappers inside the phys I had in my earlier diff are apparently necessary, I think. Lan1 is sporadic on link detection (only worked first boot, maybe register carryover), I think the fixed link is not between the MAC and the network, but between the MAC and the phy inside the SFP? Without it, I get no link detected and random sfp oopses in dmesg.
With that put back in, I get working SFP+ 10GBase-T (RJ45). I have a DAC and a Finnisar 10GBase-SR handy. So I tested them. The DAC didn't work, the supported ports list is empty, but the chosen port is listed as direct attach, link is sporadic and no traffic passed. I knew DACs were finicky so I switched to real 10GBase-SR. ethtool looks good:
Settings for lan7:
Supported ports: [ FIBRE ]
Supported link modes: 10000baseSR/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10000baseSR/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: on
Port: FIBRE
PHYAD: 0
Transceiver: internal
Supports Wake-on: d
Wake-on: d
Link detected: yes
However it doesn't pass traffic. Assuming my fixed link was the problem, removed it...didn't work. This phy works in u-boot, the DAC does not. Not sure what to debug next for real fiber, tcpdump just shows quiet, which isn't correct.
So, I now have compile-tested things, so that shouldn't be an issue anymore, and I can read the EEPROM of my SFP module! so that makes me happy Nothing corrupted or lost; so my own driver doesn't work properly yet
Anyway, we can now use a variant of the earlier reworked i2c dts entries. E.g. adding the sda and scl properties to the nodes. Did have to patch the mux driver for it, as that doing something wrong.
No idea what the networking status is atm; I did change some mdio stuff in my tree, so might be a bug there, didn't have time to test networking just yet.
If you need that, that's not right; but could be related to the fact that we have 10g-base-r now, instead of the base1000-x. idk, that was the next thing I was looking into before going down the i2c route.
good question; but in the end, this applies to some effect to the network?
:S your switch is annoying, in that you are using SFP, which is the worst supported feature we have right now
I think fundamentally, that's what DSA is supposed to be? Distributed switch Architecture now, I always thought that this was only useful for multiple stacked switches, but turns out, there's also multi-chip switches, where two identical chips (rtl9301 for example) can be daisy chained
All fun aside, I think there could be ways as you could sent management frames over the network. How secure that is though, idk, I'm not familiar with much of this ...
What do you mean? If the switch can do storm-control in hardware, it won't matter, but if it needs the CPU, then it'll drown quickly? but idk what openwrt/linux even supports to this end ...
So that's quite an open question. So lets replace the first bit with 'can openwrt stack be fully booted on an realtek based chip as per this forum thread
"It depends". So for the zyxel rtl930x, we can compile, from source, U-Boot and have it boot without any blobs. But the realtek U-Boot is an old bastardized version of U-Boot. This, given time, can be fixed of course.
There are more of our switches that could get this treatment, but there's always a few small things. RAM initialization (if it needs tuning for a specific switch, you have a specific bootloader), and networking support (might not be crucial). For my zyxel, the gpl drop includes both, so that's why it works, but it's not a drop in replacement for every switch.
However, with enough time, this should be possible for all rtl83xx switches, as we do have enough code. You'd have to probably pay someone to do the work though. If you expect this to be done by volunteers in their free time, you'll be waiting for a while I'd think. I personally don't have the time, unless being compensated
Does linux support this at all? Does openwrt? If they do, I'd be surprised if the realtek switch doesn't support it in hardware.
this has moved to http://svanheule.net/switches ages ago I know it's a long thread though. We should find some time to update some first posts, though the very first one, is not possible
yeah, but sometimes you get lucky if you have an OEM that is sharing information/datasheets
done what exactly? RTSP? U-Boot? porting?
I have personally not seen one of the realtek switches that have a USB port; but the SoC's do have support for USB. The USB IP seems to be something off-the-shelf. So should be plausible to enable, but probably needs some help from realtek to fill in some blanks, this due to us not knowing of any hardware with this, so no GPL drops generally with this, and no hardware to actually validate and verify that it works.
Are you designing your own switches? Do you get any support from realtek, or is 'none' really 'you can buy chips, but we don't talk to you otherwise' (Which is typical for asian companies that only talk to you if you order 1m pieces or more). Are you getting OEM bits? or just looking for off-the-shelf solutions?
Some background. We've been building product, first with fast ethernet, and then with gigabit unmanaged switches inside for about 5 years. Used the rtl8306, and now the rtl8370 as switch chips. Recently I found the rtl8367c driver SDK online, and compiled that on a raspberry pi, and successfully got it to show me its mac table(s), and port counters from an rtl8370 over the SMI port. I have also booted openwrt on the pi, and successfully loaded the 8367b driver which found the rtl8370 chip, but of course the 8367b driver does not support the 8370, and the rtl8367c driver(which does have 8370 support) is in a different architectural tree in openwrt.
In any event, it does not look like much of the interface in the realtek SDK is actually exposed by the rtl8367 kernel driver. Specifically it looks like its all focused on VLAN support, and port perf counters, which makes sense. I did not even find the L2 Mac table code exposed (which I also need, and is in the SDK, although seems buggy, sometimes returning an empty table).
So now, if I'm going to design yet another switch/system to do the next set of upgrades I want to find some path which is more "community supported," i.e. likely to have better info, and more usage in the future. The integrated rtl8380 seems like a logical choice, as it is widely used in actual shipping products, and there seems to not be much "custom" in the hardware. The phy's are included, and the basic system is really just RTL + DRAM + flash chip. Also the code looks more "complete." The downside for me is the part costs are much higher, and there is no USB port on that part (at least not shown in the datasheet), so I would have to have a second CPU to run my own code.
So my questions are geared more toward what to pick as my next platform, to build our custom hardware, which depends on some features which seem "sort of supported" like RSTP. The linux kernel RSTP support is an open question in both hardware support and pure software support in the bridge driver as far as what I have been able to find online, and I guess my easiest way to get an answer is to just buy a Zyxel or Dlink switch with the 8380, boot openwrt and see if RSTP works, but I figured someone might know the current state, and at least if/how it is actually implemented, which would reveal its limitations more clearly.
There seems to be little further development on the rtl8367 type switches happening anymore.
We can definitely pay someone to help move this project along, and hopefully that could be someone who already has experience working at exactly this level, and the desire to make openwrt better.
With the fixed-link inside the phy, link is detected correctly, and is absent when link is down. Without it, link is always down, and the phylink.c code gets surprised by mismatched phy statuses (calling stop when already stopped, etc). Since Birger's last commits had these, I'm assuming he was on to something.
your switch is annoying
Aside from getting it off my damn workbench one day, it's the mystery that gives this switch so much charm. I did make some progress on the LCD panel, I found a string that will at least blank it. Need to solder in a wire to spy on the UART and it seems like it should be easy to have it "work" with a little init.d script. Updating stats might even be possible that way.
If I set my switch to 10g-base-r, it spams a lot. I can remove the spam, that's not the issue, but I do not get the spam with base1000-x, so somehow the spam path is not called in that mode, so I want to figure out why.
I did notice my leds are green/blue (1g/10g) based on the dts setting, which is new afaik. Before I would always see it being negotiated to 10g; but I may have broken that so need to double check that. 10g-base-r is the right setting of course, but I don't have a 1g SFP unit yet to confirm that the the kernel will downgrade to 1000base-x if I insert it.
well that's what I ponder, could be that the fixed-link is a short cut to avoid detection, could be that it is required for SFP+ ports; I have simply got no idea, and we have very little references to this in the kernel itself, as I don't see any major switch upstream/openwrt yet
hah, I have mine on my desk for 7 months now; when I bought it, I figured 'should be easy, i'll have a nice openwrt based switch soon
Where do I find the xgs1250 images? This thread has gotten long enough that I've lost track of where the image links were, and the wiki doesn't link to any images.
Thanks, I was still thinking the images were in an unofficial source.
Using TeraTerm, I was able to boot the OpenWRT kernel via ymodem (slow), but it behaves rather oddly. I don't see it actually sending any traffic, and there are autonegotiation errors: [ 60.020135] RTL8226B-CG_RTL8221B-CG 2.5Gbps PHY mdio-bus:01: Downshift occurred from negotiated speed 1Gbps to actual speed 10Mbps, check cabling!
I'll bet the ethernet controller is just not wired up. Maybe I shouldn't try flashing anything yet, so I can do more investigation with the stock firmware image.
The DTS for your device would need to be worked out.
It seems like it might be close to the Hasivo S600WP that is being discussed here
To set expectations, OpenWRT will almost certainly not work 'well' with your device right now.
If you just want a switch that works, best to stay with the stock firmware.
If you want to get involved in the development and testing of OpenWRT for this switch, then you probably want to get a development environment setup to build the OpenWRT images.
Ollivers gitlab repo has a branch realtek-wip that has lots of progress towards these switches, and there's a few other github etc repos that have bits and pieces also.
We're still working on getting the DTSes correct, and finding tweaks to the drivers required for various PHY/SDS configurations.
It's amazing seeing devices with more ports being supported and I've been watching the realtek board space closely for a while and waiting for a working 48 port with POE switch. Until now I've been using a D-Link DGS-1210-28 and it's worked flawlessly so far.
I was trying to understand the differences between the GS1900-48 and and the GS1900-48HP. Do you see much difference between the two boards? Would it be a case of me adjusting the image definition from the 24HP (adding more ports) and the 48HP and adding the "ZYXEL_VERS := AAHO"? Or would it be more complicated than that and I should wait before going out and picking up a used GS1900-48HP?
sorry for that.
I'll push a fix. But I won't be testing all my changes till tomorrow.
