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

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Wed Jul 24 19:52:46 CEST 2019


iam, 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.
>>
> 
> I've attached v1.3 binaries to github for all targets built with GCC

with not the ones built with XCC?

The ones with GCC are helpful in case someone wants to reproduce the 
build, but they are really not used in actual products. it'd be odd to 
ask folks to use the GCC-generated ones when Intel folks internally use 
the XCC-generated ones. From a support perspective it's also odd.


More information about the Sound-open-firmware mailing list