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

[Konrad Dybcio]

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@xxxxxxxxxx
>>> Signed-off-by: Jianping Li <jianping.li@xxxxxxxxxxxxxxxx>
>>> ---
>>>  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