Firmware design points

Where?

Loader will create a firmware_path env var. This sill be created the same as module_path and will nomonially default to /boot/kernel/firmware;/boot/firmware based on where the loader is snagging the kernel from.

Some firmware is tightly coupled to the driver. It will remain in the kernel build process, and install into $KODIR/firmware (/boot/kernel/firmware by default).

Some firmware is loosely couple to the driver where the driver version generally doesn't matter. This firmware will go into /boot/firmware. This firmware will be moved into the buildworld side of the house, or out to ports. The packages from these ports should be in the install media if the device is a network or storage driver (or some other driver needed to install the system).

Firmware that's part of the world build will live in share/firmware and will install to /boot/firmware or subdirectories of that. There's some firmware shared between multiple drivers, and that will wind up here (or as a pkg). Having it here would allow for pkgbase to slice and dice small. Some firmware will wind up in subdirectories, since that's how other OSes do it.

Changes

Warner's current firmware changes for loading binary firmware need the following changes for this:

  • Add a path to iterate over
  • Change from 'native' to 'binary' in docs.

The kernel needs to have:

  • Each driver that loads firmware audited
  • Single firmware drivers (or drivers that package firmware to load singly) should move to the new scheme.
  • Drivers that expect to load everything and then pick and choose will need some care.
  • Firmware building of kernel modules needs support for the new scheme.
  • Need to define FWDIR in the build as the location for firmware to install to.
    • FWDIR would either be /boot/firmware (standalone) or $KODIR/firmware (installkernel)
  • Need an easy way to install to a subdir too, maybe FWSUBDIR that's the path relative to FWDIR.

Open Questions

  • firmware versions
    • usually embedded in filename or in firmware-specific data in the binary
    • is our current version number in firmware(9) useful? should it just be deprecated? (do any drivers use it today?)
    • How do we deal with drivers that have version dependency and use that to load different firmware versions? Or is that just part of the general firmware_get imagename and it isn't handled by outside-the-driver machinery?
  • kernel world separation
    • installworld w/o a installkernel might create cross-threading of kernel driver vs required firmware. Need to understand the parameters of this issue better.
Select a repo