Writing to ESP32-S2 IRAM at runtime [solved]

[cnlohr]

I am currently trying to further develop a fast-design-code-compile-iterate system for the ESP32-S2. I have a proof of concept working here: https://twitter.com/cnlohr/status/1546445702636584960

There is a big snag/question, though. In order to accomplish this, the IRAM must be writable at runtime. But the ESP32-S2 IDF pretty aggressively seals the IRAM via `memprot_ll_iram0_set_lock()` / `esp_memprot_set_lock()`. And it seems? there is no way to unseal it?

From Section 14.3.1.1 of the TRM: "At the same time, the value of the PMS_PRO_IRAM0_LOCK signal will also remain at 1 and cannot be changed. The value of the PMS_PRO_IRAM0_LOCK signal is reset to 0 only when the CPU is reset."

For the time being I've modified things to _never_ log the IRAM and keep it wide open for writes.

https://github.com/cnlohr/esp32-c3-play ... e5eR28-R37

I can understand for final products the desire to lock the IRAM memory region, but while developing, I am curious:

1) Is there any technical reason IRAM must be locked, and/or writing to IRAM would be bad?
2) Are there any performance implications of not locking IRAM? Of leaving it in read/write mode?
3) What is the ideal way to be able to write into IRAM after boot?
4) Is the proper way to handle this to set CONFIG_ESP_SYSTEM_MEMPROT_FEATURE_LOCK = n?

[ESP_Sprite]

The reason is security: making it impossible to write to codespace that is also executable, it makes it non-trivial to use a bug in firmware to upload and execute an exploit. There is no other reason to lock the space; the hardware doesn't really care if the memory is writable or not. It's enabled by default because it adds a fair bit of security while normal users don't notice the effect - but you're not a 'normal' user I guess.

The solution to this indeed is to disable CONFIG_ESP_SYSTEM_MEMPROT_FEATURE_LOCK.

[cnlohr]

Thank you for all the clarification. I was worried my approach would not be one that others could reasonably use.

I was also wondering, is there a way of making normal DRAM executable? I have been having difficulty finding/understanding a clear memory map that explains what the properties of the different sections are. It would be nice to be able to "malloc" executable space, as well as quirks surrounding read/write alignment.

EDIT: I just needed to re-read section 3.3. BTW, yes, for anyone who googles this and ends up here to my earlier question. "The CPU can access data via the data bus in a byte-, half-word-, or word-aligned manner. The CPU can also access data via the instruction bus, but only in a word-aligned manner; non-word-aligned access will cause a CPU exception."

[snip/edit] may ask more later.

[cnlohr]

I just realized - are 0x3FFB_8000 and 0x4002_8000 shadows of each other? As in can I malloc in normal DRAM, then write into the data in normal DRAM, then execute the corresponding segment in IRAM?

[ESP_Sprite]

Yep, but I think memory protection also protects the alias: the DRAM region corresponding to code is not writable, the IRAM region corresponding to data is not executable. (If it doesn't, that's a bug; note that memory protection is explicitly trying to stop specifically what you are trying to do.)

[cnlohr]

This worked perfectly. ‍🤌

Thank you!