Why does the factory_data partition needs to be in front the settings partition?

[rosc]

I just ran into the issue that the settings_storage partition needs to be after the factory_data partition, and I asked myself why.

The problem is that, in case you need to expand the settings_storage partition in field, you would run into the problem that you need to move 2 partitions (factory_data and settings_storage), but if the settings_storage could be placed in front of the factory_data partition I would just need to redefine the start address. This restriction feels arbitrary.

[Marte Myrvold]

Hi,

The restriction is caused by the hardware flash write protection driver (fprotect). To ensure the correct operation of fprotetct, the factory_data partition must be placed right after the app partition and before settings_storage. This is due to the limitation that requires the write-protected areas to be aligned to CONFIG_FPROTECT_BLOCK_SIZE.

For more details, you can refer to Factory data partition in our documentation.

Best regards,
Marte

[rosc]

Dear Marte, thanks for the answer!

However, if an fprotect block has a size of 0x1000, and the factory_data has the same size, shouldn't it be no problem to move it where I want?

Also, given that my fprotect block size is bigger than the factory_data partition, and given I am willing to leave the space empty or increase the factory_data partition size, shouldn't that be an option also?

[Marte Myrvold]

Hi,

Some devices have limitations regarding block size. For example, on the nRF5340, the fprotect block size is 4 kB. The settings_storage partition cannot be protected with fprotect, as this would prevent writing to it, while it is recommended that the factory_data partition be write-protected. If factory_data is placed after settings_storage, you might get the fprotect block with the factory_data partition overlapping with the settings_storage partition. I have made a quick figure to visualize this:

This will cause an issue because either factory_data cannot be write-protected or parts of settings_storage will be write-protected. Because of this, the developers included a static assert that gives an error when building to avoid using fprotect on settings_storage, and they strongly recommend that customers do not try to bypass the assert.

However, if you change the size of the factory_data partition to 4 kB, you should be able to place it after settings_storage. Just make sure that the size of settings_storage is also a multiple of 4 kB.

Please note that the fprotect blocks in the figure do not necessarily mean that fprotect is enabled. They merely represent blocks that are the same size as the fprotect block size.

Best regards,
Marte

[rosc]

I know, but putting the settings_storage in front of the factory_data while honoring the fprotect size triggers a build error since it is simply checked that the factory_data partition is located in front of the settings_storage partition.

[Marte Myrvold]

Hi,

You are correct. I have asked the developers about this and will get back to you when I have an update.

Best regards,
Marte

[Marte Myrvold]

Hi,

According to the developers, moving the factory data and settings storage partitions should be allowed as long as they are aligned to a proper size, so the fact that this is not possible could be a bug. They will look into it and provide a fix, but I cannot comment on the schedule for when this will be fixed since this needs to be prioritized against other tasks.

The developers would normally not recommend bypassing the assert. Still, since the assert is checking the incorrect thing and causing an assert to happen for something that should be allowed, they have stated that if this is a blocker, then a possible workaround is to remove the assert from FactoryDataProvider.h as long as you make sure that the partitions are consistent with the requirements that they are aligned with the fprotect block size.

Best regards,
Marte

[rosc]

So I figured out that this was working in nrfconnect-sdk v2.2.0.

The change was introduced in 4c7f38d6427436f47c603dce67a1acd63ab7106a. It adds the lines

constexpr size_t kFactoryDataBlockEnd =
(PM_FACTORY_DATA_ADDRESS + PM_FACTORY_DATA_SIZE + CONFIG_FPROTECT_BLOCK_SIZE - 1) & (-CONFIG_FPROTECT_BLOCK_SIZE);
static_assert(kFactoryDataBlockEnd <= PM_SETTINGS_STORAGE_ADDRESS,
"FPROTECT memory block, which contains factory data"
"partition overlaps with the settings partition."
"Probably your settings partition size is not a multiple"
"of the atomic FPROTECT block size of " TO_STR(CONFIG_FPROTECT_BLOCK_SIZE) "kB");

As you may see, the test ist simply if the end of the factory data is in front of the PM_SETTINGS_STORAGE_ADDRESS address. Maybe the developers can fix this approach for the next nrfconnect-sdk version.

Best regards,
Juliane

[Marte Myrvold]

Hi Juliane,

The developers are aware of this and it is registered as a bug internally. I cannot comment on the schedule for when this will be fixed since this needs to be prioritized against other tasks.

Best regards,
Marte

[Marte Myrvold]

Hi Juliane,

I just wanted to update you that there is a pull request for the fix now: https://github.com/nrfconnect/sdk-connectedhomeip/pull/499.

Best regards,
Marte