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