Zephyr retention SRAM area and mcuboot common memory map

I have declared retention area in SRAM, that I;m using for the following:

  • boot info
  • boot mode
  • my app's private data.

DTS file is common for bootloader and app, so they have the same idea about these areas.

But: in the future, it's possible that my app will require more retention area for it's own purposes, I can predict the size as of today.

Currently, DTS says that SRAM end is below retention area, so this address is used as initial stack pointer. Both by bootloader and app.

In the future, when I have to resize retention area for my data, I wil have to move available SRAM end to the lower address, and that's fine for the app - it will get recompiled with new stack pointer, but mcuboot is fixed and uses previous SRAM end address (defined at the time when mcuboot was compiled) - now somewhere in the middle of my new enlarged retention area. And disturbing my private data when booting. Obviously - wrong.

I think that I can move bootloader's initial stack pointer somewhere lower, in the really safe area - let's say to the half of the memory and that would reserve upper half of RAM for my possible required use as retention area - half of RAM would certainly suffice. But I don't want this unused reservation to be unusable by the app, so the app would need to get different stack address, just below currently defined retained area in the app, and that would change with every change of retained area size and recompilation of app. And bootloader's stack pointer would stay somewhere much lower, to be safe.

Is this the correct approach for such case? Having separate SRAM declarations, one for app (the changing one), and one for bootloader (fixed forever)?

Any other way?

If this is the way, how to apply separate SRAM declarations for app and bootloader? But still keeping common bootloader_info and bootloader_mode areas?

Related