<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Make mcuboot select recovery app</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/89634/make-mcuboot-select-recovery-app</link><description>Hello 
 We are planning to build a product without physical pins and currently evaluating different recovery options. For that we want to use OTA via BLE/SMP in a dedicated recovery app. Following this thread it is not advised to add the BLE stack to</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 15 Jul 2022 10:28:09 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/89634/make-mcuboot-select-recovery-app" /><item><title>RE: Make mcuboot select recovery app</title><link>https://devzone.nordicsemi.com/thread/377151?ContentTypeID=1</link><pubDate>Fri, 15 Jul 2022 10:28:09 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:84d7b2fa-2d94-4348-9b99-ac5364e9c8c5</guid><dc:creator>Sigurd Hellesvik</dc:creator><description>&lt;p&gt;I think that it is the information in the&lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/design.html#image-trailer"&gt; image trailer&lt;/a&gt; that chooses what mcuboot will do on next boot.&lt;/p&gt;
&lt;p&gt;These are for example changed using &lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/zephyr/services/device_mgmt/mcumgr.html"&gt;mcumgr image test&lt;/a&gt; or the &lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/nrf/libraries/bootloader/bl_validation.html#c.bl_validate_firmware"&gt;bl_validate_firmware()&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Since it is summer vacation here, we have limited staff. So for now all I can to is to point you to the docs.&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Sigurd Hellesvik&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Make mcuboot select recovery app</title><link>https://devzone.nordicsemi.com/thread/377109?ContentTypeID=1</link><pubDate>Fri, 15 Jul 2022 08:30:56 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ac055bb8-d40b-46cc-a536-c739963bee4f</guid><dc:creator>Patrick Guenzel</dc:creator><description>&lt;p&gt;The &amp;quot;rollback on recovery&amp;quot; approach is actually quiet neat. Haven&amp;#39;t thought about that yet.&lt;/p&gt;
&lt;p&gt;The second suggestion basically comes back to my initial question: How does the upgrade management inside of mcuboot work to redirect it, so that it works with a fixed and two upgradable&amp;nbsp; partitions? The recovery app would be something like a 2nd stage bootloader in this case but we don&amp;#39;t have much interest in replicating all the upgrade/rollback/verification mechanisms, that are already in mcuboot.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Make mcuboot select recovery app</title><link>https://devzone.nordicsemi.com/thread/377103?ContentTypeID=1</link><pubDate>Fri, 15 Jul 2022 08:14:07 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1012aa4b-bb2a-4c69-a84a-c0888f85977a</guid><dc:creator>Sigurd Hellesvik</dc:creator><description>&lt;p&gt;Here are some more thoughts on the issue:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Button and not recovery partition&lt;/strong&gt;&lt;br /&gt;If you already have a button on the device, would it be enough for the button press to simply roll back to the previous version of the application?&lt;br /&gt;In this case the, both the new version of the application AND the old version must be fatally broken so that both break in order for your device to be bricked. Which should be very very unlikely, right?&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Buttonless recovery partition?&lt;/strong&gt;&lt;br /&gt;However, maybe the recovery partition might make button-less FOTA recovery be possible. &lt;br /&gt;I have not tried it, but maybe it could be possible to make MCUBoot always boot into the recovery partition. &lt;br /&gt;Then the recovery partition waits a bit, and if there are no FOTA updates coming, it will boot into the main application?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Make mcuboot select recovery app</title><link>https://devzone.nordicsemi.com/thread/377093?ContentTypeID=1</link><pubDate>Fri, 15 Jul 2022 07:49:22 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:407cd164-5450-4984-9d2c-32a1b9f4c555</guid><dc:creator>Patrick Guenzel</dc:creator><description>&lt;p&gt;Hi Sigurd&lt;/p&gt;
&lt;p&gt;Yes that is exactly our scenario.&lt;/p&gt;
&lt;p&gt;We first thought about integrating the Bluetooth stack of Zephyr into the MCUBoot application itself but did not follow it because of the first linked post in my original question. In general our company is doing bootloading via RF for some years now but on a different tech and with a self-written protocol stack and a different bootloader. So our initial idea was to replicate that with MCUBoot and BLE.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Make mcuboot select recovery app</title><link>https://devzone.nordicsemi.com/thread/377088?ContentTypeID=1</link><pubDate>Fri, 15 Jul 2022 07:38:13 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:e3dfd801-b3c9-4204-8830-c821d097bf69</guid><dc:creator>Sigurd Hellesvik</dc:creator><description>&lt;p&gt;I talked to Simon about this, and we have a couple of questions to try and understand the problem you want to solve with your design:&lt;/p&gt;
&lt;p&gt;You say: &amp;quot;For that we want to use OTA via BLE/SMP in a dedicated recovery app.&amp;quot;&lt;br /&gt;Am I correct to say that this aims to protect against the following scenario?&lt;/p&gt;
&lt;p&gt;Your application runs a SMP Server. You update the application. The tests you run on your device completes without issue, so the new application is verified. Some time later, the application breaks fatally, and will not even be fixed on reboot. You can no longer update the application, since you need the application to do FOTA. And since you verified the application, MCUBoot will not roll back to the previous, working, version.&lt;br /&gt;So you hold a button on reboot to enter the recovery partition on reboot, and can now do FOTA with the recovery partition.&lt;/p&gt;
&lt;p&gt;If I am wrong, please correct me. &lt;br /&gt;Are there additional reasons for having the recovery partition?&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Sigurd Hellesvik&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Make mcuboot select recovery app</title><link>https://devzone.nordicsemi.com/thread/377027?ContentTypeID=1</link><pubDate>Thu, 14 Jul 2022 15:45:47 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:fd53bced-d32d-4d70-81d7-96df6f011994</guid><dc:creator>Sigurd Hellesvik</dc:creator><description>&lt;p&gt;Hi Patrick,&lt;/p&gt;
&lt;p&gt;I will continue on this case.&lt;/p&gt;
&lt;p&gt;I think my colleague Simon added an extra pair of slots for MCUBoot in his unofficial &lt;a href="https://github.com/simon-iversen/ncs_samples/tree/master/multi_img_dfu"&gt;multi image dfu&lt;/a&gt; sample.&lt;br /&gt;Does this look like the type of extra slots you want to add?&lt;/p&gt;
&lt;p&gt;If you want to boot into another slot on pin toggle, you probably need to fork MCUBoot and make some changes to it.&lt;br /&gt;It should not be a problem though, as this functionality is a lot less complicated than Bluetooth Low Energy.&lt;br /&gt;You could have a look at the &lt;a href="https://github.com/nrfconnect/sdk-mcuboot/blob/129b6312d61a9dc2c3b0c8810326678cdbd27b80/boot/zephyr/main.c#L506"&gt;MCUBoot main()&lt;/a&gt; to see how this is handled for Serial Recovery(which is triggered by holding a pin on reset).&lt;/p&gt;
&lt;p&gt;Execute In Place(XIP): The way MCUBoot works, is that it can swap an image from one of the slots to the primary slot, then boot from the primary slot.&lt;br /&gt;If you have the recovery partition in an extra slot, I do not think you need to do XIP, as the recovery can just be swapped to run. &lt;br /&gt;Does that make sense?&lt;/p&gt;
&lt;p&gt;-----------------------------------------------------------------------------------------&lt;/p&gt;
&lt;p&gt;For your overall plan, I think it sounds like a reasonable design. It will of course use a lot of storage space, so external flash might be needed. But I do not see any way to have recovery Firmware Over The Air(FOTA) without using the extra space.&lt;/p&gt;
&lt;p&gt;In other words, I can not think of any better solution myself.&lt;br /&gt;For a second opinion, I will ask my colleague Simon if he agrees on the solution.&lt;br /&gt;I will return here when I hear from him.&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Sigurd Hellesvik&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Make mcuboot select recovery app</title><link>https://devzone.nordicsemi.com/thread/376257?ContentTypeID=1</link><pubDate>Fri, 08 Jul 2022 14:21:28 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6c89735c-96c4-44a7-93ff-2db835318ee1</guid><dc:creator>JONATHAN LL</dc:creator><description>&lt;p&gt;&lt;span&gt;Due to summer holiday staffing is low and response time is slower than usual, pardon the inconvenience.&amp;nbsp;&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span&gt;We will get back to you as soon as we can.&amp;nbsp;&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span&gt;Regards,&lt;/span&gt;&lt;br /&gt;&lt;span&gt;Jonathan&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>