31 lines
1.5 KiB
ReStructuredText
31 lines
1.5 KiB
ReStructuredText
|
========================
|
||
|
|
Direct filesystem lookup
|
||
|
|
========================
|
||
|
|
|
||
|
|
Direct filesystem lookup is the most common form of firmware lookup performed
|
||
|
|
by the kernel. The kernel looks for the firmware directly on the root
|
||
|
|
filesystem in the paths documented in the section 'Firmware search paths'.
|
||
|
|
The filesystem lookup is implemented in fw_get_filesystem_firmware(), it
|
||
|
|
uses common core kernel file loader facility kernel_read_file_from_path().
|
||
|
|
The max path allowed is PATH_MAX -- currently this is 4096 characters.
|
||
|
|
|
||
|
|
It is recommended you keep /lib/firmware paths on your root filesystem,
|
||
|
|
avoid having a separate partition for them in order to avoid possible
|
||
|
|
races with lookups and avoid uses of the custom fallback mechanisms
|
||
|
|
documented below.
|
||
|
|
|
||
|
|
Firmware and initramfs
|
||
|
|
----------------------
|
||
|
|
|
||
|
|
Drivers which are built-in to the kernel should have the firmware integrated
|
||
|
|
also as part of the initramfs used to boot the kernel given that otherwise
|
||
|
|
a race is possible with loading the driver and the real rootfs not yet being
|
||
|
|
available. Stuffing the firmware into initramfs resolves this race issue,
|
||
|
|
however note that using initrd does not suffice to address the same race.
|
||
|
|
|
||
|
|
There are circumstances that justify not wanting to include firmware into
|
||
|
|
initramfs, such as dealing with large firmware firmware files for the
|
||
|
|
remote-proc subsystem. For such cases using a userspace fallback mechanism
|
||
|
|
is currently the only viable solution as only userspace can know for sure
|
||
|
|
when the real rootfs is ready and mounted.
|