René van Dorst <opensou...@vdorst.com> writes: > Quoting Bjørn Mork <bj...@mork.no>: > >> I'm afraid this is way over my head. My understanding of the MT7621 SoC >> and the different hardware configurations is limited. IIUC there are >> basically two ways to connect the 2nd CPU GMAC: >> 1) by RGMII to something outside the SoC >> 2) to a port on the SoC internal switch, similar to the 1st GMAC >> > > You have even more options. I think these are the most common. > a) GMAC2 disabled; P5 -> RGMII (external phy) > b) GMAC2 -> switch P5 -> switch P0/P4 > c) GMAC2 -> RGMII (external phy) > > > a) In my code this is working. With this option you can get 1G HNAT > wire-speed > between wan and lan. > b) is great to support. P0 or P4 = wan port of the device. With this option > you can get 2G HNAT wire-speed. > c) is great for me and other users which uses the external phy as wan port. > RGMII = wan port of the device. With this option you also can get 2G HNAT > wire-speed.
Thanks. I am still confused, but that's not your fault :-) >> What I have been able to get working is 1). I have not experimented >> with 2). But I guess that is what you want, since the SFP is connected >> to the switch on the ER-X-SFP? > > Did you get any data on your network? Yes. The Quantenna module boots over this interface using tftp. I use dnsmasq to serve it the u-boot.bin and topaz-linux.lzma.img images (built using the Quantenna SDK - no OpenWrt here. Yet :-). So there has been a few bytes transferred already after a client boot from poweroff: root@OpenWrt:/# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 60:31:97:66:16:11 inet addr:1.1.1.1 Bcast:1.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::6231:97ff:fe66:1611/64 Scope:Link inet6 addr: fdfa:f6cd:60a:10::1/60 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5858 errors:0 dropped:1 overruns:0 frame:0 TX packets:5857 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:352536 (344.2 KiB) TX bytes:8814324 (8.4 MiB) Interrupt:15 I can also talk to the Quantenna module over this interface using tools from the SDK: root@OpenWrt:/# qcsapi_sockrpc --host 1.1.1.2 get_firmware_version 37.3.1.25 root@OpenWrt:/# qcsapi_sockrpc --host 1.1.1.2 get_sys_status C000001F bit 0 - Ethernet interface bit 1 - PCIE EP driver bit 2 - PCIE RC driver bit 3 - WiFi driver bit 4 - Rpcd server bit 30 - Calstate mode bit 31 - System boot up completely root@OpenWrt:/# qcsapi_sockrpc enable_telnet 1 complete And after the last command, I can log into it: root@OpenWrt:/# telnet 1.1.1.2 Entering character mode Escape character is '^]'. soc1 login: root BusyBox v1.10.3 (2015-04-21 17:30:57 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. quantenna # quantenna # cat /proc/cpuinfo Processor Family: ARC 700 [0x33] CPU speed : 500.00 Mhz Timers: TIMER1 TIMER0 Interrupt Vect Base: 0x88026400 Peripheral Base: NOT present; assuming 0xCOFC0000 Data UNCACHED Base (I/O): start 0xc0 Sz, 1024 MB Bogo MIPS : 249.03 ARC700 MMU Ver [2] PAGE SIZE 8k JTLB 128 x 2 = 256 entries uDTLB 8 entr, uITLB 4 entr TLB Refill "will NOT" Flush uTLBs Detected I-cache : Type=2 way set-assoc, Line length=32, Size=16K (enabled) Detected D-cache : Type=4 way set-assoc, Line length=32, Size=16K (enabled) Extensions: MPY: 32x32 with ANY Result Reg MAC MPY: Dual 16 x 16 and 32 x 16 DCCM: N/A ICCM: N/A CRC: N/A, SWAP: Present NORM: Present Min-Max: Present, Barrel Shifter: Present Ext Arith Insn: Present Floating Point Extension: N/A AFAICS, this interface works pretty stable. And I've been trying to generate a bit of simultaneous traffic on both eth0 and eth1 without killing anything. Looks good to me. At least so far. I am still struggling with the weird Quantenna API, wondering if it is really worth the effort. It would be good to run OpenWrt on that module too of course, but I don't think that will happen any time soon... I started out with ILOVEPIEs excellent work here: https://github.com/ILOVEPIE/qts1kpcie_wifi_driver which, despite what the support table says, works just as fine with my RGMII module. The problem is that it works "mostly". Getting it anywhere near something I would like to use myself outside the lab is still lots of work. The API is (or was?) unstable, so there are lots of different firmware versions with matching tools around. And the firmware is usually built by the OEM for some specific application. Trying to make this into more generic "Quantenna QTS1000 support" might be impossible. I spent a couple of weeks trying to figure out why the wifi interface I created sucked, before I realized that it was a well known bug in many of the more recent Quantenna firmware versions, affecting Android clients. And I always used my phone as a test client of course... Changing client or changing firmware back to an older version fixed the issue. But then I got a completely different API. Really annoying. > On ER-X-SFP sfp port is connected like: SFP port -> SGMII -> external > phy (at8035) -> RGMII -> MT7621 RGMII2 > > In my case 2nd GMAC did work in linux but no real data comes in or out > the device. > Probably of some hardware setting that I have missed. > >> This is probably related to the magic register settings I had to disable >> to get my device working. I assume the real fix is to make the driver >> DTRT based on the DTS. > > I think option a is for now the best option to get supported in openwrt. > This works for both of us. John was busy to refactor my code to get it > upstream. > Because of lack of time it is still not done. > > Next step could be enabling the 2nd GMAC and try to implement the > option above. > >> Not sure I have the correct picture of the MT7621 though. Either I am >> stupid or this is explained confusingly in the docs I've seen... A >> little of both probably. > > Lack of the offical and compleet documents and time are for me the main > issue it is still not working. > >> Bjørn > > BTW. Do you have some more info about WAP6805? Not many hits on Google. I believe it's a custom version of the WAP6806. I've only seen it sold from a local ISP under the marketing name "Altibox WiFi+. You can see it here: https://www.komplett.no/product/904060/datautstyr/nettverk/range-extender/altibox-wifi-pluss I took a few pictures of the internals: https://www.mork.no/~bjorn/wap6805/ As you can see, it is a quite nice box: Easy to open without breaking anything, and the board had two serial headers (both with "standard" Mitrastar pinout - like the P8702N for example). One of the serial ports is connected to the console on the Quantenna module. The Quantenna module is an oversized "mini-PCIe" module. But as I said: It is connected by RGMII. And obviously serial, and maybe some GPIOs? So it cannot be simply replaced by a standard mini-PCIe module, unfortunately. If you look at the FCC photos linked from https://wikidevi.com/wiki/ZyXEL_WAP6806_(Armor_X1) you will notice that the Quantenna module is exactly the same. And the main boards are almost identical. The only differences appear to be due to the casing. The OEM firmware on the WAP6805 is of course slightly customized for Altibox. The most important change is the default root password, which is Wi9cXkg5Hse2K As you can see from the marketing stuff, it isn't really intended to be managed by the end user at all. It will attempt to tunnel TR69 to Altibox so they can configure it for you. There isn't any local web gui or anything. But it runs dropbear by default, so who cares? :-) Bjørn _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel