Update via fwupd

[pentamassiv]

Verification

• I searched for similar feature request and found none was relevant.

Pitch us your idea!

companion apps (for Linux) don't need to all implement the update mechanism

Description

Many users probably already have fwupd installed and update firmware for their computer with it. The modem on the Pinephone for example can be updated with it. It would be nice if I could update all firmware from a central place. Companion apps on Linux could get rid of the code to update the Pinetime. The releases would be hosted on LVS and there are additional checks that fwupd does such as disable firmware versions if the install failed for too many users or ensuring the device is not running only on battery. Additionally there are UIs for it already.

[JF002]

This is an idea I have in the back of my mind for a while, but I have not yet taken the time to learn how fwupd works and what it would take to add support for the pinetime.

[DylanVanAssche]

@JF002 I do have the experience with fwupd etc.
Does InfiniTime use a standardized update protocol? I'm not familiar with that part to be honest.

In general you need:

• A way to get the current version of the firmware
• A plugin implementing the upgrade protocol you have for your firmware/device

There's a BlueZ BLE test and backend in fwupd, but no plugins yet that actually make use of it.

[JF002]

Hi @DylanVanAssche ! You worked on the support for the Pinephone modem in fwupd, right? Amazing work!

I don't think the BLE spec defines any standard protocol for OTA. InfiniTime implements the DFU (legacy) protocol (here and here).

InfiniTime exposes the version of the firmware via the DeviceInformation Service.

The protocol has already been implemented in multiple companion apps (Siglo, ITD, Amazfish, Gadgetbridge,..), and in multiples languages (C, Python, Go,..). These implementation could be use as examples for the plugin in fwupd. In which languages should those plugins be written?

[DylanVanAssche]

Yes :) I also work on Tow-Boot support and for Android devices as well :)

I don't think the BLE spec defines any standard protocol for OTA. InfiniTime implements the DFU (legacy) protocol (here and here).

DFU? There's already a plugin for that!

https://github.com/fwupd/fwupd/tree/main/plugins/dfu

InfiniTime exposes the version of the firmware via the DeviceInformation Service.

The plugin will need to subclass probably the DFU plugin, add a method to get that info from the watch to make fwupd aware of the watch, disable upgrades when battery power is low, expose version information.

The protocol has already been implemented in multiple companion apps (Siglo, ITD, Amazfish, Gadgetbridge,..), and in multiples languages (C, Python, Go,..). These implementation could be use as examples for the plugin in fwupd. In which languages should those plugins be written?

Exactly! But it is pretty well documented it seems, awesome!
Plugins are written in GLib C.
I use my InfiniTime as daily driver and it is so awesome, but messing with the firmware updates is hard for a sealed one ;P I pretty rely on it.

[Avamander]

DFU? There's already a plugin for that!
https://github.com/fwupd/fwupd/tree/main/plugins/dfu

That is USB Device Firmware Update. InfiniTime provides Nordic Semiconductor's OTA DFU (legacy) service.

I think this sounds relatively out of scope for fwupd and we do have at least four implementations that should work on desktop Linux. I'm closing this for now as it does not sound like a thing InfiniTime (or its team) will take on any time soon.

[DylanVanAssche]

Just my 2 cents :)

I think this sounds relatively out of scope for fwupd

Well, this kind of stuff is what fwupd does... It focus on firmware updates for internal devices but also devices connected over USB or Bluetooth. Having a fwupd plugin will make firmware updates work out-of-the-box on any Linux distro, without having to install any app. This would also allow to remove all update implementations from the apps so they can focus on what they do well: notifications, step counter, heartbeat, etc. Moreover, users have more trust into updates as Infinitime devs only have the power to upload releases to the LVFS (repo of firmware used by fwupd).

Example: UPower already displays the Infinitime battery level in GNOME Settings for example. UPower handles all kinds of batteries, fwupd handles all kinds of firmware upgrades on Linux.

I'm closing this for now as it does not sound like a thing InfiniTime (or its team) will take on any time soon.

If Infinitime devs want to generate CAB files (archives with the firmware binary to flash and some metainfo), it should be doable to have a plugin in fwupd. Building the firmware etc. is not something I am familiar with, but I can help with the other stuff (CAB files, plugin, etc.).

