[OpenWrt-Devel] [RFC 0/9] Using the mainline mtk-eth-soc driver for MT7621

Thu Oct 18 13:07:41 EDT 2018

René van Dorst <opensource at vdorst.com> writes:
> Quoting Bjørn Mork <bjorn at 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 at 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 at OpenWrt:/# qcsapi_sockrpc --host 1.1.1.2 get_firmware_version
37.3.1.25
root at 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 at OpenWrt:/# qcsapi_sockrpc enable_telnet 1
complete

And after the last command, I can log into it:

root at 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel