Configuring pm_static.yml when porting from SPM to TFM

RE: Configuring pm_static.yml when porting from SPM to TFM

Hieu — Mon, 07 Oct 2024 18:07:56 GMT

Hi Ethan,

I also apologize for the late response. I have been out of office.

To rule out the external flash initialization issue, could you please configure your setup to work without external flash and see if the issue can still be reproduced?

Also, are you working on a custom board? If so, may I know what external flash device you are using, and what the configuration is?

Hieu

RE: Configuring pm_static.yml when porting from SPM to TFM

esisk — Fri, 20 Sep 2024 15:52:54 GMT

Hey Hieu,

Sorry for the delayed response, this is a side quest that I'm working on alongside other priorities. Something interesting to note, I finally got the project to build and run by disabling MCUBoot in the build. I have TFM enabled and my program is just printing Hello World. So the problem must lie with MCUBoot or how I've configured it. I will try building without a pm_static.yml file and see how that goes. Any other suggestions you could provide would be helpful.

Edit 1: My current hunch is that the regulator powering my external flash is not getting initialized correctly. MCUBoot needs to be able to access the external flash in order to determine which image to boot into. I think this is the issue because my app is hanging whenever I am initializing the application NVS file systems on the external flash, so I figure that the same thing would happen in MCUBoot. I'm able to get the regulator device handle correctly and call regulator_enable by passing in the handle, but this doesn't seem to be doing anything because trying to get the external flash device handle results in NULL. Has anything changed in how the regulator is powered upon boot or how to get the external flash device handle? The overlay that I sent in the zip folder above works fine in my project built with NCS 1.7.0

Edit 2: I have further confirmed the problem seems to be with MCUBoot. I built my hello world application with NCS 2.4.2 and sent an update to a device running an MCUBoot, SPM, and an application all built with NCS 1.7.0. The update was successful. So that implies to me that MCUBoot is the issue since the MCUBoot on the updated device is the same version that was on it previously

RE: Configuring pm_static.yml when porting from SPM to TFM

Hieu — Wed, 07 Aug 2024 13:17:43 GMT

Hi esisk,

Sorry for the delay from me too. We had a high-loading period, and I am still recovering from it.

[quote user="esisk"]

Edit 1:

When trying to build a the hello_world sample from zephyr/samples, I get this error:

[/quote]

Are you building a secure target (without _ns)?

[quote user="esisk"]

Edit 2:

When looking at some samples I see this config variable CONFIG_TFM_BL2, could you explain more what this does?

[/quote]

TFM has a two-stage bootloader solution. However, that is not supported in NCS.

RE: Configuring pm_static.yml when porting from SPM to TFM

esisk — Thu, 01 Aug 2024 14:08:52 GMT

Hey Hieu,

Sorry for the delay, I've gotten sidetracked with other priorities. I just tried running my app without MCUBoot, and I'm not seeing anything being printed to the console. The app is an infinite while loop that prints "Hello World" every five seconds. I will try to build the application without TFM as well and see how that affects it.

Edit 1:

When trying to build a the hello_world sample from zephyr/samples, I get this error:

/home/ethan/fw-dev/v2.4.2/nrf/lib/nrf_modem_lib/nrf_modem_lib.c:17:10: fatal error: pm_config.h: No such file or directory
   17 | #include <pm_config.h>

Any ideas on how to fix this? I'm trying to just run something with only tfm and an app that prints hello world to the console with nothing else configured.

Edit 2:

When looking at some samples I see this config variable CONFIG_TFM_BL2, could you explain more what this does?

RE: Configuring pm_static.yml when porting from SPM to TFM

esisk — Wed, 10 Jul 2024 13:07:16 GMT

[quote userid="9456" url="~/f/nordic-q-a/112548/configuring-pm_static-yml-when-porting-from-spm-to-tfm/493046"]The public key is regenerated from the private key whenever you build the application. However, that should not be an issue as long as the private key remain the same.[/quote]

Good to know, I won't consider this as a possible problem.

[quote userid="9456" url="~/f/nordic-q-a/112548/configuring-pm_static-yml-when-porting-from-spm-to-tfm/493046"]I think it might be worth it to try this with a very minimal setup. Perhaps use the Hello World sample, and adding just MCUboot, the MCUboot relevant Kconfig, and the current pm_static.yml. If this setup works, then it would indicate the issue is with the application.[/quote]

I've already made it to where my application is just an infinite while loop printing "Here" every 5 seconds once entering into main, so I doubt it'd be my application. But I will try a minimal setup with an out of the box sample and see if that works. I will also try running both my app and a sample app without MCUBoot. I'll work on this today and update you on my progress

RE: Configuring pm_static.yml when porting from SPM to TFM

Hieu — Tue, 09 Jul 2024 20:00:08 GMT

The public key is regenerated from the private key whenever you build the application. However, that should not be an issue as long as the private key remain the same.

[quote user="esisk"]MCUBoot is attempting to boot into the image. However, I'm still seeing nothing being logged by my application. That leads me to believe that either the address it's booting into is incorrect or TFM is getting stuck. The address it's booting into is 0xc000 which corresponds to mcuboot_pad as outlined in my pm_static.yml. Shouldn't it be using 0xc200 as the address? And is there a way to log TFM output via RTT?[/quote]

This is good progress. Given your finding, I agree with your conclusion.

Adding logging from TF-M is possible, but only via UART. Please refer to this page: Running applications with Trusted Firmware-M (nordicsemi.com).

I think it might be worth it to try this with a very minimal setup. Perhaps use the Hello World sample, and adding just MCUboot, the MCUboot relevant Kconfig, and the current pm_static.yml. If this setup works, then it would indicate the issue is with the application.

Following a similar logic, please also try compiling the application without MCUboot to see if it has any issue running.

RE: Configuring pm_static.yml when porting from SPM to TFM

esisk — Fri, 05 Jul 2024 15:50:16 GMT

After doing some further debugging, it seems that available RAM is not the issue. I've now tracked the stall down to bootutil_img_hash called in bootutil_img_validate. Maybe there is something that's changed in terms of MCUBoot performing crypto calls in NCS 2.x.x. Also, did the public key used to verify images change when the SDK was updated, or do I need to somehow link the public key to the private signing key that I'm using when re-installing the SDK? I'll include all my configuration files for clarity.

devzone.nordicsemi.com/.../curr_5F00_cfg.zip

Edit:

Tried building with the default signing key provided with the SDK and I run into the same stall, so the key is most likely not the issue.

Edit 2:

Interesting find... I programmed the board using the configuration setup included in the zip file I attached here and ran into the same stall. However, if I do a pin reset of the board, I see that my application starts up just fine. Any ideas as to why that could be?

Edit 3:

After doing more debugging, I discovered that for some reason, logging stopped working after a bit in MCUBoot. So the program was never actually getting stuck. I just replaced calls to BOOT_LOG_INF with printf and I got more info:

00> Here[00:00:00.489,593] <inf> mcuboot: Starting bootloader
00> [00:00:00.490,325] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> [00:00:00.490,661] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> [00:00:00.490,661] <inf> mcuboot: Boot source: none
00> [00:00:00.491,149] <inf> mcuboot: Swap type: none
00> here12here14Bootloader chainload address offset: 0xc000Jumping to the first image slot

MCUBoot is attempting to boot into the image. However, I'm still seeing nothing being logged by my application. That leads me to believe that either the address it's booting into is incorrect or TFM is getting stuck. The address it's booting into is 0xc000 which corresponds to mcuboot_pad as outlined in my pm_static.yml. Shouldn't it be using 0xc200 as the address? And is there a way to log TFM output via RTT?

RE: Configuring pm_static.yml when porting from SPM to TFM

Hieu — Thu, 04 Jul 2024 12:15:01 GMT

Hi esisk,

It seems you have made lots of progress. That's great.

Regarding the partition configuration, if you still have concern, can you share the partition manager report from the original 1.7.1 setup and the current setup? It helps make it easier to check if everything is correct.

