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?

Parents
  • Thanks. This sample is loosely connected with my case, it shows some RAM loadable mcuboot image handling (unless I omitted something), and doesn't show application side, only bootloader.

    My working solution is:

    - Device Tree in boards/ (common to bootload and app) doesn't define anything in RAM

    - bootloader DT overlay in sysbuild/mcuboot.overlay: define retention area in last bytes of RAM, and redefine SRAM memory range so stack doesn't land in retention area. To be safe and for future unknown usage in app, leave hahr RAM unused - that shoud suffice. But this last step seems to be not even required, because bootloader is also Zephyr app, and Zephyr defines stacks as static arrays within RAM segment, together with DATA and BSS, not at the end of available RAM (as is the usual way in bare metal code). At least it looks like this, initial SP from vector table is in the low RAM area, certainly not at half RAM (as sram0 range defined by me)

    - firmware DT overlay in firmware/boards/some_board.overlay - similar to bootloader's overlay, but retention area is larger and contains app private areas. But: areas shared between bootloader and app must have the same sizes and reside at the same addresses, so it's a binary contract between bootloader and app - so they are placed at the end of retention area (at the end of RAM). In future versions app's private retention areas can grow downwards in RAM, before the areas shared with bootloader. sram0 address range is redefined taking the retention area size into account.

    This way bootloader can be fixed forever, bl_info and bl_mode stay at fixed place forever, app can resize it's retention areas as required without worry.

Reply Children
No Data
Related