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@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@linux.intel.com wrote:_______________________________________________ > Sound-open-firmware mailing list > Sound-open-firmware@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