Device Tree replacement for deprecated Partition Manager is ridiculously poorly documented at this NCS v3.4.1 stage

[Burt]

Hi,

I am going nuts with the device tree replacement for PM that seems to cover about 1 case out of a larger number of possibilities. Please give me the overlay files and related information to set up NSIB bootloader, NO MCUBOOT, TF-M, and External Flash for nRF9160DK. You quite clearly state that this is a valid configuration on your README.html#bootloader-flash-layout. But it looks like you have thrown up all sorts of road blocks to most configurations when you tried to replace Partition Manager with DTS. We know from the documentation that Partition Manager was deprecated last quarter, June-August, the third quarter of 2026.

I also would like the overlay file that works with NO NSIB, MCUBOOT, TF-M, and External Flash.

I also would like the overlay file that works with NO NSIB, NO MCUBOOT, TF-M, and External Flash.

The proof that your documentation needs lots of help is that when I try to use AI to solve these problems, it ends up in a divergence rather than convergence.

Thank you very much for help.

Regards,

Burt Silverman

[Simonr]

Hi again Burt

After discussing this predicament with a colleague as well, the NSIB bootloader isn't recommended to run alone with TF-M, as NSIB only is the first stage bootloader, and is designed to be used with MCUBoot as the second stage bootloader. It's possible to also run it directly with the application, but that would require changes to the SDKs sysbuild since the s0_partition starts at the same address as the secure TF-M image (0x8000), so the two collide. Is there a specific reason you're requesting an overlay file for NSIB + TF-M without MCUBoot here, as I don't see a specific use case for it.

The recommended path here would be to use NSIB + MCUBoot + TF-M, as these were designed to work together.

Best regards,

Simon

[Burt]

Hi Simon,

Allow me to be a "Grammar Nazi," and first let me define that term using AI, as it is not often used in the modern software industry, according to AI:
The Usenet and Seinfeld Boom: By 1991, the term "Grammar Nazi" emerged on early internet forums (Usenet) to describe users who aggressively corrected typos. The concept was permanently cemented into mainstream culture by the 1995 Seinfeld episode "The Soup Nazi," which featured an authoritarian chef who banned customers for violating his strict ordering guidelines.

Also
"Grammar Nazi" (in Tech): In programming, this often translates to someone who is obsessively rigid about documentation,...

With that out of the way, I wish to go through some of the basic nRF Secure Immutable Bootloader and Secure bootloader chain documents, https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/samples/bootloader/README.html#bootloader-flash-layout, and https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.html#ug-bootloader.

I will highlight things that are of interest. I believe there are some contradictory concepts in those documents, but the rules you are giving me add to that problem.

 It can verify and boot a second-stage bootloader or application

Here I have a question based on this statement: Currently, the NSIB does not support performing firmware updates over the SMP transport. If the application using the NSIB requires SMP-based firmware updates, such as Bluetooth® LE DFU, include MCUboot as a second-stage bootloader.
My question is, when talking about FOTA over Cellular, I want to believe that this does not apply, but I am not certain at all. Please confirm.

Halfway down the page of the nSIB document is a "B0 flash memory layout" diagram. Although the text mentions nrf52840dk/nRF52840 target, I assume the diagram is more general. Above the diagram it is written

s0_partition and s1_partition — redundant slots for the next stage in the boot chain (application or upgradable MCUboot)

But the diagram only shows App in Slot 0. Won't App also go into Slot 1 as a Pre-signed variant if I want to use b0 only in an upgrade situation? This is what I mean when I say that the nSIB document seems to have a contradiction.

Now moving to the Secure bootloader chain document. It tells us:
If you want the bootloader to perform firmware updates for only upgrading an application, then use the single-stage, immutable bootloader solution.

The section "Architecture" of that document starts off with:
The nRF Connect SDK currently supports two implementations:

The first implementation provides the first stage in the chain, the immutable nRF Secure Immutable Bootloader, which could be either nRF Secure Immutable Bootloader or MCUboot. It does not support bootloader upgradability, but it is useful if you need just the capability to update your application.

See the following image for an abstract representation of the memory layout for an application that uses only an immutable bootloader in its boot chain:

At this point they provide a diagram which shows the Immutable Bootloader immediately followed by one copy of the Application. Again I don't know why they do not show the case of redundant slots like they do for the case where a second stage bootloader is used. I should add this statement from the first document (nSIB), under the Pre-signed variants section:

If this image is faulty and cannot be booted, the other partition will always hold a working image that is booted instead.

 Finally, moving to your reply, I have a couple of questions about your statement "It's possible to also run it directly with the application, but that would require changes to the SDKs sysbuild since the s0_partition starts at the same address as the secure TF-M image (0x8000), so the two collide."

First minor question is your choice of 0x8000 for the address. Minor question, but that number is based on how the samples dtsi are layed out; not a hardcoded number, (maybe it needs to be a multiple of 0x8000 though) am I correct?  And the more significant question: are you saying that the problem cannot be solved by modifying the .dtsi files but would require changes to the sysbuild code? By the way, I may have come close to getting something: I managed to set up partitions so that the build went through okay: it build b0, the application variant, 2 instances of tfm_s, and the application, but it looks like tfm_s did not make it into the flashing, so b0 would run and continually cycle (reboot). So I can repeat the question: is that because sysbuild needs to change, or is it just a partition naming thing?

