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
