OTP allocation for NSIB

[Amira R.]

In the documentation for the secure bootloader, it's mentioned that the provisioning data gets stored in OTP memory for some chips (e.g. nRF5340). Is there a way to know what portion or address space of the OTP will be used by the bootloader?

The current project I'm working on, using the nRF5340, requires roughly 40-48B of OTP for manufacturer-specific data. Is there a way to ensure that these datasets will not overlap and corrupt one another? 

Thank you!

[Einar Thorsrud]

Hi,

There is no region of the OTP that is reserved for customer use, so in principle, there can be changes in future SDK releases that use additional registers that are not currently used. One option is to manage that youself. Another option could be to use the CUSTOMER region in the UICR for the network core. However, then you would need to handle the use of this on the nework core, as this is not directly accessible from the application core.

[Amira R.]

Hi Einar,

Thank you for your response!

Einar Thorsrud said:

One option is to manage that youself.

This option would likely be the most viable for this project - but ignoring the possibility that later SDK changes might use additional registers, with the version I'm using (2.9.0), will the provisioning data for the secure bootloader always be written to the same registers? Or is it possible to choose where the provisioning data will be written?

Thank you again!

[Amira R.]

Hello,

After setting up the static partitions for the bootloader, I saw the provision partition that was automatically generated: 

provision:
  address: 0xff8100
  end_address: 0xff8380
  region: otp
  size: 0x280

I added it to my static partitions file and shifted it to the end of the partition, then I added a placeholder partition to fill in the gap at the start of the region (which is where the manufacturer-specific data will be stored)

provision:
  address: 0xff8180
  end_address: 0xff8400
  region: otp
  size: 0x280
  
factory_data_otp:
  address: 0xff8100
  end_address: 0xff8180
  placement:
    before: provision
  region: otp
  size: 0x80

But this resulted in the following partition being generated during the build:

otp:
  address: 0xff8400
  end_address: 0xff83fc
  region: otp
  size: -0x4

What does this mean? Why would a gap be detected with negative size?

Also do you know if shifting the provision partition might cause any other issues? Are there other known uses for the OTP region that I may be missing or overlooking? Unfortunately I'm running into some separate build errors that are preventing me from gaining information through testing/experimentation, but I'm hoping I can get some answers on this front.

Thank you!

[AHaug]

Hi,

Einar is currently on vacation so I'll pick up this case. The negative size typically indicates that your partitions are not properly aligned making it so that there are some partitions overlapping because the partition manager can't fit in the required paddings or page alignments it needs. Are the provision and factory_data_otp partitions the only things you have in your static pm?

• TF-M and secure/non-secure boundaries: Must be aligned to the SPU region size, which is 0x4000 (16 KB) for nRF5340. Both the start address and size of these partitions must be multiples of 0x4000. 
  • https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/security/tfm/tfm_building.html#tf-m_partition_alignment_requirements 
• MCUBoot pad + TF-M: The combined size must also align to 0x4000.
• Other partitions: Should be aligned to the flash erase page size (typically 0x1000), but strict alignment is only required for partitions involved in security boundaries 

Kind regards,
Andreas

[Amira R.]

HI Andreas,

Thank you for picking up my case!

I'm not using TF-M for this project, does the SPU alignment rule still apply? All my other static partitions are aligned by page size.

Also "provision" and "factory_data_otp" are not the only defined static partitions, but they're the only partitions in the "otp" region. Would partitions in other regions affect these partitions? 

[AHaug]

Amira R. said:

I'm not using TF-M for this project, does the SPU alignment rule still apply? All my other static partitions are aligned by page size.

Yes, the page granularity is still something you need to consider for the devices

Amira R. said:

Also "provision" and "factory_data_otp" are not the only defined static partitions, but they're the only partitions in the "otp" region. Would partitions in other regions affect these partitions? 

Any region that may have addresses overlapping could affect any other region

Kind regards,
Andreas

[Amira R.]

Hi Andreas,

Thank you for getting back to me.

Since TF-M is not being used, I'll assume that partitions only need to be aligned by erase page size (0x1000), which is the case at the container level.

I'm attaching my partition file here if you don't mind checking for errors - I don't think partitions are overlapping, but perhaps I'm missing something.

Fullscreen pm_static_device_nrf5340_cpuapp.txt Download

b0:
  address: 0x0
  end_address: 0x8000
  placement:
    after: start
  region: flash_primary
  size: 0x8000
  
b0_container:
  address: 0x0
  span: [ b0 ]
  size: 0x8000

# B0 Provision Data stored in OTP for nRF5340
provision:
  address: 0xff8180
  end_address: 0xff8400
  region: otp
  size: 0x280

s0_pad:
  address: 0x8000
  end_address: 0x8200
  placement:
    after: b0_container
    align: { start: 0x1000 }
  region: flash_primary
  size: 0x200
  share_size: 
  - mcuboot_pad
s0_image:
  address: 0x8200
  span: [ mcuboot ]
  size: 0x4e00

mcuboot:
  address: 0x8200
  end_address: 0xd000
  inside: [ s0_image ]
  placement:
    after: s0_pad
  region: flash_primary
  size: 0x4e00

s0:
  address: 0x8000
  span: [ s0_pad, s0_image ]
  size: 0x5000

s1_pad:
  address: 0xd000
  end_address: 0xd200
  placement:
    after: s0
    align: { start: 0x1000 }
  region: flash_primary
  share_size:
  - mcuboot_pad
  size: 0x200
s1_image:
  address: 0xd200
  end_address: 0x12000
  placement:
    after: s1_pad
  region: flash_primary
  share_size:
  - mcuboot
  size: 0x4e00

s1:
  address: 0xd000
  span: [ s1_pad, s1_image ]
  size: 0x5000

mcuboot_pad:
  address: 0x12000
  end_address: 0x12200
  placement:
    after: s1
    align: { start: 0x1000 }
  region: flash_primary
  size: 0x200
mcuboot_primary_app:
  address: 0x12200
  span: [ app ]
  size: 0xeae00

app:
  address: 0x12200
  placement: 
    after: 
  inside: [ mcuboot_primary_app ]
  region: flash_primary
  size: 0xeae00

mcuboot_primary:
  address: 0x12000
  span: [ mcuboot_pad, app ]
  size: 0xeb000

# Device settings (app NVS)
project_settings:
  address: 0xfd000
  end_address: 0xfe000
  placement:
    after: mcuboot_primary_app
  region: flash_primary
  size: 0x1000
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  placement:
    after: project_settings
  region: flash_primary
  size: 0x2000
factory_data_otp:
  address: 0xff8100
  end_address: 0xff8180
  placement:
    before: provision
  region: otp
  size: 0x80

# Shared RAM for network core
pcd_sram:
  address: 0x20000000
  region: sram_primary
  size: 0x2000
mcuboot_primary_1:
  address: 0x0
  device: flash_ctrl
  region: ram_flash
  size: 0x40000

# External Flash
mcuboot_secondary:
  address: 0x0
  device: HUB_EXTERNAL_FLASH_A
  region: external_flash
  size: 0xeb000
mcuboot_secondary_1:
  address: 0xeb000
  device: HUB_EXTERNAL_FLASH_A
  region: external_flash
  size: 0x40000
data_partition:
  address: 0x12b000
  device: HUB_EXTERNAL_FLASH_A
  region: external_flash
  size: 0x1ff000
sub_image_1:
  address: 0x32a000
  device: HUB_EXTERNAL_FLASH_A
  region: external_flash
  size: 0x8000
sub_image_2:
  address: 0x332000
  device: HUB_EXTERNAL_FLASH_A
  region: external_flash
  size: 0x65000
sub_image_3:
  address: 0x397000
  device: HUB_EXTERNAL_FLASH_A
  region: external_flash
  size: 0x7000
external_flash:
  address: 0x39e000
  device: HUB_EXTERNAL_FLASH_A
  region: external_flash
  size: 0x462000
  

Thank you!