Thanks! We have an entry for mdio but it was missing the reset-gpio. I was able to update this along with port@5.
ahb makes since but then what are those 2 devices being detected on the pci bus currently?
The OEM DTS seems to have a lot that was never used. Audio even. Another item is the fan controller where fan_right (i2c @49) exists in DTS even though it's not populated on the board.
To get wifi working properly, you need to create a device specific board file.
Use the ath11k-bdencoder:
You need first figure out, which board file the rax120 is using, from the stock bootlog:
40.954101] cnss: BDF IPQ8074/bdwlan.bin size 131072
Full path should be /lib/firmware/IPQ8074, grab that file from the extracted firmware or the device and use it to create a proper board file.
Create a board-2.json like that:
[
{
"names": [
"bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=Netgear-RAX120"
],
"data": "bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=Netgear-RAX120.bin"
}
]
-> board-id 255 should be the right one, as there isn't a board_id set in the stock DTS and the default is 255 / 0xFF
Rename your board file to 'bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=Netgear-RAX120.bin' and then use the "ath11k-bdencoder -c board-2.json"
Next step create an override in ipq-wifi package, you can find an example in this commit:
Last step: add that to your device DTS:
&wifi {
status = "okay";
/* using board_id 0xff is intentionally
* as the stock firmware is also using this default board_id
*/
qcom,board_id = <0xff>;
qcom,ath11k-calibration-variant = "Netgear-RAX120;
};
The ath11k driver should then find the right board file.
Would that single entry cover both QCN5054 chips? OEM DTS has 2 wifi entry's for c0000000.
Then I think the QCN5024 chip (QCA6290) is sitting on mhi.
They are both RF for the built-in remoteproc, so they dont have a DT node nor the exact model matters to the kernel at all.
Noted. We can probably remove a bit of unnecessary DT data then.
'python2 ath11k-bdencoder -c board-2.json' creates a board-2.bin file however it's basically empty.
Attempting to inject the original bin file from OEM (firmware/IPQ8074/bdwlan.b210) yields the following results.
root@OpenWrt:/# dmesg | grep ath11k
[ 10.721496] ath11k c000000.wifi: ipq8074 hw2.0
[ 11.085733] ath11k c000000.wifi: qmi ignore invalid mem req type 3
[ 11.091290] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
[ 11.096757] ath11k c000000.wifi: fw_version 0x250a04a5 fw_build_timestamp 2021-12-20 07:09 fw_build_id WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
[ 11.105581] ath11k c000000.wifi: found invalid board magic
[ 11.118482] ath11k c000000.wifi: found invalid board magic
[ 11.155969] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=Netgear-RAX120 from ath11k/IPQ8074/hw2.0/board-2.bin
[ 11.156031] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255 from ath11k/IPQ8074/hw2.0/board-2.bin
[ 11.169424] ath11k c000000.wifi: failed to fetch board.bin from IPQ8074/hw2.0
[ 11.182252] ath11k c000000.wifi: qmi failed to fetch board file: -12
[ 11.189274] ath11k c000000.wifi: failed to load board data file: -12
remoteproc shows the following
root@OpenWrt:/# dmesg | grep remote
[ 4.069377] remoteproc remoteproc0: cd00000.q6v5_wcss is available
[ 10.721714] remoteproc remoteproc0: powering up cd00000.q6v5_wcss
[ 10.724892] remoteproc remoteproc0: Booting fw image IPQ8074/q6_fw.mdt, size 668
[ 11.084292] remoteproc remoteproc0: remote processor cd00000.q6v5_wcss is now upYou need python3 ath11k-bdencoder -c board-2.json as it was converted to Python3, and using Python2 will just make it spit out a 20 or so byte empty file
2 and 3 are giving me the same results for some reason. Both output a 20 byte file that only contains "QCA-ATH11K-BOARD"
Thats weird as I used the board encoder recently
It's odd that I get no errors on either version. I uploaded the OEM .bin file to the test repo if you have a moment to try on a known working instance board encoder.
here you go
Thanks!
root@OpenWrt:/# dmesg | grep ath
[ 11.519997] ath11k c000000.wifi: ipq8074 hw2.0
[ 11.884900] ath11k c000000.wifi: qmi ignore invalid mem req type 3
[ 11.890429] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
[ 11.895887] ath11k c000000.wifi: fw_version 0x250a04a5 fw_build_timestamp 2021-12-20 07:09 fw_build_id WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1root@OpenWrt:/# ifconfig -a
br-lan Link encap:Ethernet HWaddr C8:9E:43:82:F0:C0
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fd4a:f24a:f8bb::1/60 Scope:Global
inet6 addr: fe80::ca9e:43ff:fe82:f0c0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2121 (2.0 KiB) TX bytes:1756 (1.7 KiB)
eth0 Link encap:Ethernet HWaddr C8:9E:43:82:F0:C0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Base address:0x1000
eth1 Link encap:Ethernet HWaddr C8:9E:43:82:F0:C1
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Base address:0x1200
eth2 Link encap:Ethernet HWaddr C8:9E:43:82:F0:C2
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Base address:0x1400
eth3 Link encap:Ethernet HWaddr 42:44:AB:0C:65:2A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:40 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3495 (3.4 KiB) TX bytes:1796 (1.7 KiB)
Base address:0x1600
eth4 Link encap:Ethernet HWaddr 32:1A:3B:81:76:A4
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Base address:0x1800
eth5 Link encap:Ethernet HWaddr 56:3F:BA:A6:44:4D
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:2 dropped:2 overruns:0 frame:2
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4 (4.0 B) TX bytes:0 (0.0 B)
Base address:0x7000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:48 errors:0 dropped:0 overruns:0 frame:0
TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3744 (3.6 KiB) TX bytes:3744 (3.6 KiB)
miireg Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
[NO FLAGS] MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr 00:03:7F:12:49:63
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:4096
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan1 Link encap:Ethernet HWaddr 00:03:7F:12:8D:47
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:4096
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan2 Link encap:Ethernet HWaddr 00:03:7F:12:11:6B
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:4096
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Can you post the output of
iwinfo wlan0 freqlist
and
iwinfo wlan2 freqlist
?
Actually you should have one 5G radio for the lower band and the other radio for the upper band.
But according to your screenshot, both 5G radios running on channel 36
Some overlap but wlan0 does appear to cover the higher band.
root@OpenWrt:/# iwinfo wlan0 freqlist
5.180 GHz (Channel 36)
5.200 GHz (Channel 40)
5.220 GHz (Channel 44)
5.240 GHz (Channel 48)
5.260 GHz (Channel 52)
5.280 GHz (Channel 56)
5.300 GHz (Channel 60)
5.320 GHz (Channel 64)
5.500 GHz (Channel 100)
5.520 GHz (Channel 104)
5.540 GHz (Channel 108)
5.560 GHz (Channel 112)
5.580 GHz (Channel 116)
5.600 GHz (Channel 120)
5.620 GHz (Channel 124)
5.640 GHz (Channel 128)
5.660 GHz (Channel 132)
5.680 GHz (Channel 136)
5.700 GHz (Channel 140)
5.720 GHz (Channel 144)
5.745 GHz (Channel 149)
5.765 GHz (Channel 153)
5.785 GHz (Channel 157)
5.805 GHz (Channel 161)
5.825 GHz (Channel 165)
root@OpenWrt:/# iwinfo wlan2 freqlist
5.180 GHz (Channel 36)
5.200 GHz (Channel 40)
5.220 GHz (Channel 44)
5.240 GHz (Channel 48)
5.260 GHz (Channel 52)
5.280 GHz (Channel 56)
5.300 GHz (Channel 60)
5.320 GHz (Channel 64)Current status
Functional items in testing:
Pending:
Looks like ipq807x will get a pull request for OpenWrt. 
I can consolidate the RAX120 commits tomorrow to help with hopeful eventual merging.
wlan0 should only use channels >= 100, due to avoid interference with the second 5G radio.
But it loks like netgear didn't reflect that in the board file.
That means, you need to make sure (in the wireless config) that wlan0 is only using channels >= 100
And I'm pretty sure, wlan0 isn't even technically capable of using channels <100 as the RF-frontend has HF-filters implemented.
The Aquantia phy needs a firmware. You can load that firmware (thanks to robimarko) via aq-fw-download utility. Have a look in the QNAP 301w thread were to grab the firmware and how to load that in linux.
I'm not sure about that ipq led controller. I doubt the driver is available upstream.
You can just ignore the IPQ-LED controller and set those pins as GPIO-s and use GPIO LED driver
It's not upstream. g761 is not upstream either but thankfully g760a and g762 are so I had refences.
We can set them as GPIO except OEM only defines clk, data, and clr pins. I'm not sure the best way to identify the correct pins.
ledc_pinmux {
linux,phandle = <0x2b>;
phandle = <0x2b>;
led_clk {
pins = "gpio18";
function = "gpio";
drive-strength = <0x08>;
bias-pull-down;
};
led_data {
pins = "gpio19";
function = "gpio";
drive-strength = <0x08>;
bias-pull-down;
};
led_clr {
pins = "gpio20";
function = "gpio";
drive-strength = <0x08>;
bias-pull-up;
};
gpio_usb1_enable {
pins = "gpio30";
function = "gpio";
drive-strength = <0x08>;
bias-pull-down;
};
gpio_usb2_enable {
pins = "gpio31";
function = "gpio";
drive-strength = <0x08>;
bias-pull-down;
};
};Ahh, that looks like a SSR to me, probably HC595 or one of the compatibles.
For that you bitbang SPI via GPIOs
That was it. hc164 here. 10 of 11 LED's are working.. #11 is a redundant Wifi_On LED under the rfkill button and this could be connected to the wifi hardware directly since none of the free GPIO's seem to drive it.
Buttons are good as well.
I loaded in the aq-fw-download package and did not notice any effect but I'll play around with it more later on.
Its not enough to just have it installed, you have to load the fw using it