On 9/3/2026, Aaradhana Sahu wrote:
> Before we look into the SMEM handling, could you please confirm whether
> you are using the latest ath.git ToT and whether the remoteproc v14
> series is included?
No on both counts, and thank you for the pointer -- I had not seen v14.
Let me be precise about the base so we compare like for like, and then
ask you the one question that would settle most of this.
This is an OpenWrt build, not ath.git ToT:
- kernel 6.18.44
- ath12k from the OpenWrt "backports-6.18.39" package
- the multipd remoteproc support is the *old* series: Manikanta
Mylavarapu's original multipd patches (Nov 2023) plus Ziyang Huang's
"split q6_wcss to rootpd and userpd" fixes (Sep 2024), carried as
OpenWrt target patches.
It does not include your v14 series. So it is very possible the issues I
raised are already addressed there, and I do not want to send you
chasing a three-year-old base.
The core of my first mail was a *text PD* level between the root PD and
the user PDs, which the vendor firmware for this part requires and which
the 2023/2024 series does not model, so I added it locally:
q6v5_wcss qcom,ipq5332-q6-mpd q6_fw0.mdt root PD
text-pd qcom,ipq5332-mpd-upd-text q6_fw3.mdt shared RO text
pd1 q6_fw1.mdt user PD
pd2 q6_fw2.mdt user PD
So the question that would settle it: does the v14 series introduce this
text-PD level (a shared read-only text image loaded between root and
user PDs)? If it does, my local patch is redundant and the right move is
simply to use v14 -- no need to debug the old base at all. You wrote the
series, so you can answer that far faster than I can by porting it.
I am glad to help validate v14 on this hardware if that is useful -- if
you can point me at the base it is meant to apply on (ath.git ToT plus
the series, or a branch), I will build it for IPQ5332 and report what
reproduces. I would just rather not promise a blind full rebase, since
2.4 GHz already works here on the old base and I do not want to trade a
working setup for guesswork. The OpenWrt device support proceeds on the
current base regardless; the upstream question is only about landing on
your track correctly.
The details you asked for, in any case:
Firmware version, from the Q6 error record:
WLAN.WBE.1.3.2-00067-QCAHKSWPL_SILICONZ-1.128291.1.135427.1
Platform: Qualcomm IPQ5332 (Xiaomi BE3600 Pro). Two on-chip WiFi
devices, two user PDs, both attached to the single Q6 root PD via the
shared text PD:
- wifi0 / pd1: on-chip QCA5332, 2.4 GHz, AHB
- wifi1 / pd2: QCN6432, 5 GHz
The multipd DT (our downstream form on the old base):
&q6v5_wcss {
firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw0.mdt",
"ath12k/IPQ5332/hw1.0/iu_fw.mdt",
"ath12k/QCN6432/hw1.0/iu_fw.mdt";
status = "okay";
text-pd3 {
compatible = "qcom,ipq5332-mpd-upd-text";
firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw3.mdt";
pd1 { /* wifi0, 2.4 GHz */
firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw1.mdt";
interrupts-extended =
<&wcss_smp2p_in 8 IRQ_TYPE_NONE>,
<&wcss_smp2p_in 9 IRQ_TYPE_NONE>,
<&wcss_smp2p_in 12 IRQ_TYPE_NONE>,
<&wcss_smp2p_in 11 IRQ_TYPE_NONE>;
interrupt-names = "fatal", "ready",
"spawn-ack", "stop-ack";
qcom,smem-states = <&wcss_smp2p_out 8>,
<&wcss_smp2p_out 9>,
<&wcss_smp2p_out 10>;
qcom,smem-state-names = "shutdown", "stop", "spawn";
};
pd2 { /* wifi1, 5 GHz */
firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw2.mdt";
interrupts-extended =
<&wcss_smp2p_in 16 IRQ_TYPE_NONE>,
<&wcss_smp2p_in 17 IRQ_TYPE_NONE>,
<&wcss_smp2p_in 20 IRQ_TYPE_NONE>,
<&wcss_smp2p_in 19 IRQ_TYPE_NONE>;
interrupt-names = "fatal", "ready",
"spawn-ack", "stop-ack";
qcom,smem-states = <&wcss_smp2p_out 16>,
<&wcss_smp2p_out 17>,
<&wcss_smp2p_out 18>;
qcom,smem-state-names = "shutdown", "stop", "spawn";
};
};
};
&wifi0 { qcom,rproc = <&wcss_upd1>; status = "okay"; }; /* pd1 */
&wifi1 { qcom,rproc = <&wcss_upd2>; status = "okay"; }; /* pd2 */
Thanks,
Hideo
