Partition Manager not using flash efficiently

RE: Partition Manager not using flash efficiently

Sigurd Hellesvik — Wed, 08 Feb 2023 13:23:10 GMT

[quote user="Cla"]tfm:
address: 0x8200
end_address: 0x14200[/quote]

That looks 0x4000 = 16KiB aligned, which is odd.

[quote user="Cla"]I understand it like that too. My guess was, that it will configure the region that contains both (tfm and app) as secure with a non-secure subregion[/quote]

That could be. It would be a bit confusing if actual secure and non-secure regions were mixed in such a way.

Can you share the project or the pm_static.yml to achieve your partitioning so I can try it myself?

Regards,
Sigurd Hellesvik

RE: Partition Manager not using flash efficiently

Cla — Mon, 06 Feb 2023 15:06:12 GMT

In your example yes, but in my example it is way off:

tfm:
address: 0x8200
end_address: 0x14200

That lead me to think, that it need not be aligned.

[quote userid="106736" url="~/f/nordic-q-a/95599/partition-manager-not-using-flash-efficiently/407772"]The way I understand this, the secure region still has the same boundaries limited to 32KiB.
And the NSC regions are just a sub-region of the secure region.[/quote]

I understand it like that too. My guess was, that it will configure the region that contains both (tfm and app) as secure with a non-secure subregion. Lets say like this:

32 KiB | secure     | tfm part 1 (start: 0x8000, end: 0xf000)
32 KiB | secure     | tfm part 2 (start: 0x0f000, end: 0x14200)
                    | app part 1 (non-secure subregion, start: 0x14200, end: 0x18000)
32 KiB | non-secure | app part 2 (start: 0x18000, end: 0x1f000)
...

RE: Partition Manager not using flash efficiently

Sigurd Hellesvik — Thu, 02 Feb 2023 12:48:52 GMT

Hi,

[quote user="Cla"]I was wondering, why the end of the `tfm` partition, bordering the `app` did not have to be aligned to `0x8000`.[/quote]

If you take the end -0x200, I think you will get it aligned to 0x8000, right?
If yes, then it is the bug I talked about.
Let me know if you see other numbers.

[quote user="Cla"]My guess would be, that FLASHNSC[n].REGION and FLASHNSC[n].SIZE are use to define the secure-callable and non-secure-callable sub-regions within a region?[/quote]

The Non-Secure callable regions are part of the secure flash.
From Non-secure callable (NSC) region definition in flash:
A non-secure callable sub-region can only exist within an existing secure region

The way I understand this, the secure region still has the same boundaries limited to 32KiB.
And the NSC regions are just a sub-region of the secure region.

Regards,
Sigurd Hellesvik

RE: Partition Manager not using flash efficiently

Cla — Thu, 02 Feb 2023 12:18:01 GMT

It is good to hear, that this discussion helped in finding a bug.

Unfortunately I do not really understand it to 100% yet.

[quote userid="121943" url="~/f/nordic-q-a/95599/partition-manager-not-using-flash-efficiently/405064"]I was wondering, why the end of the `tfm` partition, bordering the `app` did not have to be aligned to `0x8000`. My guess would be, that FLASHNSC[n].REGION and FLASHNSC[n].SIZE are use to define the secure-callable and non-secure-callable sub-regions within a region?[/quote]

My focus is on the internal workings here, just for better understanding. Did I understand this correctly?

RE: Partition Manager not using flash efficiently

Sigurd Hellesvik — Mon, 30 Jan 2023 09:31:04 GMT

Our developers agree that the part of the tfm partition that exceeds the secure flash is there because we have forgot to take the padding into account.

This means it is a bug, and we have created an internal ticket for it.

Thanks for pointing this out!

Regards,
Sigurd Hellesvik

RE: Partition Manager not using flash efficiently

Sigurd Hellesvik — Thu, 26 Jan 2023 14:28:12 GMT

First I was spending a bit of time to understand that you were talking about the last 0x200 part of the tfm partition.

