# 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.