[PATCH v2] configs: am571x_hs_evm_defconfig: Reserve EMIF memory used by PPA
Andrew Davis
afd at ti.com
Mon Dec 8 15:21:06 CET 2025
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.
Andrew
>
> [4]: https://github.com/u-boot/u-boot/blob/master/common/board_f.c#L391
> [5]: https://github.com/u-boot/u-boot/blob/master/common/board_f.c#L371
>
> Thanks,
> Beleswar
>
>>
>> Andrew
>>
>>>
>>> [3]: https://github.com/u-boot/u-boot/blob/master/common/board_f.c#L990
>>>
>>> Thanks,
>>> Beleswar
>>>
>>>>
>>>> Andrew
>>>>
>>>>> Thanks,
>>>>> Beleswar
>>>>>
>>>>>> should be enough for all
>>>>>> and doesn't hurt to have more than needed reserved to be safe.
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> [0] https://github.com/u-boot/u-boot/blob/master/include/configs/am43xx_evm.h#L153
>>>>>>
>>>>>>> Signed-off-by: Beleswar Padhi <b-padhi at ti.com>
>>>>>>> ---
>>>>>>> Fix boot for TI AM571x HS EVM board
>>>>>>> v2: Changelog:
>>>>>>> 1. Drop [PATCH v1 2/2] in v2 series. There is no need to add reserved
>>>>>>> memory node in DT as it is done by U-Boot as part of FDT fixups
>>>>>>> https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-omap2/fdt-common.c#L72-L107
>>>>>>> 2. Add entry in MAINTAINERS for new config.
>>>>>>> 3. Update commit message to use memory size in MB than raw hex bytes
>>>>>>>
>>>>>>> Link to v1:
>>>>>>> https://lore.kernel.org/all/20251128064353.1295063-1-b-padhi@ti.com/
>>>>>>>
>>>>>>> Test logs:
>>>>>>> https://gist.github.com/3V3RYONE/e86b3f4551986b0400d0e0f66d6ecc66
>>>>>>>
>>>>>>> MAINTAINERS | 1 +
>>>>>>> configs/am571x_hs_evm_defconfig | 3 +++
>>>>>>> 2 files changed, 4 insertions(+)
>>>>>>> create mode 100644 configs/am571x_hs_evm_defconfig
>>>>>>>
>>>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>>>>> index b43dae882b3..e5d564cd760 100644
>>>>>>> --- a/MAINTAINERS
>>>>>>> +++ b/MAINTAINERS
>>>>>>> @@ -1780,6 +1780,7 @@ F: configs/am335x_hs_evm_spi_defconfig
>>>>>>> F: configs/am335x_hs_evm_uart_defconfig
>>>>>>> F: configs/am43xx_hs_evm_defconfig
>>>>>>> F: configs/am43xx_hs_evm_qspi_defconfig
>>>>>>> +F: configs/am571x_hs_evm_defconfig
>>>>>>> F: configs/am57xx_hs_evm_defconfig
>>>>>>> F: configs/am57xx_hs_evm_usb_defconfig
>>>>>>> F: configs/dra7xx_hs_evm_defconfig
>>>>>>> diff --git a/configs/am571x_hs_evm_defconfig b/configs/am571x_hs_evm_defconfig
>>>>>>> new file mode 100644
>>>>>>> index 00000000000..7e44ee5221a
>>>>>>> --- /dev/null
>>>>>>> +++ b/configs/am571x_hs_evm_defconfig
>>>>>>> @@ -0,0 +1,3 @@
>>>>>>> +#include <configs/am57xx_hs_evm_defconfig>
>>>>>>> +
>>>>>>> +CONFIG_SYS_MEM_TOP_HIDE=0x2600000
>>>>>>
>>>>
>>
More information about the U-Boot
mailing list