tmedicci commented on PR #16756: URL: https://github.com/apache/nuttx/pull/16756#issuecomment-3189786526
I'm sorry for the late response to this PR. As @yamt , I continued testing this implementation and reached some conclusions. I'm convinced that we should allocate memory from the user heap (if available) for `up_textheap_memalign` as suggested at https://github.com/apache/nuttx/pull/16756#issuecomment-3113617106. Please check the discussion at https://github.com/apache/nuttx/pull/16768: even with flat build, there are parts of the code that belong to the kernel while others are used by the applications. This applies to the ELF-related files: the mentioned [`insmod`](https://github.com/apache/incubator-nuttx/blob/52482219c853d3244bb80ece8b87173249708c9c/sched/module/mod_insmod.c#L66) function (from `mod_insmod.c`) calls [`libelf_insert`](https://github.com/apache/incubator-nuttx/blob/52482219c853d3244bb80ece8b87173249708c9c/libs/libc/elf/elf_insert.c#L293) whose files are not built with `__KERNEL__`. Just for the sake of sanity, this can be checked by building with `--trace`: ``` CC: elf/elf_load.c xtensa-esp32s3-elf-gcc -c -fno-common -Wall -Wstrict-prototypes -Wshadow -Wundef -Wno-attributes -Wno-unknown-pragmas -Wno-psabi -Os -fno-strict-aliasing -fomit-frame-pointer -ffunction-sections -fdata-sections "-g" -fno-strength-reduce -mlongcalls -isystem /home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_alfa/nuttx/include -D__NuttX__ -Wno-cpp -Werror -I /home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_alfa/nuttx/libs/libc elf/elf_load.c -o bin/elf_load.o ``` Furthermore, it's easy to conclude that a code that should run from the userspace (just like a ELF file being loaded in a non-flat build), should allocate its text heap from the user heap. **Talking about the ELF loader...** After running some testing, I conclude that we couldn't run any ELF files from the external PSRAM on ESP32-S3 at all... we never caught this issue because the external PSRAM was being allocated along with the internal RAM and the testing applications didn't require allocating from the external memory. This issue can be reproduced by just enabling the external PSRAM and allocating it into a separate heap, ensuring to apply the following patch: ``` diff --git a/arch/xtensa/src/esp32s3/esp32s3_textheap.c b/arch/xtensa/src/esp32s3/esp32s3_textheap.c index a0695200f7..1ebcb57f90 100644 --- a/arch/xtensa/src/esp32s3/esp32s3_textheap.c +++ b/arch/xtensa/src/esp32s3/esp32s3_textheap.c @@ -87,7 +87,7 @@ void *up_textheap_memalign(size_t align, size_t size) if (ret == NULL) { - ret = kmm_memalign(align, size); + ret = memalign(align, size); if (ret) { /* kmm_memalign buffer is at the Data bus offset. Adjust it so we ``` Built with: ``` make -j distclean && ./tools/configure.sh esp32s3-devkit:elf && kconfig-tweak -e DEBUG_FEATURES && kconfig-tweak -e DEBUG_ASSERTIONS && kconfig-tweak -e DEBUG_SYMBOLS && kconfig-tweak -e ESP32S3_SPIRAM && kconfig-tweak -e ESP32S3_SPIRAM_USER_HEAP && kconfig-tweak -e ESP32S3_SPI_FLASH_SUPPORT_PSRAM_STACK && make olddefconfig && make EXTRAFLAGS="-Wno-cpp -Werror" bootloader && make flash EXTRAFLAGS="-Wno-cpp -Werror" ESPTOOL_PORT=/dev/ttyUSB0 ESPTOOL_BINDIR=./ -s -j$(nproc) --trace && picocom -b 115200 /dev/ttyUSB0 ``` The above issue can be checked against the master branch: whenever we force the device to allocate from the PSRAM, it fails... that would happen even without the applied patch once the internal memory runs out... **And, finally...** The update PR (I also updated the description) fixes it: if the external PSRAM is disabled (or allocated to a common heap whenever this is possible), it doesn't matter from where the ELF file's allocates its memory. If we have a separate heap (which is mandatory when SPI flash or Wi-fi are enabled), it will allocate from the external PSRAM. Also, it will ensure that any data being copied to the memory is copied using the data bus. Finally, we still needed to ensure that the cache status is cleaned before running the ELF file. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
