Was I tagged or something? Because I was notified lol
Haha yeah I replied but it got moved to the mx5500 thread instead as a variation of that.
Ah I see, was just strange to see the post was deleted lol
Can you run
cat /sys/firmware/devicetree/base/soc/ess-instance/ess-switch1@1/compatible
And likewise on all PHYs you find under
/sys/firmware/devicetree/base/soc/mdio@88000/
if you load my initramfs image, you could also issue the following command to identify what phys are connected:
mdio 8*
mdio 9*
I suspect the topology to be a qca8337 switch connected to MAC1 on the ipq5018 switch with the 2.5gbps wan port directly attached to MAC0 with a 2.5 gbps PHY.
I'm totally not against it, I simply 1. don't have the time right now, 2. need to learn a lot as I've never tinkered with NSS, and 3. was discouraged by @BrainSlayer who mentioned getting NSS to work for ipq50xx is a big pain 
1 Like
its not a big pain. just he mx5500/mr5500 is a big pain since the only nss firmware with works on this device is the one provided in the vendor firmware. now there are 2 ipq5018 revisions too. it seem that this cpu variant is very special used on these devices
1 Like
you guessed correct
~ # cat /sys/firmware/devicetree/base/soc/ess-instance/ess-switch1@1/compatibleSamknows: waiting for node mode setting...
qcom,ess-switch-qca83xx~ #
/sys/firmware/devicetree/base/soc/mdio@88000 # ls -l
-r--r--r-- 1 root root 4 Jun 2 01:02 #address-cells
-r--r--r-- 1 root root 4 Jun 2 01:02 #size-cells
-r--r--r-- 1 root root 32 Jun 2 01:02 compatible
drwxr-xr-x 2 root root 0 Jun 2 01:02 ethernet-phy@0
-r--r--r-- 1 root root 5 Jun 2 01:02 name
-r--r--r-- 1 root root 4 Jun 2 01:02 phandle
-r--r--r-- 1 root root 8 Jun 2 01:02 reg
-r--r--r-- 1 root root 14 Jun 2 01:02 reset-names
-r--r--r-- 1 root root 8 Jun 2 01:02 resets
-r--r--r-- 1 root root 3 Jun 2 01:02 status
/sys/firmware/devicetree/base/soc/mdio@88000/ethernet-phy@0 # ls -l
-r--r--r-- 1 root root 13 Jun 2 01:03 name
-r--r--r-- 1 root root 4 Jun 2 01:03 reg
/sys/firmware/devicetree/base/soc/mdio@88000/ethernet-phy@0 # cat name
ethernet-phy/sys/firmware/devicetree/base/soc/mdio@88000/ethernet-phy@0 #
/sys/firmware/devicetree/base/soc/mdio@88000/ethernet-phy@0 #
/sys/firmware/devicetree/base/soc/mdio@88000/ethernet-phy@0 # cat reg
/sys/firmware/devicetree/base/soc/mdio@88000/ethernet-phy@0
on basis I have already flashed mx5500 i saw the following
root@OpenWrt:~# mdio 8*
DEV PHY-ID LINK
0x00 0x00000000 down
0x01 0x00000000 down
0x02 0x00000000 down
0x03 0x00000000 down
0x04 0x00000000 down
0x05 0x00000000 down
0x06 0x00000000 down
0x07 0x004dd0c0 down
0x08 0x00000000 down
0x09 0x00000000 down
0x0a 0x00000000 down
0x0b 0x00000000 down
0x0c 0x00000000 down
0x0d 0x00000000 down
0x0e 0x00000000 down
0x0f 0x00000000 down
0x10 0x00000000 down
0x11 0x00000000 down
0x12 0x00000000 down
0x13 0x00000000 down
0x14 0x00000000 down
0x15 0x00000000 down
0x16 0x00000000 down
0x17 0x00000000 down
0x18 0x00000000 down
0x19 0x00000000 down
0x1a 0x00000000 down
0x1b 0x00000000 down
0x1c 0x00000000 down
0x1d 0x00000000 down
0x1e 0x00000000 down
0x1f 0x00000000 down
root@OpenWrt:~# mdio 9*
DEV PHY-ID LINK
0x00 0x004dd036 down
0x01 0x004dd036 down
0x02 0x004dd036 down
0x03 0x004dd036 down
0x04 0x004dd036 down
0x10 0x00000000 down
0x11 0x55555555 up
0x12 0x00700000 down
0x13 0x00000000 down
0x14 0x00000000 down
0x15 0x00000000 down
0x16 0x00000000 down
0x17 0x00000000 down
0x18 0x00000000 down
@Hostle, @hzyitc: I've managed to massively simplify the QCN6122 wifi driver and have it follow the existing hybrid_bus_type code path and use the existing related functions to initialize and setup the device (incl. the interrupts for CE and DP). I'll push the code soon to my repo, but I would like to ask you for a favor to see whether the changes would also work for your particular devices. I'd like to get the assigned base address for the MSI interrupts.
in pcic.c, in function ath11k_pcic_ipci_config_irq, can you add one line, compile and load the image and send me an excerpt of dmesg?
can you add:
ath11k_info(ab, "msi irq %d - addr_lo: %d, addr_hi: %d\n", i, ab->pci.msi.addr_lo, ab->pci.msi.addr_hi);
right after
i++;
ab->pci.msi.addr_lo = msi_desc->msg.address_lo;
ab->pci.msi.addr_hi = msi_desc->msg.address_hi;
if the outcome is as expected, we'd have much higher chances of getting the support for QCN6122 upstreamed, thanks!
1 Like
ok i found it here
/openwrt-pr/build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq50xx/mac80211-regular/backports-6.11.2/drivers/net/wireless/ath/ath11k/pcic.c
compiling now...
1 Like
Oh, I have resolved this. But the busy jobs making me having no time to prepare PR. lol...
Anyway, I have push it to github. You can refer to it.
great stuff @hzyitc, appreciate the work. Don't hate me for it, but I've got a much much simpler way... patches incoming. It uses the wcn6750 code path which is already upstreamed, all we need is to add the hw params and a small number of changes and that's it.
and here's the patch set:
mac80211: ath11k: add support for QCN6122 wifi
and modified wifi1 and wifi2 nodes for QCN6122 wifi:
openwrt/target/linux/qualcommax/patches-6.6/0815-arm64-dts-qcom-ipq5018-add-wifi-support.patch
qcom did half a job and only specified the first interrupt but there are 13 and I believe they're static. They second change or addition is the reg pointing to a fixed address in the msi-controller similar to wcn6750, see its dt-bindings here:
[v7,1/9] dt: bindings: net: add bindings of WCN6750 for ath11k - Patchwork
that's why I asked you to test with with the kernel message above to print the address to confirm it's a fixed address across devices, so waiting for @Hostle and would kindly ask you to do the same.
one thing I'm not entirely happy about it the code to lookup the userpd from the ath11k driver. Don't think it'll be accepted upstream by simply adding a property to the wifi node in the DTS, nor do I think exporting the function from the mpd driver is clean. I've tested an approach, which works, to get the userpd from memory loaded by the rproc mpd driver, but that's not entirely clean either..
Sorry for the delay, the honey doo list was long today.
here is the log
Please press Enter to activate this console.
[ 11.283050] kmodloader: loading kernel modules from /etc/modules.d/*
[ 11.473926] urngd: v1.0.2 started.
[ 11.658397] Loading modules backported from Linux version v6.11.2-0-g7aa21fec187b
[ 11.658440] Backport generated by backports.git v6.1.110-1-32-gc61f71fe0942
[ 11.690849] NET: Registered PF_QIPCRTR protocol family
[ 11.880489] PPP generic driver version 2.4.2
[ 11.882665] NET: Registered PF_PPPOX protocol family
[ 11.904301] ath11k c000000.wifi: ipq5018 hw1.0
[ 11.904357] ath11k c000000.wifi: FW memory mode: 2
[ 11.981702] remoteproc remoteproc1: powering up pd-1
[ 11.982523] remoteproc remoteproc1: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[ 11.985889] remoteproc remoteproc0: powering up cd00000.remoteproc
[ 11.994287] remoteproc remoteproc0: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[ 14.138562] remoteproc remoteproc0: remote processor cd00000.remoteproc is now up
[ 14.157950] remoteproc remoteproc1: remote processor pd-1 is now up
[ 14.162084] ath11k soc@0:wifi1@c000000: qcn6122 hw1.0
[ 14.163058] ath11k soc@0:wifi1@c000000: FW memory mode: 2
[ 14.183517] ath11k c000000.wifi: qmi fail to get qcom,m3-dump-addr, ignore m3 dump mem req
[ 14.191012] ath11k c000000.wifi: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[ 14.191081] 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.230931] remoteproc remoteproc2: powering up pd-3
[ 14.231264] remoteproc remoteproc2: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[ 14.246504] remoteproc remoteproc2: remote processor pd-3 is now up
[ 14.248096] ath11k soc@0:wifi1@c000000: msi irq 1 - addr_lo: 184590400, addr_hi: 0
[ 14.251673] ath11k soc@0:wifi1@c000000: msi irq 2 - addr_lo: 184590400, addr_hi: 0
[ 14.259519] ath11k soc@0:wifi1@c000000: msi irq 3 - addr_lo: 184590400, addr_hi: 0
[ 14.266950] ath11k soc@0:wifi1@c000000: msi irq 4 - addr_lo: 184590400, addr_hi: 0
[ 14.274477] ath11k soc@0:wifi1@c000000: msi irq 6 - addr_lo: 184590400, addr_hi: 0
[ 14.282028] ath11k soc@0:wifi1@c000000: msi irq 1 - addr_lo: 184590400, addr_hi: 0
[ 14.289667] ath11k soc@0:wifi1@c000000: msi irq 2 - addr_lo: 184590400, addr_hi: 0
[ 14.297198] ath11k soc@0:wifi1@c000000: msi irq 3 - addr_lo: 184590400, addr_hi: 0
[ 14.304866] ath11k soc@0:wifi1@c000000: msi irq 4 - addr_lo: 184590400, addr_hi: 0
[ 14.312332] ath11k soc@0:wifi1@c000000: msi irq 5 - addr_lo: 184590400, addr_hi: 0
[ 14.319863] ath11k soc@0:wifi1@c000000: msi irq 6 - addr_lo: 184590400, addr_hi: 0
[ 14.327464] ath11k soc@0:wifi1@c000000: msi irq 7 - addr_lo: 184590400, addr_hi: 0
[ 14.335014] ath11k soc@0:wifi1@c000000: msi irq 8 - addr_lo: 184590400, addr_hi: 0
[ 14.347641] ath11k soc@0:wifi1@c000000: qmi ignore invalid mem req type 10
[ 14.359031] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 14.359341] ath11k soc@0:wifi1@c000000: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[ 14.364908] ath11k soc@0:wifi1@c000000: fw_version 0x270206d0 fw_build_timestamp 2022-08-04 13:28 fw_build_id WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
1 Like
Cool, that confirms it’s at the same fixed address, thanks!
1 Like
@georgem83 I'm glad to see some many peoples trying to make IPQ5018 upstream. It's a odd chip in Qualcomm WiFi 6 Family, Lots of modules are special, make it requires lots of extra jobs.
I believe they're static
The addr is fixed. Because it's the addr of v2m0.
But the irqs are not. It depend on the number and types of your PCI-E device. But it may seem like yes when you only have one PCI device ( the wifi ).
MSI ( not MSI-X ) is the dynamic resources:
- The device can require 2^X vectors (X <= 5)
- The host must alloc consecutive vectors to it.
So the irq shouldn't be 416 when there is an other PCI-E device as device0 while QCN6122 as device1.
According to the MSI spec and my understand, it's seem like that it's ok to use 0-15 for qcn6122_0 and 16-31 for qcn6122_1. But in the downstream dts, the qcn6122_1 use the different MSI group. ( 416 for qcn6122_0, 448 for qcn6122_1 ). I'm not sure why. Is QCN6122 require 32 vectors ? Or it just use different MSI groups for different devices ?
I would try to insert an other PCI-E card and try to make it work with QCN6122 to see what happen. But due to my busy jobs, it requires lots of time. lol...
patches incoming. It uses the wcn6750 code path which is already upstreamed, all we need is to add the hw params and a small number of changes and that's it.
It's seem like that most of our patches are same.
What's I do special is to adjust the windows of QCN6122, make it same as WCN6750. So we don't need the dp_window_idx field. You can check the ath11k_ahb_config_static_window_qcn6122() function.
What's more, the value of hal_seq_wcss_umac_ce0_src_reg... are incorrent. I fix them. So the only thing different between qcn6122_regs and wcn6750_regs is hal_shadow_base_addr field ( hal_reo1_misc_ctl field is not used in QCN6122 ).
one thing I'm not entirely happy about it the code to lookup the userpd from the ath11k driver.
Yes. It's bad. An solution is to use reg property, similar like MDIO device. But I think this get_upd_id() function should be put into MPD driver. At least, this is a MPD special function.
So the irq shouldn't be 416 when there is an other PCI-E device as device0 while QCN6122 as device1.
do you know of any example? none of the reference boards have a config of ipq5018 + qcn6122 + other PCIE device. It's one of the following board configs:
- ipq5018 + qcn9074(or 9024)
- ipq5018 + qcn6122
- ipq5018 + qcn6122 + qcn6122 (for wifi 6E)
so if it has a qcn6122 card, it will always be device0 based on the ref boards and I don't know of any other router/access point with another config.
Just as qcn6750 is specific to snapdragon boards, qcn6122 is only found on ipq5018 boards.
if it has a qcn6122 card, it will always be device0
qcn6122 is a just pcie device. And at most device, it connect to PCIE1 ( as you known, upd2 use pcie1 by default ). So when the device has an other pcie card ( e.g. 5g modem), it possibly connect to pcie0.
I'm not sure is there a published CPE device do like this. But i have a device can test this.
I don't disagree, I understand, but even their own dts has them hardcoded (the first one at 416 and second one at 448) and they must be consecutive..
You can continue your progress. At lease it work on most device.
I will do the test for the case what I said when I have time. ( As your said, this kind of hardware may not existed. ). If the irqs are not fixed. I can open a new PR. 
1 Like