docs: record what the GPU firmware trace actually proves

Tested on the machine. With the generic Adreno firmware reachable from the
initramfs and the model-signed blob absent, the GPU gets two files in and stops:

    loaded qcom/a630_sqe.fw from new location
    loaded qcom/a630_gmu.bin from new location
    *ERROR* Unable to load qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn
    *ERROR* gpu hw init failed: -2

That settles a question the docs had been hedging: the zap shader is a hard
requirement, not an optimisation, and the generic pieces are necessary but not
sufficient. Getting past sqe and gmu only to die at zap is about as clean a
demonstration as the hardware will give.

Two things fall out of the same trace and are worth writing down, because
nothing upstream documents them for this machine. The driver never falls back
to the installed sdm845/a630_zap.mbn — the device tree pins the model-specific
path — and a fallback would not help anyway, since the shader is signed against
this device's own secure-boot chain. And the display survives the failure
entirely: msm_dpu still binds the panel, so a dead GPU costs acceleration
rather than a picture, and a desktop runs on llvmpipe.

Also record why these files have to travel in the initramfs at all: msm_dpu
probes around six seconds in, while the initramfs is still root, and never
retries.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS

docs/firmware.md

@@ -45,6 +45,52 @@ until you supply it you get an unaccelerated display.
 Each file is independent, so a partial recovery is still worth having —
 `qcdxkmsuc850.mbn` on its own buys you working graphics.
 
+### Confirmed on the hardware
+
+This is not inferred from the device tree. On a machine with the generic
+Adreno firmware present and the model-signed blob absent, the GPU gets two
+files in and then stops:
+
+```
+[drm:adreno_request_fw]   loaded qcom/a630_sqe.fw from new location
+[drm:adreno_request_fw]   loaded qcom/a630_gmu.bin from new location
+[drm:zap_shader_load_mdt] *ERROR* Unable to load qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn
+[drm:adreno_load_gpu]     *ERROR* gpu hw init failed: -2
+```
+
+So the generic pieces are necessary and not sufficient, and the zap shader is a
+hard requirement rather than an optimisation. Two details follow from that
+trace:
+
+The driver never falls back to `sdm845/a630_zap.mbn`, even though the file is
+installed — the device tree's `firmware-name` pins the model-specific path. Nor
+would falling back help: the zap shader is signed against the device's own
+secure-boot chain, and the Snapdragon 845 development board's copy will not
+validate here.
+
+The display keeps working throughout. `msm_dpu` binds the panel and the console
+lands on `msmdrmfb` regardless, so a failed GPU costs you acceleration, not a
+picture. A desktop still runs on llvmpipe — though `/dev/dri/renderD128` is
+present even when `hw init` has failed, so mesa may try freedreno, fail, and
+take the display manager down with it. `LIBGL_ALWAYS_SOFTWARE=1` in
+`/etc/environment` avoids that.
+
+### These have to be in the initramfs
+
+`msm_dpu` probes about six seconds in, while the initramfs is still the root
+filesystem, and does not retry. Firmware that only exists on the real root is
+therefore invisible to it:
+
+```
+msm_dpu ae01000.display-controller: Direct firmware load for qcom/a630_sqe.fw failed with error -2
+```
+
+`overlay/etc/dracut.conf.d/10-c630.conf` puts the Adreno files in the initramfs
+for this reason, and `c630-firmware` adds the extracted DSP blobs to it after
+extraction — the ADSP has to be up before the root filesystem is mounted, and
+dracut rejects `install_items` globs that match nothing, so the entry can only
+be written once the files exist.
+
 ## Finding them on a backup
 
 If Windows is long gone from the machine but you kept a copy of the files, one