New version of MCUBoot bootloader : I need your help!

[JF002]

UPDATE : I've generated 3 test firmwares to test degraded cases (invalid firmware, firmware that does not refresh the watchdog, firmware that refresh the watchdog but does not provide OTA functionality).

You can use them to test which degraded cases are handled by the bootloader and how. More info in the first post or in the release note.

[JF002]

New test release (RC3)

I've just published a new test released (RC3 because I messed up RC2) : https://github.com/JF002/pinetime-mcuboo...es/tag/RC3.

It shows a more realistic version (0.0.1) and prevent the watchdog reset during the bootloader processing.

[JF002]

The final release of this bootloader is approaching! I've just published the RC4 which will be renamed 1.0.0 if it works for everyone !

There are very few changes in this release :

• The bootloader exposes its version to the application firmware
  
• The bootloader now displays version 1.0.0.
  

Here is the release note : https://github.com/JF002/pinetime-mcuboo.../1.0.0-RC4

I've also pushed a new branch for InfiniTime : this branch generates the recovery firmware used by the bootloader to recover from non-functionning firmware. You can find it here: https://github.com/JF002/Pinetime/tree/r...y-firmware

[VMMainFrame]

I am running Pinetime 0.10 and the bootloader that shows 1.2.3.  I installed the RC4 loader and the dfu-0.11 recovery firmware.  Both seem to work fine.  The bootloader now shows 1.0.0.  I noticed three logos during this process.  The large Pinetime logo, which fills with one of three colours, a smaller Pinetime logo which fills with blue, and an Infinitime logo with a gradually increasing bar beneath.  Can you explain what the last two logos mean.

Hugh

[danielt]

The little blue pine logo sounds like the reloader application.

The reloader is an application (e.g. a payload booted by mcuboot) that will overwrite the old bootloader with a new one. Most importantly the reloader never sets the flag that tells mcuboot there is a successful boot... so after it has rewriten the bootloader and the device is rebooted then new bootloader will immediately returns favour and overwrites the reloader application and restore Infinitime.

It sounds a little complex but the main purpose of the reloader is to be all or nothing. Either we pass some checksum tests and overwrite the bootloader or we fail and don't attempt to overwrite anything at all. If is (hopefully... and assuming the battery is fully charged) very unlikely that the reloader will fail part way through and brick the watch.

PS I'm not 100% sure but I suspect the third logo is from the tool JF wrote to program the recovery slot.

[VMMainFrame]

Thanks for the information.

I also tested three of the testfw... firmware versions, the big version, the random version and the no-validate no-watchdog version.  All worked correctly, I got back to my current firmware without getting bricked.  I didn't try the remaining version since your description says it seems to brick the watch until the battery runs out.

I used Gadgetbridge (version 0.50.0) and my Pixel3A phone to do the updates.  I noticed that the Gadgetbridge firmware update page says "Pinetime firmware (unknown version)."  Later on the page it says "hardware (unknown)".  Is it possible to supply the firmware version information and which hardware the firmware is for to Gadgetbridge?  It would make last minute mistakes less likely.

When doing the OTA uploads the uploads failed several times for each testfw.  Eventually I got them loaded.  This has happened before when loading newer versions of the firmware.  Any idea what the problem is when it takes several tries to upload a new version of the firmware

Hugh