[PATCH v2] configs: am571x_hs_evm_defconfig: Reserve EMIF memory used by PPA

[Beleswar Prasad Padhi]

On 08/12/25 19:54, Tom Rini wrote:
> On Mon, Dec 08, 2025 at 08:21:06AM -0600, Andrew Davis wrote:
>> On 12/8/25 3:25 AM, Beleswar Prasad Padhi wrote:
>>> On 05/12/25 20:12, Andrew Davis wrote:
>>>>
>>>> On 12/5/25 1:32 AM, Beleswar Prasad Padhi wrote:
>>>>> On 02/12/25 18:47, Andrew Davis wrote:
>>>>>> On 12/1/25 11:56 PM, Beleswar Prasad Padhi wrote:
>>>>>>> On 02/12/25 00:58, Andrew Davis wrote:
>>>>>>>> On 11/28/25 9:04 AM, Beleswar Padhi wrote:
>>>>>>>>> The AM571x SoC has 1 GB DDR space. As part of normal re-location process
>>>>>>>>> U-Boot copies itself to the top of DDR bank. However, on HS devices, the
>>>>>>>>> top 37 MB is used by PPA and is firewalled. This results in an exception
>>>>>>>>> and the boot fails.
>>>>>>>>>
>>>>>>>>> Introduce a new defconfig for AM571x HS platforms and set
>>>>>>>>> CONFIG_SYS_MEM_TOP_HIDE to reserve the top 38 MB memory (aligned to 2MB
>>>>>>>>> as per page size for ARM32) for the same.
>>>>>>>>>
>>>>>>>> This "SYS_MEM_TOP_HIDE" looks new, for other OMAP-class HS devices we
>>>>>>>> use "CFG_PRAM"[0], seems these two configs do the same thing, could probably
>>>>>>>> combine them in some way..
>>>>>>>>
>>>>>>>> As CFG_PRAM is set based on TI_SECURE_EMIF_TOTAL_REGION_SIZE which is 32MB
>>>>>>>
>>>>>>> CFG_PRAM is only set if TI_SECURE_EMIF_REGION_START is not set, but we
>>>>>>> have it set it to 0xbdb00000 in the am57xx_hs_evm_defconfig.
>>>>>>>
>>>>>>> https://github.com/u-boot/u-boot/blob/master/include/configs/ti_omap5_common.h#L75-L81
>>>>>>>
>>>>>>>> for all other AM57x, why is this needed only for AM571?
>>>>>>>
>>>>>>> Other AM57x boards have >1 GiB DDR. So, the top of DDR space does not
>>>>>>> intersect with the firewalled EMIF region (0xbdb00000). Only in case of
>>>>>>> AM571x, the top of DDR collides with firewalled region, so boot fails while
>>>>>>> doing reloc.
>>>>>>>
>>>>>> Is there some way to detect this at runtime? Nothing prevents any of the
>>>>>> AM57x SoCs being used on boards with 1GB DDR (although they also might use
>>>>>> a different defconfig). How do we deal with this for K3 devices? Some use
>>>>>> an OP-TEE address aligned at 512MB and I'm sure one of them have that amount
>>>>>> of DDR.
>>>>>
>>>>> Well, actually not...
>>>>> It's the AM62 SIP platform. From DT, it would look like OPTEE is at the top of the
>>>>> DDR[1], but we do a FDT fixup here in u-boot to replace the OPTEE to the start
>>>>> of DDR[2]
>>>>>
>>>>> [1]: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi#L71
>>>>> [2]: https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-k3/am62x/am625_fdt.c#L84
>>>>>
>>>>> I am not sure if we can do such a thing here for mem used by PPA/firmware
>>>>> as it could assume it has that memory hardcoded.
>>>>>
>>>>>>>> We build for all
>>>>>>>> the AM57x with one defconfig, so this new defconfig will go unused. Just set
>>>>>>>> the default CFG_PRAM size to 64MB (same as AM43x),
>>>>>>>
>>>>>>> I am guessing all AM43x devices have the same amount of memory unlike
>>>>>>> AM57x devices? If we set CFG_PRAM to 38MB by default, won't we lose out
>>>>>>> that memory on other devices which do not face this limitation?
>>>>>>>
>>>>>> We only really supported "officially" the AM437x-EVM. But our over-focus
>>>>>> on just our EVMs caused us to make assumptions that would later make
>>>>>> it difficult to add support for customer boards. Assuming DDR size was
>>>>>> one such assumption, and should a customer board have the "wrong" DDR
>>>>>> size things like this would break.
>>>>>>
>>>>>> So instead of making another one-off fix to get one of our EVMs working,
>>>>>> I'm trying to think of a way we can make this work automatically for any
>>>>>> combination of DDR size and firewalled region.
>>>>> TL;DR
>>>>> I think adding that dynamic support would be tied up only for TI usecase?
>>>>>
>>>>> Hmm yes, I get your point. But to be able to do this dynamically, we
>>>>> would want to see if gd->relocaddr intersects with CFG_PRAM:
>>>>>
>>>>> Case 1:
>>>>> gd->relocaddr > (SECURE_REGION_START + SECURE_REGION_SIZE)
>>>>> = Best case. U-Boot relocates to an address higher than firewalled addr
>>>>>
>>>>> Case 2:
>>>>> gd->relocaddr <= (SECURE_REGION_START + SECURE_REGION_SIZE)
>>>>> = Fixup needed. U-Boot relocates to an address which could overlap
>>>>> with secure region. Update the gd->relocaddr to a lower address range
>>>>> which won't overlap with secure region:
>>>>>
>>>>>       reloc_text_size = (RAM_TOP - gd->relocaddr);
>>>>>       gd->relocaddr = SECURE_REGION_START - reloc_text_size;
>>>>>
>>>>>
>>>>> And ofcourse, we can't put this logic in the existing 'reserve_pram'[3]
>>>>> INITCALL because gd->relocaddr gets modified in the subsequent
>>>>> initcalls like 'reserve_trace'. We would want to introduce a new
>>>>> INITCALL which would be invoked after all reserve_* initcalls and
>>>>> before the reloc_* initcalls; where we can put this logic.
>>>>>
>>>>> Let me know if you think this is worth adding, or is an overkill and
>>>>> we can live happily with CFG_PRAM = 38 MB for all AM57x devices :)
>>>> Thanks for doing all this evaluation. I don't think this will be
>>>> the last time we run into this issue, but for now let's just make
>>>> CFG_PRAM = 64 MB for all AM57x devices and create the perfect solution
>>>> later.
>>>
>>> Thanks, I tried setting CFG_PRAM but it still ended up in a firewall
>>> exception. I guess this is because CFG_PRAM only ensures U-Boot doesn't
>>> relocate to that protected address[4], however that memory is still open
>>> for access by anything else if needed. Whereas, SYS_MEM_TOP_HIDE reduces
>>> the ram size itself[5], which ensures that memory is not visible to
>>> U-Boot at all (either for reloc, or general usage).
>> Seem PRAM ("Protected" RAM) isn't all it claims to be, better route then
>> is to convert our existing uses of PRAM to SYS_MEM_TOP_HIDE, which seems
>> more modern and uses KConfig.
> I don't think it's any more or less modern, but to be clear, there's no
> way (or no reason?) to describe these memory areas in DT? Or is it that
> we also need to do some game to remove it from U-Boot's view early on
> because how of little memory there is / where this area is? Thanks!


Yes.. We need to remove that memory from U-Boot's view early on because
this area is in top of DDR where U-Boot would relocate to if not hidden.

Thanks,
Beleswar