[quote user="esisk"]In the console, "false" is getting printed so I know that the function should return it just doesn't. Which makes me realize that I had to reduce CONFIG_MAIN_STACK_SIZE to 5000 in order to build the project with logging, so the stack must have overflowed at some point. However, setting it back to CONFIG_MAIN_STACK_SIZE=10240 overflows the RAM allocated for MCUBoot by 600ish bytes when building. Setting the stack size to anything lower than 10240 results in my app not running and I can't build the project now with the original stack size.[/quote]

In a setting with secure domain, MCUboot is limited to the secure RAM region. If the logging is only for debugging, you can use CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM to help give it more RAM to work. Once we figure out the issue, CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM can be disabled again.

RE: Configuring pm_static.yml when porting from SPM to TFM

esisk — Wed, 03 Jul 2024 12:50:36 GMT

/home/ethan/build_keys/cell_priv.pemYes I followed the instructions for command line installation found here https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/installation/install_ncs.html. I did not update my old version of the SDK, just made a completely new copy and checked out v2.4.2 from GitHub. Is there a PR on GitHub where I can reference the partition manager fix you mentioned? Maybe I could try to patch my issue locally based on that

Thanks for confirming that the application address offset must be the same. I tried to simplify pm_static.yml as much as possible and got:

mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_primary: # mcuboot primary contains the updatable apps (tfm and main app) and mcuboot pad
  address: 0xc000
  end_address: 0xfa000
  span: [tfm, mcuboot_pad, app]
  region: flash_primary
  size: 0xf2000
mcuboot_primary_app: # mcuboot primary contains the updatable apps (tfm and main app)
  address: 0xc200
  end_address: 0xfa000
  span: [tfm, app]
  region: flash_primary
  size: 0xf1e00
tfm_nonsecure:
  address: 0x1c200
  end_address: 0xfa000
  span: [app]
  region: flash_primary
  size: 0xdde00
tfm_secure:
  address: 0xc000
  end_address: 0x1c200
  span: [mcuboot_pad, tfm]
  region: flash_primary
  size: 0x10200
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  region: flash_primary
  size: 0x200
tfm:
  address: 0xc200
  size: 0x10000
  region: flash_primary
app:
  address: 0x1c200
  end_address: 0xfa000
  region: flash_primary
  size: 0xdde00
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000

I received an error while building saying:

!!!Partition alignment error!!!
The non-secure start address in pm_static.yml or generated partition.yml is: 0x1c200
which is not aligned with the SPU region size.
Refer to the documentation section 'TF-M partition alignment requirements'
for more information.

   '
   16 | #pragma message "\n\n!!!Partition alignment error!!!"\
      |         ^~~~~~~
/home/ethan/ncs/nrf/modules/tfm/tfm/boards/common/assert.c:22:2: error: #error "TF-M non-secure start address is not aligned on SPU region size"
   22 | #error "TF-M non-secure start address is not aligned on SPU region size"

Is configuring this impossible? I've tried a few different set ups where the non-secure region is aligned with the SPU region size and my project will build. However, MCUBoot will run and print out something like

*** Booting Zephyr OS build v3.3.99-ncs1-2 ***
[00:00:00.494,262] <inf> mcuboot: Starting bootloader
[00:00:00.494,903] <wrn> mcuboot: Cannot upgrade: not a compatible amount of sectors
[00:00:00.535,491] <err> mcuboot: Image in the primary slot is not valid!
[00:00:00.535,522] <err> mcuboot: Unable to find bootable image

Thanks for looking into this Hieu

Edit:

I believe I've gotten pm_static.yml into a state that satisfies my requirements as well as the build system's: my app is in the same address as what's in the field and T-FM is aligned correctly. I'd appreciate you confirming that there shouldn't be any problems with this set up based on the original pm_static.yml file I shared in my original post.

mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_primary: # mcuboot primary contains the updatable apps (tfm and main app) and mcuboot pad
  address: 0xc000
  end_address: 0xfa000
  span: [tfm, mcuboot_pad, app]
  region: flash_primary
  size: 0xf2000
