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.
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.
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 <[email protected]>
---
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/[email protected]/
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
