bcm5719-fw
bcm5719-fw copied to clipboard
fwupd cannot install firmware on a Talos II
Hello!
My system has an old version of this libre firmware installed a little while ago just before the first release was created and thus when fwupd support didnt exist.
I am getting these logs from fwupd:
# sudo fwupdtool install talos2-bcm5719-0.4.62.cab --allow-branch-switch
Loading… [- ]06:00:26:0262 FuEngine failed to add udev device /sys/devices/pci0004:00/0004:00:00.0/0004:01:00.0: tried to read outside of EEPROM size [0x40000]
06:00:26:0278 FuDeviceList ignoring device 0baa416819a148f8c7f8fe3ecbb37fb243a3b155 [optionrom:(null)] existing device c236922af9d2129801e8852d0e5f663bd65b63f5 [optionrom:(null)] already exists
Loading… [***************************************]
Decompressing… [***************************************]
Device NetXtreme BCM5719 Gigabit Ethernet PCIe [c236922af9d2129801e8852d0e5f663bd65b63f5] does not currently allow updates
Version:
# fwupdmgr --version
client version: 1.5.2
compile-time dependency versions
gusb: 0.3.5
daemon version: 1.5.2
And I run Fedora 33
Thank you!
It looks like this is an issue where a word that's now reserved for a version pointer was set to a value that confuses fwupd.
I'll look into options to patch fwupd to allow this to work when tested with the initial fw release, but it's not a high priority.
For now you can do one of the following:
- Using bcmflash, restore the original firmware backup
- Using bcmflash, flash a new stage1 image. This will fix the check and allow fwupd to function again.
I could not flash using fwupd after flashing the original firmware back because of another error in dmesg:
kernel:unregister_netdevice: waiting for <ifname> to become free. Usage count = <number>
fwupd hangs at some point with this error repeating in dmesg and the only solution to stop it seems to shutdown the system.
I could however update successfully when booting in rescue mode, reflashing the original firmware and running: $ fwupdtool switch-branch
I am guessing online updates are not possible for now.
Thank you.
That dmesg error is most probably a kernel bug, a reference count leak, considering the number was 60000+ when I first tried with few days of uptime.