Thanks for the patch. I am curious: why add second gmac? If MT7632 connect switch with 2 RGMII, the bandwidth will be doubled? How to test this kind of performance boost?
i will use that for LAN/WAN-separation…if wan is connected to one and LAN to the other you can test it with traffic wan-lan 
To confirm my understand on kernel 4.14 to enable native/hardware switch/bridge we need 2gmac as available in hardware. From what i can see in the forum it is not functional yet. How can i test it?
if the lan-port-separation is disabled anyhow you need a lan/wan-separation, so you need the 2nd gmac between switch (mt7530) and cpu (mt7623)…
the gmacs are recognized in debian based systems as ethx…currently you have only eth0…with the lede-patches you’ll see also eth1, but here eth0 will not work because outgoing frames are damaged
if the second gmac works it may be possible to bridge the lan-ports in the switch, not via software in CPU.
currently you can bridge the ports with bridge-utils, but imho this is done in CPU. so if Traffic goes from LAN0 to LAN1 (assuming ports are bridged via br0) this way:
LAN0 => SWITCH => ETH0 => CPU (br0) => ETH0 => SWITCH => LAN1
this means, if you you have full bi-directional traffic on these ports you will get only the half speed
@Ryder.Lee @garywang @moore @linkerosa please correct me if i’m wrong…and can you please contact john to look at the lede-4.14-patches for 2nd gmac
Thanks for the clarification, therefor i should not use the DSA code and ensure the 2Gmac to get full speed.
Regarding speed, it should be noted that GMAC1 supports ‘Turbo-RGMII’ mode (trgmii), running at 2.5 Gbps instead of the usual 1Gbps. In theory this should leave enough bandwidth for two bidirectional gig-e links running simultaneously over a single GMAC.
According to the devicetree, probably yes. ‘phy-mode’ is set to ‘trgmii’, I’m assuming the ‘speed = <1000>’ setting is just a dummy value.
cpu_port0: port@6 {
reg = <6>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "trgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};anything new here?? some people want to use bpi-r2 like with 4.4 but with newer kernel (lan-ports together over one gmac and wan over the other)…imho currently it’s not possible to deactivate dsa-driver and access lan+wan because there is only 1 gmac available
i have no response from my questions to sean, john and others i contacted regarding this
I did this! After some trial and error I noticed in Wireshark that the problem is that packets from switch (cpu_port0) arrive corrupted. Then I found this thread and tried to disable trgmii – and it worked!
I have an OpenWrt fork with those fixes. Internal WiFi doesn’t work (I use a PCIe card instead) and I also didn’t try GPIO or HDPI – probably they are broken. Still, this is upstream OpenWrt with minimal changes that builds working SD card images (EMMC is trickier). It needs more work and has rough edges of course.
1 Like
I will try this,thanks. have you used lede 4.14-patches to get 2nd gmac in your tree?
For wifi you can try this: https://github.com/frank-w/BPI-R2-4.14/commits/4.18-wlan
4.17-wlan have clearer commits (only 2: driver-folder, outside),but currently untested
Emmc-problems should be lede-specific…in debian/ubuntu it’s only different mountpoint (preloader-steps on boot0 have to be done once manually for emmc-images)
In kernel 4.4 cpu-port is also set to trgmii
Maybe something like this is missing: http://lkml.iu.edu/hypermail/linux/kernel/1609.2/04008.html or https://patchwork.kernel.org/patch/9341133/
Or only 1port support trgmii…this schould be lan-port…so i guess we have to swap cpu-ports
@garywang @linkerosa can you bring light in the dark?
Yeah, the kernel is LEDE kernel with several small patches on top to fix BPI-R2 in several places (see https://github.com/abbradar/openwrt/tree/bpi-upstream/target/linux/mediatek/patches-4.14 , 0228 and onward).
On LEDE 4.9, Banana Pi’s fork, both ports are set to trgmii so this shouldn’t be the problem…
does your patch really fix the damaged packets-issue on cpu-port0 (lan)? then it seems that trgmii is handled wrong by code (headerbytes stripped again or similar)
The packets seemed to be trimmed in Wireshark (also checksums were reported as invalid but this is because of trimmed content I believe).
I have the board now working with both lan*@eth0 and wan@eth1 used. Packets are not corrupted.
ok, i will try it…but trgmii-driver should also be ok because actual dts (here from my 4.14-main) without 2nd gmac is working with trgmii
gmac0: mac@0 {
compatible = "mediatek,eth-mac";
reg = <0>;
phy-mode = "trgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
…
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "trgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
btw. have you seen my tests:
17:13:42.430047 IP truncated-ip - 6 bytes missing! 192.168.0.10 > 192.168.0.5: ICMP echo request, id 815, seq 9, length 64
tcpdump from my other router…means outgoing packets are damaged not (only) incoming
Interesting… This seems something complex – my patch definitely helped me and I can’t run more tests now but I’ll maybe try switching trgmii on and off on both ports later and see what happens.
FWIW I also have some funkiness regarding speed negotiation (with a host which works with other router) but it doesn’t seem to be related at the first glance.
Yes, you are right – I meant incoming to the other host which I tested this on. Packets incoming on R2 seemed well.
I have some news – I’ve tried to enable TRGMII on both ports instead and voila, it still works! I’ll take some time to verify that current kernel image has the modified DTB – just in case.
1 Like
i can confirm, that cpu-port0 works with this patch (changing trgmii to rgmii)