Use LVFS for distributing firmware updates?

[hughsie]

Hi,

My name is Richard Hughes and I work for Red Hat. I'm the maintainer of fwupd, an open source firmware update system designed for Linux. We're updating over 350,000 devices every month safely and securely using the Linux Vendor Firmware Service. We've had a large number of hardware vendors join this service in the last few months, including HP, Dell, Logitech and Jabra.

Using the LVFS means you're able to offer firmware updates onto thousands of devices without having to use a command line update tool. The best bit is that it's a completely free service, and I'm happy to help you as much as you need. DFU is already well supported in fwupd so I don't think there would be any code to write.

If this sounds interesting, please see https://fwupd.org/ or ask me a question here.

There's a draft technical whitepaper here if you'd like more details https://people.freedesktop.org/~hughsient/temp/LVFS_Whitepaper.pdf about how the service works. Thanks for reading!

Richard

[UweBonnes]

How do you think that some update service does fit for a device that is plugged as tool into different computers?

[hughsie]

Well, as I understood it the firmware was updatable using DFU. The idea would be that you insert the hardware into a Linux PC, it tells you have updates available, installs them for you, then you remove the device.

[dragonmux]

o/ hughsie. We had to do some research on what fwupd was and what LVFS was, and using this channel for helping people update their Black Magic Probe native hardware would be of potential interest to us. Sorry it's been 4 and a bit years since you opened this.

We do have a few questions - for example, can fwupd use product description strings to tell native hardware apart from the other platforms so we can target the update files to only native hardware? This is unfortunately important because different platforms need quite different firmware update files and the only way to tell them apart is the presence (or absence) of "()" in the product string.

As an example, BMP (native) uses the product string "Black Magic Probe v1.9.0", while an ST-Link v2 would show as "Black Magic Probe (ST-Link/v2) v1.9.0"

[hughsie]

can fwupd use product description strings to tell native hardware apart from the other platforms

Yes, we might need to add a quirk for that specific device, but we certainly have other devices that use the product string, e.g. https://fwupd.github.io/libfwupdplugin/emmc-README.html#guid-generation

[dragonmux]

👍🏼 excellent, then we'll have a talk with @esden about it and work with you to get the firmware listed as this makes a lot of sense for the typical user to ensure they get the latest release firmware if they're on old firmware

The only other thing of note is that the DFU implementation is specifically DFUse based rather than straight DFU, so needs rebooting into the firmware with the DFUse-specific -s 0x08002000:leave (as it would be given to dfu-util) - we assume that's not a problem as that's cropped up before in fwupd?

[hughsie]

specifically DFUse based rather than straight DFU

I think that should be fine; lots of STM32 devices are supported now

DFUse-specific -s 0x08002000:leave

Hmm, that's a new one; normally we do the empty payload to manifest trick, i.e. https://github.com/fwupd/fwupd/blob/main/plugins/dfu/fu-dfu-target-stm.c#L29

I'm more than happy to implement that as a quirk if needed, but I do wonder if the fwupd attach function works too. e.g. if you do fwupdtool --plugins dfu attach if that puts the device from bootloader to runtime.

[VilleWitt]

As a user, this would be a nice feature.

Just inserted 1.9 and saw there is a 2.0-rc2. fwupd would be nice for when 2.0 is official.

[esden]

v2.0.0 is already officially released. (we need to cleanup the milestones and issues) You can update your probe using bmputil.

IIRC there was some blocking problem with the deployment of the firmware into the fwupd system. I will have to check what the problem was. In the mean time please consider using bmputil.

[hughsie]

there was some blocking problem with the deployment of the firmware into the fwupd system

Anything I can help with?

[VilleWitt]

I used bmputil to get developing.

I came to the conclusion that fwupd is probably NOT the way to go for one simple reason: one has to select firmware depending on target. I had 4 options: ARM, RISC, ..., not just "the current thing". I don't see how fwupd is able to switch between "branches".

[hughsie]

I don't see how fwupd is able to switch between "branches"

It's perfectly okay to have different firmware streams for different devices -- we need a way to know the difference at enumeration time and then from that we can construct an instance ID that we use to match firmware to devices. So for instance, if the VID+PID is unique for each firmware blob kind we can use something like USB\VID_2BD9&PID_A031 as the identifier for the stream. If the VID/PID is the same for all models, then we can add an extra instance ID parameter, e.g. USB\VID_2BD9&PID_A031&CUSTOMER_12345 or USB\VID_2BD9&PID_A031&ARCH_RISC although we do then need to "teach" fwupd how to get the extra nugget of information from the device.

Note, we can also support more than one stream of firmware for the same device -- e.g. if you wanted a "release" and "testing" branch for the very same hardware. This is chosen using the UI, or using fwupdmgr switch-branch -- but again you need to teach fwupd how to know what branch you're on now. For some vendors that'll be a dumb rule (e.g. Lenovo server has a rule that if the last number of the version is odd then then it's a debug branch, otherwise release) and for others it'll be a USB request or a clue in a USB descriptor somewhere.