@yh-deng , commercial kabylake products do not use SOF, they use another, closed-source firmware. You can see that from the filename: dsp_fw_release.bin. You cannot use SOF on these commercial devices for firmware authentication reasons. Do you have a development board?
@marc-hb, I see, I apologize for my lack of familiarity with this topic. From reading this issue's comment, I assumed I may be able to get things going.
In that case, my original issue is trying to get speakers and microphone working. My problem is basically the same as this person's (same laptop, same issues, same partial fixes, etc. which led me to that Github issue). I thought there might have been progress from a year ago. In any case, do you think I'm out of luck or is there another way you can maybe recommend?
Marc Herbert
@marc-hb
No need to apologize this is quite complicated. Great you found this issue, I never saw it before.
Daniel Baluta
@dbaluta
@ranj063 hi
Ranjani Sridharan
@ranj063
@dbaluta Hello. Sorry I havent logged into gitter in a while
Daniel Baluta
@dbaluta
@ranj063 no problem. I have a question regarding how to support two different DAIs with SOF. I've seen this usecases many times with Intel. On i.MX we have separate topology files for two DAIs + their codecs.
I created a new topology files and defined all DAIs
no, i'm not sure about the DAI links. Do you have a single machine driver instance that takes care of these? Or multiple machine drivers instances?
so do you have a single sound card with multiple subdevices?
Ranjani Sridharan
@ranj063
@dbaluta we specify all our DAI links in a single machine driver and yes we have a single sound card with multiple devices for different codecs
Ranjani Sridharan
@ranj063
Do you have a requirement for using separate tplg file for the different DAIs? Its not a big deal but I'm guessing you'd need 2 separate component drivers and therefore have separate cards for the 2 topologies
Kai Vehmanen
@kv2019i
hey all! FYI, we now tagged a Zephyr mainline git version in the build scripts for the v2.0 branch. this is still very loose way to define the dependency, but at least something to indicate a working combination of SOF and Zephyer. let me know if anyone has ideas how to best tackle this dependency in the future. I did try v2.7.0 as well, but that is missing key patches... maybe in the future we can sync to a public release
@dbaluta FYI ^^^
Daniel Baluta
@dbaluta
@kv2019i great! thanks for pinging me
we thought about this together with our Yocto team. the preffered way (as we already doing with SOF is to have a separate branch)
but having a tag i think can work for a while.
do we plan to do this for each SOF release, right?
zephyr development model looked a little bit different than SOF (I think they have some sort of LTS release every year and keep that for customers)
Kai Vehmanen
@kv2019i
I think we'll do this for a while now. one recommendation from Zephyr folks for us to branch a stable release and cherry-pick patches SOF needs. we could host this in SOF github project (we already have a copy of zephyr there)
probably for all platforms, we'll need a pretty bleeding edge Zephyr in practise, so we'll probably need a few iterations before we can move to use a Zephyr LTS for SOF
_
Daniel Baluta
@dbaluta
I think that would be a good choice. Initially, I suggested to fork zephyr internally. but i think doing that on SOF github is better.
Daniel Baluta
@dbaluta
@kv2019i can you point me to the script you use the zephyr tagged version? I'm trying to integrate this internally now
the 2.0 branch has this bit "# SOF2.0 release uses this commit, verified in 2021-12-03 daily test zephyr_fetch_and_switch origin fd089b361d8aebbcb49cca989444aaeb0b6fbb4d"