docs: document both firmware sources on equal terms
All checks were successful
build image / build (push) Successful in 1h51m36s
All checks were successful
build image / build (push) Successful in 1h51m36s
The repo named WOA-Project as a source and called its cabinets "the easiest route", while aarch64-laptops appeared only as a place where files "have circulated before" — despite it having actual .mbn files checked into its tree and being where the WiFi trio used in today's testing came from. That ranking was mine, not something the evidence supports. Both are now documented with what each actually contains. They overlap and neither is a superset: WOA-Project is the only source of the two for qcdxkmsuc850.mbn, qcadsp850.mbn, qccdsp850.mbn, qcslpi850.mbn, qcvss850.mbn and ipa_fws.elf, and publishes nine versions whose cabinets differ. aarch64-laptops carries the modem/WLAN trio, the bdwlan board data, a prebuilt board-2.bin and the script that makes it, a630_gmu.bin, the machine's ACPI tables and a device tree — none of which WOA-Project has, and it has none of the six above. Its wifi/firmware-5.bin is an HTML error page rather than firmware, which is worth knowing before copying it somewhere. Also restate the modem result without implying a verdict on either source. Both sets produce the identical QLINK failure here; that shows changing firmware does not change the outcome, not that either set is wrong, and not that one is more trustworthy than the other. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
This commit is contained in:
@@ -54,8 +54,9 @@ Note `LIBGL_ALWAYS_SOFTWARE=1` does *not* work here — mutter uses EGL, which
|
||||
ignores it.
|
||||
|
||||
Getting the firmware: see
|
||||
[docs/firmware.md](docs/firmware.md). The cabinets from WOA-Project are the
|
||||
easiest route; `sudo c630-firmware` works if the Windows partition survives.
|
||||
[docs/firmware.md](docs/firmware.md), which compares the two projects that
|
||||
publish it — WOA-Project and aarch64-laptops — and what each one covers.
|
||||
`sudo c630-firmware` works if the Windows partition survives.
|
||||
|
||||
## Building
|
||||
|
||||
|
||||
@@ -156,40 +156,61 @@ licensing question, not a technical one.
|
||||
|
||||
`qcom/sdm850/LENOVO/81JL/` has simply never been contributed. Fedora ships no
|
||||
sdm850 model firmware at all, so it will not turn up in a `linux-firmware`
|
||||
update. Three routes, easiest first:
|
||||
update. Four sources are known:
|
||||
|
||||
**WOA-Project.** <https://github.com/WOA-Project/Qualcomm-Reference-Drivers>
|
||||
collects the Windows-on-ARM driver packages by SoC. The C630's are three
|
||||
cabinet files, and between them they hold every file this machine asks for:
|
||||
Two projects publish C630 firmware. They overlap but neither is a superset of
|
||||
the other, and both are worth knowing about.
|
||||
|
||||
**WOA-Project** — <https://github.com/WOA-Project/Qualcomm-Reference-Drivers>
|
||||
|
||||
Windows-on-ARM driver packages by vendor and model, under `Lenovo/YogaC630/`.
|
||||
Nine versions are published, `200.0.1.0` through `200.0.19.0`; the cabinets
|
||||
differ between them. This is the only source here for the GPU, DSP, sensor and
|
||||
venus blobs:
|
||||
|
||||
| Cabinet | Contains |
|
||||
|---|---|
|
||||
| `qcdx850.cab` | `qcdxkmsuc850.mbn` (zap shader), `qcvss850.mbn` (venus) |
|
||||
| `qcipa850.cab` | `ipa_fws.elf` |
|
||||
| `qcsubsys850.cab` | `qcadsp850.mbn`, `qccdsp850.mbn`, `qcslpi850.mbn`, `qcdsp1v2850.mbn`, `qcdsp2850.mbn`, and `WLANMDSP.MBN` |
|
||||
| `qcsubsys850.cab` | `qcadsp850.mbn`, `qccdsp850.mbn`, `qcslpi850.mbn`, `qcdsp1v2850.mbn`, `qcdsp2850.mbn`, `WLANMDSP.MBN` |
|
||||
| `qcwlan850.cab` | `bdwlan.bin`, `bdwlan.b3*` — ath10k board data |
|
||||
| `mcfg_subsys_ext850.cab` | `MCFG/*` modem configuration |
|
||||
| `qcsubsys_extension850.cab` | ADSP/CDSP runtime modules, `fastrpc_shell_*` |
|
||||
|
||||
That last one is a bonus — the WiFi firmware, which is not in the device tree's
|
||||
`firmware-name` list but is what the onboard ath10k needs.
|
||||
`cabextract` or `7z x` opens them. Ignore the `_nm` and `_CLS` variants; the
|
||||
device tree asks for the plain names. Fetch via the GitHub API's
|
||||
`download_url` — the `raw.githubusercontent.com` paths return 404.
|
||||
|
||||
`cabextract` or `7z x` will open them:
|
||||
**aarch64-laptops** — <https://github.com/aarch64-laptops/build>
|
||||
|
||||
```sh
|
||||
for f in qcdx850.cab qcipa850.cab qcsubsys850.cab; do 7z x -o./extracted "$f"; done
|
||||
find ./extracted -iname 'qc*850.mbn' -o -iname 'ipa_fws.elf' -o -iname 'WLANMDSP.MBN'
|
||||
```
|
||||
Files checked directly into `misc/lenovo-yoga-c630/`, no extraction needed.
|
||||
A narrower set, but with things WOA-Project does not carry:
|
||||
|
||||
Ignore the `_nm` and `_CLS` variants; the device tree asks for the plain names.
|
||||
Verify what you get with `file` — they should report as
|
||||
`ELF 32-bit LSB executable, QUALCOMM DSP6`, not as text or HTML.
|
||||
| Path | Contains |
|
||||
|---|---|
|
||||
| `wifi/` | `qcdsp1v2850.mbn`, `qcdsp2850.mbn`, `wlanmdsp.mbn`, `bdwlan.*` |
|
||||
| `wifi/create-board-2.bin/` | a prebuilt `board-2.bin`, and the script that makes it |
|
||||
| `gpu/firmware/` | `a630_gmu.bin` |
|
||||
| `acpi/`, `laptop-lenovo-yoga-c630.dts` | the machine's ACPI tables and a device tree |
|
||||
|
||||
It has none of `qcdxkmsuc850.mbn`, `qcadsp850.mbn`, `qccdsp850.mbn`,
|
||||
`qcslpi850.mbn`, `qcvss850.mbn` or `ipa_fws.elf`. Note `wifi/firmware-5.bin` is
|
||||
an HTML error page in the checkout, not firmware — Fedora's `atheros-firmware`
|
||||
ships a real one.
|
||||
|
||||
**Which to use.** For the GPU, DSPs, sensors and venus, WOA-Project is the only
|
||||
option of the two. For the modem and WLAN trio both publish files, and they are
|
||||
different builds — same sizes for the modem pair, different checksums. On this
|
||||
machine both produce identical results, so nothing here distinguishes them; see
|
||||
[What the firmware does not fix](#what-the-firmware-does-not-fix).
|
||||
|
||||
**Lenovo's Digital Download Recovery Service.** Lenovo builds a Windows
|
||||
recovery image against a machine's serial number and lets the owner download
|
||||
it. That image contains `Windows/System32/DriverStore/FileRepository`, and
|
||||
therefore all eight files. Slower than the cabinets, but it is unambiguously
|
||||
your own machine's firmware.
|
||||
therefore the whole set as shipped for your specific machine. Slower than
|
||||
either repository, and untested here.
|
||||
|
||||
**Another C630 owner.** The aarch64-laptops project is where these have
|
||||
circulated before, and any 81JL's copy is as good as your own.
|
||||
**Another C630 owner.** Any 81JL's copy is as good as your own.
|
||||
|
||||
Whichever route, drop the result into `firmware/local/` and rebuild — see
|
||||
[Baking firmware into the image](#baking-firmware-into-the-image).
|
||||
@@ -294,12 +315,16 @@ made to load.
|
||||
|
||||
#### Firmware has been eliminated as the variable
|
||||
|
||||
The decisive test: [aarch64-laptops' wifi directory][aal-wifi] contains the
|
||||
`qcdsp1v2850.mbn`, `qcdsp2850.mbn` and `wlanmdsp.mbn` from the setup whose
|
||||
support table ticks WiFi. All three differ from the WOA-Project copies — the
|
||||
modem pair matches on size but not checksum. Installed on this machine, with
|
||||
`rmtfs` and `tqftpserv` running and `wlanmdsp` in the TFTP path, they produce
|
||||
the **identical** QLINK failure.
|
||||
The test that narrows it: both projects publish the modem trio, and their
|
||||
copies differ — the modem pair matches on size but not checksum. Both were
|
||||
installed on this machine, with `rmtfs` and `tqftpserv` running and `wlanmdsp`
|
||||
in the TFTP path. Both produce the **identical** QLINK failure.
|
||||
|
||||
That is worth stating carefully. It does not show either set to be wrong, and
|
||||
it does not make one more trustworthy than the other — the aarch64-laptops
|
||||
copies come from a setup whose support table ticks WiFi, but on a 2019 kernel,
|
||||
and neither set has been shown to work here. What it does show is that changing
|
||||
firmware does not change the outcome.
|
||||
|
||||
So the difference is not the firmware, and not the userspace services. What
|
||||
remains is the kernel: that setup ran `aarch64-laptops/linux` branch `gpu`,
|
||||
|
||||
Reference in New Issue
Block a user