mcuboot_primary_app: # mcuboot primary contains the updatable apps (tfm and main app)
  address: 0xc200
  end_address: 0xfa000
  span: [tfm, app]
  region: flash_primary
  size: 0xf1e00
tfm_nonsecure:
  address: 0x18000
  end_address: 0xfa000
  span: [app]
  region: flash_primary
  size: 0xe2000
tfm_secure:
  address: 0xc000
  end_address: 0x18000
  span: [mcuboot_pad, tfm]
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  region: flash_primary
  size: 0x200
tfm:
  address: 0xc200
  end_address: 0x18000
  size: 0xbe00
  region: flash_primary
app:
  address: 0x1c200
  end_address: 0xfa000
  region: flash_primary
  size: 0xdde00
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000

My project builds. When running I get output from MCUBoot which seems like it's functioning correctly, but my application never boots. Here's the log output:

[00:00:00.518,890] <inf> mcuboot: Starting bootloader
[00:00:00.519,622] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.519,958] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.519,958] <inf> mcuboot: Boot source: none
[00:00:00.520,385] <inf> mcuboot: Swap type: none

Any insights as to what could be wrong? Also, is there a way to route T-FM logs via RTT? It'd be great to see if MCUBoot is booting into T-FM and there's some error there.

Edit 2:

After more debugging, I've found that MCUBoot is getting hung in the function boot_validate_slot in the file loader.c. This leads me to believe that MCUBoot cannot validate the images that are programmed in flash on my board. I looked in autoconf.h and found:

#define CONFIG_TFM_KEY_FILE_S "/home/ethan/ncs/modules/tee/tf-m/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem"
#define CONFIG_TFM_KEY_FILE_NS "/home/ethan/ncs/modules/tee/tf-m/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072_1.pem"

which is different than the path of my actual signing key which is /home/ethan/build_keys/cell_priv.pem. I made sure that I set:

CONFIG_TFM_KEY_FILE_S="/home/ethan/build_keys/cell_priv.pem"
CONFIG_TFM_KEY_FILE_NS="/home/ethan/build_keys/cell_priv.pem"

in my application prj.conf and setting:

CONFIG_BOOT_SIGNATURE_KEY_FILE="/home/ethan/build_keys/cell_priv.pem"

in child_images/mcuboot/prj.conf

However after making those changes, the application still isn't running. Any thoughts after these findings?

Edit 3:

Found a function where there are no more function calls and MCUBoot is getting stuck:

/*
 * Check that a memory area consists of a given value.
 */
static inline bool
boot_data_is_set_to(uint8_t val, void *data, size_t len)
{
    uint8_t i;
    uint8_t *p = (uint8_t *)data;
    for (i = 0; i < len; i++) {
        BOOT_LOG_ERR("boot_data_is_set_to i: %u, p: %p val: %u", i, p, val);
        if (val != p[i]) {
            BOOT_LOG_ERR("false");
            return false;
        }
    }
    BOOT_LOG_ERR("done");
    return true;
}

In the console, "false" is getting printed so I know that the function should return it just doesn't. Which makes me realize that I had to reduce CONFIG_MAIN_STACK_SIZE to 5000 in order to build the project with logging, so the stack must have overflowed at some point. However, setting it back to CONFIG_MAIN_STACK_SIZE=10240 overflows the RAM allocated for MCUBoot by 600ish bytes when building. Setting the stack size to anything lower than 10240 results in my app not running and I can't build the project now with the original stack size.

I'm assuming because more features/code have been added to MCUBoot since my previous SDK version. Could you give me guidance as to where I should go from here? I'm thinking of defining RAM partitions in my pm_static.yml that are the same as I had in my original pm_static.yml. I'm leaving work for today but would appreciate any feedback you have regarding this.

RE: Configuring pm_static.yml when porting from SPM to TFM

Hieu — Tue, 02 Jul 2024 21:48:05 GMT

