Re: [gentoo-user] Re: Firmware exists but fails to load
Is the firmware path set correctly in the kernel config? In Device Drivers-Generic Driver Options, set Firmware blobs root directory to /lib/firmware and build a new kernel. I have the same kernel config as my laptop which loads intel wifi firmware from /llib/firmware ok; # zgrep -i firmware /proc/config.gz CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE= # CONFIG_FIRMWARE_EDID is not set # Firmware Drivers CONFIG_FIRMWARE_MEMMAP=y # CONFIG_GOOGLE_FIRMWARE is not set Firmware blobs root directory is EXTRA_FIRMWARE_DIR which is only available once i enable EXTRA_FIRMWARE, but the help for that says; This option allows firmware to be built into the kernel, for the │ │ cases where the user either cannot or doesn't want to provide it from │ │ userspace at runtime So that's a workaround, not a fix, but it works so it'll do. Thanks.
Re: [gentoo-user] Re: Firmware exists but fails to load
It's not a workaround, but how it's supposed to work. Loading from userspace means using a user-space program to load the firmware. This is not what you're trying to do, since you don't have such a program. ? Udev has been the standard way to service kernel firmware requests for quite some time. The relevant bit is in /lib/udev/rules.d/50-firmware.rules . However, udevd is only started after the kernel is loaded, and therefore will only load firmware for drivers which are built as modules. Firmware for built-in drivers must either be compiled into the kernel or be provided in an initrd along with a suitable helper. Is there a specific reason why the r8169 driver cannot be loaded as a module? AFAIK the only case in which you *need* a built-in net driver is if you're doing root over NFS. Your other option is writing a userspace program that reads the firmware after the kernel has booted and patches it into the hardware. Patching is always done by the kernel driver. The userspace helper only has to answer kernel requests for a specific firmware by providing the correct data. But why would you want to do something like that anyway? Typical reasons are to keep the kernel image size down and to avoid having to recompile the kernel whenever a new firmware version is released. Though I'll admit that kernel releases tend to be more frequent than new firmware versions :) Just my .02€ andrea
Re: [gentoo-user] Re: Firmware exists but fails to load
? Udev has been the standard way to service kernel firmware requests for quite some time. The relevant bit is in /lib/udev/rules.d/50-firmware.rules . Ok so that must be working on my laptop (automatically, i didn't configure anything) but failing on my desktop. However, udevd is only started after the kernel is loaded, and therefore will only load firmware for drivers which are built as modules. I tried compiling as a module, and it still failed. I'll go back and verify I haven't made a mistake, then check firmware.rules. Thanks again.
Re: [gentoo-user] Re: Firmware exists but fails to load
? Udev has been the standard way to service kernel firmware requests for quite some time. The relevant bit is in /lib/udev/rules.d/50-firmware.rules . Ok so that must be working on my laptop (automatically, i didn't configure anything) but failing on my desktop. However, udevd is only started after the kernel is loaded, and therefore will only load firmware for drivers which are built as modules. I tried compiling as a module, and it still failed. I'll go back and verify I haven't made a mistake, then check firmware.rules. it does not actually matter how you configured the driver -- built-in kernel or as module: everytime when driver operates the device, it checks whether firmware is loaded. if it does not or the firmware is not preloaded at kernel build time as a blob, the driver requests for firmware. the request is a generated kernel event which is handled in userspace by udev. the udev daemon processes event using mentioned above rule. the rule is trivial -- it starts a firmware loader utility (/lib/udev/firmware) with parameters passed within the event: device name and firmware file path. appropriate status is returned back to kernel and dispatched to the driver in your case the status is -2 (ENOENT) so it could be problem with either firmware blob file or firmware loader itself. functionality of /lib/udev/firmware is controlled by USE=extras. did you installed udev with extras support? again, firmware load is udev responsibility. you may diagnose all the stuff enabling udev debug output in /etc/udev/udev.conf finally i confirm that r8169 driver works fine on my notebook with 2.6.39 kernel
