rootfs: add udev rule to autostart remoteproc

[guanquan (GuanquanTian)]

Adds a udev rule to build-rootfs.sh that autostarts the adsp and cdsp remote processors on attach, so they come up automatically without a manual echo start > /sys/class/remoteproc/remoteprocN/state.

The rule matches on the stable sysfs name attribute rather than the remoteprocN index, since the number is assigned in probe order and is not guaranteed to map to the same processor across boards or kernel versions:

ACTION=="add", SUBSYSTEM=="remoteproc", ATTR{name}=="adsp", ATTR{state}="start"
ACTION=="add", SUBSYSTEM=="remoteproc", ATTR{name}=="cdsp", ATTR{state}="start"

The rule is injected into the existing chroot provisioning block in build-rootfs.sh, after manifest package installation and before update-grub.

Ref: https://github.com/qualcomm-linux/qcom-distro-images/issues/91

[Bjordis Collaku (bjordiscollaku)]

Thanks for picking this up. I had this implemented in #124, closed at the time because it bundled two unrelated changes alongside it. I've used this approach for a long time in my Debian images for Hamoa and Glymur, which have gone out to external partners. I'd like to go that way instead, and I'll re-raise the resize service on top of a proper mechanism for runtime bits: a directory in the tree that gets staged into the image, so anything like this lands as real files rather than heredocs generated inside the chroot. Your remoteproc rule would slot straight into it.

Two problems with the implementation in #218. First, I don't think growpart is buying us anything. I've run resize2fs by hand on CRD targets with no growpart and the filesystem spans the full partition, which means the partition is already sized to the disk and there's no unallocated space after it to claim. If you saw growpart report CHANGED rather than NOCHANGE on your run I'd want to know, because that would mean the tables differ from what I've seen. Otherwise cloud-guest-utils and gdisk are avoidable, and I'd rather not ship partition editing tools plus a root script that rewrites a GPT on production images.

Second, findfs LABEL=system doesn't necessarily return the running root. We hardcode mkfs.ext4 -L system for every image (build-rootfs.sh:745) and ship the same rootfs.img across storage types, so the label isn't unique. Boot from UFS with an SD card still holding a flashed image and findfs can return the removable device, at which point growpart rewrites that disk's partition table and the real root stays at 8G. findmnt -n -o SOURCE / reads the mount table, so it can only ever resolve to the actual root.

Net: I'll take the resize side, could you carry the remoteproc rule in its own PR? The dmesg you shared in Teams shows it earning its place, auto_boot fires at 11.07 and fails on firmware with -2, then your rule picks it up once firmware is reachable. Worth a second look at the matching though: remoteproc[01] matches by index and numbering follows probe order, so it isn't guaranteed to be the same processors across boards. The sysfs name attribute is stable if you need specific ones.

[Bjordis Collaku (bjordiscollaku)]

Looks good, name matching is the right call and the comment in the rule should stop anyone putting the index back.

Two small things. The title still mentions growing the root partition, worth updating now that the PR is just the udev rule.

And one question on the dmesg you shared. adsp is available at 11.07 and the early power-up attempts fail with -2, then an attempt at 16.1 succeeds once firmware is reachable. The add event is long past by then, so what's driving that last attempt? Asking because if it's incidental timing rather than something the rule guarantees, a board where firmware lands later would silently never start adsp/cdsp, with no retry and no error.

[Shoudi Li (shoudil)]

Need to add gate ATTR{state}=="offline". As KLMHP targets get supported through qcom-distro-images, same issue should be present on KLM as well, so we also need to have a check on KLM targets， if cdsp1/gpdsp0/gpdsp1/sdsp/spli needed to add together.
https://github.com/qualcomm-linux/kernel/blob/qcom-next-7.2-rc3-20260731/drivers/remoteproc/qcom_q6v5_pas.c#L1790

[Shoudi Li (shoudil)]

Looks good, name matching is the right call and the comment in the rule should stop anyone putting the index back.

Two small things. The title still mentions growing the root partition, worth updating now that the PR is just the udev rule.

And one question on the dmesg you shared. adsp is available at 11.07 and the early power-up attempts fail with -2, then an attempt at 16.1 succeeds once firmware is reachable. The add event is long past by then, so what's driving that last attempt? Asking because if it's incidental timing rather than something the rule guarantees, a board where firmware lands later would silently never start adsp/cdsp, with no retry and no error.

Hi Bjordis Collaku (@bjordiscollaku) ，

The first attempt happen in initramfs without firmware (load fw failed), the 2nd attempt happened after rootfs get mounted, triggered by the udev rule added in this PR (firmware is ready).

Here share the timestamp of rootfs mount for clear understanding.

root@qcom:/home/qcom# dmesg | grep adsp
[ 11.856445] remoteproc remoteproc0: adsp is available
[ 11.868701] remoteproc remoteproc0: Direct firmware load for qcom/x1e80100/adsp.mbn failed with error -2
[ 11.879590] remoteproc remoteproc0: powering up adsp
[ 11.893194] remoteproc remoteproc0: Direct firmware load for qcom/x1e80100/adsp.mbn failed with error -2
[ 17.085086] remoteproc remoteproc0: powering up adsp
[ 17.172814] remoteproc remoteproc0: Booting fw image qcom/x1e80100/adsp.mbn, size 17922440
[ 17.390205] remoteproc remoteproc0: remote processor adsp is now up
[ 18.206332] qcom,apr 6800000.remoteproc:glink-edge.adsp_apps.-1.-1: Adding APR/GPR dev: gprsvc:service:2:1
[ 18.228127] qcom,apr 6800000.remoteproc:glink-edge.adsp_apps.-1.-1: Adding APR/GPR dev: gprsvc:service:2:2
root@qcom:/home/qcom# dmesg | grep mounted
[ 13.878760] EXT4-fs (sda16): mounted filesystem 55287d23-f43d-4d1e-966a-cd48cb5a8197 r/w with ordered data mode. Quota mode: none.

[Shoudi Li (shoudil)]

As the issue is reported across targets in several scenarios now ( in which update-initramfs get executed), I would like to merge this PR as a temp solution. meanwhile fix from kernel or upstream change to initramfs-tools/dracut will be considered, but both will take time.

Known cases:

1. kernel deb installation.
2. kgsl dkms installation
3. install ubuntu-desktop-minimal pkg on server distro.
4. directly "update-initramfs -k $(uname -r) -c"
   ..