system: allow using SRAM1 as IRAM (IDFGH-8351)

[ESP-Marius]

Is your feature request related to a problem?

Currently on the ESP32 the SRAM1 region is used as DRAM, but the chip also allows for this region to be used as IRAM. For users that are running low on IRAM it would be beneficial to be able to use parts of SRAM1 as IRAM.

Describe the solution you'd like.

We should make this functionality available to users, either automatically at compile time or through a kconfig option if this turns out to be more convenient.

Describe alternatives you've considered.

No response

Additional context.

Related issue: #7876

[someburner]

+1 for this. With release/v5 IRAM fills up (especially with bluetooth) unless we disable optimizations. We don't have a very big dram footprint. Trying the changes suggested in that issue compiled and ran, but blufi couldn't init. Guessing something with the heap layout.

[someburner]

Actually, got it working with these edits:
iram.patch.txt

Would be nice to have it be a config option and officially supported.

[alxvasilev]

+1 for having such a setting in the config. I could successfully build and start my firmware with the above patch to increase the IRAM.

[franz-ms-muc]

+1

[TeunVR]

+1 We really need more IRAM in our project

[someburner]

In case this helps anyone, this seems to be the best sweet spot for nimble BLE + wifi + wifi iram optimizations, with a little to spare. The other one is too much iram in my case.

iram-bt.patch

[ESP-Marius]

Added a kconfig option for this in 5cbd311, please let me know if there is any issues with it.

[darthcloud]

@ESP-Marius For a couple years my project is running at the IRAM limit. So I was quite happy to see this new feature today. Every 6 month or so when I update to latest IDF I got to fight to get my project link again due to latest IDF using more IRAM.

Unfortunately it look for me I can't use this feature as it require a bootloader update. I got around 10K devices in the field relying on OTA FW update so I can't really do that.

The error I get is a bit different than the one in the docs:
E (198) esp_image: Segment 5 0x400845f8-0x400a126c invalid: bad load address range
E (199) boot: Factory app partition is not bootable

Is there anyway to increase the IRAM amount without requiring a new bootloader build?

[ESP-Marius]

@darthcloud Yeah, you are right unfortunately. I've updated the docs to better reflect that this feature wont work with an older bootloader.

I don't see a good way of getting tolder bootloaders to accept using SRAM1 as IRAM.

Lately we've also been adding more and more options for placing code that was previously in IRAM into flash. You can keep checking in on https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/performance/ram-usage.html#optimizing-iram-usage which we will keep updating with all these options.

[darthcloud]

@ESP-Marius the biggest problem is that the IDF iram usage increase by around 1Kb to 2Kb every six months using the same project & same sdkconfig. That's not really sustainable. I think any new IRAM usage by IDF should come with an opt-out option.

I feel my only option is to stop updating the idf and run my own fork were I cherry pick only the update I need. This might be fine for a while but I can see this becoming quite a burden as the branches divergent over time.

Can''t we somehow make the old bootloader load an app that is actually an updated bootloader that will in turn boot the real app?

[KaeLL]

@ESP-Marius generalizing @darthcloud's question: what exactly is not possible/feasible to update once devices are already on the field (with secure boot/encrypted nvs enabled)? Let's say the need to update the 2nd stage bootloader or the partition table arose. Could it be done by the app running on it or something?

[ESP-Marius]

the biggest problem is that the IDF iram usage increase by around 1Kb to 2Kb every six months using the same project & same sdkconfig. That's not really sustainable. I think any new IRAM usage by IDF should come with an opt-out option.

We are aware of this issue and are trying to be stricter internally about placing stuff in IRAM (i.e. only code that must always be in IRAM should go there by default). I Think with the recent changes we are making to improve this we should be getting close to having the same IRAM requirement in 5.1 as e.g. v4.3/v4.3

Can''t we somehow make the old bootloader load an app that is actually an updated bootloader that will in turn boot the real app?

I'm afraid something like this isn't an easy change, as it would mean modifying the boot work-flow a lot.

@ESP-Marius generalizing @darthcloud's question: what exactly is not possible/feasible to update once devices are already on the field (with secure boot/encrypted nvs enabled)? Let's say the need to update the 2nd stage bootloader or the partition table arose. Could it be done by the app running on it or something?

In theory there is nothing stopping us from writing to flash and modifying the bootloader, but the main issue is how to do this safely (i.e. device should not brick if something goes wrong during this update).

Doing this safely would probably require some kind of third stage bootloader so you would have:

ROM-> 2. stage bootloader (very simple, but non-updatable)-> 3 stage bootloader (more complex, but can be updated, and roll-back on failure etc) -> app. Which is starting to get pretty complex.

So IDF tries keep the functionality in the bootloader as simple as possible, so that the chance of a bootloader update being required is kept to a minimum, in order to avoid this complexity.

[someburner]

@ESP-Marius

Is it still possible to customize the IRAM/DRAM tradeoff with this?

[ESP-Marius]

Is it still possible to customize the IRAM/DRAM tradeoff with this?

Not sure exactly what you refer to here but yes, this basically trades heap for IRAM.

[someburner]

I mean is it possible to tweak SRAM1_IRAM_LEN without affecting bootloader, and also curious about these regions still:

+//    { 0x3FFF0000, 0x8000, 1, 0x400A8000}, //pool 7 <- can be used for MAC dump
+//    { 0x3FFF8000, 0x4000, 1, 0x400A4000}, //pool 6 blk 1 <- can be used as trace memory
+//    { 0x3FFFC000, 0x4000, 1, 0x400A0000}, //pool 6 blk 0 <- can be used as trace memory

Or do these get used as heap automatically depending on sdkconfig?

[ESP-Marius]

I mean is it possible to tweak SRAM1_IRAM_LEN without affecting bootloader,

No, as this area was previously reserved for the bootloader

Or do these get used as heap automatically depending on sdkconfig?

Even with this option enabled, these areas are available as heap if no IRAM code is put there, how much will depend on your binary of couse.

[someburner]

Should have been a little more clear- is it possible to -reduce- SRAM1_IRAM_LEN and have a bit more DRAM?

Edit: nvm haha stupid question.

[Abhay-2412]

Actually, got it working with these edits: iram.patch.txt

Would be nice to have it be a config option and officially supported.

hey i am complete newbie and i ran out of iram can you please tell me how to apply the patch

[someburner]

latest IDF has an option for this now in menuconfig. ESP_SYSTEM_ESP32_SRAM1_REGION_AS_IRAM