Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for fwupd - Linux Vendor Firmware Service #387

Open
shiftee opened this issue Apr 28, 2020 · 12 comments
Open

Support for fwupd - Linux Vendor Firmware Service #387

shiftee opened this issue Apr 28, 2020 · 12 comments

Comments

@shiftee
Copy link

shiftee commented Apr 28, 2020

Would it be possible to support firmware updates via fwupd?

fwupd is an open-source daemon for managing the installation of firmware updates on Linux-based systems: wikipedia

Support for this would provide trivial firmware updates across all Linux distros.

I am happy to help out with this if you wish.

  • Device:
    Kira - (Kono Store March 2020)
    Any other dfu updatable products would also be appreciated.

  • Firmware Origin:
    Factory supplied firmware

  • OS:
    Ubuntu 20.04

  • Version:
    bcdDevice 4.07

  • Reproduction Steps:
    N/A

  • Resulting Issue:
    See this blog post by the fwupd project maintainer:
    https://blogs.gnome.org/hughsie/2019/11/18/google-and-fwupd

@haata
Copy link
Member

haata commented Apr 28, 2020

I've had some cursory awareness of this project for a number of years now. It seems like things have started to really take off (yay!).

(don't let this wall of text discourage you, I'm genuinely interested; but this might be a bit more complicated than it first seems!)

Some good things about the current architecture

  • Uses standard dfu (even supports detach properly)
  • Most recent devices (starting with Kira and some Whitefoxes) have an official USB VID:PID. Earlier devices have a fake VID:PID for the bootloader.

Some potential issues

  • Currently, the layout (and animation) files are bundled with the firmware update. I do plan on fixing this in the future, but this may take a long time (and there are some limitations).
  • I'm working on a device that has two different firmwares using different Altsettings (standard dfu feature), is this supported?
  • The bootloader (since the K-Type in 2017) has two different modes
    • Bypass, which can flash any firmware. Requires either a keyboard shortcut be pressed or the flash button on the back of the keyboard be pressed (this is the current standard method of flashing). If firmware flashing fails for any reason (and the firmware is intact), the firmware will reset to the Secure mode bootloader.
    • Secure, which requires a one-time generated key be prepended to the firmware before loading. This key must be requested from the running firmware before switching from the firmware to the bootloader, this action requires physical interaction with the keyboard (usually a prompted keypress). The bootloader has no ability to provide this information (this is on purpose so it's not possible to flash unwarranted firmware to the device). If flashing fails, the key is invalidated and another key must be requested and prepended to the firmware; this request further physical interaction. More details are documented here: https://github.com/kiibohd/controller/tree/master/Bootloader
  • Firmware should not be upgraded automatically (under any circumstances) for a few reasons
    • Failure may temporarily brick the keyboard (if corruption occurs). Another firmware will have to be loaded.
    • Keyboard is non-functional while firmware update proceeding
    • It's possible to cancel the firmware update on some versions of the bootloader and corrupt the firmware by pressing the Esc key (updating the bootloader ranges from near-impossible to almost painless for the end-user depending on which keyboard they have; the intention is to never update the bootloader).
    • Some users have customized firmware (layouts, options, animations), these will be lost with an automatic firmware update. The standard usage of GUIDs (https://lvfs.readthedocs.io/en/latest/metainfo.html#using-guids) might not work as the vendor+product+revision are not unique to any configuration. Just to the firmware version. The revision is an incrementing number based off the commit number of the build tree.
  • Users with stock firmware might be able to have their firmwares updated automatically, but I'm not sure there is a good way of validating this, even when running from the firmware. It might be possible to "upload" the firmware (dfu terminology) to the host computer and compare with official versions. HID-IO, which is an interface I'm working on could solve this problem.

Some other questions

  • Would Input Club be considered an IHV? There are a few cases where we might be considered an ODM as well.
  • How complicated is the release process? Right now we have at least 16 different firmwares that get released per version update (and this number is growing).
  • Would the first step be requesting an account?

@shiftee
Copy link
Author

shiftee commented Apr 29, 2020

Altsettings:

Devices with multiple firmwares are supported. I'm not sure about the alt settings but it is mentioned in the code which bodes well.

Firmware is never updated automatically:

If there are updates that need applying then they are downloaded and the user is notified and the update details are shown in the specified language. The user has to explicitly agree to the firmware update action before the update is performed. Source

I'm not too sure about the rest, I would suggest you go ahead and request an account.
If you link to this issue they will hopefully provide a few answers

@haata
Copy link
Member

haata commented May 11, 2020

I've put in a request for an account.

@shiftee
Copy link
Author

shiftee commented Jun 4, 2020

Did you hear anything back?

@haata
Copy link
Member

haata commented Jun 4, 2020

I never got a reply back to the email to [email protected] (sent it on May 11th).

@shiftee
Copy link
Author

shiftee commented Jun 4, 2020

Let's try poking the bear :)
@hughsie

@hughsie
Copy link

hughsie commented Jun 5, 2020

The bear apologizes profusely. There was 3 weeks where the info@ redirect was sending emails to /dev/null, so we assassinated the sysadmin. Could you please send me the email again please and I'll get things set up for you to experiment with. Thanks!

@haata
Copy link
Member

haata commented Jun 6, 2020

Np, will send again.

@hughsie
Copy link

hughsie commented Jun 8, 2020

Urgh, on the assumption you've sent it, I've not got it. I've just tested it again, and it's broken: I've got suitably stroppy at the people responsible. Can you sent it to [email protected] please.

@haata
Copy link
Member

haata commented Jun 8, 2020

Sent to your address.

@shiftee
Copy link
Author

shiftee commented Jun 29, 2020

Just wondering if there's any update on this?

@haata
Copy link
Member

haata commented Jun 29, 2020

I got everything I needed to start work. I owe hughsie a pcb for testing, and I need to put together a basic firmware for updating. I've been a bit busy though...
I might work on this a bit this weekend as a change of pace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants