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?

[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