Expanding Nrf9160 Internal Storage Partition for LittleFs

[sheldon_b]

I'm looking for some general guidance regarding the internal storage partition where LittleFs is mounted.

I am writing a new firmware for the NRF9160 where having a larger LittleFs partition is needed. The "default" configuration for the storage partition is location 0xfa000 and size 0x6000. I am interested in increasing this size, maybe to 0xc000. From all of my research, the only way I have found to do this is to do the following:

• Enable MCUBoot (If needed, in my case it is)
• Because I am using the NRF9160 I have a multi image build so I need to use the Partition Manager instead of the partition section of the board dts file.
• Rather than building a pm_static.yml file by hand, I will just build the project normally and copy the partitions.yml from the build directory into a pm_static.yml in the app root directory. 
• At this point, I'm considering modifying the app, mcuboot_primary, mcuboot_primary_app, mcuboot_secondary, and littlefs_storage (Note: I may need to edit the empty sections). 
• The purpose of the modifications above are to make each of the sections a little smaller, then make the littlefs_storage proportionally larger.

Now, for my questions:

1. Is the above approach correct for increasing the littlefs partition size?
2. I have an older firmware running on the same PCB. What will happen if I attempt a FOTA opreation. Will the partitions be resized (assuming I don't mess with the mcuboot and mcuboot padding sections?

Note: I have attached the partitions.yml file for reference

EDIT: I created a CSV of all the partition sections within the flash_primary region. After looking at them in a flattened way, it appears that I might be able to do the following:

1. Delete the EMPTY_1 and EMPTY_2 sections
2. Change the nonsecure_storage section's start address from 0xf8000 to 0xf0000 (EMPTY_2 original start address)
3. Change the nonsecure_storage section's end address from 0xfe000 to 0x100000 (EMPTY_1 original end address)
4. Adjust the littlefs_storage section in accordance with the above changes to nonsecure_storage.
   

Note: This is all assuming my original approach is valid. I will await a response.

partitions.csv

[Amanda Hsieh]

Hi,

Is the above approach correct for increasing the littlefs partition size?

That's correct. 

I have an older firmware running on the same PCB. What will happen if I attempt a FOTA opreation. Will the partitions be resized (assuming I don't mess with the mcuboot and mcuboot padding sections?

Please use the same pm_static.yml for FOTA. See Static partition requirement for DFU.

Regards,
Amanda H.

[sheldon_b]

Amanda, thanks for responding.

Can you please look into my second question a little more? I understand the need for the pm_static.yml, I am trying to figure out if it will be possible to do a firmware update with the partition scheme updated from the original. Obvious cases where this wouldn't work would include things like changes to the app size, mcu boot primary or secondary slots. As my edits implied, I want to eliminate EMPTY_1 and EMPTY_2 and increase non_secure_storage. 

I suppose this whole situation opens up additional questioning: Given the default partition scheme for the NRF9160, why is the size of nonsecure_storage (nvs or littlefs) 0x6000 instead of 0x10000 (Defined in nrf/subsys/partition_manager/Kconfig?  A size of 0x6000 creates two empty spots that aren't useful. I would think anyone using the default layout would want the storage partition to be as large as possible. I apologize if I'm missing something here.

On a semi-unrelated note, rather than modifying the yml file by hand, the easiest way to increase the littleFS partition size to 0x10000 from 0x6000 is to set CONFIG_PM_PARTITION_SIZE_LITTLEFS=0x10000 inside of prj.conf and let the partition manager dynamically generate partition.yml. Then copy partition.yml into the root of the application pm_static.yml.

[Amanda Hsieh]

Hi, 

sheldon_b said:

why is the size of nonsecure_storage (nvs or littlefs) 0x6000 instead of 0x10000 (Defined in nrf/subsys/partition_manager/Kconfig? 

I agree that it might not use the space efficiently in your case, but the default value is designed for most used cases to leave more space for updating large images.    

sheldon_b said:

On a semi-unrelated note, rather than modifying the yml file by hand, the easiest way to increase the littleFS partition size to 0x10000 from 0x6000 is to set CONFIG_PM_PARTITION_SIZE_LITTLEFS=0x10000 inside of prj.conf and let the partition manager dynamically generate partition.yml. Then copy partition.yml into the root of the application pm_static.yml.

That's correct. This can help eliminate EMPTY_1 and EMPTY_2 and increase the non_secure_storage. 

Regards,
Amanda H.

[sheldon_b]

I agree that it might not use the space efficiently in your case, but the default value is designed for most used cases to leave more space for updating large images. 

If you include a LittleFs parition, but don't specify its size, the default value is 0x6000. All else on the default settings, the partition manager will create two empty slots around the storage_partition. All I'm saying is the default size should probably be 0x10000 so those slots aren't created.

If anyone else finds this useful: if you don't include the storage partition via LittleFs or Settings, the partition manager will reallocate that memory to the mcuboot secondary and mcuboot_primary_app slot. In my case, I ran a little test that showed an extra 0x8000 being allocated to both slots.