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

[sheldon_b]

I'm not sure why the partition.yml file in my post is no longer accessible. Here it is:

EMPTY_0:
  address: 0xc000
  end_address: 0x10000
  placement:
    before:
    - mcuboot_pad
  region: flash_primary
  size: 0x4000
EMPTY_1:
  address: 0xfe000
  end_address: 0x100000
  placement:
    after:
    - littlefs_storage
  region: flash_primary
  size: 0x2000
EMPTY_2:
  address: 0xf0000
  end_address: 0xf8000
  placement:
    after:
    - mcuboot_secondary
  region: flash_primary
  size: 0x8000
app:
  address: 0x18000
  end_address: 0x80000
  region: flash_primary
  size: 0x68000
littlefs_storage:
  address: 0xf8000
  end_address: 0xfe000
  inside:
  - nonsecure_storage
  placement:
    align:
      start: 0x8000
    before:
    - end
  region: flash_primary
  size: 0x6000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  placement:
    align:
      start: 0x8000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  end_address: 0x80000
  orig_span: &id001
  - tfm
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x70000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  end_address: 0x80000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0x6fe00
  span: *id002
mcuboot_secondary:
  address: 0x80000
  end_address: 0xf0000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x8000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x70000
mcuboot_sram:
  address: 0x20000000
  end_address: 0x20008000
  orig_span: &id003
  - tfm_sram
  region: sram_primary
  size: 0x8000
  span: *id003
nonsecure_storage:
  address: 0xf8000
  end_address: 0xfe000
  orig_span: &id004
  - littlefs_storage
  region: flash_primary
  size: 0x6000
  span: *id004
nrf_modem_lib_ctrl:
  address: 0x20008000
  end_address: 0x200084e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - tfm_sram
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x2000a568
  end_address: 0x2000c568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20008000
  end_address: 0x2000c568
  orig_span: &id005
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x4568
  span: *id005
nrf_modem_lib_tx:
  address: 0x200084e8
  end_address: 0x2000a568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2080
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
sram_nonsecure:
  address: 0x20008000
  end_address: 0x20040000
  orig_span: &id006
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x38000
  span: *id006
sram_primary:
  address: 0x2000c568
  end_address: 0x20040000
  region: sram_primary
  size: 0x33a98
sram_secure:
  address: 0x20000000
  end_address: 0x20008000
  orig_span: &id007
  - tfm_sram
  region: sram_primary
  size: 0x8000
  span: *id007
tfm:
  address: 0x10200
  end_address: 0x18000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x7e00
tfm_nonsecure:
  address: 0x18000
  end_address: 0x80000
  orig_span: &id008
  - app
  region: flash_primary
  size: 0x68000
  span: *id008
tfm_secure:
  address: 0x10000
  end_address: 0x18000
  orig_span: &id009
  - mcuboot_pad
  - tfm
  region: flash_primary
  size: 0x8000
  span: *id009
tfm_sram:
  address: 0x20000000
  end_address: 0x20008000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x8000

[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.