Mirrors_Framework/nuttx
1
0
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2026-06-06 16:50:55 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

esp32_allocateheap.c: Don't allocate the ROM CPU regions the same way in

Browse Source 
QEMU, the image is different.

Signed-off-by: Abdelatif Guettouche <abdelatif.guettouche@espressif.com>
This commit is contained in:
Abdelatif Guettouche
2021-03-16 18:18:27 +01:00
committed by Masayuki Ishikawa
parent 85edf0f49d
commit 27d5c9340a
2 changed files with 14 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
arch/xtensa/include/esp32/memory_layout.h
+6 -6
View File
@@ -114,18 +114,18 @@
* 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.
* The ROM on PRO and APP CPUs 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 PRO CPUs region
* 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.
* PRO CPU's regions when a QEMU image generation is enabled with SMP.
*/
#if defined(CONFIG_ESP32_QEMU_IMAGE) && defined(CONFIG_SMP)
# define HEAP_REGION2_START 0x3ffe1330
# define HEAP_REGION2_START 0x3ffe7e40
#else
# define HEAP_REGION2_START 0x3ffe0450
#endif