Publish firmware on Linux Vendor Firmware Service #817
Comments
So there are a few different ways for USB devices you can get a "custom" GUID. The easiest is to have a different USB PID for each language; that makes everything happen correctly with no code changes, although kinda sucks from a build-time complexity problem. I have a USB VID you can use if you want so certainly don't spend the $2000 to just get a new VID assigned -- and it has 0xfff2 PIDs remaining :) The other way is to somehow tell fwupd what language the device is in; maybe using the extended descriptor thing from Microsoft or just something custom we have to add code for. You could even stick it in the serial number string index or something. Basically; if the device can export the data we can add code to fwupd to consume it.
So
If it helps, the LVFS already supports "branches" -- e.g. on the BC57XX network cards there's an unofficial open source firmware and the nonfree broadcom one and you can "fwupdmgr swithc-branch" between them.
Ha! Got any ideas? it needs to be freely re-distributable and in the hicolor theme. More seriously, I think the bigger problem is that the firmware doesn't seem to have a runtime; that is when you plug in the soldering iron you don't see a USB device being added, you only see one when the device is in bootloader mode. This means that fwupd can't get the current firmware version without the user manually going into bootloader mode first, which kinda sucks as:
@Ralim seems to be open to the idea of a runtime interface for monitoring, and it would be trivial to implement a DFU runtime with all the required bits so that fwupd can enumerate the hardware to get the language and current firmware version and also automatically push it into bootloader mode. I think that's the prerequisite before we start talking about icons :) |
I don't think it's |
|
Ahh, it's a strange beast indeed. I've started the process with hughsie/libgusb#43 |
|
100% untested incomplete WIP branch: wip/hughsie/GD32VF103 -- I've ordered a Sipeed Longan Nano dev board and can finish off the branch when it arrives. |
|
Seems to work for me: fwupd/fwupd#2815 -- there's the slight issue that fwupd doesn't know how to flash an Intel Hex file to the DFU device, but I can work on that too. |
|
@hughsie We do also pack the |
|
Ahh, I missed that. The bin file might need fwupd work as I'm assuming the base offset is 0 rather than 0x8000000 or whatever the chip has. Got a link handy? Also, did you ponder a runtime USB interface? |
|
Ah yes the bin files are setup to be flashed at the start of flash which is indeed 0x8000000. As an example, any pinecil.zip from the actions tab will work or this release https://github.com/Ralim/IronOS/releases/download/v2.14.1/Pinecil.zip Heh, yeah have been thinking about adding a usb mode. At the least even just all of the descriptors would be useful for this. Just haven't sat down to code it yet sadly 😅 |
|
I see support is now merged in the latest fwupd-release now! That is great! Does that mean it is nearing completion? Or is there still outstanding work to be done on the Pinecil side of things? |
Without a USB mode, how would fwupd identify the Pinecil? I don't think we can just use the GD32 DFU VID/PID pair. The Pinecil is not the only thing that uses the GD32VF103 MCU and we wouldn't want to accidentally flash IronOS to some other devices. |
We need a USB runtime interface, even if it's just the interface with some revision number and a VID PID. fwupd is smart enough to know that Pinecil -> generic DFU bootloader = "Pinecil in bootloader mode", although without the runtime with unique VIDPID you're correct in that we can't do anything correctly. |
I tried to flash the UK Pinecil firmware to the GD32VF103 I have in the Sipeed Longan Nano but that seems to have |
|
@hughsie |
Install libgusb fwupd from git master (or the F33 packages from https://people.freedesktop.org/~hughsient/fedora/ -- both fwupd and libgusb) and then |
|
ChipID seems for the Pinecil seems to be Full log |
|
@t-8ch does fwupd/fwupd#2952 fix things? I'm away from my lab today so I can actually test until Monday. |
|
Ah you are correct in the different flash sizes; though the fitness can be flashed to either as it fits; just that I'm not certain what would happen when it tries to save settings as these are located at the end of flash |
|
@hughsie Now it looks different, but still 0603. Full log |
Ya, as it should; I misunderstood the original quirk purpose. I've fixed up the branch and just flashed successfully Pinecil_UK.bin to the development board. It did not, however, magically turn into a soldering iron. Once @Ralim adds a DFU runtime (or rather, any USB runtime really, but a DFU runtime would make things "just work") I think we could actually upload firmware to the LVFS. |
|
@Ralim |
|
@t-8ch Sorta thinking could just implement a CDC or something while at it but unsure what is most useful long term as well. Totally open to ideas here :) |
Certainly if you implement a DFU runtime interface then it's easy for fwupd to put the device into bootloader mode without asking the user to reinsert without pressing a button -- i.e. it goes from "urgh" to "just works". Would there be a different USB PID for each language? Or perhaps a different USB REV? Either works for fwupd, we just need to know the language from the descriptor so we can download (from the LVFS) and then write the correct .bin file to the device. |
|
I don't like the idea of using different PIDs for different languages. That means assigning a new PID every time a new language is added and having to keep a mapping between PID and language. Wouldn't it be more flexible to provide some mechanism (e.g. HID reports but I don't know what's the best way) for the host software to query the current version and language? I think once such feature is added, it may also be utilized by the official Pinecil firmware updater tool to make the manual update process more user-friendly. CC @gamelaster |
|
@alvinhochun as I said, if there will be higher demand of Linux version, it's not problem to create it. Although, I'm bit worried about packaging, since it's best to ship the app with custom dfu-util. I will think about this and try to port it over Linux. |
No, I was mainly referring to the use on Windows and macOS. While this issue is mostly focused on LVFS, the addition of a runtime interface may also allow the updater to automatically detect firmware version and flash the updated firmware without requiring the user to manually enter DFU mode by holding the "-" button. |
If different PIDs are not going to fly (to me a product in a different language is a different thing, but that's juts me...) then you could use a different REV for the languages. e.g. REV=0 for en, 1=fr, 2=de etc. If you did either REV or PID then there are no code changes required. If you do want a custom HID interface with some sort of command set to:
then it would also be quite simple to support, something like https://github.com/fwupd/fwupd/blob/master/plugins/system76-launch/fu-system76-launch-device.c would be fine. The other thing to consider is just adding the language in a string descriptor. e.g. in the serial, product, or a custom index. Then fwupd (or the windows updater) can just read that without claiming any interface. |
|
My vote for language would to put its name in a string in the descriptor as that also removes the requirement to have a number <-> name lookup and instead we can just place it into the USB descriptions somewhere. |
Works for me; it would be a few lines in fwupd to parse that and add an extra GUID. |
Ah sorry, yeah, this is interesting idea and if this whole feature will be implemented into IronOS and LVFS, I guess it can be implemented into the app. |
The Linux Foundation operates a online repository of device firmware (the Linux Vendor Firmware Service, LVFS) at https://fwupd.org/ .
This repository is currently consumed by the fwupd tool on Linux which provides a easy one-click update-experience to update device firmware.
It would be great if IronOS could be uploaded there and be at least published as the default firmware for the Pinecil.
As fwupd already supports the USB DFU protocol that part should be reasonably straight forward.
Some context: https://twitter.com/dal000/status/1344630316015755265
The following open points I see:
@Ralim is this something you would want to have?
@hughsie As maintainer of fuwpd and LVFS what is your take on this?
Relevant issue for Pine64s official firmware updater: pine64/pine64_updater#1
The text was updated successfully, but these errors were encountered: