[alsa-devel] [Sound-open-firmware] Signed firmware availability for kbl/cnl

[Jaroslav Kysela]

Dne 24. 07. 19 v 18:09 Liam Girdwood napsal(a):
> On Wed, 2019-07-24 at 18:00 +0200, Jaroslav Kysela wrote:
>> Dne 24. 07. 19 v 16:41 Pierre-Louis Bossart napsal(a):
>>> On 7/24/19 8:59 AM, Jaroslav Kysela wrote:
>>>> Dne 23. 07. 19 v 16:22 Liam Girdwood napsal(a):
>>>>> On Thu, 2019-07-18 at 16:43 +0800, Daniel Drake
>>>>> wrote:_______________________________________________
>>>>>> Sound-open-firmware mailing list
>>>>>> Sound-open-firmware at alsa-project.org
>>>>>>
>>>>> https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>>>>>
>>>>>> On Wed, Jul 17, 2019 at 8:09 AM Pierre-Louis Bossart
>>>>>> <pierre-louis.bossart at linux.intel.com>
>>>>>> wrote:_______________________________________________
>>>>>>> Sound-open-firmware mailing list
>>>>>>> Sound-open-firmware at alsa-project.org
>>>>>>>
>>>>>> https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>>>>>>
>>>>>>> I was indeed told a while ago that there was a limited
>>>>>>> number of
>>>>>>> KBL-based devices with DMIC, but mistakenly assumed we
>>>>>>> could avoid
>>>>>>> dealing with this configuration and Murphy's Law applied of
>>>>>>> course.
>>>>>>> we'll have to huddle with our Intel colleagues to figure
>>>>>>> this one
>>>>>>> out.
>>>>>>
>>>>>> OK, thanks.
>>>>>>
>>>>>> Is there any update on the release of signed firmware files
>>>>>> for the
>>>>>> other platforms? We are under pressure to return the other
>>>>>> unit we
>>>>>> have to the vendor (which needs the cnl files), but we would
>>>>>> like to
>>>>>> try SOF first.
>>>>>>
>>>>>
>>>>> Apologies for the delay, I hurt my back and was off work for a
>>>>> few
>>>>> weeks. Signed binaries now on v1.3 github release tag. Will now
>>>>> be
>>>>> upstreaming into Linux FW repo.
>>>>
>>>> Liam, the sizes of signed firmware binaries are a lot different
>>>> than the
>>>> unsigned ones (v1.3 tag) which I can build in docker:
>>>>
>>>> -rw-rw-r--. 1 perex perex 270336 Jul 24 15:44 sof-apl-signed-
>>>> intel.ri
>>>> -rw-r--r--. 1 perex perex 167936 Jul 24 15:44 sof-apl.ri
>>>> -rw-rw-r--. 1 perex perex 278528 Jul 24 15:44 sof-cnl-signed-
>>>> intel.ri
>>>> -rw-r--r--. 1 perex perex 172032 Jul 24 15:44 sof-cnl.ri
>>>> -rw-rw-r--. 1 perex perex 278528 Jul 24 15:44 sof-icl-signed-
>>>> intel.ri
>>>> -rw-r--r--. 1 perex perex 172032 Jul 24 15:44 sof-icl.ri
>>>>
>>>> Is that ok?
>>>
>>> The firmware used for production is typically built with the
>>> Cadence 
>>> tools, which unfortunately are not available publicly (but can be
>>> made 
>>> available to Intel partners). It wouldn't be surprising if the code
>>> size 
>>> was different due to the use of intrinsics (though 100K seems like
>>> a lot 
>>> indeed).
>>>
>>> Liam, I think we ought to release binaries with the community key
>>> as 
>>> well so that people can use them as is, e.g. on the Up2 board which
>>> does 
>>> not require the Intel production key. Same for GLK Chromebooks.
>>
>> It would be probably more nice to create a tar ball with all firmware
>> and
>> topology files bundled with the proper (usual) filesystem location
>> (/lib/firmware/intel/sof/... and /lib/firmware/intel/sof-tplg/...).
>> So we
>> (users/distribution packagers) can just use it.
> 
> Yeah, been thinking about this atm. It may be better to package the
> binaries (firmware and topologies) as part of Linux firmware repo
> (since the driver expects to load them all from lib/firmware) and
> package the sources (firmware and topology) via sof tarball ?

It looks good in my eyes, because topology files are another pieces of the
driver from the user space perspective. The unanswered question is the UCM
configuration which is linked to the topology configuration (if I understand
this correctly). I proposed to place an unique identifier/version to the
topology file and propagate this identifier to the user space, so the alsa-lib
can pick the right UCM configuration when topology changes. The component
string (snd_component_add function / struct snd_ctl_card_info -> components)
can be used for this identification.

					Jaroslav

> 
> Would this be OK for the distros ?
> 
> Liam 
> 
>>
>> BTW: Do we need UCM config files for SOF, too?
>>
>> 					Jaroslav
>>
> 


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