Closes the v4.0 plan P3 'per-vendor firmware packaging' item.
redbear-firmware (the single bundle recipe) shipped the entire
linux-firmware tarball wholesale. That works but forces every image
to drag in blobs it does not use (e.g., a serial console image pulls
amdgpu GPU firmware). The plan called for per-vendor splits mirroring
linux-firmware's per-package convention (linux-firmware-amdgpu,
linux-firmware-intel, etc.).
New recipes (all version 0.3.1, Cat 1, locally maintainable):
redbear-firmware-amdgpu - /lib/firmware/amdgpu/ + amdnpu/
redbear-firmware-intel - /lib/firmware/i915/ + intel/
redbear-firmware-iwlwifi - /lib/firmware/iwlwifi-*.{ucode,pnvm}
redbear-firmware-bluetooth - /lib/firmware/ibt-*.{sfi,ddc}
Each recipe downloads the same linux-firmware-main tarball into a
shared cookbook cache (build/redbear-firmware-cache/) and stages only
its subset, with the matching LICENSE.* and WHENCE metadata in
/lib/firmware/LICENSES/. The share cache means a single wget per
cookbook build regardless of how many per-vendor recipes are included.
redbear-firmware (the whole bundle) stays in place for legacy configs
that don't want to choose. Per-vendor recipes do not conflict with it
because the subsets are disjoint paths under /lib/firmware.
redbear-driver-policy/initfs.manifest gains a [firmware] section
documenting the per-vendor recipe -> driver mapping. driver-manager
itself does not install firmware -- configs pull the relevant
redbear-firmware-* packages via the [packages] section.
fetch-firmware.sh already supports the same per-vendor / per-subset
matrix (--vendor {amd,intel} --subset {all,rdna,dmc,wifi,bluetooth})
so the manual fetch path and the build path now agree on taxonomy.
vasilito
88ecd36e3a