Redundant pcd_sram region in app image with nRF5340 and MCUboot multi image update

[Bogdan Marinescu]

Hi,

I have a project that uses nRF5340 with MCUboot and multi image update configuration. The update works, but today I noticed that the pcd_sram RAM region seems to be reserved even in the app core image:

> less build/zephyr/linker.cmd

MEMORY
{
  FLASH (rx) : ORIGIN = 0x18200, LENGTH = 0xe7e00
  RAM (wx) : ORIGIN = 0x20002000, LENGTH = 0x6e000

IDT_LIST (wx)
}
......

> less build/partitions.yml

pcd_sram:
  address: 0x20000000
  end_address: 0x20002000
  placement:
    after:
      - start
  region: sram_primary
  size: 0x2000
sram_primary:
  address: 0x20002000
  end_address: 0x20070000
  region: sram_primary
  size: 0x6e000
.....

> arm-none-eabi-readelf -S --wide build/zephyr/zephyr.elf

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
......
[19] .ramfunc PROGBITS 20002000 073e28 000000 00 W 0 0 1
[20] datas PROGBITS 20002000 072368 00120c 00 WA 0 0 8
......

If I understand correctly, pcd_sram is used only by the bootloader and only when updating the network core, so why does it have to be reserved in the application core image too (and waste 8K of RAM)? Or maybe my build configuration has an issue? I've searched other posts here and I've seen some people that list a similar configuration, so I still believe something isn't right somewhere.

Using NCS 2.6.1.

Thanks,
Bogdan

[Kazi Afroza Sultana]

You are welcome. Do you have any update for your issue now?

[Bogdan Marinescu]

I think I'll just patch the bootloader code to remove the call that protects the memory, then I'll attempt to use an MPU region to protect just the first part of the RAM, as you suggested (not sure if this is possible yet, looking into it. It's the best thing that I could come up with.

[Bogdan Marinescu]

After looking through how Zephy uses the MPU, it doesn't appear that protecting the start of ther SRAM (by marking it as read-only) is possible right now. So I am just accessing the memory from 0x20000004 to 0x20002000 directly by address (after patching MCUboot to not SPU-lock this memory area anymore), which seems to work fine for now,  but it obviously has security implications, just like you described.