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

[Liam Girdwood]

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 ?

Would this be OK for the distros ?

Liam 

> 
> BTW: Do we need UCM config files for SOF, too?
> 
> 					Jaroslav
>