There was an issue in NCS 2.2.0 and 2.3.0 where the Partition Manager with dynamic configuration causes this issue. I thought that this has been fixed in 2.4.2 though... Does this still happen in your standalone new copy of NCS? I will probably have to approach this from a different angle.

Regarding the new application address offset, you are completely right that it has to be the same as it was originally on the in-field device.

RE: Configuring pm_static.yml when porting from SPM to TFM

esisk — Mon, 01 Jul 2024 19:02:32 GMT

Technically yes I solved my initial question since the project builds. Functionally, no since I believe that I've built the project in an incorrect way. MCUBoot can't find a suitable program to boot into so I probably have the address of either TFM or my app configured incorrectly.

Sure I just tried building without pm_static.yml and got this error during build:

!!!Partition alignment error!!!
The non-secure start address in pm_static.yml or generated partition.yml is: 0x14000
which is not aligned with the SPU region size.
Refer to the documentation section 'TF-M partition alignment requirements'
for more information.

   '
   16 | #pragma message "\n\n!!!Partition alignment error!!!"\
      |         ^~~~~~~
/home/ethan/ncs/nrf/modules/tfm/tfm/boards/common/assert.c:22:2: error: #error "TF-M non-secure start address is not aligned on SPU region size"
   22 | #error "TF-M non-secure start address is not aligned on SPU region size"

The generated partitions.yml is:

EMPTY_0:
  address: 0xfa000
  end_address: 0x100000
  placement:
    after:
    - settings_storage
  region: flash_primary
  size: 0x6000
app:
  address: 0x14000
  end_address: 0xf8000
  region: flash_primary
  size: 0xe4000
external_flash:
  address: 0xec000
  end_address: 0x400000
  region: external_flash
  size: 0x314000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0xf8000
  orig_span: &id001
  - app
  - tfm
  - mcuboot_pad
  region: flash_primary
  size: 0xec000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0xf8000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0xebe00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xec000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xec000
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: 0xfa000
  orig_span: &id004
  - settings_storage
  region: flash_primary
  size: 0x2000
  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
settings_storage:
  address: 0xf8000
  end_address: 0xfa000
  inside:
  - nonsecure_storage
  placement:
    align:
      start: 0x8000
    before:
    - end
  region: flash_primary
  size: 0x2000
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: 0xc200
  end_address: 0x14000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x7e00
tfm_nonsecure:
  address: 0x14000
  end_address: 0xf8000
  orig_span: &id008
  - app
  region: flash_primary
  size: 0xe4000
  span: *id008
tfm_secure:
  address: 0xc000
  end_address: 0x14000
  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

I ended up just installing an entirely new copy of the SDK. It's important that I get this working with the correct application address offsets since I need to update devices that are already in the field running code build with NCS 1.7.0 and an immutable MCUBoot bootloader.

RE: Configuring pm_static.yml when porting from SPM to TFM

Hieu — Mon, 01 Jul 2024 18:51:40 GMT

Hi esisk,

Does this mean that you have resolved the original "Incorrect amount of gaps found in static configuration" issue?

Could you please try compiling without pm_static.yml, test, and share with us the result and the generated partitions.yml file?

When you mention updating your copy of NCS from 1.7.1 to 2.4.2, what do you mean? Did you checkout a new west manifest and run west update, or did you install a new copy of the SDK?

Hieu

RE: Configuring pm_static.yml when porting from SPM to TFM

esisk — Mon, 01 Jul 2024 14:52:12 GMT

I've gotten the project to build now, but I think that I have the partitions set up incorrectly because I receive this log from MCUBoot:

*** Booting Zephyr OS build v3.3.99-ncs1-2 ***
[00:00:00.474,884] <wrn> mcuboot: Failed reading image headers; Image=0
[00:00:00.474,914] <err> mcuboot: Unable to find bootable image

Here's my updated pm_static.yml file:

app:
  address: 0x1c200
  end_address: 0xfa000
  region: flash_primary
  size: 0xdde00
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id001
  - tfm
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xf2000
  span: *id001
