You're not going to find them with lsof because they are not open file handles (they are in memory, with the driver)
There is no need for me to keep thousands of files and hundreds of megabytes of firmware blobs when I only use a few. Moreover, I'm not using the distro packages for those, as I'm chasing DCMUB firmware updates ("Display Core Microcontroller Unit B" a.k.a "DMUB" in kernel). THAT is what fucks up when I use display power management in a window manager with no compositor these days. Ever since I went to UEFI and enabled Resizable BAR for my graphics card, I noticed sync issues but that PM thing started a few months ago. It's avoidable (use a compositor or don't use DPMS) but I'm looking to get that fixed. Also. I'm going back to Mesa/Main (24.3.0-devel it will be versioned) for some new Vulkan video work that needs new VCN firmware.
Distros help with this now by compressing them with xz or zstd, but now it's a zillion individually compressed files. Other distros (e.g. Debian I think) only install firmware for specific drivers. I guess it would take cues from udev in some way. I don't like that approach.
So today, after grabbing the latest firmware blobs from git (noting DCMUB updates 45 hours ago), I decide to find out exactly what firmware blobs are needed on this rig. I had that on the old system, but haven't gotten around to it yet. The only real way I can think of is to remove them and reboot to see what complains. Don't try that with video card firmware (pretty easy to know what directory to keep) or you'll be fucked at driver loading/modeswitching time and don't try that with some SCSI/RAID controller that uses firmware or something (if you have anything like that), but everything else you should be able to let complain in dmesg.
OK, I know I need /lib/firmware/amdgpu (actually that'd be a symlink to /usr/lib/firmware nowadays with usrmerge distros... that's probably everything but Slackware now). Within that I know I need the navi* files, but not which ones. Some of my card's architecture is "NAVI31" and "NAVI32" but that's supported by navi-12 or navi-14 firmware, I'm not sure which. There is also other supporting firmware blobs in there (common) to figure out. It's not worth worrying about, so for now I'm just going to leave all of amdgpu. It will make upgrading much easier if I just copy the amdgpu and rtl_nic directories and the files will be trivial.
That brings me to my next point. My onboard RealTek NIC again loads a firmware blob on this system. I was hoping a newer model didn't but it does still load 8125b firmware. Since I build my NIC right in the kernel, I also want that firmware blob in there too (there's a config setting to specify firmware blobs to build in). With most hardware it's even necessary... for example if you were to build amdgpu right in, it would fail unless you also built in ALL the firmware blobs it uses. I don't, but for the simple reason that I want the video card to initialize last.
I'm not even sure what the NIC firmware does, as the NIC still works without it. I'm using it right now. Furthermore, this firmware load doesn't happen at driver initialization time, but as the interface is being brought up. This is "weird" (to me lol)
Code: Select all
[grogan@nicetry ~]$ dmesg | grep firmware
[ 0.459783] systemd[1]: Clear Stale Hibernate Storage Info was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67).
[ 0.465828] nct6683 nct6683.2592: NCT6687D EC firmware version 1.0 build 09/09/21
[ 0.579029] [drm] Loading DMUB firmware via PSP: version=0x07002A00
[ 0.579133] [drm] Found VCN firmware Version ENC: 1.22 DEC: 8 VEP: 0 Revision: 3
[ 0.579136] amdgpu 0000:03:00.0: amdgpu: Will use PSP to load VCN firmware
[ 1.570563] r8169 0000:06:00.0: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
[ 1.570565] r8169 0000:06:00.0: Unable to load firmware rtl_nic/rtl8125b-2.fw (-2)
)That nct6683 is my sensor chip, and that's just reading the firmware revision from the chip (not loading a firmware blob)
You can see that amdgpu doesn't really tell you all the firmware blobs it's using.
Anyway, there's my NIC firmware blob to include in the kernel. Note that I will still need to keep the rtl_nic/rtl8125b.fw (the rtl_nic directory) on disk as it will be used at kernel build time. So I need to keep two directories in /lib/firmware... amdgpu and rtl_nic.
Anyway, that's how to get a handle on what firmware files you're using. It also helps to look in the directories too of course. For example if I knew I was using, say, Atheros wifi, I'd find out what driver I'm using in dmesg. Say it's ath10K, then I'd know I need that firmware directory etc.