RE: nRF9160 non-secure app flash partition

Sigurd — Fri, 24 Jan 2020 12:10:01 GMT

Take a look at the Multi-image build use guide, see this link and this link.

RE: nRF9160 non-secure app flash partition

af2377 — Mon, 20 Jan 2020 16:02:27 GMT

Thank you.

As follow-up, I noticed that the values in DTS are ignored by pm.yml and that different values are used, per the defines in KConfig for multi-image build positions. Why is that?!

RE: nRF9160 non-secure app flash partition

Sigurd — Mon, 20 Jan 2020 12:08:43 GMT

Hi,

1) You need the 4 slots for the DTS, but I think MCUBoot stills treats SPM+APP as a single image, i.e. both is under "mcuboot_primary_app"

E.g. here is the rom_report for the aws_fota sample:

[quote userid="14033" url="~/f/nordic-q-a/56397/nrf9160-non-secure-app-flash-partition"]Can we add our own services?[/quote]

Yes.

[quote userid="14033" url="~/f/nordic-q-a/56397/nrf9160-non-secure-app-flash-partition"]Can we reduce the 64K RAM it needs and free some of it up for the application?[/quote]

You might be able to reduce it a bit, but as far as I know it's not only SPM that uses this RAM section, the MCUBoot also uses this section.

[quote userid="14033" url="~/f/nordic-q-a/56397/nrf9160-non-secure-app-flash-partition"]In the latest bsdlib this is far less than the 128KB that is actually allocated for it in the dts. Is this something different? Can we reduce that 128KB to be closer to this value without any issues?[/quote]

BSDlib does not use 128K RAM. By default 64K RAM is allocated for it(sram0_bsd). Looking at the BSDlib documentation, at this link, it's mentioned that the leftover memory in the seventh block (8160 bytes, starting at address 0x2001 c020) is configured as non-secure, but it can be used by the application.