| 1 |
> It's not a workaround, but how it's supposed to work. "Loading from |
| 2 |
> userspace" means using a user-space program to load the firmware. This |
| 3 |
> is not what you're trying to do, since you don't have such a program. |
| 4 |
|
| 5 |
? Udev has been the standard way to service kernel firmware requests for |
| 6 |
quite some time. The relevant bit is in |
| 7 |
/lib/udev/rules.d/50-firmware.rules . |
| 8 |
|
| 9 |
However, udevd is only started after the kernel is loaded, and therefore |
| 10 |
will only load firmware for drivers which are built as modules. |
| 11 |
|
| 12 |
Firmware for built-in drivers must either be compiled into the kernel or |
| 13 |
be provided in an initrd along with a suitable helper. |
| 14 |
|
| 15 |
Is there a specific reason why the r8169 driver cannot be loaded as a |
| 16 |
module? AFAIK the only case in which you *need* a built-in net driver is |
| 17 |
if you're doing root over NFS. |
| 18 |
|
| 19 |
> Your other option is writing a userspace program that reads the firmware |
| 20 |
> after the kernel has booted and patches it into the hardware. |
| 21 |
|
| 22 |
Patching is always done by the kernel driver. The userspace helper only |
| 23 |
has to answer kernel requests for a specific firmware by providing the |
| 24 |
correct data. |
| 25 |
|
| 26 |
> But why would you want to do something like that anyway? |
| 27 |
|
| 28 |
Typical reasons are to keep the kernel image size down and to avoid |
| 29 |
having to recompile the kernel whenever a new firmware version is |
| 30 |
released. Though I'll admit that kernel releases tend to be more |
| 31 |
frequent than new firmware versions :) |
| 32 |
|
| 33 |
Just my .02€ |
| 34 |
|
| 35 |
andrea |
Archives