On Thu, Feb 6, 2020 at 11:38 AM Tanu Kaskinen tanuk@iki.fi wrote:
On Mon, 2020-01-27 at 15:28 +0000, Liam Girdwood wrote:
On Thu, 2020-01-23 at 16:07 +0000, Mark Pearson wrote:
Hi all,
I've been following this thread with interest and thank you all for your efforts on working on this. Did we reach consensus on the solution? If we did I think I missed it. Please let me know.
I hope so. The main contention point is the home for .ldc files and probably the topology binaries.
We have a lot of users waiting for this and I know I'll be working with the distro's to get this rolled out when it's available. If there's anything I can do to help let me know - I don't have enough expertise to comment on the solution so I've been keeping quiet .
There was a SOF TSC meeting last week and the outcome was to create a separate "sof-bin" repo to store the binary outputs of the SOF build processes. This would include the FW, .ldc files and binary topologies.
The part that is not clear to me (since I'm not a packager) is how to add the necessary packaging infrastructure in this repos to create rpm and deb files.
I would imagine we would want to create 2 packaging targets
sof-bin (fw binaries and topology binaries)
sof-bin-dbg (ldc files).
I hope this proposal would also be acceptable to Jaroslav ?
I can create a repo with the correct binaries but would need help from Jaroslav, Tanu or yourself getting the packing added.
Sorry for the slow reply. It sounds like you want to add packaging to the upstream repo, but why? Distributions can and will maintain the packaging bits themselves.
I maintain the ALSA recipes in the OpenEmbedded core layer (which is used by Yocto), including alsa-topology-conf and alsa-ucm-conf, and I guess I could present my thoughts here for the curious.
Thanks for jumping in. I work at NXP and we enable SOF on i.MX8 (arm based boards) and we use Yocto for Linux distro.
Currently SOF isn't packaged in OpenEmbedded. My understanding is that at least currently SOF is only used on Intel platforms, so if someone is going to package SOF for OpenEmbedded, it will probably be via the "meta-intel" layer, which I'm not involved with. I saw a message from Daniel Baluta in this thread, and he said that he's working on Yocto, but I'm not familiar with his work, is it for the meta-intel layer or something else?
Partially true. SOF is *currently* supported only on Intel platforms, but this will change very soon.
Supporting SOF in Yocto via "meta-intel" layer doesn't seems what we want for NXP. I think the better solution would be to support it via meta-freescale layer.
Cc-ing NXP Yocto people, Mihai and Lauren.
I got the impression that the SOF firmware will get distributed also via the linux-firmware repo, and I'm a bit worried about a dependency between linux-firmware and alsa-topology-conf (and alsa-ucm-conf?). The linux-firmware recipe isn't updated in sync with the ALSA recipes, is that going to cause problems? Can an update in linux-firmware cause breakage if alsa-topology-conf isn't updated at the same time, or vice versa? If so, maybe I should push the alsa-topology-conf (and alsa-ucm- conf?) maintenance to the linux-firmware maintainer or otherwise make sure that updates are done in sync. I hope the kernel itself isn't another component in the chain that can cause breakages if not kept in sync with all the other components.