And now that I understand it, I it looks odd to me, and I think it could even be a bug in the partitioning.

I think that TF-M does not really care that much about the partitions of zephyr, as it does not really build in the "zephyr way".

Either way, I have asked our developers about this.

Regards,
Sigurd Hellesvik

RE: Partition Manager not using flash efficiently

Sigurd Hellesvik — Wed, 18 Jan 2023 10:19:09 GMT

[quote user="Cla"]This is more an understanding question out of interest. The original question can be considered answered.[/quote]

This also helps me get more understanding into this complicated topic, so I am glad to continue answering.

I might take a bit longer to answer than usual, since the important part of the case is solved, but I will figure this out eventually.

Regards,
Sigurd Hellesvik

RE: Partition Manager not using flash efficiently

Cla — Mon, 16 Jan 2023 13:51:01 GMT

[quote userid="106736" url="~/f/nordic-q-a/95599/partition-manager-not-using-flash-efficiently/405057"]Is this what you were looking for?[/quote]

Not quite. I am sorry, that I did not express myself well.

I was wondering, why the end of the `tfm` partition, bordering the `app` did not have to be aligned to `0x8000`. My guess would be, that FLASHNSC[n].REGION and FLASHNSC[n].SIZE are use to define the secure-callable and non-secure-callable sub-regions within a region?

This is more an understanding question out of interest. The original question can be considered answered.
Thanks for your help.

RE: Partition Manager not using flash efficiently

Sigurd Hellesvik — Mon, 16 Jan 2023 13:41:45 GMT

Hi,

[quote user="Cla"]So, just for my understanding, the tfm partition does not have to be aligned to the flash-regions (and can therefore share a region with the `app`), because it makes use of non-secure-callable sub-regions[/quote]

Since we have 2 different regions we talk about here, I am a bit unsure what you ask about.
But I asked our experts the following question:

"Does the TF-M partition need to be aligned to fit with The SPUs 32 KiB regions?"

And they answer:

"The answer is yes.
Or to be more precise. The application needs to start on an SPU aligned 32 / 16 KB region.
So that means if you have bootloaders, that affects it also. As the sum of bootloaders + TF-M sizes is what you need to look at."

and
"Correct it needs to be aligned within the locking granularity of https://infocenter.nordicsemi.com/topic/ps_nrf9160/spu.html?cp=2_0_0_5_14_1#register.FLASHREGION.PERM
So that you are ensured that the flash can be set to secure.
"

Is this what you were looking for?

My example might have misled you some.
When testing it, I had to increase the size of MCUboot by exactly 16KiB as you see.
If I remember correctly, it did not build for smaller increases.
I should have realized this when testing, but oh well.
Good job asking questions about this, it increases both our understanding on the matter.

Regards,
Sigurd Hellesvik

RE: Partition Manager not using flash efficiently

Cla — Mon, 16 Jan 2023 09:26:50 GMT

Very good, thanks.
So, just for my understanding, the tfm partition does not have to be aligned to the flash-regions (and can therefore share a region with the `app`), because it makes use of non-secure-callable sub-regions (https://infocenter.nordicsemi.com/pdf/nRF9160_PS_v2.0.pdf#%5B%7B%22num%22%3A2810%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C85.039%2C465.123%2Cnull%5D)?

RE: Partition Manager not using flash efficiently

Sigurd Hellesvik — Fri, 13 Jan 2023 13:19:53 GMT

To test the placement of the tfm partition, I did the following:

Use nrf/samples/crypto/aes_cbc, with CONFIG_BOOTLOADER_MCUBOOT=y.

Now the partition manager report is as follows:

+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x74000 - 464kB)-----+
+---0xc000: tfm_secure (0x40200 - 256kB)----------+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x73e00 - 463kB)-+
| 0xc200: tfm (0x40000 - 256kB)                   |
+---0x4c200: tfm_nonsecure (0x33e00 - 207kB)------+
| 0x4c200: app (0x33e00 - 207kB)                  |
+-------------------------------------------------+
| 0x80000: mcuboot_secondary (0x74000 - 464kB)    |
| 0xf4000: EMPTY_0 (0x4000 - 16kB)                |
+---0xf8000: tfm_storage (0x8000 - 32kB)----------+
| 0xf8000: tfm_its (0x2000 - 8kB)                 |
| 0xfa000: tfm_otp_nv_counters (0x2000 - 8kB)     |
| 0xfc000: tfm_ps (0x4000 - 16kB)                 |
+-------------------------------------------------+

  otp (0x2fc - 764B): 
