Re: Looking for guidance on Qualcomm Hexagon DSP binaries
Hi!
I'm a DD intending to sponsor hexagon-dsp-binaries for Dmitry once we've
settled on the outstanding issues.
On Sat, Aug 23, 2025 at 12:09:57AM +0300, Dmitry Baryshkov wrote:
> The binaries for the DSP must exactly match the version of DSP
> firmware (provided by the firmware-qcom-soc package).
I think there are a few different options for dealing with this, none of
which are great:
0) We do nothing. When firmware-nonfree updates the relevant DSP
firmware, hexagon-dsp-binaries will stop working until it is also
updated.
1) hexagon-dsp-binaries is upstreamed into linux-firmware itself, making
it straightforward to always update all the binaries at the same time.
But Dmitry also tells me that these (non-free) hexagon-dsp-binaries are
*not* firmware (whatever "firmware" actually means!) and if upstream
agree then presumably they wouldn't consider it acceptable to include
there.
2) hexagon-dsp-binaries depends on an exact (enough) version of
firmware-qcom-soc. When firmware-nonfree is updated, it will not be able
to migrate to testing until hexagon-dsp-binaries is also updated. In the
common case where DSP firmware has *not* been updated, this would
require an otherwise-unchanged upload of hexagon-dsp-binaries that only
bumps the "required" firmware-qcom-soc version. In the less common case
that the DSP firmware *has* been updated, it would be a proper and
necessary update of hexagon-dsp-binaries that also bumps the "actual"
required firmware-qcom-soc version. I'm less in favour of this approach
because I don't wish to burden the firmware-nonfree maintainers with
waiting on hexagon-dsp-binaries maintainers (or otherwise taking some
upload action on a different package) before their package can migrate
to testing, especially in that common case of DSP binaries not having
been updated at all. And users will have to keep re-downloading
unchanged hexagon-dsp-binaries updates every time firmware-nonfree is
updated. It seems like this would run counter to the concept of package
versioning entirely.
3) firmware-qcom-soc Provides a virtual package at some DSP ABI version,
and hexagon-dsp-binaries depends on that. Then firmware-nonfree will
require no special treatment and will be unaffected *unless* the DSP
firmware is changed, in which case the DSP ABI version needs to be
bumped in the appropriate firmware-nonfree upload instead. In this case
we need to ensure that the DSP binaries are not updated unless the ABI
version *is* bumped, which would be very easy to do since that's the
normal workflow. Appropriate tooling can help with that and also make
this very easy for the firmware-nonfree maintainers to manage. I've
demonstrated this here:
https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/128
Currently I favour the third option. I think the Provides would
accurately represent the reality of the hardware behaviour having an
effective ABI to userspace. Package updates would only be required when
actually necessary under this reality. And I think I've essentially
eliminated the burden to firmware-nonfree maintainers in my proposed
tooling.
I welcome any other opinions and suggestions. Is there a cleaner way to
do this entirely?
Thanks,
Robie
Reply to: