IPQ5018: Support for Linksys MX2000 Atlas 6 & MX5500 Atlas 6 Pro

For Developers
449

I've encountered an issue on the ipq5018 where the logs are flooded with:

[84045.702113] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 0 (-105)
[84045.702177] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 1 (-105)
[84045.709639] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 2 (-105)
[84045.718483] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 3 (-105)
[84045.726727] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 4 (-105)
[84045.735276] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 5 (-105)
[84045.743730] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 6 (-105)
[84045.752299] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 7 (-105)
[84045.760685] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 8 (-105)
[84045.769252] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 9 (-105)
[84045.777775] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 10 (-105)
[84045.786333] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 11 (-105)
[84045.794750] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 12 (-105)
[84045.803338] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 13 (-105)
[84045.811899] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 14 (-105)
[84045.820606] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 15 (-105)
[84045.829138] ath11k c000000.wifi: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 16 (-105)
[84045.852750] ath11k c000000.wifi: failed to configure rx tid 0 queue for pn replay detection -105
[84045.852810] ath11k c000000.wifi: failed to offload PN replay detection -105

not sure if it's entirely the same, but there is a related downstream patch for it:
patches/ath11k/308-ath11k-poll-reo-status-ipq5018.patch

Will test it, but have you seen this too?

450

to circle back, I've actually managed to get one of these devices. Update so far, I've got the WAN port working which is based on a QCA8081 PHY. The switch is the same, qca8337, but I'm unable to get it to work so far..

@hzyitc: this device (Linksys SPNMX56) uses both MACs on the ipq50xx switch. The GE Phy is connected to the qca8337 switch, and the uniphy is connected to the qca8081 phy which supports 2.5 gbps.
This config slightly differs from our other devices (Redmi AX3000 and the Linksys MX2000/MX5500) as the ge_phy is connected to the switch.

* ===============================================================
*     _______________________           _______________________
*    |        IPQ5018        |         |        QCA8337        |
*    | +------+   +--------+ |         | +--------+   +------+ |
*    | | MAC0 |---| GE Phy |-+--SGMII--+ | SerDes |---| MAC6 | |
*    | +------+   +--------+ |         | +--------+   +------+ |
*    |                       |         |_______________________|
*    |                       |          _______________________
*    |                       |         |        QCA8081        |
*    | +------+   +--------+ |         | +--------+   +------+ |
*    | | MAC1 |---| Uniphy |-+--SGMII--+ | Phy    |---| MAC0 | |
*    | +------+   +--------+ |         | +--------+   +------+ |
*    |_______________________|         |_______________________|
*
* ===============================================================

The IPQ5018 internal PHY driver is initialized when dp1 is probed and scans for connected PHYs. The node includes a phy-handle to the GE Phy. When changing it to a fixed link for it to work with the switch, the ge_phy isn't detected anymore.
Would you know of any other way to make it work? the CPU bitmap points to port6 of the switch.
Does it need to be configured as a fixed link or should the phy-handle to GE Phy in dp1 be sufficient?

the stock DTS is here:SPNMX56 stock DTS

WIP DTS for OpenWrt: SPNMX56 OpenWrt DTS

1 Like
451

I think the IPQ5018 Phy driver is incomplete? Will try to implement autoneg for SGMII to work, which according to QSDK is the same implementation as that of qca808x.

452

it is a ethernet phy, the outpin is MDI, not SGMII. IPQ5018 only have one SGMII/SGMII+ and one MDI.

453

the stock DTS has two SGMII links, one between dp1 (ipq5018 ge phy) and the qca8337 switch, and the other between dp2 (uniphy) and the qca8081 phy..

454

The "SGMII" link between MAC0 and IPQ5018 internal PHY is inside the IPQ5018. The only output pin is MDI. You can connect RJ45/UTP to it directly（ need some external circuit and vulnerable ）

455