+------------------------------+
| 0xff8100: otp (0x2fc - 764B) |
+------------------------------+

  sram_primary (0x80000 - 512kB): 
+------------------------------------------------+
+---0x20000000: sram_secure (0x40000 - 256kB)----+
| 0x20000000: tfm_sram (0x40000 - 256kB)         |
+---0x20040000: sram_nonsecure (0x40000 - 256kB)-+
| 0x20040000: sram_primary (0x40000 - 256kB)     |
+------------------------------------------------+

To move the tfm partition, I increased the size of mcuboot.
Then the tfm partition would have to move to make space.

I used the following pm_static.yml:

mcuboot:
  address: 0x0
  end_address: 0x10000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x10000

And get the following partition manager report:

+--------------------------------------------------+
| 0x0: mcuboot (0x10000 - 64kB)                    |
+---0x10000: mcuboot_primary (0x74000 - 464kB)-----+
+---0x10000: tfm_secure (0x40200 - 256kB)----------+
| 0x10000: mcuboot_pad (0x200 - 512B)              |
+---0x10200: mcuboot_primary_app (0x73e00 - 463kB)-+
| 0x10200: tfm (0x40000 - 256kB)                   |
+---0x50200: tfm_nonsecure (0x33e00 - 207kB)-------+
| 0x50200: app (0x33e00 - 207kB)                   |
+--------------------------------------------------+
| 0x84000: mcuboot_secondary (0x74000 - 464kB)     |
+---0xf8000: tfm_storage (0x8000 - 32kB)-----------+
| 0xf8000: tfm_its (0x2000 - 8kB)                  |
| 0xfa000: tfm_otp_nv_counters (0x2000 - 8kB)      |
| 0xfc000: tfm_ps (0x4000 - 16kB)                  |
+--------------------------------------------------+

  otp (0x2fc - 764B): 
+------------------------------+
| 0xff8100: otp (0x2fc - 764B) |
+------------------------------+

  sram_primary (0x80000 - 512kB): 
+------------------------------------------------+
+---0x20000000: sram_secure (0x40000 - 256kB)----+
| 0x20000000: tfm_sram (0x40000 - 256kB)         |
+---0x20040000: sram_nonsecure (0x40000 - 256kB)-+
| 0x20040000: sram_primary (0x40000 - 256kB)     |
+------------------------------------------------+

Observe that in the first build, tfm starts at 0xc200.
At the second build, tfm starts at 0x10200

Regards,
Sigurd Hellesvik

RE: Partition Manager not using flash efficiently

Cla — Fri, 13 Jan 2023 08:06:42 GMT

[quote userid="106736" url="~/f/nordic-q-a/95599/partition-manager-not-using-flash-efficiently/404599"]I will try to create a sample to move TF-M partitions to test this tomorrow or Monday.[/quote]

Could it be, that tfm is using sub-regions?

https://infocenter.nordicsemi.com/pdf/nRF9160_PS_v2.0.pdf#%5B%7B%22num%22%3A2810%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C85.039%2C465.123%2Cnull%5D

"6.15.2.1 Non-secure callable (NSC) region definition in flash"

I interpret this section to mean, that in each region there can be a "non-secure" and a "secure"-callable sub-region. This might explain, why the tfm-partition does not need to be aligned to the region border?

RE: Partition Manager not using flash efficiently

Cla — Thu, 12 Jan 2023 14:56:15 GMT

