[v1] arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap

[PATCH] arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap

Posted by Jianping Li 1 month, 3 weeks ago

On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap"
reserved-memory region overlaps with firmware allocations (UEFI/EFI
runtime). The kernel then reports failure to reserve the region and
subsequent EFI runtime activity may trigger aborts.

The remote heap node was described as a fixed "no-map" region, which
turns it into a hard carveout. Replace it with a "shared-dma-pool"
reserved memory region with reusable CMA-backed allocation, specifying
alignment and size.

This avoids hard carveouts and reduces the chance of conflicting with
firmware memory maps while keeping an explicit pool for ADSP remote
heap usage.

Fixes: 90a58ffa9c55 ("arm64: dts: qcom: kodiak: Add memory region for audiopd")
Cc: stable@kernel.org
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 988ca5f7c8a0..420219823496 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -191,9 +191,12 @@ rmtfs_mem: rmtfs@9c900000 {
 			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
 		};
 
-		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@9cb80000 {
-			reg = <0x0 0x9cb80000 0x0 0x800000>;
-			no-map;
+		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
+			reusable;
+			alignment = <0x0 0x400000>;
+			size = <0x0 0x800000>;
 		};
 	};
 
-- 
2.43.0

Re: [PATCH] arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap

Posted by Konrad Dybcio 1 month, 3 weeks ago

