Firmware binary upstreaming #7378
Replies: 7 comments
-
@dbaluta I guess you will be upstreaming i.MX FW binaries (since you will have xcc for your ISA) ? |
Beta Was this translation helpful? Give feedback.
-
the symlinks are fine, it's the same as currently done in /lib/firmware/intel. |
Beta Was this translation helpful? Give feedback.
-
@dbaluta one more thing, you probably want to add imx to README.md now. This means it will be prominent on the main SOF repo page. |
Beta Was this translation helpful? Give feedback.
-
@plbossart good point. We could have several binaries for one platform signed by different keys. The SOF driver could try different locations / binaries if authentication was failing. i.e. we could have |
Beta Was this translation helpful? Give feedback.
-
I don't know if it makes sense to retry, it'll increase the boot time significantly with the existing timeouts. Better try and find a quirk or something to identify which version should be used. |
Beta Was this translation helpful? Give feedback.
-
Works for me. Default is Intel signed unless DMI name matches table for open key ? |
Beta Was this translation helpful? Give feedback.
-
actually yes, that's pretty easy to do. I already have the quirks for this but I was using it to kick the SST/cAVS driver out. I can actually change the location for those open devices (Up2, Chromebooks, etc). Good suggestion, need to complete this work. |
Beta Was this translation helpful? Give feedback.
-
Now that v1.3 is done, I will be upstreaming the firmware binaries.
I would like to use soft links in the FW repos so that we can have multiple versions available i.e.
sof-apl-ri -> sof-apl-v1.3.1.ri
Any objections to this ? This allows users to revert if needed.
Also at what point should we remove old versions from the repo ? year old, 4 versions old ??
Beta Was this translation helpful? Give feedback.
All reactions