[quote userid="106736" url="~/f/nordic-q-a/95599/partition-manager-not-using-flash-efficiently/404599"]I will try to create a sample to move TF-M partitions to test this tomorrow or Monday.[/quote]

Thanks

And thanks for the quick and detailed answer.

RE: Partition Manager not using flash efficiently

Sigurd Hellesvik — Thu, 12 Jan 2023 14:54:12 GMT

[quote user="Cla"]These are unfortunately not accessible to me. I get a "503 Service unavailable".[/quote]

Infocenter is now up and running again.

[quote user="Cla"]Do you know, what the alignment requirements are for the tfm_secure partition? [/quote]

I do not know.
I will try to create a sample to move TF-M partitions to test this tomorrow or Monday.

[quote user="Cla"]as far as I could see this was closed.[/quote]

I reached out to the guy who closed it and it seems like it was closed due to it being 1 year since it was created.
If you comment the issue it will show that users are interested in this feature, which may speed up its progress.

[quote user="Cla"]Alternatively, we considered reserving the required amount in the `pm_static`, but I was unsure about what that amount should be (hence my question here: MCUBoot Swap using move, how to calculate size?). Now I start to understand, that the block size is 4kB and to be used in that calculation whereas the sectors/partitions are 32KiB to be used for partitioning. Is this correct?[/quote]

I agree yes.

Regards,
Sigurd Hellesvik

RE: Partition Manager not using flash efficiently

Cla — Thu, 12 Jan 2023 14:30:49 GMT

Thanks for the detailed explanation.

[quote userid="106736" url="~/f/nordic-q-a/95599/partition-manager-not-using-flash-efficiently/404585"]The general block size of the flash is 4kB(0x1000), see INFO.CODEPAGESIZE in the FICR.
However, the SPU splits the flash for partitions, and have a size of 32kB(0x8000). See SPU Flash access control.[/quote]

These are unfortunately not accessible to me. I get a "503 Service unavailable".

[quote userid="106736" url="~/f/nordic-q-a/95599/partition-manager-not-using-flash-efficiently/404585"]I do not know of any certain address requirements of tfm. Can you explain a bit further?[/quote]

When I hand edited the `pm_static` I ran into a linker issue with tfm. Even when I did not modify the size of the partition. This was unexpected. Now that I learned more, I guess that it was an alignment issue. Nevertheless: Do you know, what the alignment requirements are for the tfm_secure partition? I would have guessed, that it will need its own 32KiB sector also, but that does not seem to be, what the partition manager puts out.

[quote userid="106736" url="~/f/nordic-q-a/95599/partition-manager-not-using-flash-efficiently/404585"]Yes, and there seems to be a pull request for this as well:
https://github.com/nrfconnect/sdk-nrf/pull/6245[/quote]

as far as I could see this was closed.
Alternatively, we considered reserving the required amount in the `pm_static`, but I was unsure about what that amount should be (hence my question here: MCUBoot Swap using move, how to calculate size?). Now I start to understand, that the block size is 4kB and to be used in that calculation whereas the sectors/partitions are 32KiB to be used for partitioning. Is this correct?

[quote userid="106736" url="~/f/nordic-q-a/95599/partition-manager-not-using-flash-efficiently/404585"]Good job with searching and finding relevant DevZone cases yourself by the way.[/quote]

Thanks. Maybe I should have searched a bit more before asking though ;)

RE: Partition Manager not using flash efficiently

Sigurd Hellesvik — Thu, 12 Jan 2023 14:13:36 GMT

Hi,

[quote user=""]My main question is, how can the flash layout be optimized (by Hand)? If it cannot, how can partition manager be disable, so that the partitions from the device-tree are used instead?[/quote]

Yes, static partitioning (pm_static.yml) is the way to optimize partitions "by hand".

If you use child images, Partition Manager is included by default, so I think it will be hard to disable it if you want to use MCUboot.

[quote user=""]1. Is this approach to optimize the flash-layout correct?[/quote]

You have two different ways to configure mcuboot flash usage:

