[alsa-devel] SOF firmware/ucm/topology packaging (was: CA0132 firmware)

Jaroslav Kysela perex at perex.cz
Tue May 28 21:15:27 CEST 2019


I believe that we need to discuss this more.

Dne 28. 05. 19 v 18:59 Pierre-Louis Bossart napsal(a):
> 
> 
> On 5/28/19 11:38 AM, Jaroslav Kysela wrote:
>
>> The same situation is for the SoC SOF firmware files (drivers are
>> in kernel, firmware files are missing). Perhaps, we can release those files
>> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
> 
> for SOF there are 4 cases
> 
> 1. developers/integrators build from scratch themselves from the public 
> tree.
> 2. integrators build from scratch with their own secret sauce added.
> 3. distros want a binary since they don't want to build from source 
> and/or don't have access to all the DSP tools
> 4. distros needs a binary signed with the Intel production key (e.g. to 
> run on devices initially designed for Windows).

Do you mean that the firmware should be signed because the hardware is doing a
check, if the hardware vendor enables it and rejects the unsigned binaries?

> So far we were mostly dealing with case 1. Case 2 is allowed by the SOF 
> permissive license and there's no need to look into this. We are 
> planning releases for the last two cases, with a cadence aligned with 
> kernel updates. It's not fully clear to me if the linux-firmware tree is 
> the 'right' solution since ideally we'd want to have firmware, topology 
> and UCM files released at the same time.

Do you plan to create a new package for this? I can eventually offer the space
/ docker build system on the ALSA server, if you like. The github releases
work fine, too. The question is, if it's the right way. It seems that the
firmware/topology files are read-only chunks used by the driver (standard
usage) and the UCM config is for alsa-lib (the user space). It might make
probably sense to add compatibility IDs to link/check the correct parts
together at runtime and keep the standard (binary) code distribution for the
most of users (linux-firmware / alsa-lib).

Speaking for distributions, we need to correctly identify the driver which
will load the proper firmware files. From notes posted to the alsa-devel ML,
it seems that there are three drivers for similar hardware (sound bridges) now
and it is not easy to identify the proper driver, because the similar PCI ID
is registered in all of them:

1) legacy HDA
2) sound/soc/intel
3) sound/soc/sof/intel

Do not forget that the distributions include all driver modules in their
universal kernels. It seems like a problem for the Intel hardware at the
moment. Perhaps, you may give us some recommendations / hints.

Totaly another topic is the on-demand installation of firmware files (and
eventually ALSA configuration files). The linux-firmware package has over
180MB now and it's growing. It makes sense to install only useable firmware
files - ommit the files for hardware / drivers which are not detected and
used. It's probably a topic for linux-firmware rather then the ALSA project.

					Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.


More information about the Alsa-devel mailing list