I found four screws not under the sticker, but under the rubber strips of the stand.
Thank you.
you could also just upload the factory image to the stock firmware.
Click on the 'CA' link on the right bottom and then go to connectivity which allows you to upload a fw file.
Else just browse to http://ip/fwupdate.html
No need to take the box apart, unless you want to
1 Like
@robimarko: ipq5018 supports USB3 and uses the same (uni)phy driver as the one for ipq5332. The patch was submitted but requires some changes. Do you want me to submit the ‘as is’ patch set by qcom or submit one with requested changes that I would have to add myself?
Ideally, you would send the modified version upstream and then include that, I did that with plenty of QCA drivers that they newer followed-up with, just preserve their authorship and send with modifications
1 Like
If it helps, here’s my commit to refactor the driver:
Ill also look at whether we can snap to the existing support for hybrid bus, which by the sounds of it may just be the same as qcn6122 is actually a PCI device enumerated as AHB.
Do you have any IPQ5018 based device with USB port?
no, not at the moment
usb and bluetooth are not necessary for now. we can drop them in the current PR
qcn6122 is a special device. It's a pcie device. but the driver of pci part is in MPD. ath11k use AHB to communicates with MPD
Installed the openwrt-qualcommax-ipq50xx-linksys_mx5500-squashfs-factory.bin from https://filebin.net/hcue887wxiwghoht on my MX55EC
What should I test?
to start with, please check if ethernet and the wifi radios work as expected. Run some ping and speed tests, then check for stability.
here you can download the 2.12 firmwares for the ipq5018 v2 variants which are used with QCN6122 (see spruce / spr_spr)
beautiful, thanks @BrainSlayer. Will test later and report back
No issue with 5Ghz, test speed is about as good as my T-Mobile hotspot can get me.
Will try 2.4Ghz later today
how's this?
Commits · georgemoussalem/openwrt (github.com)
any other changes required?
Probably different firmware for ipq5018 should be used depending on configuration: IPQ5018: Support for Linksys MX2000 Atlas 6 & MX5500 Atlas 6 Pro - #320 by BrainSlayer
Yes, but you really need to add proper descriptions to all of the patches you are adding
1 Like
initial results from testing fw 2.12 spr_spr are good. Similar throughput measured at ~700Mbps maxing out ISP connection.
I'll leave it running for a couple of days..
in case it's all good, do we then switch to this version? and if so, how do we get it in the quic repo?
[ 12.614443] ath11k c000000.wifi: ipq5018 hw1.0
[ 12.614485] ath11k c000000.wifi: FW memory mode: 2
[ 12.768517] remoteproc remoteproc1: powering up pd-1
[ 12.777067] remoteproc remoteproc1: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[ 12.777128] remoteproc remoteproc0: powering up cd00000.remoteproc
[ 12.784841] remoteproc remoteproc0: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[ 16.437297] remoteproc remoteproc0: remote processor cd00000.remoteproc is now up
[ 16.454386] remoteproc remoteproc1: remote processor pd-1 is now up
[ 16.458410] ath11k soc@0:wifi1@c000000: qcn6122 hw1.0
[ 16.459488] ath11k soc@0:wifi1@c000000: FW memory mode: 2
[ 16.482269] ath11k c000000.wifi: qmi fail to get qcom,m3-dump-addr, ignore m3 dump mem req
[ 16.489733] ath11k c000000.wifi: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[ 16.489795] ath11k c000000.wifi: fw_version 0x2c058558 fw_build_timestamp 2024-07-11 15:51 fw_build_id WLAN.HK.2.12-01368-QCAHKSWPL_SILICONZ-1
[ 16.523449] remoteproc remoteproc2: powering up pd-3
[ 16.523667] remoteproc remoteproc2: Booting fw image ath11k/IPQ5018/hw1.0/q6_fw.mdt, size 1820
[ 16.539067] remoteproc remoteproc2: remote processor pd-3 is now up
[ 16.552724] batman_adv: B.A.T.M.A.N. advanced 2024.2-openwrt-1 (compatibility version 15) loaded
[ 16.564657] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 16.635157] ath11k soc@0:wifi1@c000000: qmi ignore invalid mem req type 10
[ 16.645510] ath11k soc@0:wifi1@c000000: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[ 16.645567] ath11k soc@0:wifi1@c000000: fw_version 0x2c058558 fw_build_timestamp 2024-07-11 15:51 fw_build_id WLAN.HK.2.12-01368-QCAHKSWPL_SILICONZ-1
[ 16.769412] mtdblock: MTD device 'devinfo' is NAND, please consider using UBI block devices instead.
[ 17.830142] mtdblock: MTD device 'devinfo' is NAND, please consider using UBI block devices instead.
[ 17.886067] ath11k c000000.wifi: htt event 48 not handled
[ 19.178595] ath11k soc@0:wifi1@c000000: htt event 48 not handle
the following message occasionally appears in the logs:
[ 472.587104] qca8k 90000.mdio-1:11: port 3 failed to delete fe:06:0c:0d:fe:78 vid 99 from fdb: -2
[ 593.361943] qca8k 90000.mdio-1:11: port 5 failed to delete fe:06:0c:0d:fe:78 vid 99 from fdb: -2
[ 593.362022] qca8k 90000.mdio-1:11: port 2 failed to delete fe:06:0c:0d:fe:78 vid 99 from fdb: -2
I have 2 VLANs, one LAN with VLAN ID 10 and the other Guest with VLAN ID 99.
Anyone else ran into this before? Should I ignore?
qca has to bring it up to the codelinaro repo. i have no influence to it. but i dont think this will ever happen