From 9cfc30fa85b836c293b498d0150f187de3c334ad Mon Sep 17 00:00:00 2001 From: Abdelatif Guettouche Date: Mon, 8 Mar 2021 13:04:41 +0100 Subject: [PATCH] memory_layout.h: Fix the start of region2 when a QEMU image generation is enabled. That region is technically part of the PRO CPU and we should be able to allocate it early. However, QEMU uses a slightly different bootloader image that uses the same part for both CPU. So, when APP CPU starts during the SMP bring up it will corrupt some data. Signed-off-by: Abdelatif Guettouche --- arch/xtensa/include/esp32/memory_layout.h | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/xtensa/include/esp32/memory_layout.h b/arch/xtensa/include/esp32/memory_layout.h index 2d45a639a05..5f0c7637b85 100644 --- a/arch/xtensa/include/esp32/memory_layout.h +++ b/arch/xtensa/include/esp32/memory_layout.h @@ -72,9 +72,23 @@ * * When an internal heap is enabled this region starts at an offset equal to * the size of the internal heap. + * + * The QEMU bootloader image is slightly different than the chip's one. + * The ROM on PRO and APP uses different regions for static data. In QEMU, + * however, we load only one ROM binary, taken from the PRO CPU, and it is + * used by both CPUs. So, in QEMU, if we allocate this part early, it will + * be clobbered once the APP CPU starts. + * We can delay the allocation to when everything has started through the + * board_late_initiliaze hook, as is done for the APP data, however this + * should be fixed from QEMU side. The following macros, then, just skip + * PRO CPU's data when a QEMU image generation is enabled with SMP. */ -#define HEAP_REGION2_START 0x3ffe0450 +#if defined(CONFIG_ESP32_QEMU_IMAGE) && defined(CONFIG_SMP) +# define HEAP_REGION2_START 0x3ffe1330 +#else +# define HEAP_REGION2_START 0x3ffe0450 +#endif #ifdef CONFIG_SMP # define HEAP_REGION2_END 0x3ffe3f10