Adding second gmac to 4.14


(Frank W.) #21

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?


(Frank W.) #22

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


(Frank W.) #23

No answer till now…has anybody contact to lede-team or john crispin and give him a hint for that?

@garywang @moore


(Paweł Kalemba) #24

Maybe you can try his email? Its in commits. Here


(Frank W.) #25

i have contacted john via this email…also the lede-bug-report is not confirmed yet


(fkpwolf) #26

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?


(Frank W.) #27

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 :slight_smile:


(xbgmsharp) #28

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?


(Frank W.) #29

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


(xbgmsharp) #30

Thanks for the clarification, therefor i should not use the DSA code and ensure the 2Gmac to get full speed.


(Wolfgang) #31

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.


(Frank W.) #32

Is this speed-option enabled by default 4.14?


(precompiled) Kernels for BPI-R2
(Wolfgang) #33

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;
	};
};

(Frank W.) #34

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