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

[Val Packett <val@packett.cool>]

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