[PATCH v2] arm64: dts: qcom: hamoa: Add remoteproc in EL2 device trees

[PATCH v2] arm64: dts: qcom: hamoa: Add remoteproc in EL2 device trees

[Xin Liu]

All the existing variants Hamoa boards are using Gunyah hypervisor
which means that, so far, Linux-based OS could only boot in EL1 on
those devices. However, it is possible for us to boot Linux at EL2
on these devices [1].

When running under Gunyah, the remote processor firmware IOMMU streams
are controlled by Gunyah. However, without Gunyah, the IOMMU is managed
by the consumer of this DeviceTree. Therefore, describe the firmware
streams for each remote processor.

Add remoteproc to the EL2 device trees to generate the corresponding
-el2.dtb files.

[1]
https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi

Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
---
Changes in v2:
- Fix the adsp iommus mask
- Link to v1 : https://lore.kernel.org/all/20260130073113.3091884-1-xin.liu@oss.qualcomm.com/

 arch/arm64/boot/dts/qcom/x1-el2.dtso | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/x1-el2.dtso b/arch/arm64/boot/dts/qcom/x1-el2.dtso
index 175679be01eb..ee006742d6f3 100644
--- a/arch/arm64/boot/dts/qcom/x1-el2.dtso
+++ b/arch/arm64/boot/dts/qcom/x1-el2.dtso
@@ -52,6 +52,14 @@ &pcie_smmu {
 	status = "okay";
 };
 
