Hello,
Lesson 8, exercise 3, regarding bootloaders and BLE DFU, of the intermediate DevAcademy course had a compilation issue with the nrf5340 DK, and using TF-M. It was caused by the amount of memory used by MCUBoot to include the .bss.mock_flash object using 256k of SRAM (see build/mcuboot/zephyr/zephyr_pre0.map). See this ticket https://github.com/NordicDeveloperAcademy/ncs-inter/issues/8.
Mr Sigurd Hellesvik proposed a solution here: https://github.com/NordicDeveloperAcademy/ncs-inter/commit/32ec0ca3f3a7517920d41722d7d269cda60ad7de by using CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=y. This symbol comes with the security warning that secrets might leak. This is not a good solution when using TF-M for improved security.
A partition report shows that mcuboot uses all SRAM, iso being limiting to sram_secure.
sram_primary (0x80000 - 512kB):
+------------------------------------------------+
+---0x20000000: mcuboot_sram (0x80000 - 512kB)---+
+---0x20000000: sram_secure (0xa000 - 40kB)------+
| 0x20000000: pcd_sram (0x2000 - 8kB) |
| 0x20002000: tfm_sram (0x8000 - 32kB) |
+---0x2000a000: sram_nonsecure (0x76000 - 472kB)-+
| 0x2000a000: sram_primary (0x66000 - 408kB) |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+------------------------------------------------+
Without CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM, mcuboot_sram is limited to sram_secure (location and size).
Once MCUBoot finishes and hands over control to the unsecure application code, the latter has access to unprotected SRAM and could find confidential data left by MCUBoot. Since the mock_flash is sized 256k, exactly the size of the network core's flash why not make it much smaller and do chunk sized data transfer between the application and network cores during an upgrade?
Mr Sigurd Hellesvik suggested to create this ticket and asked to be name-dropped in this ticket.
Thank you!
Kind regards,
francis
