From: Simon Glass <sjg@chromium.org> With the shared library the size can be quite large. Normally sandbox pretends that its code is mapped into emulated RAM, even though it actually isn't. This is fine in most cases, but when mon_len exceeds the RAM size the reservation top starts off at a negative address (i.e. very near the top of the address space), which immediately segfaults. Add a special case for this, for sandbox only. We might consider dropping this mapping altogether, as is down with RISC-V, but that is left for further discussion. With this, the test app boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org> --- common/board_f.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/common/board_f.c b/common/board_f.c index 3a4fb9a42ef..eac51d61fa1 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -460,7 +460,11 @@ static int reserve_uboot(void) * reserve memory for U-Boot code, data & bss * round down to next 4 kB limit */ - gd->relocaddr -= gd->mon_len; + if (IS_ENABLED(CONFIG_SANDBOX) && gd->mon_len > gd->relocaddr) + log_debug("Cannot reserve space for U-Boot\n"); + else + gd->relocaddr -= gd->mon_len; + gd->relocaddr &= ~(4096 - 1); #if defined(CONFIG_E500) || defined(CONFIG_MIPS) /* round down to next 64 kB limit so that IVPR stays aligned */ -- 2.43.0