Would that mean the qca8337 switch's CPU port is connected through one of its PHY ports directly using UTP? I would assume Port 6 based on the cpu bitmap in the stock DTS (0x40 which is bit 6).

something like this?

port@6 {
				reg = <6>;
				label = "cpu";
				phy-handle = <&qca8337_1>;
				phy-mode = "sgmii";
				ethernet = <&dp1>;
				qca,sgmii-enable-pll;
			};
456

Would that mean the qca8337 switch's CPU port is connected through one of its PHY ports directly using UTP?

Yes. (MDI, more precisely)

I would assume Port 6 based on the cpu bitmap in the stock DTS (0x40 which is bit 6).

No, Phy0-4 are connected to MAC1-5. So the CPU port should be one of them.

BTW, the current qca8337 driver doesn't support such topo.

457

If my understanding is correct, according to below diagram, port 5 would be the only candidate which has an ethernet PHY and the port itself can be configured as a CPU port by its PORT5_PAD_CTRL register:

image
image1179×697 155 KB

swconfig dev switch1 show | grep link shows that PORT0 and PORT6 are connected and the PHY of PORT5 seems connected in a way to PORT6 as well.

If that’s the case, I’ll try to create a patch that allows the current qca8k-83xx driver to use port 5 as a cpu port. Thoughts?

458

really interested to understand how you have found / identified those documents and also listed the oem DTS like that (OT for this thread but interesting rabbit hole for me to undertsand)

459

First hit on G when searching for qca8337 datasheet :grinning:

I took the stock dts from connecting the device to serial and grabbing the fdt file that I found in /sys/firmware/devicetree (or one of its subdirectories, can’t remember)

460

port 5 would be the only candidate which has an ethernet PHY and the port itself can be configured as a CPU port

no, what we talk about is cpu tag header which is necessary for DSA. In qca8337, it can be enabled on all port by PORTX_HEADER_CTRL.

BTW, stock firmware use VLAN instand of DSA. So you can just treat it as a managed switch.

1 Like
461

I did a pull a build this morning. I must be missing something as 6122 does not start..

[   13.523014] qcom-q6-mpd cd00000.remoteproc: Direct firmware load for ath11k/qcn6122/hw1.0/m3_fw.mdt failed with error -2
[   13.523068] qcom-q6-mpd cd00000.remoteproc: Falling back to sysfs fallback for: ath11k/qcn6122/hw1.0/m3_fw.mdt
[   13.672113] remoteproc remoteproc0: remote processor cd00000.remoteproc is now up
[   13.692709] remoteproc remoteproc1: remote processor pd-1 is now up

