[Sound-open-firmware] [External] Re: Distribution of sof firmware and tplg files

[Daniel Baluta]

On Thu, Feb 6, 2020 at 11:38 AM Tanu Kaskinen <tanuk at 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
> >
> > 1) sof-bin (fw binaries and topology binaries)
> >
> > 2) 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.