Actual i had only applied gmac-patches from lede made for 4.14 without modify anything,just testing. I had thought that they should work,but they did not so i do some debug see here:
@garywang is this information enough or do you need additional infos?
tested tcpdump on my router again with a working ping:
[root@bananapi ~]# tcpdump -nni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:02:16.781003 IP 192.168.0.21 > 192.168.0.5: ICMP echo request, id 20647, seq 1, length 64
18:02:16.781234 IP 192.168.0.5 > 192.168.0.21: ICMP echo reply, id 20647, seq 1, length 64
18:02:17.781727 IP 192.168.0.21 > 192.168.0.5: ICMP echo request, id 20647, seq 2, length 64
18:02:17.781913 IP 192.168.0.5 > 192.168.0.21: ICMP echo reply, id 20647, seq 2, length 64
18:02:18.781675 IP 192.168.0.21 > 192.168.0.5: ICMP echo request, id 20647, seq 3, length 64
18:02:18.781869 IP 192.168.0.5 > 192.168.0.21: ICMP echo reply, id 20647, seq 3, length 64
18:02:19.781757 IP 192.168.0.21 > 192.168.0.5: ICMP echo request, id 20647, seq 4, length 64
18:02:19.781967 IP 192.168.0.5 > 192.168.0.21: ICMP echo reply, id 20647, seq 4, length 64
18:02:20.781712 IP 192.168.0.21 > 192.168.0.5: ICMP echo request, id 20647, seq 5, length 64
18:02:20.781912 IP 192.168.0.5 > 192.168.0.21: ICMP echo reply, id 20647, seq 5, length 64
as you can see with same command now there are outgoing icmp echo reply’s…so i assume that the problem is that the outgoing packets from gmac-kernel are getting damaged (truncated-ip - 6 bytes missing!) so my current router does not send a reply…
contacted John crispin (author from the patches on lede), hoping for a reply
added task to lede-project: https://bugs.lede-project.org/index.php?do=details&task_id=1403
No answer till now…has anybody contact to lede-team or john crispin and give him a hint for that?
i have contacted john via this email…also the lede-bug-report is not confirmed yet
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.
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)