sergiotarxz/nuttx
sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

memory_layout.h: Fix the start of region2 when a QEMU image generation

Browse Source 
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 <abdelatif.guettouche@espressif.com>
This commit is contained in:
Abdelatif Guettouche 2021-03-08 13:04:41 +01:00 committed by YAMAMOTO Takashi
parent 7fbc350589
commit 9cfc30fa85
1 changed files with 15 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
arch/xtensa/include/esp32/memory_layout.h
View File

@ -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