From: Marc Zyngier <maz@kernel.org>
To: Nikita Travkin <nikita@trvn.ru>
Cc: Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
cros-qcom-dts-watchers@chromium.org,
Jens Glathe <jens.glathe@oldschoolsolutions.biz>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] arm64: dts: qcom: x1e/x1p: Add EL2 overlay for WoA devices
Date: Fri, 02 May 2025 11:38:58 +0100 [thread overview]
Message-ID: <86o6wbguv1.wl-maz@kernel.org> (raw)
In-Reply-To: <20250501-sc-el2-overlays-v1-5-9202e59e3348@trvn.ru>
On Thu, 01 May 2025 18:03:45 +0100,
Nikita Travkin <nikita@trvn.ru> wrote:
>
> WoA devices using x1e/x1p use android firmware to boot, which notably
> includes Gunyah hypervisor. This means that, so far, Linux-based OS
> could only boot in EL1 on those devices.
>
> However Windows can replace Gunyah upon boot with it's own hypervisor,
> and with the use of tools such as "slbounce", it's possible to do the
> same for Linux-based OS, in which case some modifications to the DT are
> necessary to facilitate the absence of Gunyah services.
>
> Add a EL2-specific DT overlay and apply it to x1e/x1p WoA devices to
> create -el2.dtb for each of them alongside "normal" dtb.
>
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 36 +++++++++++++++++---------
> arch/arm64/boot/dts/qcom/x1-el2.dtso | 46 ++++++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 2 +-
> 3 files changed, 71 insertions(+), 13 deletions(-)
>
[...]
> diff --git a/arch/arm64/boot/dts/qcom/x1-el2.dtso b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> new file mode 100644
> index 0000000000000000000000000000000000000000..7a818045ef098b44632df45253d32e31c5c7aeed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +
> +/*
> + * x1 specific modifications required to boot in EL2.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +/* We can't and don't need to use zap shader in EL2 as linux can zap the gpu on it's own. */
> +&gpu_zap_shader {
> + status = "disabled";
> +};
> +
> +/*
> + * When running under Gunyah, this IOMMU is controlled by the firmware,
> + * however when we take ownership of it in EL2, we need to configure
> + * it properly to use PCIe.
> + */
> +&pcie3 {
> + iommu-map = <0 &pcie_smmu 0x30000 0x10000>;
> +};
> +
> +&pcie4 {
> + iommu-map = <0 &pcie_smmu 0x40000 0x10000>;
> +};
> +
> +&pcie5 {
> + iommu-map = <0 &pcie_smmu 0x50000 0x10000>;
> +};
> +
> +&pcie6a {
> + iommu-map = <0 &pcie_smmu 0x60000 0x10000>;
> +};
> +
> +&pcie_smmu {
> + status = "okay";
> +};
> +
> +/*
> + * The "SBSA watchdog" is implemented in software in Gunyah
> + * and can't be used when running in EL2.
> + */
> +&sbsa_watchdog {
> + status = "disabled";
> +};
I also carry this [1] patch to correctly route MSIs from pcie5 to the
ITS. There is no reason not to. The same treatment could be applied to
pcie3, but I never tried it.
Thanks,
M.
[1] https://lore.kernel.org/linux-arm-kernel/20241024161814.1827514-1-maz@kernel.org/
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-05-02 10:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 17:03 [PATCH 0/5] arm64: dts: qcom: Add EL2 overlays for WoA devices Nikita Travkin
2025-05-01 17:03 ` [PATCH 1/5] arm64: dts: qcom: sc7180: Add EL2 overlay " Nikita Travkin
2025-05-01 17:03 ` [PATCH 2/5] arm64: dts: qcom: sc8280xp: Add PCIe IOMMU Nikita Travkin
2025-05-01 17:03 ` [PATCH 3/5] arm64: dts: qcom: sc8280xp: Add EL2 overlay for WoA devices Nikita Travkin
2025-05-01 17:03 ` [PATCH 4/5] arm64: dts: qcom: x1e80100: Add PCIe IOMMU Nikita Travkin
2025-05-01 17:03 ` [PATCH 5/5] arm64: dts: qcom: x1e/x1p: Add EL2 overlay for WoA devices Nikita Travkin
2025-05-02 10:38 ` Marc Zyngier [this message]
2025-05-02 12:55 ` Nikita Travkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86o6wbguv1.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cros-qcom-dts-watchers@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=jens.glathe@oldschoolsolutions.biz \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nikita@trvn.ru \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.