Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Marc Herbert
    @marc-hb
    @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?
    RealYHD
    @RealYHD
    @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
    Kai Vehmanen
    @kv2019i
    hey @dbaluta , sorry, late reply. the script is this one https://github.com/thesofproject/sof/blob/stable-v2.0/scripts/xtensa-build-zephyr.sh
    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"
    Daniel Baluta
    @dbaluta
    @kv2019i thanks! This works for us now.
    lenghonglin
    @lenghonglin
    Hello @dbaluta , the issue with https://github.com/thesofproject/sof/issues/5077#issuecomment-995533938。 boot with imx8mp-mek-sof-wm9860.dtb, and the kernel is hang on
    image.png
    Daniel Baluta
    @dbaluta
    @lenghonglin yes. this is a known issue. because rootfs is not yet available.
    you have two options
    (1) compile firmware inside linux kernel
    (2) complile SOF as modules <M> and insmod them after kernel boots
    we use (2)
    lenghonglin
    @lenghonglin
    image.png
    Daniel Baluta
    @dbaluta
    @lenghonglin yes, that's OK! No you need to install the modules inside your rootfs.
    and then after bootings insmod them.
    I think you can find ho wto do this on google. otherwise, i can help you on Monday.
    lenghonglin
    @lenghonglin
    image.png
    @dbaluta ヽ(✿゚▽゚)ノ
    lenghonglin
    @lenghonglin
    @dbaluta Hello
    image.png
    this is sof firmware in rootfs, but i wanna to build sof which add some logs. <br> i check out sof to cc5ba3393 and build imx8m.
    i replace new sof firmware which i built to /lib/firmware/imx/sof/, but hang on
    image.png
    lenghonglin
    @lenghonglin
    this is default sof firmware info :
    Firmware info: version 1:5:0-cc5ba
    Firmware: ABI 3:16:0 Kernel ABI 3:11:0
    Linux OK8MP 5.4.70-2.3.0
    i only replace sof-imx8m.ri
    Daniel Baluta
    @dbaluta
    @lenghonglin you are still using linux kernel 5.4