From 2457df7a37d52f9d7ad743d27ba5fdc56ce790d9 Mon Sep 17 00:00:00 2001 From: rob thijssen Date: Mon, 27 Jul 2026 20:05:17 +0300 Subject: [PATCH] docs: record what the GPU firmware trace actually proves MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS --- docs/firmware.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/docs/firmware.md b/docs/firmware.md index 82bf20b..e779ce1 100644 --- a/docs/firmware.md +++ b/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