mcuboot_primary_app:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0xf2000
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000
nrf_modem_lib_ctrl:
  address: 0x20010000
  end_address: 0x200104e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x200124e8
  end_address: 0x200144e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20010000
  end_address: 0x200144e8
  orig_span: &id003
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x44e8
  span: *id003
nrf_modem_lib_tx:
  address: 0x200104e8
  end_address: 0x200124e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2000
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
placeholder:
  address: 0xc200
  size: 0x3e00
tfm:
  address: 0x10000
  end_address: 0x18000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x8000
tfm_secure:
  address: 0xc000
  size: 0xc000
  span: [mcuboot_pad, tfm]
tfm_nonsecure:
  address: 0x18000
  end_address: 0xfa000
  size: 0xe2000
  span: [app]
# placeholder2:
#   address: 0x1c000
#   size: 0x200
#   region: flash_primary
sram_nonsecure:
  address: 0x20010000
  end_address: 0x20040000
  orig_span: &id004
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x30000
  span: *id004
sram_primary:
  address: 0x200144e8
  end_address: 0x20040000
  region: sram_primary
  size: 0x2bb18
  inside:
    - sram_nonsecure
sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  region: sram_primary
  size: 0x10000
tfm_sram:
  address: 0x20000000
  end_address: 0x20010000
  placement:
    after:
    - start
  region: sram_primary
  size: 0x10000
lwm2m_carrier:
  address: 0xfa000
  size: 0x4000
  inside:
  - nonsecure_storage
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  placement:
    before:
    - end
  region: flash_primary
  inside:
  - nonsecure_storage
  size: 0x2000
nonsecure_storage:
  address: 0xfa000
  end_address: 0x100000
  region: flash_primary
  size: 0x6000

And here's the generated partitions.yml

app:
  address: 0x18000
  end_address: 0xfa000
  region: flash_primary
  size: 0xe2000
external_flash:
  address: 0xf2000
  end_address: 0x400000
  placement:
    after:
    - mcuboot_secondary
  region: external_flash
  size: 0x30e000
lwm2m_carrier:
  address: 0xfa000
  end_address: 0xfe000
  inside:
  - nonsecure_storage
  region: flash_primary
  size: 0x4000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id001
  - tfm
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xf2000
  span: *id001
mcuboot_primary_app:
  address: 0xc000
  end_address: 0xfe000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0xf2000
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: MX25L3
  end_address: 0xf2000
  placement:
    align:
      start: 0x0
  region: external_flash
  size: 0xf2000
nonsecure_storage:
  address: 0xfa000
  end_address: 0x100000
  region: flash_primary
  size: 0x6000
nrf_modem_lib_ctrl:
  address: 0x20010000
  end_address: 0x200104e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x200124e8
  end_address: 0x200144e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20010000
  end_address: 0x200144e8
  orig_span: &id003
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x44e8
  span: *id003
nrf_modem_lib_tx:
  address: 0x200104e8
  end_address: 0x200124e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2000
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
placeholder:
  address: 0xc200
  end_address: 0x10000
  region: flash_primary
  size: 0x3e00
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  inside:
  - nonsecure_storage
  placement:
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_nonsecure:
  address: 0x20010000
  end_address: 0x20040000
  orig_span: &id004
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x30000
  span: *id004
sram_primary:
  address: 0x200144e8
  end_address: 0x20040000
  region: sram_primary
  size: 0x2bb18
sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  region: sram_primary
  size: 0x10000
tfm:
  address: 0x10000
  end_address: 0x18000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x8000
tfm_nonsecure:
  address: 0x18000
  end_address: 0xfa000
  region: flash_primary
  size: 0xe2000
  span:
  - app
tfm_secure:
  address: 0xc000
  end_address: 0x18000
  region: flash_primary
  size: 0xc000
  span:
  - mcuboot_pad
  - tfm
tfm_sram:
  address: 0x20000000
  end_address: 0x20010000
  placement:
    after:
    - start
  region: sram_primary
  size: 0x10000

There's some discrepancy between the addresses but not sure why that would be?