If the b0 without mcuboot is not going to be supported, they need to rewrite all the documentation I pointed to, and probably more that I didn't see!

Thanks, Simon.

Best Regards,

Burt

 

[Simonr]

Hi Burt

I'll go through the questions you have and answer them.

Burt said:

when talking about FOTA over Cellular, I want to believe that this does not apply, but I am not certain at all. Please confirm.

If you require FOTA that can upgrade both the application and the bootloader, you will need a second-stage bootloader, that is true. Both for Cellular and 2.4GHz solutions. Is there a specific reason you think that shouldn't go for Cellular solutions? I don't see anywhere specific in the docs saying that doesn't count for cellular.

Burt said:

But the diagram only shows App in Slot 0. Won't App also go into Slot 1 as a Pre-signed variant if I want to use b0 only in an upgrade situation?

The s0 and s1 partitions are alternate slots for the stage in the boot chain after the bootloader image. The app can go into either s0 or s1 depending on how your application is configured. http://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.html#devicetree-node-labels 

Regarding your question on s0/s1 on single stage bootloaders, that's possible, but we do not recommend using NSIB as a single stage bootloader, as DFU with NSIB isn't supported out of the box https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_quick_start.html#supported-features-and-configurations. I'm not saying this is impossible, but the recommended configurations here saves you a lot of headache if you use the configs supported by default. 

Using MCUBoot as a single stage bootloader should let you have separate application images in the slot0 and slot1 partitions though, if that's of interest. Example: https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_quick_start.html#supported-features-and-configurations 

Burt said:

First minor question is your choice of 0x8000 for the address.

This is the default number used in our SDK as the boot usually takes the storage before 0x8000. You can change it at your leisure, and a multiple of 0x8000 should indeed be set. 

I have forwarded your feedback on the documentation not being clear enough, but I can't promise this will be rewritten right away, as the change will likely take some time.

Burt said:

are you saying that the problem cannot be solved by modifying the .dtsi files but would require changes to the sysbuild code?

Here, do you refer to the problem of using NSIB as a single stage bootloader with DFU? The issue here is that you would need to implement the DFU logic yourself here, the specifics on what needing to be changed I'm not sure about, but just getting a single stage bootloader with NSIB should not require sysbuild changes.

(I can't quote the snippets from your other replies, so please follow the context on these chronologically). You will indeed need to explicitly state if you want a slot to be put in the external flash. The slot needs to be added to the partition addresses where the external flash is defined.

Yes we are working on improving the west flash procedure. Please note that the AI tool you use suggests that you use nrfjprog. You should rather use nrfutil device for programming and erasing devices in nRF Connect SDK, as nrfjprog is in maintenance mode and for the nRF5 SDK.

If you don't want to move from the partition manager, our suggestion long-term is to stay on the nRF Connect SDK v3.4.0 LTS release where it will still be available. Newer SDKs will require that you move to the DTS structure for partitioning.

Best regards,

Simon

[Burt]

Hi Simon,

Thank you very much for your reply.

My question about FOTA over cellular was slightly different. The issue wasn't updating both app and bootloader. The document I was reading from stated that mcuboot was required for SMP firmware updates. I was asking if SMP was required for FOTA over cellular. I am pretty sure it is not, and that FOTA over cellular can be done without mcuboot (but only for updating the app). I just wanted to verify my understanding.

My question about "won't App also go into Slot1" I did some experimenting with today. I believe the answer is yes...I take a small cellular sample application, at_client, and using old Partition Manager (like in v3.2.1), I modify the build by adding an sysbuild.conf containing SB_CONFIG_SECURE_BOOT_APPCORE=y. As far as I can see, the build is generating code for s0 and s1. (A bit complicated and lots of hex files since I am building for the non-secure target nrf9160dk/nrf9160/ns.) With the help of AI that eventually gave me some good information, I finally understand why the code has to be built twice: otherwise you'd need Position Independent Code and that would not be easy (I suppose it is close to impossible, in practice). Of course, I had to use Partition Manager to have luck with NSIB but no MCUBOOT. I'm just trying to understand the possibilities rather than looking at only the best engineering cases.

Simon wrote: "Here, do you refer to the problem of using NSIB as a single stage bootloader with DFU?"
No, I meant to ask (and it's probably obvious): the reason I cannot use NSIB without MCUBOOT in the new device tree methodology is not simply that the needed files are not spelled out in nrf/dts/samples/cellular but that it can't be done without additional engineering to the scripts. It's just a "theoretical" question: at this point I am happy to accept that in the new world we only use NSIB when using MCUBOOT.

I will switch to nrfutil from nrfjprog. AI so often gives us old style! It's great to hear that west will get improvements. That's the most important thing at this point.

Thanks so much, Simon.

Burt