[OpenWrt-Devel] Second RGMII ethernet on MT7621?
Marek Behun
marek.behun at nic.cz
Fri Aug 17 10:22:49 EDT 2018
Will this work with WiTiBoard also? Should I try? :D
On Fri, 17 Aug 2018 14:12:29 +0200
Bjørn Mork <bjorn at mork.no> wrote:
> Bjørn Mork <bjorn at mork.no> writes:
>
> > The WiFi extender I am having trouble with (ZyXEL WAP6805 - similar
> > to the WAP6806) has an RGMII connected Quantenna 5Ghz module. My
> > assumption is that this module is connected to the RGMII pads on the
> > MT7621 and that I need support for the second GMAC to get it
> > running. The Quantenna module loads its firmware using TFTP in the
> > OEM firmware.
> >
> > I note that forum user Thirsty has had some success using the
> > mainline MT7623 driver to enable both GMACs:
> > https://forum.lede-project.org/t/er-x-sfp-sfp-eth5-port-has-link-state-led-lit-but-swconfig-says-link-port-5-link-down/4608/70
> >
> > but this currently implies DSA, so it's not exactly plug-and-play
> > with OpenWrt. I haven't tried it myself yet.
>
> My progress is slow... Just keeping this thread alive ;-)
>
> Encouraged by the possible switch (pun intended) to DSA for the next
> release, I decided to try out Thirsty's solution. And it worked fine,
> with a slight device-specific tweak (details below).
>
> So I thought I could go a little further and try to reduce the diff as
> much as possible. The attached patch is what I ended up with. Like
> John said: pretty easy. Almost no diff at all.
>
> How to use: Remove the conflicting out-of-tree mtk_eth_soc driver from
> the ramips target, copy all mtk_eth_soc patches from the mediatek
> target to the ramips target, and then apply the attached patch. And
> use the following kernel config changes (are all these necessary? not
> verified):
>
> KCONFIG:= \
> CONFIG_NET_MEDIATEK_GSW_MT7621=n \
> CONFIG_NET_MEDIATEK_MDIO=n \
> CONFIG_NET_MEDIATEK_MDIO_MT7620=n \
> CONFIG_NET_MEDIATEK_MT7621=n \
> CONFIG_NET_DSA=y \
> CONFIG_NET_DSA_MT7530=y \
> CONFIG_NET_DSA_TAG_MTK=y \
> CONFIG_MDIO_BUS=y \
> CONFIG_MDIO_DEVICE=y \
> CONFIG_MDIO_I2C=y \
> CONFIG_MFD_SYSCON=y \
> CONFIG_REGMAP_MMIO=y
>
> With a minor diff to the mt7621.dtsi for the syscon support. note that
> the ethernet reg size adjustment is somewhat optional. You'll only get
> access warnings from the mt7623_trgmii_* functions in the mt7530
> driver without it. That code should probably be disabled instead:
>
> diff --git a/target/linux/ramips/dts/mt7621.dtsi
> b/target/linux/ramips/dts/mt7621.dtsi index
> 31d930d2251b..389c7064cc9a 100644 ---
> a/target/linux/ramips/dts/mt7621.dtsi +++
> b/target/linux/ramips/dts/mt7621.dtsi @@ -60,7 +60,7 @@
> #size-cells = <1>;
>
> sysc: sysc at 0 {
> - compatible = "mtk,mt7621-sysc";
> + compatible = "mtk,mt7621-sysc", "syscon";
> reg = <0x0 0x100>;
> };
>
> @@ -384,11 +384,11 @@
> };
>
> ethernet: ethernet at 1e100000 {
> - compatible = "mediatek,mt7621-eth";
> - reg = <0x1e100000 0x10000>;
> + compatible = "mediatek,mt7621-eth", "syscon";
> + reg = <0x1e100000 0x20000>;
>
> #address-cells = <1>;
> - #size-cells = <1>;
> + #size-cells = <0>;
>
> resets = <&rstctrl 6 &rstctrl 23>;
> reset-names = "fe", "eth";
> @@ -397,6 +397,7 @@
> interrupts = <GIC_SHARED 3 IRQ_TYPE_LEVEL_HIGH>;
>
> mediatek,switch = <&gsw>;
> + mediatek,ethsys = <&sysc>;
>
> mdio-bus {
> #address-cells = <1>;
>
>
>
>
>
> In my target device DTS I've used this
>
> ðernet {
> gmac0: mac at 0 {
> compatible = "mediatek,eth-mac";
> reg = <0>;
> phy-mode = "rgmii";
> mtd-mac-address = <&factory 0xe000>;
> fixed-link {
> speed = <1000>;
> full-duplex;
> pause;
> };
> };
> gmac1: mac at 1 {
> compatible = "mediatek,eth-mac";
> reg = <1>;
> phy-mode = "rgmii";
> mtd-mac-address = <&factory 0xe000>;
> mtd-mac-address-increment = <1>;
> fixed-link {
> speed = <1000>;
> full-duplex;
> pause;
> };
> };
> };
>
> &phy1f {
> compatible = "mediatek,mt7530";
> #address-cells = <1>;
> #size-cells = <0>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port at 0 {
> reg = <0>;
> label = "lan0";
> };
> port at 1 {
> reg = <1>;
> label = "lan1";
> };
> port at 2 {
> reg = <2>;
> label = "lan2";
> };
> port at 3 {
> reg = <3>;
> label = "lan3";
> };
> cpu_port0: port at 6 {
> reg = <6>;
> label = "cpu";
> ethernet = <&gmac0>;
> };
> };
> };
>
>
>
> That's everything necessary for the mainline mtk_etc_soc and mt7530
> drivers with MT7621, with both GMACs enabled!
>
> There are still a couple of rough corners though:
>
> - I've completely ignored clocks. Thirsty created a clock driver, but
> looking at mtk_eth_soc, this seemed optional to me. So I dropped it
> for simplicity and simply did '#define MT7621_CLKS_BITMAP (0)'
>
> - I've also ignored regulators. The mt7530 drivers needs a couple,
> but the automatic dummy does the job.
>
> - Not too sure about the shared interrupt thingy. I tried reusing the
> interrupt handlers, and it ends up in a tight ksoftirq loop (aka
> lockup) if there is simultaneous traffic over the two gmacs. This
> "fixes" the problem, but something doesn't seem quite right:
>
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -1775,8 +1775,8 @@ static irqreturn_t mtk_handle_irq_rx(int
>
> if (likely(napi_schedule_prep(ð->rx_napi))) {
> __napi_schedule(ð->rx_napi);
> - mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
> }
> + mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
>
> return IRQ_HANDLED;
> }
> @@ -1787,8 +1787,8 @@ static irqreturn_t mtk_handle_irq_tx(int
>
> if (likely(napi_schedule_prep(ð->tx_napi))) {
> __napi_schedule(ð->tx_napi);
> - mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
> }
> + mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
>
> return IRQ_HANDLED;
> }
>
>
> It does halfway make sense, given that returning IRQ_HANDLED without
> actually doing anything seems like a bad idea. But that code is there
> in the mainline driver. Why doesn't it lock up from time to time? Or
> does it?
>
>
>
> The required device specific tweak mentioned above is related to an
> undocumented(?) FE or switch register at 0x1e110008. By default this
> register reads
>
> root at OpenWrt:/# io -4 0x1e110008
> 1e110008: 000c000c
>
> and nothing is received on the eth1 interface. But the FCS error
> counter increases. Writing another magic value makes the FCS errors
> go away and packets are received normally:
>
> root at OpenWrt:/# io -4 -w 0x1e110008 0x9000c
>
> I've experimented somewhat with different values and found that
> 0x8000c also works. So it seems clearing bit 18 is the important
> part. For those who wonder where I got this magic: It comes almost
> directly from an OEM firmware script (/sbin/internet.sh), having:
>
> # Support QTN 5G
> if [ "$CONFIG_QTN_5G" = "y" ]; then
> reg s 0xbe110000
> reg w 8 0x9000c
> mii_mgr -s -p 0 -r 0 -v 0x3900
> mii_mgr -s -p 1 -r 0 -v 0x3900
> mii_mgr -s -p 2 -r 0 -v 0x3900
> mii_mgr -s -p 3 -r 0 -v 0x3900
> #switch reg w 2004 20ff0400
> #switch reg w 2104 20ff0400
> #switch reg w 2204 20ff0400
> #switch reg w 2304 20ff0400
> ifconfig eth3 up
> brctl addif br0 eth3
> ifconfig br0:9 1.1.1.1 netmask 255.255.255.0 broadcast 1.1.1.255
> cp /usr/etc/protocols /etc/
> cp /usr/etc/rmt_ip.conf /etc/
> rmt_qcsmngr -m 0 &
> fi
>
>
> My best guess is that this is somehow related to RMGII delays, based
> on the FCS effect. In which case it should probably be related to
> rgmii-id, rgmii-txid, or rgmii-rxid somewhere. But guessing where is
> difficult not knowing the exact meaning of those bits. So I've not
> implemented anything here yet, except a local device fix to ease my
> own testing.
>
> Still have a long way to go before I have the Quantenna module up and
> running without a kick in the butt. But the good news is that the
> Quantenna PCIe work done by ILOVEPIE at
> https://github.com/ILOVEPIE/qts1kpcie_wifi_driver.git
> seems to apply to RMGII connected Quantenna modules too. Even the
> module firmware! So there is a good chance we can reuse tools,
> plugins and firmware packages for all Quantenna modules regardless of
> connection, if we ever finish the support. But there is quite a lot
> of polishing left...
>
>
>
> Anyway, the main point here was the mtk_eth_soc and mt7530 mainline
> driver part. Hope this info is useful to someone.
>
>
>
> root at OpenWrt:/# ifconfig -a
> br-lan Link encap:Ethernet HWaddr 60:31:97:66:16:10
> inet addr:192.168.1.1 Bcast:192.168.1.255
> Mask:255.255.255.0 inet6 addr: fe80::6231:97ff:fe66:1610/64 Scope:Link
> inet6 addr: fd5f:9350:2bf2::1/60 Scope:Global
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:6 errors:0 dropped:0 overruns:0 frame:0
> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:2414 (2.3 KiB) TX bytes:8170 (7.9 KiB)
>
> eth0 Link encap:Ethernet HWaddr 60:31:97:66:16:10
> inet6 addr: fe80::6231:97ff:fe66:1610/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:405 errors:0 dropped:0 overruns:0 frame:0
> TX packets:61 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:96287 (94.0 KiB) TX bytes:11043 (10.7 KiB)
> Interrupt:15
>
> eth1 Link encap:Ethernet HWaddr 60:31:97:66:16:11
> inet addr:1.1.1.1 Bcast:255.255.255.248
> Mask:255.255.255.248 inet6 addr: fe80::6231:97ff:fe66:1611/64
> Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:6457 errors:0 dropped:0 overruns:0 frame:0
> TX packets:6544 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:396616 (387.3 KiB) TX bytes:9515000 (9.0 MiB)
> Interrupt:15
>
> lan0 Link encap:Ethernet HWaddr 60:31:97:66:16:10
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:405 errors:0 dropped:399 overruns:0 frame:0
> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:88997 (86.9 KiB) TX bytes:8170 (7.9 KiB)
>
> lan1 Link encap:Ethernet HWaddr 60:31:97:66:16:10
> UP BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> lan2 Link encap:Ethernet HWaddr 60:31:97:66:16:10
> UP BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> lan3 Link encap:Ethernet HWaddr 60:31:97:66:16:10
> UP BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:65536 Metric:1
> RX packets:2073 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2073 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:134060 (130.9 KiB) TX bytes:134060 (130.9 KiB)
>
> wlan0 Link encap:Ethernet HWaddr 02:10:18:FF:5B:F8
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> root at OpenWrt:/# ls -la /sys/class/net/*/device/driver
> lrwxrwxrwx 1 root root 0 Aug 17
> 11:24 /sys/class/net/eth0/device/driver
> -> ../../../bus/platform/drivers/mtk_soc_eth lrwxrwxrwx 1 root
> root 0 Aug 17 11:24 /sys/class/net/eth1/device/driver
> -> ../../../bus/platform/drivers/mtk_soc_eth lrwxrwxrwx 1 root
> root 0 Aug 17 11:25 /sys/class/net/lan0/device/driver
> -> ../../../../../../bus/mdio_bus/drivers/mt7530 lrwxrwxrwx 1
> root root 0 Aug 17
> 11:25 /sys/class/net/lan1/device/driver
> -> ../../../../../../bus/mdio_bus/drivers/mt7530 lrwxrwxrwx 1
> root root 0 Aug 17
> 11:25 /sys/class/net/lan2/device/driver
> -> ../../../../../../bus/mdio_bus/drivers/mt7530 lrwxrwxrwx 1
> root root 0 Aug 17
> 11:25 /sys/class/net/lan3/device/driver
> -> ../../../../../../bus/mdio_bus/drivers/mt7530 lrwxrwxrwx 1
> root root 0 Aug 17
> 11:25 /sys/class/net/wlan0/device/driver
> -> ../../../../bus/pci/drivers/mt7603e
>
> root at OpenWrt:/# brctl show
> bridge name bridge id STP enabled interfaces
> br-lan 7fff.603197661610 no lan0
> lan1
> lan2
> lan3
>
> root at OpenWrt:/# ip route get 192.168.1.33
> 192.168.1.33 dev br-lan src 192.168.1.1
>
>
> root at OpenWrt:/# ping 192.168.1.33
> PING 192.168.1.33 (192.168.1.33): 56 data bytes
> 64 bytes from 192.168.1.33: seq=0 ttl=64 time=1.010 ms
> ^C
> --- 192.168.1.33 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max = 1.010/1.010/1.010 ms
>
> root at OpenWrt:/# qcsapi_sockrpc --host 1.1.1.2 get_info eth1
> Build name: v37.3.1.25
> Build revision: 30503
> Build type: GPL
> Build timestamp: 1429609059
> Platform ID: 450
> Hardware ID: QV840
> Hardware revision: bbic4_rev_a2
> Band: 5GHz
> Kernel version: 2.6.35
> Calibration version: disabled
> DC/IQ cal version: V8.1
> Power cal version: V8.1
> MuC firmware: qtn_driver.qtn_ruby.0.bin
> DSP firmware: rdsp_driver.0.bin
> AuC firmware: auc_driver.0.bin
> MAC address 0: 00:26:86:32:b9:03
> MAC address 1: 00:00:00:00:00:00
> U-Boot version: v37.3.0.22
>
> Bjørn
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list