Re: [PATCH 2/2] arm64: dts: qcom: agatti: Address Gunyah memory alignment needs

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 1/8/26 11:50 AM, Sumit Garg wrote:
> On Wed, Jan 07, 2026 at 12:29:02PM +0100, Konrad Dybcio wrote:
>> On 1/5/26 6:46 AM, Sumit Garg wrote:
>>> On Sat, Jan 03, 2026 at 09:49:04AM -0600, Bjorn Andersson wrote:
>>>> On Mon, Dec 29, 2025 at 12:42:58PM +0530, Sumit Garg wrote:
>>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>>
>>>>> Gunyah hypervisor requires it's memory start address to be 2MB aligned.
>>>>> So the address map for Agatti is updated to incorporate that requirement.
>>>>> This should be a backwards compatible DT change which should work with
>>>>> legacy QHEE based firmware stack too.
>>>>>
>>>>
>>>> How come this isn't conveyed to the operating system using the UEFI
>>>> memory map?
>>>>
>>>
>>> I agree that with EFI boot, the information is getting conveyed via EFI
>>> memory map. But there will be non-EFI boot scenarios as well in case of
>>> U-Boot. And moreover I suppose we need to keep the reserved memory
>>> ranges in DT updated to reflect the actual memory map.
>>
>> Can U-Boot not do the same by altering /reserved-memory or /memory/reg?
> 
> I suppose you are referring to DT fixups here, we generally try to keep
> them to a minimum required in U-Boot.
> 
> BTW, don't we want to keep reserved memory ranges updated in DT? Or we plan
> to drop them altogether?

Generally I believe they're only a necessary evil..

Since Gunyah-on-Agatti doesn't seem to have been released yet, it would
seem like a sane idea to fix the issue in the firmware. If it was, well..

On UEFI-enabled targets, we can largely rely on the reservations coming
from there, only adding some carveouts for e.g. PIL regions and SMEM (not
because they're not resereved, but because we need a pointer to them)

Konrad