+&remoteproc_adsp {
+	iommus = <&apps_smmu 0x1000 0x80>;
+};
+
+&remoteproc_cdsp {
+	iommus = <&apps_smmu 0x0c00 0x0>;
+};
+
 /*
  * The "SBSA watchdog" is implemented in software in Gunyah
  * and can't be used when running in EL2.
-- 
2.43.0

Re: [PATCH v2] arm64: dts: qcom: hamoa: Add remoteproc in EL2 device trees

[Abel Vesa]

On 26-02-01 21:54:36, Xin Liu wrote:
> All the existing variants Hamoa boards are using Gunyah hypervisor
> which means that, so far, Linux-based OS could only boot in EL1 on
> those devices. However, it is possible for us to boot Linux at EL2
> on these devices [1].
> 
> When running under Gunyah, the remote processor firmware IOMMU streams
> are controlled by Gunyah. However, without Gunyah, the IOMMU is managed
> by the consumer of this DeviceTree. Therefore, describe the firmware
> streams for each remote processor.
> 
> Add remoteproc to the EL2 device trees to generate the corresponding
> -el2.dtb files.
> 
> [1]
> https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
> 
> Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>

I think subject line is misleading. You are not adding the remoteprocs,
but rather overriding iommus properties.

With that fixed:

Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Re: [PATCH v2] arm64: dts: qcom: hamoa: Add remoteproc in EL2 device trees

[Bjorn Andersson]

On Sun, Feb 01, 2026 at 09:54:36PM -0800, Xin Liu wrote:
> All the existing variants Hamoa boards are using Gunyah hypervisor
> which means that, so far, Linux-based OS could only boot in EL1 on
> those devices. However, it is possible for us to boot Linux at EL2
> on these devices [1].
> 

Lots of people are running Linux at EL2 on their Hamoa laptops, but
then there's no PAS. I presume adding iommu properties won't "hurt" in
that case, but can you confirm that with this change remoteproc is fully
working somewhere (i.e. [1] refers to a firmware for which the Glymur
PAS/PIL changes has been backported?)

Regards,
Bjorn

> When running under Gunyah, the remote processor firmware IOMMU streams
> are controlled by Gunyah. However, without Gunyah, the IOMMU is managed
> by the consumer of this DeviceTree. Therefore, describe the firmware
> streams for each remote processor.
> 
> Add remoteproc to the EL2 device trees to generate the corresponding
> -el2.dtb files.
> 
> [1]
> https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
> 
> Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
> ---
> Changes in v2:
> - Fix the adsp iommus mask
> - Link to v1 : https://lore.kernel.org/all/20260130073113.3091884-1-xin.liu@oss.qualcomm.com/
> 
>  arch/arm64/boot/dts/qcom/x1-el2.dtso | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/x1-el2.dtso b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> index 175679be01eb..ee006742d6f3 100644
> --- a/arch/arm64/boot/dts/qcom/x1-el2.dtso
> +++ b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> @@ -52,6 +52,14 @@ &pcie_smmu {
>  	status = "okay";
>  };
>  
> +&remoteproc_adsp {
> +	iommus = <&apps_smmu 0x1000 0x80>;
> +};
> +
> +&remoteproc_cdsp {
> +	iommus = <&apps_smmu 0x0c00 0x0>;
> +};
> +
>  /*
>   * The "SBSA watchdog" is implemented in software in Gunyah
>   * and can't be used when running in EL2.
> -- 
> 2.43.0
> 

Re: [PATCH v2] arm64: dts: qcom: hamoa: Add remoteproc in EL2 device trees

[Stephan Gerhold]

On Wed, Mar 04, 2026 at 02:16:55PM -0600, Bjorn Andersson wrote:
> On Sun, Feb 01, 2026 at 09:54:36PM -0800, Xin Liu wrote:
> > All the existing variants Hamoa boards are using Gunyah hypervisor
> > which means that, so far, Linux-based OS could only boot in EL1 on
> > those devices. However, it is possible for us to boot Linux at EL2
> > on these devices [1].
> > 
> 
> Lots of people are running Linux at EL2 on their Hamoa laptops, but
> then there's no PAS. I presume adding iommu properties won't "hurt" in
> that case, but can you confirm that with this change remoteproc is fully
> working somewhere (i.e. [1] refers to a firmware for which the Glymur
> PAS/PIL changes has been backported?)
> 

On the contrary, I would expect that this will break the existing EL2
setup people have on their Hamoa laptops. I have last tested this half a
year ago (and I don't have a suitable device for testing this anymore),
but I don't think much has changed in this area:

Since we can't start/stop remoteprocs without PAS, everyone using EL2
with the old (non-PAS) firmware currently relies on remoteprocs that are
already started by the boot firmware before Linux is started. This can
be just the "lite" ADSP that is started by UEFI for initial charging and
USB-C detection, or even the full ADSP/CDSP via a custom UEFI driver
(qebspil [1]). All of these will stay running even if we fail to
stop/start them via PAS. Without extra kernel patches, we can't make use
of the remoteprocs, but the lite ADSP firmware will probably continue
doing its work in the background, i.e. it will start/stop charging as
needed, you just won't be able to observe the status from Linux.

We manage the full IOMMU even when there is no PAS. The reason why
people are not running into issues is that the bootloader handover code
inside arm-smmu-qcom.c qcom_smmu_cfg_probe() configures bypass for all
SIDs used by the boot firmware, which includes the SIDs for all the
remoteprocs. Adding these SIDs in the "iommus" property of an actual
device will replace the bypass with a translated context, which
currently won't be set up anywhere for the non-PAS use case.

In addition, even on newer firmware with PAS support I would expect that
special care is required to "atomically" handover the IOMMU
configuration from the bootloader. If the lite ADSP remains running on
these firmware versions as well, the bypass or suitable mappings must be
maintained until the lite ADSP firmware is stopped.

Glymur does not have this problem because the same functionality is
implemented in the SoCCP, which does not have any "iommus" defined
(managed as secure context banks by TZ?).

[1]: https://github.com/stephan-gh/qebspil

> 
> > When running under Gunyah, the remote processor firmware IOMMU streams
> > are controlled by Gunyah. However, without Gunyah, the IOMMU is managed
> > by the consumer of this DeviceTree. Therefore, describe the firmware
> > streams for each remote processor.
> > 
> > Add remoteproc to the EL2 device trees to generate the corresponding
> > -el2.dtb files.
> > 
> > [1]
> > https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
> > 
> > Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
> > ---
> > Changes in v2:
> > - Fix the adsp iommus mask
> > - Link to v1 : https://lore.kernel.org/all/20260130073113.3091884-1-xin.liu@oss.qualcomm.com/
> > 
> >  arch/arm64/boot/dts/qcom/x1-el2.dtso | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/x1-el2.dtso b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> > index 175679be01eb..ee006742d6f3 100644
> > --- a/arch/arm64/boot/dts/qcom/x1-el2.dtso
> > +++ b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> > @@ -52,6 +52,14 @@ &pcie_smmu {
> >  	status = "okay";
> >  };
> >  
> > +&remoteproc_adsp {
> > +	iommus = <&apps_smmu 0x1000 0x80>;
> > +};

I have seen the ADSP trigger some faults with SID 0x100c as well.
I don't know what exactly that represents, but do we need to handle
that somewhere?

Thanks,
Stephan

Re: [PATCH v2] arm64: dts: qcom: hamoa: Add remoteproc in EL2 device trees

[Val Packett]

On 3/5/26 7:57 AM, Stephan Gerhold wrote:
> On Wed, Mar 04, 2026 at 02:16:55PM -0600, Bjorn Andersson wrote:
>> On Sun, Feb 01, 2026 at 09:54:36PM -0800, Xin Liu wrote:
>>> All the existing variants Hamoa boards are using Gunyah hypervisor
>>> which means that, so far, Linux-based OS could only boot in EL1 on
>>> those devices. However, it is possible for us to boot Linux at EL2
>>> on these devices [1].
>>>
>> Lots of people are running Linux at EL2 on their Hamoa laptops, but
>> then there's no PAS. I presume adding iommu properties won't "hurt" in
>> that case, but can you confirm that with this change remoteproc is fully
>> working somewhere (i.e. [1] refers to a firmware for which the Glymur
>> PAS/PIL changes has been backported?)
>>
> On the contrary, I would expect that this will break the existing EL2
> setup people have on their Hamoa laptops. I have last tested this half a
> year ago (and I don't have a suitable device for testing this anymore),
> but I don't think much has changed in this area:

It did break and I just spent like 3 hours debugging before realizing I 
shouldn't've just merged x1-el2 like that…

It first showed up as a "weird" hang when booting into EL2, as soon as 
SMMU related lines started showing up on the framebuffer console it 
slowed down to a crawl for a couple of these lines and then totally froze.

Disabling qebspil (i.e. having only adsp-lite loaded) let the output 
proceed for a little bit more and I saw the faults (tens of thousands of 
faults, all fsr=0x402, iova=0x86b020c0, fsynr=0x600040, SID=0x1000) and 
a hard LOCKUP being detected.

> Since we can't start/stop remoteprocs without PAS,
(Can someone at Qualcomm ask how Windows does it?)
> everyone using EL2
> with the old (non-PAS) firmware currently relies on remoteprocs that are
> already started by the boot firmware before Linux is started. This can
> be just the "lite" ADSP that is started by UEFI for initial charging and
> USB-C detection, or even the full ADSP/CDSP via a custom UEFI driver
> (qebspil [1]). All of these will stay running even if we fail to
> stop/start them via PAS. Without extra kernel patches, we can't make use
> of the remoteprocs, but the lite ADSP firmware will probably continue
> doing its work in the background, i.e. it will start/stop charging as
> needed, you just won't be able to observe the status from Linux.
>
> We manage the full IOMMU even when there is no PAS. The reason why
> people are not running into issues is that the bootloader handover code
> inside arm-smmu-qcom.c qcom_smmu_cfg_probe() configures bypass for all
> SIDs used by the boot firmware, which includes the SIDs for all the
> remoteprocs. Adding these SIDs in the "iommus" property of an actual
> device will replace the bypass with a translated context, which
> currently won't be set up anywhere for the non-PAS use case.

hm, maybe the patches supporting the handover could be updated to set up 
the context in the non-PAS case?

> In addition, even on newer firmware with PAS support I would expect that
> special care is required to "atomically" handover the IOMMU
> configuration from the bootloader. If the lite ADSP remains running on
> these firmware versions as well, the bypass or suitable mappings must be
> maintained until the lite ADSP firmware is stopped.
> […]
Thanks,
~val