A while ago I got myself an 8bitdo-nes30-controller. I was about to upgrade my controller to a recent firmware version, because the firmware versions >=4.00 offered much better stability on the wireless layer. Unfortunately the lvfs-firmware-updater fwupdmgr did not let me patch fe066b57c69265f4cce8a999a5f8ab90d1c13b24-8Bitdo-SFC30_NES30_SFC30_SNES30-4.01.cab from https://fwupd.org/lvfs/component/289/all (old link. New firmware is available under https://fwupd.org/lvfs/devices/com.8bitdo.nes30.firmware) to it, because of firmware is not for this hw:

Anyhow, i decided to take the risk to flash the default-firmware for this controller, even if it says, it is not supported, because I suspected, that 8bitdo just keeps using the available Controllers, and was kinda sure, they just don’t documented all of the used IDs, so I digged into the cab-file to make this update work for me (Spoiler: The firmware works just fine).

Prerequisities

First of all: get the new Firmware, create a folder and extract the firmware to there. On Ubuntu, you additionally need the tools cabextract and lcab to handle cabinet-files:

After that, edit the defining XML-file nes30.metainfo.xml and add or replace your device-id inside of <provides>, so that it looks like this:

The USB-V(endor)ID and the Device ID can differ from mine, but can be easily determined. fwupdmgr told us already in the first try which ID it expects, and the VID can be found with dmesg. Don’t let yourself be fooled, the 8bitdo-Controllers are reporting different VIDs and USB-IDs, dependant on if they have been booted in normal mode or in firmware-flash mode (see attached logs). But the VID is not important here anyways.

Now that we have edited the xml, we can pack the archive together again and verify (especially verify that the folder structure matches the original cab-file!).

Flashing

Now that we have our new cab-file to feed fwupdmgr with, we can put our controller into flashmode as the Firmware suggests („Unplug the controller, hold down L+R+START for 3 seconds until both LEDs are flashing then reconnect the controller.“) and give it a try:

Very likely you will get this g_atomic_int_get error. This is normal, because after the update the controller boots in normal mode instead of flashmode, and thus, from the perspective of fwupdmgr, it does not came back after flashing, resulting in this error, but the controller is just fine. You can verify this with fwupdmgr:

i needed the –allow-older option because the updater complained about
version-handling-flaws between „.“ and „,“  (which is really annoying):

This is not a localization issue, because the firmware-version is read from the device, and this is how it reports it (and calling fwupdmgr with „LANG=c“ or something would not make a difference here). After the first Update this should be fixed anyways for further ones.

Installing .dat files

Additionally to the method descibed above, you also have the possibillity to flash firmware-files directly onto a device, if you know what you are doing. In my case I flashed my 8bitdo NES-Retroreceivers (wireless dongles, which plug into the controller port of a good old NES, representing the counterpart of the controllers).

I had to flash those, because i was about to use a DIY-Module from 8bitdo (new PCB, which goes into an original controller-case, staying with the original haptic feedback). The Retroreceivers support them only upwards a specific firmware-version, so I had to patch these, and – at the time – there have been no lvfs cabinet-files for them. I downloaded a firmware from the vendor-website and used the fwupdtool:

If you are willing to take the risk, you are greeted by the new version. All in all this topic is not a big deal at all, because it happend to me that i accidentally flashed a retroreceiver firmware to a controller (or vice versa? did not remember…); and this happend to me using the vendors windows-gui-tool, so there is no protection against flashing the wrong image whatsoever. But even with the wrong firmware, the devices were able to enter the flashmode again, and a second try has baked the proper firmware to it.

Other 8bitdo Controllers

Nevertheless you should keep you eyes open for the correct files, because it also happend to me, that while flashing 2 controllers for the Sega Mega Drive (or Genesis or however you call this in your region) i bricked a device, because there was no way to determine if one should use the „V1“ or the „V2“ firmware for the controllers (and i still don’t know). Even thou it is easier for the 2.4gHz-Controllers for the Mega Drive to be flashed (they act as a mass-storage device, on which you put the file onto), they are also easier to brick, because after putting a file onto them, they will flash it. If the device does not like the firmware, they’re bricked…and they will not come back to the flash mode…

Logs

If you find this useful, i added some logs, specs and details to the devices, if you can get any benefit out of it:

device informations (before upgrade):

device informations (after upgrade):

relevant dmesg tail (normal mode):

relevant dmesg tail (flash mode):

lsusb-details (flash mode):