9ea749835f
* Add qcom-firmware-extract Copy the vendor-signed Qualcomm firmware named by a Snapdragon laptop device tree from its Windows driver store into /usr/lib/firmware/updates. * Select matching Qualcomm firmware variants * Trim firmware extractor comments * Keep firmware selection and initramfs updates safe on partial installs * Run package regression suites in existing CI * Match kernel firmware compression and search order * Limit the CI change to the package test scripts * Match firmware names exactly when updating the manifest * Count compressed firmware only when the kernel can load it * Scope the README's firmware claim to this package * Find DSP device-tree images under their Windows names The Surface Pro 11 device tree asks for adsp_dtb.mbn and cdsp_dtb.mbn, but Windows ships them as adsp_dtbs.elf and cdsp_dtbs.elf, so extraction left both DSP device-tree images missing. Look for the Windows name when the device-tree name is not found. Exact names still take precedence, and the existing companion matching still selects between variants. Validated with test.sh and on a Surface Pro 11 against its own Windows driver store: 5 of 5 firmware files staged, up from 3, and the ADSP and CDSP boot with the device-tree images taken from the .elf files. * Let later firmware sources fill in what a stage lacks Any stage manifest, even an empty one, made --stage exit as already staged and made --install use only the stage, so Windows was never read again. A --stage rerun now keeps the staged files and looks for the rest, and --install scans Windows only for what the stage lacks. -d still replaces both. A rerun without root, which cannot read Windows, keeps the stage and succeeds as before. Each run reads the stage manifest once. Mount points honour QCOM_FW_ROOT so the tests can stub the partition scan. Both root checks now take the user ID from QCOM_FW_TEST_EUID when the tests set it, and the install-mode check no longer skips when QCOM_FW_ROOT is set. * Let board packages list firmware that must not come from Windows Some device trees name firmware that should not be copied from Windows: files a board package produces or holds back until they are tested, and files the machine's boot firmware loads before Linux, which Windows drivers do not carry. On the Surface Laptop 8 these are its USB4 router image and SOCCP pair. A board package can now list such names in /usr/share/qcom-firmware-extract/provided.d/<compatible>.list. On a machine with that compatible they are never searched for, installed or reported by --list-missing, and the log names the list for each one. An unreadable list or an entry containing a space is skipped with a warning. A copy an earlier --install made of a newly listed name stays in place: the same bytes would not show that the file is still this tool's copy, since a board's own tool may keep the same file there. The next --install stops recording it and prints where it is, for the board package or the user to remove. Since --list-missing omits listed names, a board must not list firmware that a hardware check relies on unless its package installs it before the check runs. * Find staged firmware by file name when its device-tree path changed Since the stage became the first source, --install takes a staged file only by its exact device-tree path. After a full-disk install the stage is the only copy, so a device tree that files an image under another path could no longer be served from it. After Windows, fall back to a staged file with the same name that the stage manifest lists, but not when Windows refused differing variants of it as ambiguous. * Test that listed firmware never sends the extractor to the disks With every name installed or listed, --list-missing prints nothing, --stage and --install neither list nor mount partitions, and listed names are not installed from Windows or the stage. A control run without the list does scan. Listing the names again leaves the copies it installed in place but stops recording them, and another missing file still sends the extractor to Windows for that file alone. * Read only internal disks from an installed system --install mounts the Windows partitions whenever the stage lacks a file, which after a full-disk install can be every later run, and it mounted every NTFS partition, USB disks included. It now reads only partitions on disks that lsblk reports as neither removable, hotplug nor USB. --stage in the live session still reads all of them, internal disks first, and -d takes a driver store from anywhere. --------- Co-authored-by: Jimmy Van Veen <jimmy.van.veen@gmail.com> Co-authored-by: Brandon Williams <turbine.bmw@gmail.com> Co-authored-by: Jim Martin <jimmartin@gmail.com>
qcom-firmware-extract
Copies the vendor-signed Qualcomm firmware a Snapdragon laptop needs, including
the GPU zap shader and audio/compute DSP images, from the owner's own Windows
installation on the same machine into /usr/lib/firmware/updates/.
The package itself contains no firmware. The files it copies never leave the machine and are never downloaded. It is a temporary measure until laptop vendors contribute complete firmware sets to linux-firmware.
How it works
The device tree names every firmware file the kernel will ask for
(firmware-name properties). The tool keeps the names that are missing under
/usr/lib/firmware{,/updates}, finds each one by file name in
Windows/System32/DriverStore/FileRepository on an NTFS partition it can
mount read-only: with --stage, any such partition, and with --install,
only those on internal disks. A DSP device-tree image the device tree calls
*_dtb.mbn is also found under its Windows name, *_dtbs.elf, when the exact
name is missing. If Windows carries several variants and linux-firmware has a
companion image from the same device-tree node, the sibling image's hash
selects the compatible variant. Identical duplicates are accepted; differing
variants without a unique companion match are skipped. The result is
installed under /usr/lib/firmware/updates/<name>. The GPU zap shader is
added to the initramfs through /etc/mkinitcpio.conf.d/qcom-firmware.conf;
the DSP images are loaded from the root filesystem. What was installed, from
where, and its checksum is recorded in
/var/lib/omarchy/qcom-firmware/manifest.
Nothing is model-specific. A laptop whose firmware linux-firmware already ships gets nothing copied; a machine without a device tree exits at once.
Firmware that does not come from Windows
Some boards name firmware that must not be copied from Windows. The board
package may handle it itself, for example by processing a vendor driver file
or by holding back an image not yet tested on that board. Or the machine's
own boot firmware loads it before Linux starts, and Windows drivers do not
carry it as a file. The board package lists such names, one per line, in
/usr/share/qcom-firmware-extract/provided.d/<compatible>.list, where
<compatible> is one of the board's device-tree compatible strings. Blank
lines are ignored, and a # at the start of a line or after a space starts
a comment. An entry with a space inside, or a list that cannot be read, is
skipped with a warning. On that board, listed names are never searched for,
installed or reported missing, even when Windows or the stage holds a copy;
everything else is handled as usual.
A copy that an earlier --install put in /usr/lib/firmware/updates before
the name was listed stays there, and while it does, it loads before any other
copy. The tool never deletes it: matching bytes would not prove that the file
is still the one it installed, since a board's own tool may keep the same file
at that path. The next --install stops recording it in the manifest and
prints its path, so the board package, or the user, can remove it.
Because --list-missing leaves listed names out, a board must not list
firmware that a hardware check relies on unless its package installs that
firmware before the check runs. Omarchy's install/hardware/qualcomm/firmware.sh
looks for adsp in that output to decide whether to keep the DSP driver off,
so a listed ADSP image would bypass the check.
When it runs
- Installer, live session:
qcom-firmware-extract --stage DIRright after the disk is chosen, before anything is written. A full-disk install destroys the Windows partition the files come from, so this is the only moment they can be read. The stage is copied into the target. Running--stageagain, for example with-d, adds the files earlier runs did not find. - Installer, hardware setup:
qcom-firmware-extract --install --no-rebuildfrominstall/hardware/qualcomm/firmware.sh. Each file comes from the stage if it holds one, otherwise from a Windows partition still on an internal disk. A staged file that a later device tree names under another path is found by file name, after Windows, unless Windows held variants it refused as ambiguous. The installer builds the boot image once afterwards. - Installed system:
sudo qcom-firmware-extractuses the stage and scans the internal disks again for what it lacks; when nothing is missing, it does not touch the disks.sudo qcom-firmware-extract -d /path/to/FileRepositoryinstead takes any driver store you can mount, including one on a USB disk (a Windows install of the same model: the files are tied to the vendor's signing keys). It rebuilds the boot image; reboot afterwards.
BitLocker volumes cannot be read; turn BitLocker off in Windows first.
Retirement
When linux-firmware ships a machine's vendor directory, the tool copies nothing
and still configures its GPU firmware for early display. When every supported
machine is covered, drop the package and prune the /usr/lib/firmware/updates
entries listed in the manifest.
Derived from Canonical's qcom-firmware-extract (GPL-2+).