common bootloader?
#16
Most of the feedback is stuff I've mentioned before in other thread (but lets get is all in one place):

Ideally the active slot would start at 0x00001000 in order to permit SoftDevice firmware to run. This implies linking mcuboot at the end of FLASH (rather than the beginning) and providing a simple binary to load in the first 4k of FLASH. The initial version of this simple binary really can be *very* simple... just setup the vector table to point to mcuboot and jump to the mcuboot reset vector. It might eventually need a couple of extra tweaks but for early development it is all that is required.

Additionally when you talk about "support for DFU" I think there really are *two* use-cases hiding behind that:

1. An application that, when operating normally, that permits DFU by providing BLE interfaces that allow the standby slot to be modified (alongside its other duties running the watch). This is the normal case for production devices and works well when the images are reasonably well controlled (e.g. tested prior to update, etc) and where updates are secure (signed, no promiscous pairing, etc).
2. A recovery mode, triggered by some special action by the user of the device, which is used when the active application is no longer capable of booting to the point that DFU works.

In the last post you describe a recovery mode that works by swapping the active and standby apps. This assumes that the DFU definitely works in the standby app and I remain worried that that. Given the standby app in this case is a real smartwatch app that performs duties beyond offering OTA DFU there is too much risk that other changes on the system could render it inoperable (maybe it has a but where it crashes at boot when it tries to decode a corrupted or missing image from the external FLASH). It is for these reasons that I advocate implementing recovery mode as a special case that is fully independent of the active/standby swapping code.

How the recovery code works is secondary... I have proposed the recovery slot idea but what really matters is the use-case. In other words I don't think it is sufficient to rely on two closely related smartwatch images (e.g. two slightly different versions of a same zephyr app) *not* to contain the same latent bug that will brick the watch if it is ever triggered.
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye


Messages In This Thread
common bootloader? - by Jeeves - 12-05-2019, 04:36 AM
RE: common bootloader? - by lupyuen - 12-05-2019, 04:43 AM
RE: common bootloader? - by Jeeves - 12-05-2019, 05:24 AM
RE: common bootloader? - by lupyuen - 12-05-2019, 06:07 AM
RE: common bootloader? - by Jeeves - 12-05-2019, 06:17 AM
RE: common bootloader? - by Independent_Contact - 01-10-2020, 10:39 AM
RE: common bootloader? - by geoffrey.vl - 05-01-2020, 07:29 AM
RE: common bootloader? - by JF002 - 05-02-2020, 03:45 AM
RE: common bootloader? - by danielt - 05-04-2020, 03:36 AM
common bootloader? - by lupyuen - 05-02-2020, 04:17 AM
RE: common bootloader? - by geoffrey.vl - 05-02-2020, 12:51 PM
common bootloader? - by lupyuen - 05-07-2020, 09:35 AM
RE: common bootloader? - by danielt - 05-07-2020, 10:06 AM
common bootloader? - by lupyuen - 05-08-2020, 10:29 AM
common bootloader? - by lupyuen - 05-09-2020, 12:39 PM
RE: common bootloader? - by danielt - 05-11-2020, 05:34 AM

Possibly Related Threads…
Thread Author Replies Views Last Post
Lightbulb New version of MCUBoot bootloader : I need your help! JF002 15 5,610 02-01-2021, 01:50 PM
Last Post: VMMainFrame
Information PineTime Updater for Flashing New Bootloader and FreeRTOS Firmware lupyuen 2 1,923 07-31-2020, 05:10 PM
Last Post: lupyuen
  MCUBoot Bootloader for PineTime lupyuen 2 2,069 05-18-2020, 04:23 PM
Last Post: lupyuen
  wasp-bootloader: a robust SoftDevice bootloader for PineTime danielt 3 2,547 04-14-2020, 05:31 AM
Last Post: danielt

Forum Jump:


Users browsing this thread: 1 Guest(s)