ESP32-S3 Code and Data Relocation Support

[EricNRS]

Describe the bug The code and data relocation feature (https://docs.zephyrproject.org/latest/kernel/code-relocation.html ) does not work for ESP32-S3 (and likely other Xtensa ESP chips) due to the default.ld segment names including an underscore ('_') and the lack of including linker_relocate.ld in the default.ld as is done for riscv, cortex_m, and cortex_a architectures.

For example, trying this on ESP32-S3:

prj.conf CONFIG_CODE_DATA_RELOCATION=y

CMakeLists.txt zephyr_code_relocate(LIBRARY drivers__sensor LOCATION ext_ram_seg)

Doing a build results in the error:

Memory region:  ext_ram_seg|COPY
Traceback (most recent call last):
  File "/zephyrproject/zephyr/scripts/build/gen_relocate_app.py", line 614, in <module>
    main()
  File "/zephyrproject/zephyr/scripts/build/gen_relocate_app.py", line 594, in main
    sections_by_category = assign_to_correct_mem_region(memory_type, full_list_of_sections)
  File "/zephyrproject/zephyr/scripts/build/gen_relocate_app.py", line 284, in assign_to_correct_mem_region
    mpu_align[memory_region] = int(align_size)
ValueError: invalid literal for int() with base 10: 'ram_seg|COPY'
ninja: build stopped: subcommand failed.

The root cause is that the tool has a naming convention of using an underscore '_' to separate the segment name from one or more section names.

https://docs.zephyrproject.org/latest/kernel/code-relocation.html

As a work-around, the relocation can be done manually by adding an extra linker descriptor file:

CMakeLists.txt zephyr_linker_sources(SECTIONS custom-sections.ld)

custom-sections.ld

SECTION_DATA_PROLOGUE(_CUSTOM_SECTION_NAME2,,)
{
    . = ALIGN(4);
    __custom_section_start = .;
    KEEP(*(".custom_section.*"));
    __custom_section_end = ALIGN(4);
} GROUP_DATA_LINK_IN(RAMABLE_REGION, ROMABLE_REGION)

One user posted this workaround in Discord: https://discord.com/channels/720317445772017664/883444902971727882/1173967050805346384

Impact Failure of the code and data relocation support requiring work-arounds.

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[EricNRS]

The cleanup bot strikes again. It would be good to get this issue fixed for the v3.7 release, although it is lower priority than other Espressif tasks at the moment since getting a stable IDFv5.1 into Zephyr is the number one priority IMHO.

[EricNRS]

Retested with 3.6.99 and this is still an issue.

[EricNRS]

The external RAM (SPIRAM) is also currently broken and is being tracked as https://github.com/zephyrproject-rtos/zephyr/issues/74284

[kartben]

re-opened as per @EricNRS request