Linux Kernel Firmware Download
Nestor Beltran
I've been wondering how can I pick which ones I do really need. I was thinking of using every device I have in my system (even the ones I rarely use like bluetooth, ethernet, camera, touchpad, multimedia keys and so on) and look at the list of loaded firmware.
If your kernel is built with dynamic debug support (CONFIG_DYNAMIC_DEBUG), you can use a boot parameter to enable debug messages for the firmware loader. It should catch all firmware loads, unless a particular driver does something strange and does not use the kernel's firmware loading API for some reason.
(For reference, file blah/foo.c +fmp means "for all debug calls in the kernel source file blah/foo.c, enable dynamic debug printing, and make the message show the filename and module name". See the kernel docs for more detail.)
You cannot query for "currently loaded" firmware, because firmware doesn't necessarily remain in system memory. It is often uploaded to some chip in some device outside the system. Most drivers will load a firmware file into a kernel buffer, use that buffer to program the device, then discard the buffer without keeping any record of what the file was. Some drivers do log their firmware loading to the kernel log, but that is by choice of whoever wrote the driver; it's not universal.
When I was trying to figure out how to log firmware loads, my first thought was to "get between" the kernel and whatever userspace program must be responsible for grabbing firmware files. I could add some debug messages and the problem would be solved. But it turns out this is not always possible: the kernel itself is capable of getting firmware straight from the filesystem, with no userspace mechanism involved. (In fact, the kernel prefers to direct load straight from /lib/firmware/ when possible.)
The kernel's firmware loading API is generally accessed by calls to request_firmware() or request_firmware_nowait(). A driver calls one of these functions with the name of the firmware file it wants, and the kernel attempts to load it using this process:
Trying to figure out how the driver works, three words often came up: firmware, driver and kernel module. I know a bit of them: firmware usually refers to the software residing in the ROM of some hardware device; driver is the layer between the kernel and the hardware; while kernel module is a piece of kernel that can be loaded dynamically, and not necessarily related to a specific hardware device (like firmware and driver). But what confuses me is the relationship between the three concepts when dealing with hardware devices. Could anyone shed some light on this?
And another more specific question: I found a package named "rtl8192se_firmware" in AUR, and I have installed it before. But shouldn't firmware reside in the hardware? What's the "firmware software" thing, exactly?
In my mind, "Driver" and "Kernel Module" are synonymous. In reality, a Driver should probably be considered to be a Kernel Module that is directly responsible for controlling hardware. Other kernel modules provide information on how to manage file systems, encryption, loop back file systems, etc... Whereas "driver" kernel modules handle network interfaces, usb devices, keyboards, etc... These would be the special case of a kernel module called driver.
Firmware is software that is uploaded to a microprocessor or programmable logic on the hardware device itself. Examples of hardware that use firmware are HP printers that receive their code from the USB port at power up, wireless network interfaces that upload firmware at start up, routers that can update themselves from the internet, etc... In general, the ability to upload firmware to a device is a plus. it allows for product improvements to be added after the initial sale. These include fixing bugs in the product, responding to security issues, or responding to changes in the regulatory environment; Examples: FCC opening or restricting allowable bandwidths, power consumption, safety.
What about the software package rtl8192se-firmware? Does the .bin files get uploaded to my wireless card every time the system boots? That doesn't sound like the case. Firmware should be in the hardware's ROM, but this package is clearly software living on the hard drive. What's the relationship between this package and the firmware?
Firmware does not have to live in ROM. Devices can be RAM based with a small ROM based boot loader to load the firmware at start up. The device could also be FPGA based that is configured to start from a data stream that does not come from a configuration ROM
Thanks a lot for the clarification. What about the relationship between module and driver, then? Since in my case the names of the module ("r8192se_pci") and driver ("rtl819xSE") differ, I doubt whether there is a simple one-to-one relationship between modules (I'm aware that some modules don't provide drivers; I'm only talking about those that do) and drivers. Is it possible that a kernel module may provide several drivers, or several modules together provide a driver?
Good question! It appears that driver names do not have to be module names. To use my ethernet port I load the module e100 and "lspci -k" tells me that the driver in use is also called e100. But for my soundcard, the kernel module is snd-cs46xx whereas the driver in use has the pretty name "Sound Fusion CS46xx"!
I think the list of modules has nothing to do with whether they are in use. If there are several in the list, some could be modules that simply claim to have support for that hardware. For example aty128fb appears as a kernel module for my r128 graphics card, but it's not the driver in use since I'm not running a framebuffer console on it. And for some reason the DRM driver is not in that list.
As someone said, Driver is a piece of code responsoble for talking to a device. It can be either built in the kernel, or compiled as a Module and loaded at runtime, hence the difference in the name. Module name is for the kernel and it can (but doesn't have to) provide a Driver (with whatever the name).
I did not upgrade those systems at all from almost 3-4 weeks but now instead of delaying upgrade, I am planning to do a full upgrade except linux and linux-lts packages. (so as not to break my system networking)
My question is:
If I upgrade linux-firmware but not linux OR linux-lts package, will it cause any issue?
i.e. Will new linux-firmware be compatible with old linux and linux-lts package?
PS Most physical systems require some kind of firmware from that package (nearly all wifi drivers and graphics chips at least, grep your dmesg for firmware you will find quite a few loading something from there), if you only use virtualized systems you likely don't.
The kernel driver usually has definitions for the maximum versions of firmware any given module supports. These firmwares come from the linux-firmware package, and they are usually not simply replaced when new firmware becomes available, you will generally be able to keep loading older firmwares. If you want to be certain that there are no regressions then just hold back the firmware packages as well.
FWIW the "version number" of linux-firmware doesn't mean anything, that's just the date of when a packaged release was made, whether that packaged release still contains versions for your firmware the module is used to loading is up to the vendors that provide firmware. There are potentials for regressions here like with any package but usually not inherently tied to any specific version. FWIW I don't think I've ever seen firmware simply get removed without replacement, so from that aspect you should be safe.
If you just want a Yes or No answer: Yes linux-firmware is compatible with whatever kernel you install and independent of the actual kernel versions. If you want to look at this more fine grainedly, identify which firmware is actively in use and look at the linux-firmware git to see wether that specific firmware version got an update, and then decide whether that's worth the "risk"
Just an update to above post. I asked on arch general mailing list and as per "Giancarlo Razzolini" (maintainer), the new mkinitcpio will not cause any issue with old kernel. (it will simply ignore building initrd for those kernels where pkgbase file does not exist)
Contents
- A guide to the Kernel Development ProcessSubmitting patches: the essential guide to getting your code into the kernelCode of conductKernel Maintainer HandbookAll development-process docs
- Linux kernel licensing rulesHow to write kernel documentationDevelopment tools for the kernelKernel Testing GuideKernel Hacking GuidesLinux Tracing Technologiesfault-injectionKernel LivepatchingRust
- The Linux kernel user's and administrator's guideThe kernel build systemReporting issuesUser-space toolsThe Linux kernel user-space API guide
- The Linux kernel firmware guideOpen Firmware and Devicetree
- CPU Architectures
- Unsorted Documentation
- Translations
- Show Source