QCA807x DSA for ipq40xx

For Developers
1

Hi,

Do you now if someone try to port the QCA8k DSA driver for qca8072/qca8075 ?

I know that @blogic try for ipq806x here : https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/qca8k

I have a DK05 dev board (ipq4018 + qca8072) booting on linux 4.14

Thanks,
Clement

2

8072/5 is only a sgmii2phy block. 40xx has a builtin 8337n. i once tried to bring it all up but ran out of time. might go and pick up my prior work.

2 Likes
3

Thanks for the explanation,

I will try this

4

Hello.
Did you try this repo?
Any news?

I want to port this to the current IPQ40xx target.

5

Hi,

I quickly try but I'm a newbie on this point, rebase on 4.14 and then add a node in the device tree but got a panic in the kernel with the MDIO.

Didn't push further.

1 Like
6

Is there some progress of DSA support for ipq40xx?

7

I remember @robimarko mentioning working (but having reliability issues) with ipq40xx DSA / ipqess within the last year. Branches here:

@Ansuel had a number of qca8k fixes merged while getting qca8k working on ipq806x (but the switch is different to ipq40xx)

More qca8k fixes have been merged since: https://github.com/torvalds/linux/commits/master/drivers/net/dsa/qca8k.c

I wish we had an ipq40xx switch programming guide / registers datasheet. Urgh Qualcomm.

2 Likes
8

Thanks a lot! Nice to hear that there is still progress.

9

Here are the datasheets for ipq40xx and the switch (qca8337)

1 Like
10

Thank you @tomtom,
I still cannot find what I am looking for: The ipq40xx datasheets there are QSDK / OpenWrt user manuals compared to the older (ex. QCA9558) datasheets with hardware descriptions & register values.

11

I have made a PR for initial DSA support.

7 Likes
12

I've got an EA8300 and am working on getting the DSA-style initial config right.

TL;DR:

Without LuCI running, most of the wiki pages and video help I've found haven't been very helpful.

If someone with one of these DSA-enabled devices can share /etc/config/network for the "expected structure", I'd appreciate it.

(Looks like my serial board coincidentally went belly up, so not a bug rush)

I'm apparently missing something (with the auto-generated config) as I'm not seeing evidence of the 4+1 ports in

root@OpenWrt:/etc/config# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 12:34:56:aa:bb:cc brd ff:ff:ff:ff:ff:ff
3: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:03:7f:aa:bb:cc brd ff:ff:ff:ff:ff:ff
4: wlan2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:34:56:aa:bb:cc brd ff:ff:ff:ff:ff:ff

root@OpenWrt:/etc/config# ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

root@OpenWrt:/etc/config# bridge v
port              vlan-id

I'm not sure if I should be seeing the "internal" interface(s) to the CPU that used to be known as eth0 and eth1. At least as I vaguely recall DSA, I would think I'd need to associate them with a bridge and VLAN (even if only internal to the bridge).

All the "instructions" I've found so far seem to be focused on how to set things up with LuCI, which is still a step or two away.

13

Have you updated the 02_network script for the default network config?

14

After much thrashing with unrelated serial problems,

 &gmac {
-      statuus = "okay";
+      status = "okay";
 };
 
 &switch {
-      statuus = "okay";
+      status = "okay";
 };
 
 &swport1 {
-      statuus = "okay";
+      status = "okay";
 };
[...]

So I'm now going to be Edit: getting proper MAC addresses, checking out all the ways I broke the current "avoid VLANs 1 & 2" config, as well as issues with trunking and ARP failing with the "other" MAC answering.

For anyone following later:

root@OpenWrt:~# ip link | fgrep -v link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
3: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
4: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
5: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
6: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
7: wan@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN qlen 1000
8: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
9: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
10: wlan2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
11: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000