On 9/3/2026 6:12 PM, Hideo Sumi wrote:
> 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
Thanks for providing the details. This helps clarify the setup.
I checked the backports-6.18.39 code you are using. With that version of the
Multi-PD implementation,
the root PD and the Text PD handling is done by the remoteproc side, so for the
issues related to the
Text PD, I think it would be better to confirm the expected behavior with the
remoteproc team.
Regarding the latest ath.git ToT + remoteproc v14 series, please note that the
firmware you are currently using:
WLAN.WBE.1.3.2-00067-QCAHKSWPL_SILICONZ-1.128291.1.135427.1
may not be directly compatible with the latest upstream flow. The WCSS secure
PIL flow expects the Q6 DTB
rather than the bootargs-based flow.
I am also not yet sure whether the v14 remoteproc series contains all the
changes required for the complete
Multi-PD bringup on IPQ5332.
I have added Vignesh from the remoteproc team to help clarify the Text PD
handling, and also whether v14 is
sufficient for the IPQ5332 Multi-PD setup.