CONFIG_PM_PARTITION_SIZE_MCUBOOT and CONFIG_PM_PARTITION_SIZE_MCUBOOT_PAD. Ref RE: west build generates large EMPTY partitions
pm_static.yml

MCUboot operates with static partitioning.
Meaning that you can not change partitioning in an DFU update to MCUboot.

Because of this, I think it is just as well to use pm_static.yml, as you might want static partitions either way.

[quote user=""]2. Is there a reason, that the tfm partition is expected to be located at a certain address?[/quote]

I do not know of any certain address requirements of tfm. Can you explain a bit further?

If we imagine an application without a bootloader for a moment: The tfm partition is placed at the beginning of flash to make sure it is the first thing that is executed.

[quote user="Cla"]On 3. It seems it is for the image header answer found here: Partition manager primary and secondary slot sizes
[/quote]

Yes

[quote user="Cla"]On 4. I found some helpful infos here: Interpretation of the partition manager report
Is the CONFIG_NRF_SPU_FLASH_REGION_SIZE = 0x8000 in the nRF9160 ?[/quote]

The general block size of the flash is 4kB(0x1000), see INFO.CODEPAGESIZE in the FICR.
However, the SPU splits the flash for partitions, and have a size of 32kB(0x8000). See SPU Flash access control.

Use Kcofig(in VS Code) search to verify what this configuration is set to for your build specifically.
Or "west build -t menuconfig" in the Terminal.

[quote user="Cla"]

On 5. It seems others have also observed:
Partition manager primary and secondary slot sizes

Big primary image prevents FOTA

[/quote]

Yes, and there seems to be a pull request for this as well:
https://github.com/nrfconnect/sdk-nrf/pull/6245

[quote user="Cla"]After investigating a bit, I think I have to update my assumptions. Maybe someone could confirm?
- On the nRF9160 the flash sector size is 0x8000=32KiB. It has a total of 1MiB/32KiB=32 sectors.
- The sectors occupied by mcuboot can not hold anything else. Since the build > 32KiB it takes 2 sectors
- The storages (nvs and tfm) currently takes 1 sector, exactly 32kiB size.
- that leaves 32 - 3 = 29 sectors for the mcuboot primary and secondary partition. They need to be equal size (leaving out the caveat about the move algorithm for now). They also need to be aligned to the flash sectors (if so, why?). That means the sector count has to be even 29-1=28. Each partition needs half of the space 28/2=14. Which is what we see in the above report (14*32KiB = 448KiB).[/quote]

Yes, both I and one of my colleagues agree with your assumptions.

I hope I answered your questions.
Let me know if I missed some or if you have more.
Good job with searching and finding relevant DevZone cases yourself by the way.

Regards,
Sigurd Hellesvik

RE: Partition Manager not using flash efficiently

Cla — Thu, 12 Jan 2023 09:23:17 GMT

Update:
On 4. I found some helpful infos here: Interpretation of the partition manager report
Is the CONFIG_NRF_SPU_FLASH_REGION_SIZE = 0x8000 in the nRF9160 ?

On 3. It seems it is for the image header answer found here: Partition manager primary and secondary slot sizes

On 5. It seems others have also observed:
Partition manager primary and secondary slot sizes

Big primary image prevents FOTA

Regarding the empty partitions also see:
RE: west build generates large EMPTY partitions

After investigating a bit, I think I have to update my assumptions. Maybe someone could confirm?
- On the nRF9160 the flash sector size is 0x8000=32KiB. It has a total of 1MiB/32KiB=32 sectors.
- The sectors occupied by mcuboot can not hold anything else. Since the build > 32KiB it takes 2 sectors
- The storages (nvs and tfm) currently takes 1 sector, exactly 32kiB size.
- that leaves 32 - 3 = 29 sectors for the mcuboot primary and secondary partition. They need to be equal size (leaving out the caveat about the move algorithm for now). They also need to be aligned to the flash sectors (if so, why?). That means the sector count has to be even 29-1=28. Each partition needs half of the space 28/2=14. Which is what we see in the above report (14*32KiB = 448KiB).