[   13.770253] remoteproc remoteproc2: powering up pd-3
[   13.770583] remoteproc remoteproc2: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[   13.785737] remoteproc remoteproc2: remote processor pd-3 is now up
[   13.799369] kmodloader: done loading kernel modules from /etc/modules.d/*
[   13.882332] ath11k b00a040.wifi1: qmi ignore invalid mem req type 10
[   13.889624] ath11k b00a040.wifi1: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[   13.889687] ath11k b00a040.wifi1: fw_version 0x270206d0 fw_build_timestamp 2022-08-04 13:28 fw_build_id WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILIC1
[   13.987753] ath11k c000000.wifi: qmi failed to load CAL data file:cal-ahb-c000000.wifi.bin
[   13.987980] ath11k c000000.wifi: failed to load board data file: -12
[   14.190758] ath11k b00a040.wifi1: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=GL-iNet-GL-B3000 from ath11k/n
[   14.190826] ath11k b00a040.wifi1: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255 from ath11k/QCN6122/hw1.0/board-2.bin
[   14.204694] ath11k b00a040.wifi1: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255 from ath11k/QCN6122/hw1.0/board-2.bin
[   14.217349] ath11k b00a040.wifi1: failed to fetch board.bin from QCN6122/hw1.0
[   14.230005] ath11k b00a040.wifi1: qmi failed to fetch board file: -12
[   14.237123] ath11k b00a040.wifi1: failed to load board data file: -12

works fine pre latest commits, I suspect this has something to do with it.

b00a040.wifi1:
462

so i noticed that the 6122 directory is empty, aside from the board-2.bin

root@OpenWrt:~#  ls /lib/firmware/ath11k/qcn6122/hw1.0/
board-2.bin
root@OpenWrt:~#

In your patchset, it seems you've used UPPER case for this directory

+		.fw = {
+			.dir = "QCN6122/hw1.0",

[   14.217349] ath11k b00a040.wifi1: failed to fetch board.bin from QCN6122/hw1.0

Is there a reason for this ? or is this just to be consistent with the 5018 dir .. "IPQ5018/hw1.0" ??

its failing because ipq-wifi makefile has not been updated to reflect this change.

    $(call ipq-wifi-install-ath11-one-to,$(1),$(2),qcn6122/hw1.0),\

also seems the path needs updated here

[   13.813968] qcom-q6-mpd cd00000.remoteproc: Direct firmware load for ath11k/qcn6122/hw1.0/m3_fw.mdt failed with error -2

EDIT

even after fixing the paths above it still fails to start either radio..

[   11.730670] NET: Registered PF_PPPOX protocol family
[   11.766970] ath11k c000000.wifi: Multipd architecture - userpd: 1
[   11.784416] ath11k c000000.wifi: ipq5018 hw1.0
[   11.784458] ath11k c000000.wifi: FW memory mode: 2
[   11.880342] remoteproc remoteproc1: powering up pd-1
[   11.881168] remoteproc remoteproc1: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[   11.884520] remoteproc remoteproc0: powering up cd00000.remoteproc
[   11.892829] remoteproc remoteproc0: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[   14.011090] remoteproc remoteproc0: remote processor cd00000.remoteproc is now up
[   14.030180] remoteproc remoteproc1: remote processor pd-1 is now up
[   14.033386] ath11k b00a040.wifi1: Multipd architecture - userpd: 3
[   14.035891] ath11k b00a040.wifi1: qcn6122 hw1.0
[   14.041539] ath11k b00a040.wifi1: FW memory mode: 2
[   14.055796] ath11k c000000.wifi: qmi fail to get qcom,m3-dump-addr, ignore m3 dump mem req
[   14.063411] ath11k c000000.wifi: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[   14.063482] ath11k c000000.wifi: fw_version 0x270206d0 fw_build_timestamp 2022-08-04 13:28 fw_build_id WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
[   14.107105] remoteproc remoteproc2: powering up pd-3
[   14.107439] remoteproc remoteproc2: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[   14.122280] remoteproc remoteproc2: remote processor pd-3 is now up
[   14.136030] kmodloader: done loading kernel modules from /etc/modules.d/*
[   14.226228] ath11k b00a040.wifi1: qmi ignore invalid mem req type 10
[   14.233574] ath11k b00a040.wifi1: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[   14.233635] ath11k b00a040.wifi1: fw_version 0x270206d0 fw_build_timestamp 2022-08-04 13:28 fw_build_id WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
[   14.373588] ath11k c000000.wifi: qmi failed to load CAL data file:cal-ahb-c000000.wifi.bin
[   14.373871] ath11k c000000.wifi: failed to load board data file: -12
[   14.635783] ath11k b00a040.wifi1: qmi failed to load CAL data file:cal-ahb-b00a040.wifi1.bin
[   14.636228] ath11k b00a040.wifi1: failed to load board data file: -12
[   21.745995] nss-dp 39d00000.dp2 eth1: PHY Link is down
[   21.765549] nss-dp 39d00000.dp2 eth1: PHY Link up speed: 1000
[   21.782344] qca8k 90000.mdio-1:11 lan1: configuring for phy/gmii link mode

with this, I assume this patchset is not yet complete , therefore I will rollback to the old method for the time being. Please let me know when this is ready for testing.

463

I edited a previous commit, rebased, then forced updated my repo, perhaps thayt’s giving you issues.
I had to flash the factory image, not sysupgrade to make it work (to ensure the right paths for caldata and firmware is used). The hotplug script to pull caldata is also amended.

Here’s the patch:

Yes, I used uppercase to make it consistent with all other ath11k wifi chips.

1 Like
464

Thanks, i'll have a look at it.

465

I nuked it (make dirclean) and rebuilt, seems to have fixed it ...

Please press Enter to activate this console.
[   10.993969] kmodloader: loading kernel modules from /etc/modules.d/*
[   11.227717] urngd: v1.0.2 started.
[   11.248761] Loading modules backported from Linux version v6.11.2-0-g7aa21fec187b
[   11.248803] Backport generated by backports.git v6.1.110-1-32-gc61f71fe0942
[   11.307288] NET: Registered PF_QIPCRTR protocol family
[   11.487711] PPP generic driver version 2.4.2
[   11.489928] NET: Registered PF_PPPOX protocol family
[   11.511523] ath11k c000000.wifi: Multipd architecture - userpd: 1
[   11.512036] ath11k c000000.wifi: ipq5018 hw1.0
[   11.516793] ath11k c000000.wifi: FW memory mode: 2
[   11.603215] remoteproc remoteproc1: powering up pd-1
[   11.604322] remoteproc remoteproc1: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[   11.607288] remoteproc remoteproc0: powering up cd00000.remoteproc
[   11.615802] remoteproc remoteproc0: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[   13.762811] remoteproc remoteproc0: remote processor cd00000.remoteproc is now up
[   13.781912] remoteproc remoteproc1: remote processor pd-1 is now up
[   13.785260] ath11k b00a040.wifi1: Multipd architecture - userpd: 3
[   13.787605] ath11k b00a040.wifi1: qcn6122 hw1.0
[   13.793269] ath11k b00a040.wifi1: FW memory mode: 2
[   13.807805] ath11k c000000.wifi: qmi fail to get qcom,m3-dump-addr, ignore m3 dump mem req
[   13.815432] ath11k c000000.wifi: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[   13.815513] ath11k c000000.wifi: fw_version 0x270206d0 fw_build_timestamp 2022-08-04 13:28 fw_build_id WLAN.HK.2.1
[   13.860540] remoteproc remoteproc2: powering up pd-3
[   13.860885] remoteproc remoteproc2: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[   13.875309] remoteproc remoteproc2: remote processor pd-3 is now up
[   13.886910] kmodloader: done loading kernel modules from /etc/modules.d/*
[   13.971735] ath11k b00a040.wifi1: qmi ignore invalid mem req type 10
[   13.979104] ath11k b00a040.wifi1: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[   13.979197] ath11k b00a040.wifi1: fw_version 0x270206d0 fw_build_timestamp 2022-08-04 13:28 fw_build_id WLAN.HK.21
[   32.484158] nss-dp 39d00000.dp2 eth1: PHY Link is down
[   32.509021] nss-dp 39d00000.dp2 eth1: PHY Link up speed: 1000
1 Like
466

I’ve just resumed work on preparing the patch set for adding the ipq50xx target, and rebased my repo on the latest changes incl the 6.6.61 kernel.

@robimarko: with the latest change to ath11k-firmware pointing to the new repo on codelinaro, fw files for ipq5018 are of a lower fw version and the ones for qcn6122 aren’t available. As package maintainer, what would you recommend? How would one request fw files on the new repo? In the meantime, create a separate package for ipq5018/qcn6122?

467

You can require the FW to be added via the ath11k mailing list, but in the meanwhile you can manually download them from a different endpoint in ath11k-firmware package

1 Like
468

This is now fixed, good catch, will push the updated patch tomorrow. (Weird that wifi was working without it anyways)