According to the table in README.md and this https://github.com/hzyitc/openwrt-redmi-ax3000/issues/39 openWrt will start and run on this SOC with some wifi issues
Look, all of those are either pending or even rejected upstream patches or just from QCA-s 5.4 kernel.
SPI-NAND is a nightmare and I dont even want to include anything like the hackjob the original patchset nor the QCA downstream one is
QCN6122 is upstreamed here:
It shares the q6 firmware with IPQ5018’s but you need to take the m3 fw from the QCN6122 folder. Have already built it, though not been able to test yet.
I suppose you used this patch for the PHY driver and added the x1 variant with one lane?
https://patchwork.kernel.org/project/linux-arm-msm/patch/20231003120846.28626-4-quic_nsekar@quicinc.com/
The FW is there, but there is no support for it in the ath11k driver, I looked at the QCA patch for it and its not that complicated.
Yes, I used that patchset and added the missing PHY since both PHY-s are the same calibration wise just with different number of lanes.
I have serious issues with the quality of crap QCA keeps sending upstream, like its always broken, they newer check against dt bindings etc.
I have only 2 IPQ50xx boards, one being a Motorola Q14 that has 2 QCN6122 so its easy to test for me.
In reality, this SoC is way simpler than IPQ807x or IPQ60xx but they had to spice things up with the weird dual MDIO controller that is somehow tied to the networking clocks (Like WTF?) and NANDC version that includes SPI-NAND offloading which basically breaks the whole idea behind SPI-NAND.
So, it shouldnt be that extremely hard to get it into OpenWrt, but will probably find half of the things QCA upstreamed are broken.
That is why I am replying to most of the upstream threads with the issues in hope QCA are the ones fixing them this time.
Update: Seems like QCA is maybe taking the long path to adding a SPI-MEM driver to abstract the SPI-NAND support in the same way as MTK driver was finally accepted recently:
https://patchwork.kernel.org/comment/25272508/
2 Likes
Can I try to boot my AX6000 with stock dts (got it from flattened device tree) and provided repo?
Stock DTS is overcomplicated so maybe I should use QSDK version of it?
stock dts model info:
model = "Qualcomm Technologies, Inc. IPQ5018/AP-MP03.1";
compatible = "qcom,ipq5018-mp03.1\0qcom,ipq5018";
qsdk same model dts: https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4.r1/arch/arm64/boot/dts/qcom/ipq5018-mp03.1.dts
Stock DTS extracted from /sys/firmware/fdt: https://gist.github.com/r1ghty/7e36ab4f6864a0af1c1ab78ff3013dff
I am not associated with that repo in any way so I cannot answer that question.
Ofc. I'll try to merge ax3000 + Stock + AX9000 dts files and text my results later
The "compatible" parameters are used for several settings in the drivers that are only present in qsdk. Your best bet to get something to work is starting with qsdk.
Keep in mind that qcn9000 (5ghz radio) is not supported for ipq5018 in ath11k. If you take a look at the firmware files, the only firmware available are for ipq5018 + qcn6122
I'll try to get minimal boot at first, radio isn't problem at the moment
That's the easy part. Feel free to ask me in private. I have experience with qsdk
What's in it for us?
Hey I accidentally bought this instead of the supported version (the thing this is a successor to). I read this thread but I don't quite get what the status on support is. It sounds like it's possible to access the root OpenWRT interface of the router, but otherwise there isn't much more than that? Not much of a way to make any access permanent?
what do you mean by "permanent access"? once you use the exploit and get access to the shell, you can use it parmanently
Yeah I just can't seem to get any access to it. It seems like the exploit has been done with firmware 1.0.53 but the earliest one I found was 1.0.55 so maybe I'm just SOL in terms of getting access at all
Tried the patcher a cpl posts up ?
I have 1.0.95, patcher works but I think I loose SSH after reboot. Language change is permanent though. I could probably fix SSH but did not have time yet to play with it.
Did anyone try to install wireguard on the rooted stock firmware?
I didn't really get that there was a patcher which was to give access. Should I patch the latest firmware or the oldest ?I can find? Looks like the patcher doesn't work so well on Mac 