On 4/23/26 8:35 AM, Jianping Li wrote:
> On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap"
> reserved-memory region overlaps with firmware allocations (UEFI/EFI
> runtime). The kernel then reports failure to reserve the region and
> subsequent EFI runtime activity may trigger aborts.
> 
> The remote heap node was described as a fixed "no-map" region, which
> turns it into a hard carveout. Replace it with a "shared-dma-pool"
> reserved memory region with reusable CMA-backed allocation, specifying
> alignment and size.
> 
> This avoids hard carveouts and reduces the chance of conflicting with
> firmware memory maps while keeping an explicit pool for ADSP remote
> heap usage.
> 
> Fixes: 90a58ffa9c55 ("arm64: dts: qcom: kodiak: Add memory region for audiopd")
> Cc: stable@kernel.org
> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 988ca5f7c8a0..420219823496 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -191,9 +191,12 @@ rmtfs_mem: rmtfs@9c900000 {
>  			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
>  		};
>  
> -		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@9cb80000 {
> -			reg = <0x0 0x9cb80000 0x0 0x800000>;
> -			no-map;
> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
> +			compatible = "shared-dma-pool";
> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;

Since DRAM starts at 0x8000_0000, is it intended to only allow this
region to be in the lower 2 gigs?

(it may very well be for some historical reasons)

Konrad

Re: [PATCH] arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap

Posted by Ekansh Gupta 1 month, 3 weeks ago

On 23-04-2026 14:20, Konrad Dybcio wrote:
> On 4/23/26 8:35 AM, Jianping Li wrote:
>> On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap"
>> reserved-memory region overlaps with firmware allocations (UEFI/EFI
>> runtime). The kernel then reports failure to reserve the region and
>> subsequent EFI runtime activity may trigger aborts.
>>
>> The remote heap node was described as a fixed "no-map" region, which
>> turns it into a hard carveout. Replace it with a "shared-dma-pool"
>> reserved memory region with reusable CMA-backed allocation, specifying
>> alignment and size.
>>
>> This avoids hard carveouts and reduces the chance of conflicting with
>> firmware memory maps while keeping an explicit pool for ADSP remote
>> heap usage.
>>
>> Fixes: 90a58ffa9c55 ("arm64: dts: qcom: kodiak: Add memory region for audiopd")
>> Cc: stable@kernel.org
>> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 ++++++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>> index 988ca5f7c8a0..420219823496 100644
>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>> @@ -191,9 +191,12 @@ rmtfs_mem: rmtfs@9c900000 {
>>  			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
>>  		};
>>  
>> -		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@9cb80000 {
>> -			reg = <0x0 0x9cb80000 0x0 0x800000>;
>> -			no-map;
>> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>> +			compatible = "shared-dma-pool";
>> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
> 
> Since DRAM starts at 0x8000_0000, is it intended to only allow this
> region to be in the lower 2 gigs?
> 
> (it may very well be for some historical reasons)
yes, this is intentional. ADSP supports 32-bit address.
> 
> Konrad
>

Re: [PATCH] arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap

Posted by Konrad Dybcio 1 month, 3 weeks ago

On 4/23/26 11:19 AM, Ekansh Gupta wrote:
> On 23-04-2026 14:20, Konrad Dybcio wrote:
>> On 4/23/26 8:35 AM, Jianping Li wrote:
>>> On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap"
>>> reserved-memory region overlaps with firmware allocations (UEFI/EFI
>>> runtime). The kernel then reports failure to reserve the region and
>>> subsequent EFI runtime activity may trigger aborts.
>>>
>>> The remote heap node was described as a fixed "no-map" region, which
>>> turns it into a hard carveout. Replace it with a "shared-dma-pool"
>>> reserved memory region with reusable CMA-backed allocation, specifying
>>> alignment and size.
>>>
>>> This avoids hard carveouts and reduces the chance of conflicting with
>>> firmware memory maps while keeping an explicit pool for ADSP remote
>>> heap usage.
>>>
>>> Fixes: 90a58ffa9c55 ("arm64: dts: qcom: kodiak: Add memory region for audiopd")
>>> Cc: stable@kernel.org
>>> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
>>> ---
>>>  arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 ++++++---
>>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>> index 988ca5f7c8a0..420219823496 100644
>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>> @@ -191,9 +191,12 @@ rmtfs_mem: rmtfs@9c900000 {
>>>  			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
>>>  		};
>>>  
>>> -		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@9cb80000 {
>>> -			reg = <0x0 0x9cb80000 0x0 0x800000>;
>>> -			no-map;
>>> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>>> +			compatible = "shared-dma-pool";
>>> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
>>
>> Since DRAM starts at 0x8000_0000, is it intended to only allow this
>> region to be in the lower 2 gigs?
>>
>> (it may very well be for some historical reasons)
> yes, this is intentional. ADSP supports 32-bit address.

Okay, so I think this should be one of:

<0x0 0x80000000 0x0 0x80000000>;

(where we directly specify the DRAM start, which may just be form
over function)

or:

<0x0 0x00000000 0x1 0x00000000>;

to cover 0x0000_0000 - 0xffff_ffff

Konrad

Re: [PATCH] arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap

Posted by Ekansh Gupta 1 month, 3 weeks ago

On 23-04-2026 14:58, Konrad Dybcio wrote:
> On 4/23/26 11:19 AM, Ekansh Gupta wrote:
>> On 23-04-2026 14:20, Konrad Dybcio wrote:
>>> On 4/23/26 8:35 AM, Jianping Li wrote:
>>>> On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap"
>>>> reserved-memory region overlaps with firmware allocations (UEFI/EFI
>>>> runtime). The kernel then reports failure to reserve the region and
>>>> subsequent EFI runtime activity may trigger aborts.
>>>>
>>>> The remote heap node was described as a fixed "no-map" region, which
>>>> turns it into a hard carveout. Replace it with a "shared-dma-pool"
>>>> reserved memory region with reusable CMA-backed allocation, specifying
>>>> alignment and size.
>>>>
>>>> This avoids hard carveouts and reduces the chance of conflicting with
>>>> firmware memory maps while keeping an explicit pool for ADSP remote
>>>> heap usage.
>>>>
>>>> Fixes: 90a58ffa9c55 ("arm64: dts: qcom: kodiak: Add memory region for audiopd")
>>>> Cc: stable@kernel.org
>>>> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 ++++++---
>>>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> index 988ca5f7c8a0..420219823496 100644
>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> @@ -191,9 +191,12 @@ rmtfs_mem: rmtfs@9c900000 {
>>>>  			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
>>>>  		};
>>>>  
>>>> -		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@9cb80000 {
>>>> -			reg = <0x0 0x9cb80000 0x0 0x800000>;
>>>> -			no-map;
>>>> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>>>> +			compatible = "shared-dma-pool";
>>>> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
>>>
>>> Since DRAM starts at 0x8000_0000, is it intended to only allow this
>>> region to be in the lower 2 gigs?
>>>
>>> (it may very well be for some historical reasons)
>> yes, this is intentional. ADSP supports 32-bit address.
> 
> Okay, so I think this should be one of:
> 
> <0x0 0x80000000 0x0 0x80000000>;
SGTM.
> 
> (where we directly specify the DRAM start, which may just be form
> over function)
> 
> or:
> 
> <0x0 0x00000000 0x1 0x00000000>;
> 
> to cover 0x0000_0000 - 0xffff_ffff
> 
> Konrad