Understanding the S0 vs S1 MCUBoot images and slots

RE: Understanding the S0 vs S1 MCUBoot images and slots

Dax-id — Thu, 04 Jul 2024 08:30:06 GMT

I can convert it to public. I didn't know how far I needed to go into details, but nothing confidential was shared.

RE: Understanding the S0 vs S1 MCUBoot images and slots

Dax-id — Thu, 04 Jul 2024 08:28:46 GMT

Thanks for these additional details.

In our setup, we really need the upgrade to come from the SD-Card, so I'm thinking placing the upgrade code in the application is the way to go, while keeping a safety-net by enabling Serial recovery in the SBL.

We are still discussing with our client to know if an upgradable SBL is really needed or not in the project.

Concerning the sending s0 image while SBL runs from s0, I still don't fully understand why it won't work if I changed the SBL that I'm sending. In my tests, I changed both a log print in MCUBoot as well as incrementing the FW_INFO_FIRMWARE_VERSION config. Is it because it then has nothing to compare to validate that the image has changed?

Best regards

David TRUAN

RE: Understanding the S0 vs S1 MCUBoot images and slots

AHaug — Thu, 04 Jul 2024 08:18:26 GMT

Oh and by the way, I just noticed this was a private case. FYI in the future this is a typical case that would've benefited from being a public case since it's a question that many other developers are asking as well :)

Nothing wrong with creating a private case, specially as your first one, but private cases are typically meant for cases where you share sensitive information with us w.r.t debugging and development

Kind regards,
Andreas

RE: Understanding the S0 vs S1 MCUBoot images and slots

AHaug — Thu, 04 Jul 2024 08:15:34 GMT

Hi,

Glad to hear that it was helpful!

I believe that the answer to your follow up question is answered by the DFU/FOTA lesson on our academy pages https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/, but I don't remember the contents from cover to cover, so I'll chime in with some additional comments as well:

[quote user="Dax-id"]

Have the upgrade code residing in the Application code, which would run only once per boot when the app is booted.
Have the upgrade code residing in the second stage bootloader (MCUBoot), also ran only once per boot. Is it even possible to "add" some processing to MCUBoot without modifying the SDK to much? I read about the MCUBoot hooks and will have to dig a bit here, but is it planned to do such operations here?

[/quote]

My assumption is that here you refer to the "upgrade code" as either the code to initiate DFU and perform it or "the new update image". I'm going to assume it is the first one, so correct me if I'm wrong and I'll explain for the other case as well

This is explained in https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/topic/device-firmware-update-dfu-essentials/ where it is stated that you can choose either to have the upgrade code initiating the update in the bootloader or in the application. In either case you will have to have some sort of way to enter the bootloader mode, for instance with a button press, power cycle where you hold a button for certain seconds when you power on or through a BLE SMP server initiating the DFU mode.

I think for now the course I linked is the best entry point since it has explanations, graphics crosslinks to our official documentation as well as hands on exercises for you to have a look at that are more minimal than the samples in the SDK which supports DFU

[quote user=""]Why nothing happens when sending s0 image when the device currently uses s0 as the bootloader slot?[/quote]

I also noticed this question in your description. This is implied in my previous description but I'll state it explicetly as well: An new image will not be "accepted" as a new image by the bootloader to run from/swap into, both for the case of application image and second stage bootloader image, unless there has been made changes to the firmware (it can be as little as a log/print statement modification or simply changing the fw version number) due to a checksum comparison.

Let me know if this answers your questions

Kind regards,
Andreas

RE: Understanding the S0 vs S1 MCUBoot images and slots

Dax-id — Thu, 04 Jul 2024 05:46:30 GMT

Hi Andrea,

Thanks a lot for these explanations!

It is now much clearer. I also had a better look at the source code and the FOTA example. I copied the read_s0_active() function to check which one is currently in use and I'll always store both s0 and s1 variants in the upgrade package, which will then be chosen depending on read_s0_active().

Now I have another question related:

For the upgrade solution we're building, what is the nRF/Zephyr planned way to do so?

Have the upgrade code residing in the Application code, which would run only once per boot when the app is booted.
Have the upgrade code residing in the second stage bootloader (MCUBoot), also ran only once per boot. Is it even possible to "add" some processing to MCUBoot without modifying the SDK to much? I read about the MCUBoot hooks and will have to dig a bit here, but is it planned to do such operations here?

Again thanks for your time and clear answer!

Best regards,

David TRUAN

RE: Understanding the S0 vs S1 MCUBoot images and slots

AHaug — Wed, 03 Jul 2024 13:58:30 GMT

Hi,

The short, but hopefully good enough answer, to the questions is that it acts similarly to Direct XiP DFU, i.e that there are no swapping of the image between the slot where the existing image resides and the new update image resides. The architecture with s0 and s1 slots, which you've probably seen already, is illustrated in https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/bootloader/README.html#flash_memory_layout

NSIB, the first stage bootloader, checks s0 and s1 for any second stage bootloader image present. If there is an image present in both of these slot, it will check the version number on these two images and then select the slot with the highest/newest revision number.

This is somewhat elaborated on here https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/config_and_build/bootloaders/bootloader.html#immutable-bootloader

For your first iteration of firmware you will typically have a second stage bootloader present in S0. When you then need to update your second stage bootloader you would upload the new mcuboot image that is built for S1 and upload it to S1. Since this image has a newer version than the old one, NSIB will then select to boot MCUboot from S1 instead of S0.

The reason for this is because of how NSIB is implemented w.r.t revert and fallback protection AFAIK to better protect the device from downgrade attacks.

This link should also give a pointer to what the various build output files are (including the s0/s1 variants) https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/config_and_build/configuring_app/output_build_files.html

Let me know if this short answer answers your question and/or if you have any additional followups/things I've explained poorly.

Kind regards,
Andreas