wifi: add userspace linux-msm daemons for mainline linux#607
Draft
greatgitsby wants to merge 12 commits into
Draft
wifi: add userspace linux-msm daemons for mainline linux#607greatgitsby wants to merge 12 commits into
greatgitsby wants to merge 12 commits into
Conversation
…for mainline-kernel wifi bring-up
Compile qrtr v1.2, rmtfs v1.3, tqftpserv v1.2 and pd-mapper v1.1 from
source in a new Docker build stage and install the binaries plus libqrtr
into the image. All new systemd units are gated with
ConditionPathExists=/sys/class/remoteproc (rmtfs additionally on a
/dev/qcom_rmtfs_mem* glob), so they are completely inert on the
downstream 4.9 kernel and only activate on a mainline kernel.
Validated end-to-end on mici (stock AGNOS userspace + mainline vamOS
kernel): modem boots, wlan0 up and associated.
- mainline-firmware.service: oneshot that rebuilds /usr/lib/firmware
(AGNOS mounts a tmpfs over it at boot) from the factory /firmware
partition: qcom/sdm845/{mba.mbn,modem_nm.*,*.jsn,wlanmdsp.mbn}
symlinks, plus the two vendored ath10k WCN3990 files shipped at
/usr/comma/firmware (not present on the device).
- rmtfs.service: rmtfs -r -s -P (read-only RAM shadow; raw EFS
partitions auto-discovered via by-partlabel)
- tqftpserv.service: serves /lib/firmware (wlanmdsp.mbn) over
TFTP-over-QRTR; readwrite blobs go to
/var/lib/tqftpserv (StateDirectory)
- pd-mapper.service: protection-domain mapper (reads the factory .jsn
maps via the firmware farm)
- mss-start.service: oneshot, After/Requires the firmware farm and the
three daemons, writes 'start' to the mpss/modem
remoteproc state
The existing proprietary chain (rmt_storage, tftp_server, init_sys_mss,
QTI pdmapper/cnss-daemon) is untouched; zero behavior change on stock
AGNOS.
rmtfs and pd-mapper generate their QMI stubs at build time via `qmic -k < *.qmi`. qmic was not installed in the compiler image, so the rmtfs build failed with 'qmic: command not found' (make Error 127). Clone and install linux-msm/qmic v1.0 into the compiler image's /usr/bin before building rmtfs/pd-mapper.
The rootfs is read-only — nothing mounts a tmpfs over /usr/lib/firmware — so symlinking into it failed and the unit exited 1 (taking pd-mapper and mss-start with it). Build the symlink farm in /run instead: re-expose the image's original firmware tree via a bind at /run/firmware-orig, merge in the factory-partition modem/wifi firmware and the vendored ath10k files, ensure /lib/firmware/updates exists (pd-mapper errors without it), and bind-mount the farm over /usr/lib/firmware. Idempotent across restarts. Verified by hand on mici before baking into the image.
…nt of wlan0 Three fixes found validating a clean image on mici (mainline 6.18 kernel): - mss-start: the mici mss remoteproc is named just '4080000.remoteproc', so match on the firmware it loads (mba.mbn) as well as mpss/modem names. - setup-mainline-firmware.sh: rmtfs -P discovers modem EFS partitions via /dev/disk/by-partlabel, but AGNOS removed udev (commaai#592) and the UFS GPT has no labels, so nothing populated it and the modem crash-looped with 'fatal error without message' (no EFS). Create the links with the same fixed mapping comma-init.sh uses (modemst1=sdf2, modemst2=sdf3, fsg=sdf4), plus fsc=sdf1: the modem fatal-errors if its /boot/modem_fsc read is rejected; sdf1 is the LUN5 cookie partition and rmtfs runs read-only. - wlan-nm-init.sh: on mainline, wlan0 appears 60-90s into boot (after the whole modem chain), long past the 30s wait. If NM starts before the fake udev entry exists it pins wlan0 unmanaged (platform-init) forever. Extend the wait to 300s on mainline only. All three verified by hand on mici (wlan0 associated to 5GHz ch100, IP via NetworkManager, gateway ping OK) before baking into the image.
… and fix a stale timing comment
greatgitsby
force-pushed
the
mainline-wifi-daemons
branch
from
July 4, 2026 00:34
27a7b07 to
66e334e
Compare
rmtfs -s finds the mss remoteproc by modalias (sdm845-mss-pil), starts it only after publishing its own QMI service, and stops it when rmtfs exits. The separate mss-start oneshot raced that start and added nothing. This also matches how vamOS runs the same daemons.
…ng board-2.bin AGNOS already ships the SOM-tuned board files at /usr/comma/wlan/bdwlan.b*. Serve the right one as ath10k's API-1 board.bin (selected by device-tree compatible, same mici->b01 / tizi->b00 mapping the vendored board-2.bin variants encoded) and drop the 905K vendored blob. Only the 60-byte firmware-5.bin remains vendored; it has no downstream equivalent.
Timing out early leaves a late-arriving wlan0 permanently unmanaged (NM has already started with no udev entry), while a long timeout only costs anything when wlan0 never appears at all. So use the long window unconditionally.
greatgitsby
force-pushed
the
mainline-wifi-daemons
branch
from
July 4, 2026 01:35
3966b42 to
8717348
Compare
greatgitsby
marked this pull request as ready for review
July 4, 2026 01:37
greatgitsby
marked this pull request as draft
July 4, 2026 01:42
greatgitsby
marked this pull request as ready for review
July 4, 2026 01:47
greatgitsby
marked this pull request as draft
July 4, 2026 01:51
The firmware farm binds the original /usr/lib/firmware to /run/firmware-orig,
then bind-mounts the farm back over /usr/lib/firmware. Because both live under
/run (a shared mount tree), the farm bind propagated back onto firmware-orig,
stacking the farm tmpfs on top of the original firmware. Every passthrough
symlink (which targets $ORIG/*) then resolved through the farm to itself,
yielding ELOOP: tqftpserv failed to open updates/qcom/sdm845/wlanmdsp.mbn
('Too many levels of symbolic links', 3 retries) and all non-materialized
firmware was unreachable. Mark the ORIG bind private so the later farm bind
can't leak into it. Verified on mici: firmware-orig is now a single mount and
passthrough symlinks + the updates/ tree resolve to real files.
greatgitsby
force-pushed
the
mainline-wifi-daemons
branch
from
July 4, 2026 03:05
ea9e7c9 to
493b767
Compare
greatgitsby
marked this pull request as ready for review
July 4, 2026 03:06
init_sys_mss, pdmapper, tftp_server and rmt_storage are the downstream 4.9 modem/remote-storage daemons. On a mainline kernel they have no working substrate (no /sys/power/wake_lock, no /sys/class/uio, no QRTR/IPC-router socket) and fail every boot, leaving systemd degraded; the mainline remoteproc daemons (rmtfs/tqftpserv/pd-mapper) already provide the same functions. Gate all four behind ConditionPathExists=!/sys/class/remoteproc so they are skipped (not failed) on mainline and run unchanged on the downstream kernel. adb-param-watcher is intentionally left running on both kernels.
greatgitsby
marked this pull request as draft
July 4, 2026 14:16
…rvice Fold setup-mainline-firmware.sh into comma-init.sh as init_firmware and remove the standalone mainline-firmware.service. The farm has to exist before anything that loads mainline firmware from /usr/lib/firmware, and building it inside comma-init (gated on /sys/class/remoteproc) keeps that setup in one place with the rest of the mainline bring-up instead of a separate oneshot ordered after comma-init. rmtfs.service previously got its ordering solely from the deleted service's Before=rmtfs; give it the same After/Requires=comma-init.service that tqftpserv and pd-mapper already carry, so all three still start only once the farm is in place. No behavior change on the downstream 4.9 kernel: init_firmware exits early when /sys/class/remoteproc is absent, same gate the service used.
greatgitsby
force-pushed
the
mainline-wifi-daemons
branch
from
July 4, 2026 18:34
c95a866 to
458f085
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.