You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
adsp and cdsp both fail to boot with error -22 initializing firmware from qcom_q6v5_pas, and this persists even after replacing the firmware with a fresh, independently sourced copy, ruling out a bad/mismatched firmware file as the cause.
Device: Windows Dev Kit 2023 (Volterra / SC8280XP, device tree sc8280xp-microsoft-blackrock) Kernel:7.0.0-28-generic (Ubuntu Server, aarch64)
Steps taken
Initial boot with the linux-firmware-packaged qcadsp8280.mbn / qccdsp8280.mbn under qcom/sc8280xp/microsoft/blackrock/ fails:
Since no Windows install exists on this device to pull firmware from directly, sourced fresh firmware instead from WOA-Project/Qualcomm-Reference-Drivers, 8280_QRD/200.0.68.0/:
Both differ by checksum from the previously installed files (cdsp differs despite identical size).
Replaced files in /lib/firmware/qcom/sc8280xp/microsoft/blackrock/, regenerated initramfs (update-initramfs -u) since these files are baked into the initrd on Ubuntu, confirmed via lsinitramfs that the new files were embedded, and rebooted.
Confirmed via kernel log that the new firmware was actually loaded this time (size matches new file, 14606924), but the result is identical:
Two independently sourced, differently signed firmware images (different md5, and in adsp's case different size) both fail identically with -22 from qcom_scm_pas_init_image(). This suggests the failure isn't about which firmware file is used, but something upstream of that, e.g. TrustZone/fuse-level rejection tied to this device's security state, or a gap in how this kernel's qcom_scm/shmbridge interface talks to TZ for PAS_INIT on this board specifically.
Has anyone gotten adsp/cdsp to actually boot (state: running) on a WDK2023 without a prior/parallel Windows install on the device? Happy to test patches or provide more diagnostics, dmesg/journalctl output, qcom_scm module state, etc.
Note
I am very new to most of this kind of work, thus silly mistakes and wrong understandings may be present. I was able to get CPU/GPU/networking all OK on this machine. It is purely NPU that I cannot get working.
adspandcdspboth fail to boot witherror -22 initializing firmwarefromqcom_q6v5_pas, and this persists even after replacing the firmware with a fresh, independently sourced copy, ruling out a bad/mismatched firmware file as the cause.Device: Windows Dev Kit 2023 (Volterra / SC8280XP, device tree
sc8280xp-microsoft-blackrock)Kernel:
7.0.0-28-generic(Ubuntu Server, aarch64)Steps taken
linux-firmware-packagedqcadsp8280.mbn/qccdsp8280.mbnunderqcom/sc8280xp/microsoft/blackrock/fails:Since no Windows install exists on this device to pull firmware from directly, sourced fresh firmware instead from
WOA-Project/Qualcomm-Reference-Drivers,8280_QRD/200.0.68.0/:qcsubsys_ext_adsp8280.cab→qcadsp8280.mbn(14,606,924 bytes, md59053840cf631c3304ae3970ac44c5732)qcsubsys_ext_cdsp8280.cab→qccdsp8280.mbn(3,571,712 bytes, md521ffeca53a18760e10e087f9279a7a27)Both differ by checksum from the previously installed files (cdsp differs despite identical size).
Replaced files in
/lib/firmware/qcom/sc8280xp/microsoft/blackrock/, regenerated initramfs (update-initramfs -u) since these files are baked into the initrd on Ubuntu, confirmed vialsinitramfsthat the new files were embedded, and rebooted.Confirmed via kernel log that the new firmware was actually loaded this time (size matches new file,
14606924), but the result is identical:Two independently sourced, differently signed firmware images (different md5, and in adsp's case different size) both fail identically with
-22fromqcom_scm_pas_init_image(). This suggests the failure isn't about which firmware file is used, but something upstream of that, e.g. TrustZone/fuse-level rejection tied to this device's security state, or a gap in how this kernel'sqcom_scm/shmbridge interface talks to TZ for PAS_INIT on this board specifically.Has anyone gotten
adsp/cdspto actually boot (state:running) on a WDK2023 without a prior/parallel Windows install on the device? Happy to test patches or provide more diagnostics,dmesg/journalctloutput,qcom_scmmodule state, etc.Note
I am very new to most of this kind of work, thus silly mistakes and wrong understandings may be present. I was able to get CPU/GPU/networking all OK on this machine. It is purely NPU that I cannot get working.