[BUG] Topologies landing on dead branches are not making it into sof-bin

[cujomalainey]

Describe the bug
All shipping device topologies should be in sof-bin, this is not the case. E.g. sof-jsl-rt5650.tplg is missing which is a shipping chromeos device. This is the result of the split firmware branching.

To Reproduce
find . -name "sof-jsl-rt5650.tplg"

Reproduction Rate
100%

Expected behavior
All device binaries are in sof-bin

Impact
No audio for Linux users

[plbossart]

that's rather easy to do if there are not 3rd party IP,s but most Chromebooks do have such processing in the firmware, and that part is not in sof-bin by construction. So there would be a need to have 'public' sanitized versions of Chromebook topologies, which isn't super easy to do.

[cujomalainey]

that's rather easy to do if there are not 3rd party IP,s but most Chromebooks do have such processing in the firmware, and that part is not in sof-bin by construction. So there would be a need to have 'public' sanitized versions of Chromebook topologies, which isn't super easy to do.

The topology referenced is a clean topology free from 3P. And by default 3Ps are branched from a clean version, so I am not sure I follow the challenge here.

[cujomalainey]

@kv2019i you handle sof-bin releases right?

[kv2019i]

@cujomalainey The topology1 release process is not great as we have no formal separation of "upstream topologies" and topologies that have some 3P dependencies and make no sense out of Chrome environment (you cannot load the topologies with upstream FW). So in practise I have to do some manual work at every release, to filter out such topologies from the release. This is error prone and I/we've missed topologies in the past (see note about topology2 below). I do try to be careful with this and try to include everything that is supported in upstream Linux kernel. E.g. sof-bin-2024.06 supports following JSL topologies:

sof-tplg-v2.2.1 ./sof-jsl-cs42l42-mx98360a.tplg
sof-tplg-v2.2.1 ./sof-jsl-da7219.tplg
sof-tplg-v2.2.1 ./sof-jsl-da7219-mx98360a.tplg
sof-tplg-v2.2.1 ./sof-jsl-es8336-dmic2ch-ssp0.tplg
sof-tplg-v2.2.1 ./sof-jsl-es8336-dmic2ch-ssp1.tplg
sof-tplg-v2.2.1 ./sof-jsl-es8336-dmic2ch-ssp2.tplg
sof-tplg-v2.2.1 ./sof-jsl-es8336-dmic4ch-ssp0.tplg
sof-tplg-v2.2.1 ./sof-jsl-es8336-dmic4ch-ssp1.tplg
sof-tplg-v2.2.1 ./sof-jsl-es8336-dmic4ch-ssp2.tplg
sof-tplg-v2.2.1 ./sof-jsl-es8336-ssp0.tplg
sof-tplg-v2.2.1 ./sof-jsl-es8336-ssp1.tplg
sof-tplg-v2.2.1 ./sof-jsl-es8336-ssp2.tplg
sof-tplg-v2.2.1 ./sof-jsl-nocodec.tplg
sof-tplg-v2.2.1 ./sof-jsl-rt5682-mx98360a.tplg
sof-tplg-v2.2.1 ./sof-jsl-rt5682-rt1015.tplg
sof-tplg-v2.2.1 ./sof-jsl-rt5682-rt1015-xperi.tplg

I however don't see any rules to generate sof-jsl-rt5650.tplg,, either in SOF mainline or stable-v2.2 (which is the latest upstream branch for JSL hw). There are topologies for MTL and ADL with rt5650, but not for JSL. So in this case, it would seem the problem is that there is no upstream support for JSL/rt5650 combination on the tplg source side.

PS With topology2, I now release everything in the production folder ("tools/build_tools/topology/topology2/target/sof-*") so I can remove any manual steps from the process.

[cujomalainey]

It looks like it only landed on jsl-005-drop-stable. Sigh, our cherry-picking requirements are really sub par to make sure they get everywhere they can and this is only compounded by the cavs25 branch.

The change is here 6dc3504

[cujomalainey]

@mwasko FYI as it looks like you helped cherrypick this

[kv2019i]

Ok that explains @cujomalainey . I tried a direct backport of 6dc3504 to stable-v2.2, but that didn't quite work. This commit requires commit 80a7795 that added generic support for variants without speaker amp, but even with that I ended with merge conflicts. @brentlu would you be able to make a version to stable-v2.2 so we'd have mainlin support for this board?

[brentlu]

Hi @kv2019i,

Are you suggesting using stable-v2.2/cavs2.5 to host JSL topologies? Or we are going to abandon entire jsl-005-drop-stable branch and use cavs2.5-001-drop-stable instead for JSL FW/TPLG release?

Following is the branch explanation I have from the mail back to Sep. 2023. This is why I did not backport the sof-jsl-rt5650.tplg to stable-v2.2/cavs2.5 branches.

SOF branch main
-> tplg2 only for Intel boards (MTL, ARL, LNL, ...)
SOF branch stable-v2.2
-> tplg1 for Intel boards, a multi-vendor upstream stable branch
SOF branch cavs2.5-001-drop-stable (follows stable-v2.2)
-> Intel vendor-specific branch for cAVS2.5 products (TGL, ADL, RPL)

[kv2019i]

@brentlu Just to stable-v2.2. The explanation from 2023 still applies, "main" has all latest Intel stuff except for older IPC3 based platforms for which "stable-v2.2" is the latest upstream stable branch we support. PRs submitted here will end up sof-bin quarterly releases and e.g. will be shipped to Linux distros.

So no impact to cavs2.5 and jsl-005 branches -- these are Intel-specific product branches only consumed by Chrome customers and not used for upstream sof-bin binary releases. This is same for all vendors (who all have their own product release branches). To get binaries into common sof-bin releases, they have to be in SOF mainline, "main" or one of "stable-v2.xx" branches (the branches are listed when releases are made https://github.com/thesofproject/sof-bin/releases ).

Of course things that are Chromebook specific (e.g. tplgs referring to algorithms not available upstream) can only be put into these product specific branches (like cavs2.5 and jsl005). But it seems sof-jsl-rt5650.tplg is a generic topology which will work with upstream Linux kernel and upstream SOF FW build, so this we could indeed support in our upstream releases as well.

[brentlu]

Got it. Thanks for explanations. Please check #9492 for the missing commits.

[cujomalainey]

So no impact to cavs2.5 and jsl-005 branches -- these are Intel-specific product branches only consumed by Chrome customers and not used for upstream sof-bin binary releases.

Regarding this, what is the long term support location for JSL @sathya-nujella ?

[kv2019i]

@cujomalainey @brentlu @marc-hb I added an extended version of my reply here on this bug and made a submission to sof-docs thesofproject/sof-docs#501

@cujomalainey So I'm answering here with my upstream SOF maintainer hat on. SOF "main" and "stable-vx.yy" branches are upstream multivendor branches. Just like Zephyr and Linux upstream stable branches, vendors are free to use these as basis for their long-term product support, but that is a vendor call to make. And maybe a good point to add that these stable branches are relatively new addition to SOF upsream work flow, so many of the older vendor product branches predate availability of the stable branches. FYI @abonislawski @mwasko @lgirdwood

[marc-hb]

Sigh, our cherry-picking requirements are really sub par to make sure they get everywhere they can and this is only compounded by the cavs25 branch.

Speaking of the cavs25 branch:

• [BUG] rimage + openssl3 is broken in the stable-v2.2 and cavs25 branches, always have been #9340 (comment)