Support XiP from PSRAM

[Dominaezzz]

https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-guides/external-ram.html#execute-in-place-xip-from-psram

CONFIG_SPIRAM_FETCH_INSTRUCTIONS and CONFIG_SPIRAM_RODATA are the specific esp-idf configs.

In short, this feature lets you copy the application and data from flash to PSRAM at start up, which means flash is no longer needed for the rest of your application.

This is important for #2081 where you want to store huge buffers in PSRAM and DMA them to a peripheral, but you don't want flash access temporarily disabling psram access, leading to the DMA being starved of data and the peripheral getting garbage when it inevitably goes too far ahead.

Somewhat related #1083 .

[bjoernQ]

Turns out at least on ESP32-S3 we can execute code from PSRAM right after initializing PSRAM as we currently do - it's just that it's not writable via ibus (but we can via dbus and need to make sure to synchonize caches)

I think there are two ways

• the original request from Static linking in psram. Is there support or what is needed for it? #1083 extended by linking specific functions into PSRAM - for this we would need to create suitable sections in the linker scripts, copy code and data to PSRAM before anyone is allowed to access it. One challenge might be that currently we map PSRAM right after FLASH so the linker script needs to calculate the start address accordingly
• the way ESP-IDF does it (i.e. copy everything to PSRAM and then map PSRAM at the origin of external address space) - see https://github.com/espressif/esp-idf/blob/3c99557eeea4e0945e77aabac672fbef52294d54/components/esp_psram/mmu_psram_flash.c#L46-L134

[yanshay]

I'd like to place my vote in favor of implementing this issue and explain the rationale.

If I understand this right, this feature is practically required for applications that need to use large RGB displays (where buffer is in PSRAM) while at the same time using PSRAM intensively for application use.

Well, for complex applications, with user interface, using WiFi, SSL, async, etc. the limited amount of RAM on esp32 is quickly exhausted and PSRAM is required for memory allocations.
And for large displays (over 3.5") RGB is mandatory and required PSRAM memory for buffering.

There are many applications of this sort out there, and currently they are all written in C++ and out of the reach of rust developers.

Therefore, to enter the space of UI based applications, this feature is a must. I think that would be an effort wisely invested.

And to sum up:
"That's one small step for esp-hal, one giant leap for rustaceans."