* [BUG] U-Boot qemu_arm64_defconfig CONFIG_CUSTOM_SYS_INIT_SP_ADDR collides with TF-A RMM granules
@ 2025-06-25 14:04 Yuvraj Sakshith
0 siblings, 0 replies; only message in thread
From: Yuvraj Sakshith @ 2025-06-25 14:04 UTC (permalink / raw)
To: u-boot
Hi folks,
I have been experimenting with ARMv9 on QEMU.
Here is my configuration:
QEMU (8.2.2)
TF-A built with ENABLE_RME
U-Boot in Normal World (qemu_arm64_defconfig) + Linux Kernel Image passed to QEMU
TF-RMM built into TF-A
As mentioned in arm-trusted-firmware/plat/qemu/include/qemu_pas_def.h, TF-A reserves a region of
24MB starting from 0x40100000 for the RMM in L1 GPTs.
When control switches to normal world, U-Boot sets up its stack to CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x40200000.
During u-boot/arch/arm/lib/crt0_64.S:_main(), control jumps to u-boot/common/init/board_init.c:board_init_f_alloc_reserve().
I am not exactly sure what this method indends to do, but from the comments I understand it carves out some memory for the
"globals". This eventually ends up pushing the stack pointer to 0x401fde70. Which is inside the RMM PAS initialised by TF-A.
Post this, I get a Granule Protection Fault and the machine hangs up.
I wanted to know how this can be fixed and if my configuration is wrong.
Please let me know if there is any extra info that I need to provide for inspection.
R,
Yuvraj Sakshith
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2025-06-25 17:06 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-25 14:04 [BUG] U-Boot qemu_arm64_defconfig CONFIG_CUSTOM_SYS_INIT_SP_ADDR collides with TF-A RMM granules Yuvraj Sakshith
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.