Firmware Loader and Application availability

[Ramakrishnan]

Hi,

We are exploring using the Firmware Loader to do the OTA for our firmware.  As per what I understand from the documentation,  the Firmware Loader application will be booted up mcuboot on the following cases

1. GPIO assertion

2. Retention memory setting 

3. SMP manager initiated boot cmd 

We don't have any GPIO left in our final product that can be used for this purpose so we are left with using 2 or 3.  

My question is it looks like the application must be up and running in order for it to setup mcuboot to load up the firmware loader on reboot.  If my application for whatsoever reason crashes or fails to bootup ( due to a bug for ex which causes a sigsegv ) , there is no way for the firmware loader to get booted up and provide an option to do DFU . 

Is this understanding correct ? If yes, are there any other suggestion design patterns to mitigate this issue of application unavailability for DFU ?

Our primary concern is a bad application DFU bricking the board . Our current plan is to use test mode with mcuboot swap-move algorithm, and then confirm once app is good. That way at least we have a window to test.   But I was interested in firmware loader + single slot because it could save us a good amount of flash space.

Thanks

Ramakrishnan.

[Vidar Berg]

Hello,

It is also possible to have MCUboot enter the firmware loader after a pin reset by enabling CONFIG_BOOT_FIRMWARE_LOADER_PIN_RESET setting, if that helps. Another option you may consider is changing the boot mode through the retention subsystem after a fatal error by overriding the fatal error handler, which is declared as __WEAK. This should help mitigate the risk of a non-functional application causing the device to become bricked.

Best regards,

Vidar

[Ramakrishnan]

Thanks for the prompt response and those options.  They look promising. Will investigate those.

As a follow up, if we choose single slot DFU with firmware loader, is it also possible to have an upgradeable mcuboot ? 

Currently we have B0 + mcuboot ( s0 and s1 )  + application  ( primary and secondary ) partitions and with swap-move algorithm.  We are doing mcuboot upgrade by following same DFU procedure as that of the application and internally mcuboot takes care of identifying the image in secondary slot to be an mcuboot image and does what is needed.

Is it possible to realize the same 2 stage bootloader with an upgradeable mcuboot with single slot DFU + firmware loader ?

[Vidar Berg]

Supporting this configuration will likely require some modifications to the bootloader logic. I do not see any samples or tests that cover this configuration. If reducing the memory footprint is the main concern, I would suggest using MCUboot as a minimal immutable bootloader and instead considering support for updating the firmware loader. 

https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding_sysbuild.html#update-of-the-firmware-loader-image 

[Ramakrishnan]

Okay.  Thanks for the clarification. 

From security standpoint, there are concerns with mcuboot not being upgradeable as it looks like there were some CVEs against mcuboot. So not sure about taking that route.  

[Vidar Berg]

Yes, I don't have a right answer to give here other than that there are tradeoffs to be made. A minimal immutable bootloader should have a limited attack surface, and for any vulnerabilities uncovered in the future, I imagine it may be possible to apply mitigations for them in the firmware loader (depending on what the vulnerability is).

[Ramakrishnan]

Agree. Its a question of which trade off to make.  We are also evaluating if the application image has to be encrypted which necessitates mcuboot. 

I think we can close this thread for now.  I'll do some experimentation and come back again if there are more questions.

Thanks.

[Ramakrishnan]

Just to be sure that I understand this correctly - it looks like when I use firmware loader, I can't have encrypted application image.  It looks like mcuboot conditionally compiles in either firmware_loader or the usual ones ( loader/swap_move etc ) which handles decryption. Firmware Loader doesn't seem to have support for decryption of the image - it copies whatever comes in via OTA onto slot 0.  

Ref: ncs\v3.4.0\bootloader\mcuboot\boot\zephyr\CMakeLists.txt