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

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251208/98936d99/attachment.sig>