[Avamander]

This would also allow to remove all update implementations from the apps so they can focus on what they do well

Someone would have to focus on implementing Nordic's protocol and its maintenance.

Moreover, users have more trust into updates as Infinitime devs only have the power to upload releases to the LVFS (repo of firmware used by fwupd).

Same with GitHub's releases, really.

Building the firmware etc. is not something I am familiar with, but I can help with the other stuff (CAB files, plugin, etc.).

There are prebuilt binaries on the release page, as a PoC those could be used.

[JF002]

To the point of view of InfiniTime, fwupd is "just another companion app". But in my opinion, fwupd is a great tool that helps with upgrading firmware of many devices, and I think adding the support for the PineTime and InfiniTime would be a great addition for both projects and the end users.
It's also true that I'm not sure if anyone in the core developer team is planning to work on this in the near future... BUT, I would definitely try to help any contributor willing to do it.

@DylanVanAssche Would you like to take up the challenge? What's currently missing in InfiniTime to make it possible? Do you have any info about the CAB file format? Is this something we could easily generate at build time together with other build artifacts (firmware image, DFU, resources,...) ?

[DylanVanAssche]

It's also true that I'm not sure if anyone in the core developer team is planning to work on this in the near future... BUT, I would definitely try to help any contributor willing to do it.

Well, support for fwupd needs some kind of support from Infinitime people to package the release as a CAB file and upload it to LVFS as LVFS wants 'vendors' to upload the firmware themselves (preferably). postmarketOS has now an OEM account which can assist with all of this, I'm part of the postmarketOS account as well

@DylanVanAssche Would you like to take up the challenge? What's currently missing in InfiniTime to make it possible? Do you have any info about the CAB file format? Is this something we could easily generate at build time together with other build artifacts (firmware image, DFU, resources,...) ?

I cannot make any promises on this, but it should be doable since the upgrade process is nicely documented. I have the experience to make such plugins and I may have been experimenting already a bit ;)

I'm wondering though how updates to bootloaders, etc. are handled instead of Infinitime itself. In the last releases I only downloaded a ZIP, opened it with Gadgetbridge and flashed it. However, that one does not have bootloaders I think? In the early releases I saw that bootloaders, etc. are separate firmwares to flash?

My question: Can we bundle this in 1 ZIP to flash and do it all at once before rebooting or do these things really need to flashed separately with each time a reboot?

[JF002]

Well, support for fwupd needs some kind of support from Infinitime people to package the release as a CAB file and upload it to LVFS as LVFS wants 'vendors' to upload the firmware themselves (preferably).

Yes, that seems quite reasonable, and that's probably something we can add to our release workflow!

I'm wondering though how updates to bootloaders, etc. are handled instead of Infinitime itself. In the last releases I only downloaded a ZIP, opened it with Gadgetbridge and flashed it. However, that one does not have bootloaders I think? In the early releases I saw that bootloaders, etc. are separate firmwares to flash?

Firmware update and bootloader update are effectively 2 differents things.

• The firmware update is a routine operation that users are expected to execute "often" (at least once for each new release). We implemented this operation with multiple safety feature to ensure that users won't unintentionally brick their device during the update process
• The bootloader is a lot more risky as there's no fallback possible : if anything goes wrong and the bootloader is wiped or partially updated, the watch won't be able to boot anymore (and you'll have to open it and use a SWD probe to reflash it). We needed to update the bootloader only once since Pine64 is shipping InfiniTime on the PineTime, and we do not plan to do any change to the bootloader unless strictly necessary. The update process of the bootloader consists in building a separate firmware that embeds the new bootloader together with the code necessary to boot the watch, display a basic UI and overwrite the bootloader. Bootloader update are so rare that I'm not sure if we should try to automate it (at least in the beginning).

Starting from InfiniTime 1.11 (next release), we'll introduce the external resources : image and fonts stored in the SPI flash of the PineTime. Resources are packaged into a separate file and must be flashed separately from the firmware. Companion apps can update both in a row without any user interaction.

I'll re-open this issue to track the work done on this topic and to discuss how the firmware should be packaged and deployed for fwupd.

[JF002]

@lman0 Let's try to keep this discussion focused on fwupd. Please ask this question on this post.