Re: [Sound-open-firmware] Support for Tangier SoC
Hi Sven, Btw, best to subscribe as non member posts are blocked and delayed. On Tue, 2017-10-17 at 20:49 +0200, Sven Schwermer wrote:
Hi guys,
Thanks for your replies. I had tried a running a vanilla kernel on the Edison. There, the sst_pci driver is probed, but the platform data is not set and that’s basically where I got stuck because I couldn’t figure out where that’s supposed to be set. Is that usually ACPI’s job?
I dont think ACPI is used by the ADSP on Edison, I think it's purely a PCI device. Vanilla kernel wont work either atm, you will need my topic/sof-v4.13 branch from here :- git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git Note that this branch only works on the SOF 1.0-dev branches (that are not stable) and not the stable master branch. The stable SOF master firmware branch has a different IPC ABI and only works with the topic/reef kernels (that unfortunately dont support PCI mode on Edison) :(
What exactly should happen once the mrfld_sst SFI IPC is enumerated? I am lacking the big picture and the order of events here. Is there an overview document somewhere available online?
There is also more than one driver upstream. The sst driver is for Intel's closed source FW. The open source FW uses different ABIs and APIs to the closed source version, currently you need to blacklist the old SST modules in order to load the SOF FW and driver (this is being fixed in upstream atm)
I guess, the nocodec mode would be fine as a start.
Yes. Liam
Thanks, Sven
On 16 Oct 2017, at 17:59, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> wrote:
On 10/16/17 10:19 AM, Liam Girdwood wrote:
On Sun, 2017-10-15 at 19:51 +0200, Sven Schwermer wrote:
Hi.
I was wondering if the Tangier SoC (Merrifield platform) is or will be supported by SOF? I have the Intel Edison compute module in mind.
Yes, it _should_ work on Merrifield, but I don't have Edison HW so some things on the driver side might need some work. The 1.0-dev branch and sof-v4.13 kernel will probably be better for Edison than the stable 0.95 branch atm (mainly due to driver updates), but 1.0-dev is still has a few issues prior to doing an rc1 tag.
The main difference with Baytrail is pci/acpi enumeration, and sfi/acpi for the firmware. I've been wanting to enable Tangier for some time but could never figure out how to add a reference to an audio codec, so it'd likely work in 'nocodec' mode, with just the I2S signals on the connector.
On Wed, 2017-10-18 at 12:11 +0100, Liam Girdwood wrote:
Hi Sven,
Btw, best to subscribe as non member posts are blocked and delayed.
On Tue, 2017-10-17 at 20:49 +0200, Sven Schwermer wrote:
Hi guys,
Thanks for your replies. I had tried a running a vanilla kernel on the Edison. There, the sst_pci driver is probed, but the platform data is not set and that’s basically where I got stuck because I couldn’t figure out where that’s supposed to be set. Is that usually ACPI’s job?
I dont think ACPI is used by the ADSP on Edison, I think it's purely a PCI device. Vanilla kernel wont work either atm, you will need my topic/sof-v4.13 branch from here :-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git
Note that this branch only works on the SOF 1.0-dev branches (that are not stable) and not the stable master branch.
The stable SOF master firmware branch has a different IPC ABI and only works with the topic/reef kernels (that unfortunately dont support PCI mode on Edison) :(
What exactly should happen once the mrfld_sst SFI IPC is enumerated? I am lacking the big picture and the order of events here. Is there an overview document somewhere available online?
SoC documentation is here :- https://www.intel.com/content/www/us/en/processors/atom/atom-z8000-datasheet... https://www.intel.com/content/www/us/en/processors/atom/atom-z8000-datasheet... Liam
There is also more than one driver upstream. The sst driver is for Intel's closed source FW. The open source FW uses different ABIs and APIs to the closed source version, currently you need to blacklist the old SST modules in order to load the SOF FW and driver (this is being fixed in upstream atm)
I guess, the nocodec mode would be fine as a start.
Yes.
Liam
Thanks, Sven
On 16 Oct 2017, at 17:59, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> wrote:
On 10/16/17 10:19 AM, Liam Girdwood wrote:
On Sun, 2017-10-15 at 19:51 +0200, Sven Schwermer wrote:
Hi.
I was wondering if the Tangier SoC (Merrifield platform) is or will be supported by SOF? I have the Intel Edison compute module in mind.
Yes, it _should_ work on Merrifield, but I don't have Edison HW so some things on the driver side might need some work. The 1.0-dev branch and sof-v4.13 kernel will probably be better for Edison than the stable 0.95 branch atm (mainly due to driver updates), but 1.0-dev is still has a few issues prior to doing an rc1 tag.
The main difference with Baytrail is pci/acpi enumeration, and sfi/acpi for the firmware. I've been wanting to enable Tangier for some time but could never figure out how to add a reference to an audio codec, so it'd likely work in 'nocodec' mode, with just the I2S signals on the connector.
Liam, Thanks for the infos. I’ll try the SOF kernel and FW on the weekend. Isn’t the Tangier SoC in the Edison a variant of the Atom Z34xx series? At least, that’s what I found online. Sven
On 18 Oct 2017, at 13:15, Liam Girdwood <liam.r.girdwood@linux.intel.com> wrote:
On Wed, 2017-10-18 at 12:11 +0100, Liam Girdwood wrote: Hi Sven,
Btw, best to subscribe as non member posts are blocked and delayed.
On Tue, 2017-10-17 at 20:49 +0200, Sven Schwermer wrote: Hi guys,
Thanks for your replies. I had tried a running a vanilla kernel on the Edison. There, the sst_pci driver is probed, but the platform data is not set and that’s basically where I got stuck because I couldn’t figure out where that’s supposed to be set. Is that usually ACPI’s job?
I dont think ACPI is used by the ADSP on Edison, I think it's purely a PCI device. Vanilla kernel wont work either atm, you will need my topic/sof-v4.13 branch from here :-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git
Note that this branch only works on the SOF 1.0-dev branches (that are not stable) and not the stable master branch.
The stable SOF master firmware branch has a different IPC ABI and only works with the topic/reef kernels (that unfortunately dont support PCI mode on Edison) :(
What exactly should happen once the mrfld_sst SFI IPC is enumerated? I am lacking the big picture and the order of events here. Is there an overview document somewhere available online?
SoC documentation is here :-
https://www.intel.com/content/www/us/en/processors/atom/atom-z8000-datasheet...
https://www.intel.com/content/www/us/en/processors/atom/atom-z8000-datasheet...
Liam
There is also more than one driver upstream. The sst driver is for Intel's closed source FW. The open source FW uses different ABIs and APIs to the closed source version, currently you need to blacklist the old SST modules in order to load the SOF FW and driver (this is being fixed in upstream atm)
I guess, the nocodec mode would be fine as a start.
Yes.
Liam
Thanks, Sven
On 16 Oct 2017, at 17:59, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> wrote:
On 10/16/17 10:19 AM, Liam Girdwood wrote:
On Sun, 2017-10-15 at 19:51 +0200, Sven Schwermer wrote: Hi.
I was wondering if the Tangier SoC (Merrifield platform) is or will be supported by SOF? I have the Intel Edison compute module in mind.
Yes, it _should_ work on Merrifield, but I don't have Edison HW so some things on the driver side might need some work. The 1.0-dev branch and sof-v4.13 kernel will probably be better for Edison than the stable 0.95 branch atm (mainly due to driver updates), but 1.0-dev is still has a few issues prior to doing an rc1 tag.
The main difference with Baytrail is pci/acpi enumeration, and sfi/acpi for the firmware. I've been wanting to enable Tangier for some time but could never figure out how to add a reference to an audio codec, so it'd likely work in 'nocodec' mode, with just the I2S signals on the connector.
On Wed, 2017-10-18 at 22:22 +0200, Sven Schwermer wrote:
Liam,
Thanks for the infos. I’ll try the SOF kernel and FW on the weekend.
Isn’t the Tangier SoC in the Edison a variant of the Atom Z34xx series? At least, that’s what I found online.
I'm not an expert on the SoC sorry, but probably. Liam
On 10/19/17 4:11 PM, Liam Girdwood wrote:
On Wed, 2017-10-18 at 22:22 +0200, Sven Schwermer wrote:
Liam,
Thanks for the infos. I’ll try the SOF kernel and FW on the weekend.
Isn’t the Tangier SoC in the Edison a variant of the Atom Z34xx series? At least, that’s what I found online.
I'm not an expert on the SoC sorry, but probably.
It's the other way around I think, The Z34xx has two cores limited to 500MHz, in the initial phone designs the Tangier SoC ran faster - can't remember the details. For the audio IP there are no changes I believe and it's very similar to Baytrail. The main differences are pci/acpi/sfi which provides endless ways to make mistakes or miss issues.
Hi Liam, today, I tried getting SOF to run on my Edison. Here's what I did: - compiled the topic/sof-v4.13 branch - disabled everything SST related in the config - enabled the following: CONFIG_SND_SOC_SOF_PCI=m CONFIG_SND_SOC_SOF_ACPI=m CONFIG_SND_SOC_SOF_NOCODEC=y CONFIG_SND_SOC_SOF=y CONFIG_SND_SOC_SOF_INTEL=y CONFIG_SND_SOC_SOF_BAYTRAIL=m CONFIG_SND_SOC_SOF_APOLLOLAKE=m CONFIG_SND_SOC_SOF_CANNONLAKE=m - compiled the SOF from the 1.0-dev branch, following the instructions in the wiki Upon bootup I made sure, that the fw is located at /lib/firmware/intel/reef-byt.ri. Then I did the following: # insmod /mnt/snd-sof-intel-byt.ko # insmod /mnt/sof-pci-dev.ko sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) insmod: can't insert '/mnt/sof-pci-dev.ko': unknown symbol in module, or unknown parameter # insmod /mnt/snd-sof-intel-apl.ko # insmod /mnt/sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff29bfff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: error: invalid firmware signature sof-audio sof-audio: error: invalid FW header sof-audio sof-audio: error: failed to load DSP firmware -22 sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered There seem to be at least two issues here: 1. There is a memory mapping that can not be completed. 2. The firmware seems to have an invalid format. 3. The sof-pci-dev module seems to require either the apollo or coffee lake modules. Is that intentional or a bug? Does anyone know what could be wrong here? Sven On 10/18/2017 01:11 PM, Liam Girdwood wrote:
Hi Sven,
Btw, best to subscribe as non member posts are blocked and delayed.
On Tue, 2017-10-17 at 20:49 +0200, Sven Schwermer wrote:
Hi guys,
Thanks for your replies. I had tried a running a vanilla kernel on the Edison. There, the sst_pci driver is probed, but the platform data is not set and that’s basically where I got stuck because I couldn’t figure out where that’s supposed to be set. Is that usually ACPI’s job?
I dont think ACPI is used by the ADSP on Edison, I think it's purely a PCI device. Vanilla kernel wont work either atm, you will need my topic/sof-v4.13 branch from here :-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git
Note that this branch only works on the SOF 1.0-dev branches (that are not stable) and not the stable master branch.
The stable SOF master firmware branch has a different IPC ABI and only works with the topic/reef kernels (that unfortunately dont support PCI mode on Edison) :(
What exactly should happen once the mrfld_sst SFI IPC is enumerated? I am lacking the big picture and the order of events here. Is there an overview document somewhere available online?
There is also more than one driver upstream. The sst driver is for Intel's closed source FW. The open source FW uses different ABIs and APIs to the closed source version, currently you need to blacklist the old SST modules in order to load the SOF FW and driver (this is being fixed in upstream atm)
I guess, the nocodec mode would be fine as a start.
Yes.
Liam
Thanks, Sven
On 16 Oct 2017, at 17:59, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> wrote:
On 10/16/17 10:19 AM, Liam Girdwood wrote:
On Sun, 2017-10-15 at 19:51 +0200, Sven Schwermer wrote:
Hi.
I was wondering if the Tangier SoC (Merrifield platform) is or will be supported by SOF? I have the Intel Edison compute module in mind.
Yes, it _should_ work on Merrifield, but I don't have Edison HW so some things on the driver side might need some work. The 1.0-dev branch and sof-v4.13 kernel will probably be better for Edison than the stable 0.95 branch atm (mainly due to driver updates), but 1.0-dev is still has a few issues prior to doing an rc1 tag.
The main difference with Baytrail is pci/acpi enumeration, and sfi/acpi for the firmware. I've been wanting to enable Tangier for some time but could never figure out how to add a reference to an audio codec, so it'd likely work in 'nocodec' mode, with just the I2S signals on the connector.
On 10/22/17 10:28 PM, Sven Schwermer wrote:
Hi Liam,
today, I tried getting SOF to run on my Edison. Here's what I did:
- compiled the topic/sof-v4.13 branch - disabled everything SST related in the config - enabled the following: CONFIG_SND_SOC_SOF_PCI=m CONFIG_SND_SOC_SOF_ACPI=m CONFIG_SND_SOC_SOF_NOCODEC=y CONFIG_SND_SOC_SOF=y CONFIG_SND_SOC_SOF_INTEL=y CONFIG_SND_SOC_SOF_BAYTRAIL=m CONFIG_SND_SOC_SOF_APOLLOLAKE=m CONFIG_SND_SOC_SOF_CANNONLAKE=m
For the sake of simplicity, can you avoid enabling the last two, it seems to generate issues that we've not looked at yet.
- compiled the SOF from the 1.0-dev branch, following the instructions in the wiki
Upon bootup I made sure, that the fw is located at /lib/firmware/intel/reef-byt.ri. Then I did the following:
# insmod /mnt/snd-sof-intel-byt.ko # insmod /mnt/sof-pci-dev.ko sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) insmod: can't insert '/mnt/sof-pci-dev.ko': unknown symbol in module, or unknown parameter # insmod /mnt/snd-sof-intel-apl.ko # insmod /mnt/sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff29bfff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: error: invalid firmware signature sof-audio sof-audio: error: invalid FW header sof-audio sof-audio: error: failed to load DSP firmware -22 sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered
there was another report of a firmware issue signature issue that we are looking into, can you make sure you pull the last firmware (sof.git, soft.git) and Liam's branch? FYI, both Liam and I will only be able to help with delayed emails this week, thanks for your understanding.
There seem to be at least two issues here: 1. There is a memory mapping that can not be completed. 2. The firmware seems to have an invalid format. 3. The sof-pci-dev module seems to require either the apollo or coffee lake modules. Is that intentional or a bug?
Does anyone know what could be wrong here?
Sven
On 10/18/2017 01:11 PM, Liam Girdwood wrote:
Hi Sven,
Btw, best to subscribe as non member posts are blocked and delayed.
On Tue, 2017-10-17 at 20:49 +0200, Sven Schwermer wrote:
Hi guys,
Thanks for your replies. I had tried a running a vanilla kernel on the Edison. There, the sst_pci driver is probed, but the platform data is not set and that’s basically where I got stuck because I couldn’t figure out where that’s supposed to be set. Is that usually ACPI’s job?
I dont think ACPI is used by the ADSP on Edison, I think it's purely a PCI device. Vanilla kernel wont work either atm, you will need my topic/sof-v4.13 branch from here :-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git
Note that this branch only works on the SOF 1.0-dev branches (that are not stable) and not the stable master branch.
The stable SOF master firmware branch has a different IPC ABI and only works with the topic/reef kernels (that unfortunately dont support PCI mode on Edison) :(
What exactly should happen once the mrfld_sst SFI IPC is enumerated? I am lacking the big picture and the order of events here. Is there an overview document somewhere available online?
There is also more than one driver upstream. The sst driver is for Intel's closed source FW. The open source FW uses different ABIs and APIs to the closed source version, currently you need to blacklist the old SST modules in order to load the SOF FW and driver (this is being fixed in upstream atm)
I guess, the nocodec mode would be fine as a start.
Yes.
Liam
Thanks, Sven
On 16 Oct 2017, at 17:59, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> wrote:
On 10/16/17 10:19 AM, Liam Girdwood wrote:
On Sun, 2017-10-15 at 19:51 +0200, Sven Schwermer wrote:
Hi.
I was wondering if the Tangier SoC (Merrifield platform) is or will be supported by SOF? I have the Intel Edison compute module in mind.
Yes, it _should_ work on Merrifield, but I don't have Edison HW so some things on the driver side might need some work. The 1.0-dev branch and sof-v4.13 kernel will probably be better for Edison than the stable 0.95 branch atm (mainly due to driver updates), but 1.0-dev is still has a few issues prior to doing an rc1 tag.
The main difference with Baytrail is pci/acpi enumeration, and sfi/acpi for the firmware. I've been wanting to enable Tangier for some time but could never figure out how to add a reference to an audio codec, so it'd likely work in 'nocodec' mode, with just the I2S signals on the connector.
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Hi Pierre, I did indeed compile the wrong SOFT branch. Using the 1.0-dev branch with alsa utils & lib fresh from git, I managed to produce a valid firmware file. I also modified the SOF Kconfig to also build the PCI driver for Baytrail devices. I still get the memory mapping error in addition to new errors: # insmod snd-sof-intel-byt.ko # insmod sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: Firmware info: version 1:0- build 0 on Oct 22 2017:17:28:10 sof-audio sof-audio: firmware boot complete sof-audio sof-audio: error: ipc error for 0x90010000 size 0xc sof-audio sof-audio: error: cant set params for DMA for Trace-22 sof-audio sof-audio: error: failed to initialize trace -22 sof-audio sof-audio: Direct firmware load for intel/reef-byt.tplg failed with error -2 sof-audio sof-audio: error: tplg intel/reef-byt.tplg load failed with -2 sof-audio sof-audio: error: failed to load DSP topology -2 sof-audio sof-audio: ASoC: failed to probe component -2 sof-nocodec sof-nocodec: ASoC: failed to instantiate card -2 sof-nocodec: probe of sof-nocodec failed with error -2 # lsmod Module Size Used by Not tainted sof_pci_dev 16384 0 snd_sof_intel_byt 20480 1 sof_pci_dev Any sort of hints are appreciated. Thanks, Sven On 10/23/2017 06:31 AM, Pierre-Louis Bossart wrote:
On 10/22/17 10:28 PM, Sven Schwermer wrote:
Hi Liam,
today, I tried getting SOF to run on my Edison. Here's what I did:
- compiled the topic/sof-v4.13 branch - disabled everything SST related in the config - enabled the following: CONFIG_SND_SOC_SOF_PCI=m CONFIG_SND_SOC_SOF_ACPI=m CONFIG_SND_SOC_SOF_NOCODEC=y CONFIG_SND_SOC_SOF=y CONFIG_SND_SOC_SOF_INTEL=y CONFIG_SND_SOC_SOF_BAYTRAIL=m CONFIG_SND_SOC_SOF_APOLLOLAKE=m CONFIG_SND_SOC_SOF_CANNONLAKE=m
For the sake of simplicity, can you avoid enabling the last two, it seems to generate issues that we've not looked at yet.
- compiled the SOF from the 1.0-dev branch, following the instructions in the wiki
Upon bootup I made sure, that the fw is located at /lib/firmware/intel/reef-byt.ri. Then I did the following:
# insmod /mnt/snd-sof-intel-byt.ko # insmod /mnt/sof-pci-dev.ko sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) insmod: can't insert '/mnt/sof-pci-dev.ko': unknown symbol in module, or unknown parameter # insmod /mnt/snd-sof-intel-apl.ko # insmod /mnt/sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff29bfff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: error: invalid firmware signature sof-audio sof-audio: error: invalid FW header sof-audio sof-audio: error: failed to load DSP firmware -22 sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered
there was another report of a firmware issue signature issue that we are looking into, can you make sure you pull the last firmware (sof.git, soft.git) and Liam's branch?
FYI, both Liam and I will only be able to help with delayed emails this week, thanks for your understanding.
There seem to be at least two issues here: 1. There is a memory mapping that can not be completed. 2. The firmware seems to have an invalid format. 3. The sof-pci-dev module seems to require either the apollo or coffee lake modules. Is that intentional or a bug?
Does anyone know what could be wrong here?
Sven
On 10/18/2017 01:11 PM, Liam Girdwood wrote:
Hi Sven,
Btw, best to subscribe as non member posts are blocked and delayed.
On Tue, 2017-10-17 at 20:49 +0200, Sven Schwermer wrote:
Hi guys,
Thanks for your replies. I had tried a running a vanilla kernel on the Edison. There, the sst_pci driver is probed, but the platform data is not set and that’s basically where I got stuck because I couldn’t figure out where that’s supposed to be set. Is that usually ACPI’s job?
I dont think ACPI is used by the ADSP on Edison, I think it's purely a PCI device. Vanilla kernel wont work either atm, you will need my topic/sof-v4.13 branch from here :-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git
Note that this branch only works on the SOF 1.0-dev branches (that are not stable) and not the stable master branch.
The stable SOF master firmware branch has a different IPC ABI and only works with the topic/reef kernels (that unfortunately dont support PCI mode on Edison) :(
What exactly should happen once the mrfld_sst SFI IPC is enumerated? I am lacking the big picture and the order of events here. Is there an overview document somewhere available online?
There is also more than one driver upstream. The sst driver is for Intel's closed source FW. The open source FW uses different ABIs and APIs to the closed source version, currently you need to blacklist the old SST modules in order to load the SOF FW and driver (this is being fixed in upstream atm)
I guess, the nocodec mode would be fine as a start.
Yes.
Liam
Thanks, Sven
On 16 Oct 2017, at 17:59, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> wrote:
On 10/16/17 10:19 AM, Liam Girdwood wrote:
On Sun, 2017-10-15 at 19:51 +0200, Sven Schwermer wrote: > Hi. > > I was wondering if the Tangier SoC (Merrifield platform) is or > will be > supported by SOF? I have the Intel Edison compute module in mind. > Yes, it _should_ work on Merrifield, but I don't have Edison HW so some things on the driver side might need some work. The 1.0-dev branch and sof-v4.13 kernel will probably be better for Edison than the stable 0.95 branch atm (mainly due to driver updates), but 1.0-dev is still has a few issues prior to doing an rc1 tag.
The main difference with Baytrail is pci/acpi enumeration, and sfi/acpi for the firmware. I've been wanting to enable Tangier for some time but could never figure out how to add a reference to an audio codec, so it'd likely work in 'nocodec' mode, with just the I2S signals on the connector.
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Just back today. On Tue, 2017-10-24 at 22:11 +0200, Sven Schwermer wrote:
Hi Pierre,
I did indeed compile the wrong SOFT branch. Using the 1.0-dev branch with alsa utils & lib fresh from git, I managed to produce a valid firmware file. I also modified the SOF Kconfig to also build the PCI driver for Baytrail devices. I still get the memory mapping error in addition to new errors:
# insmod snd-sof-intel-byt.ko # insmod sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: Firmware info: version 1:0- build 0 on Oct 22 2017:17:28:10 sof-audio sof-audio: firmware boot complete sof-audio sof-audio: error: ipc error for 0x90010000 size 0xc sof-audio sof-audio: error: cant set params for DMA for Trace-22 sof-audio sof-audio: error: failed to initialize trace -22
Can you check you have the latest kernel ? my HEAD is at :- 09376b5f404b5185f9e7732879821cf9dbb83dfe
sof-audio sof-audio: Direct firmware load for intel/reef-byt.tplg failed with error -2 sof-audio sof-audio: error: tplg intel/reef-byt.tplg load failed with -2
The topology files are generated using the latest alsa topology compiler in alsa-utils and alsa-lib.git. The topology sources are part of the SOF tools repo (alongside rimage) Liam
sof-audio sof-audio: error: failed to load DSP topology -2 sof-audio sof-audio: ASoC: failed to probe component -2 sof-nocodec sof-nocodec: ASoC: failed to instantiate card -2 sof-nocodec: probe of sof-nocodec failed with error -2
# lsmod Module Size Used by Not tainted sof_pci_dev 16384 0 snd_sof_intel_byt 20480 1 sof_pci_dev
Any sort of hints are appreciated.
Thanks, Sven
On 10/23/2017 06:31 AM, Pierre-Louis Bossart wrote:
On 10/22/17 10:28 PM, Sven Schwermer wrote:
Hi Liam,
today, I tried getting SOF to run on my Edison. Here's what I did:
- compiled the topic/sof-v4.13 branch - disabled everything SST related in the config - enabled the following: CONFIG_SND_SOC_SOF_PCI=m CONFIG_SND_SOC_SOF_ACPI=m CONFIG_SND_SOC_SOF_NOCODEC=y CONFIG_SND_SOC_SOF=y CONFIG_SND_SOC_SOF_INTEL=y CONFIG_SND_SOC_SOF_BAYTRAIL=m CONFIG_SND_SOC_SOF_APOLLOLAKE=m CONFIG_SND_SOC_SOF_CANNONLAKE=m
For the sake of simplicity, can you avoid enabling the last two, it seems to generate issues that we've not looked at yet.
- compiled the SOF from the 1.0-dev branch, following the instructions in the wiki
Upon bootup I made sure, that the fw is located at /lib/firmware/intel/reef-byt.ri. Then I did the following:
# insmod /mnt/snd-sof-intel-byt.ko # insmod /mnt/sof-pci-dev.ko sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) insmod: can't insert '/mnt/sof-pci-dev.ko': unknown symbol in module, or unknown parameter # insmod /mnt/snd-sof-intel-apl.ko # insmod /mnt/sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff29bfff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: error: invalid firmware signature sof-audio sof-audio: error: invalid FW header sof-audio sof-audio: error: failed to load DSP firmware -22 sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered
there was another report of a firmware issue signature issue that we are looking into, can you make sure you pull the last firmware (sof.git, soft.git) and Liam's branch?
FYI, both Liam and I will only be able to help with delayed emails this week, thanks for your understanding.
There seem to be at least two issues here: 1. There is a memory mapping that can not be completed. 2. The firmware seems to have an invalid format. 3. The sof-pci-dev module seems to require either the apollo or coffee lake modules. Is that intentional or a bug?
Does anyone know what could be wrong here?
Sven
On 10/18/2017 01:11 PM, Liam Girdwood wrote:
Hi Sven,
Btw, best to subscribe as non member posts are blocked and delayed.
On Tue, 2017-10-17 at 20:49 +0200, Sven Schwermer wrote:
Hi guys,
Thanks for your replies. I had tried a running a vanilla kernel on the Edison. There, the sst_pci driver is probed, but the platform data is not set and that’s basically where I got stuck because I couldn’t figure out where that’s supposed to be set. Is that usually ACPI’s job?
I dont think ACPI is used by the ADSP on Edison, I think it's purely a PCI device. Vanilla kernel wont work either atm, you will need my topic/sof-v4.13 branch from here :-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git
Note that this branch only works on the SOF 1.0-dev branches (that are not stable) and not the stable master branch.
The stable SOF master firmware branch has a different IPC ABI and only works with the topic/reef kernels (that unfortunately dont support PCI mode on Edison) :(
What exactly should happen once the mrfld_sst SFI IPC is enumerated? I am lacking the big picture and the order of events here. Is there an overview document somewhere available online?
There is also more than one driver upstream. The sst driver is for Intel's closed source FW. The open source FW uses different ABIs and APIs to the closed source version, currently you need to blacklist the old SST modules in order to load the SOF FW and driver (this is being fixed in upstream atm)
I guess, the nocodec mode would be fine as a start.
Yes.
Liam
Thanks, Sven
On 16 Oct 2017, at 17:59, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> wrote:
On 10/16/17 10:19 AM, Liam Girdwood wrote: > On Sun, 2017-10-15 at 19:51 +0200, Sven Schwermer wrote: >> Hi. >> >> I was wondering if the Tangier SoC (Merrifield platform) is or >> will be >> supported by SOF? I have the Intel Edison compute module in mind. >> > Yes, it _should_ work on Merrifield, but I don't have Edison HW so > some > things on the driver side might need some work. > The 1.0-dev branch and sof-v4.13 kernel will probably be better for > Edison than the stable 0.95 branch atm (mainly due to driver > updates), > but 1.0-dev is still has a few issues prior to doing an rc1 tag.
The main difference with Baytrail is pci/acpi enumeration, and sfi/acpi for the firmware. I've been wanting to enable Tangier for some time but could never figure out how to add a reference to an audio codec, so it'd likely work in 'nocodec' mode, with just the I2S signals on the connector.
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Hi Liam, I think, it works now. I had forgotten to copy the topology file to /lib/firmware/intel. I have now taken the reef-byt-nocodec.tplg file and renamed it to reef-byt.tplg. The full verbosity dmesg log can be found here: https://pastebin.com/jnCxLMHm I still get the error setting up the tracing, but I guess that's mostly for debugging: sof-audio sof-audio: dma_trace_pages: 16 sof-audio sof-audio: ipc: send 0x90010000 sof-audio sof-audio: error: ipc error for 0x90010000 size 0xc sof-audio sof-audio: error: cant set params for DMA for Trace-22 sof-audio sof-audio: error: failed to initialize trace -22 I got a couple more questions: 1. Do the SOF drivers take care of the pin multiplexing for the I2S pins? 2. In the nocodec mode, is it possible to change sample frequency, DAI mode (I2S, PCM, ...) etc from userland? How? 3. What's the best way to test this now (assuming the codec had been setup manually)? Thanks! Sven On 10/30/2017 06:12 PM, Liam Girdwood wrote:
Just back today.
On Tue, 2017-10-24 at 22:11 +0200, Sven Schwermer wrote:
Hi Pierre,
I did indeed compile the wrong SOFT branch. Using the 1.0-dev branch with alsa utils & lib fresh from git, I managed to produce a valid firmware file. I also modified the SOF Kconfig to also build the PCI driver for Baytrail devices. I still get the memory mapping error in addition to new errors:
# insmod snd-sof-intel-byt.ko # insmod sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: Firmware info: version 1:0- build 0 on Oct 22 2017:17:28:10 sof-audio sof-audio: firmware boot complete sof-audio sof-audio: error: ipc error for 0x90010000 size 0xc sof-audio sof-audio: error: cant set params for DMA for Trace-22 sof-audio sof-audio: error: failed to initialize trace -22
Can you check you have the latest kernel ? my HEAD is at :-
09376b5f404b5185f9e7732879821cf9dbb83dfe
sof-audio sof-audio: Direct firmware load for intel/reef-byt.tplg failed with error -2 sof-audio sof-audio: error: tplg intel/reef-byt.tplg load failed with -2
The topology files are generated using the latest alsa topology compiler in alsa-utils and alsa-lib.git. The topology sources are part of the SOF tools repo (alongside rimage)
Liam
sof-audio sof-audio: error: failed to load DSP topology -2 sof-audio sof-audio: ASoC: failed to probe component -2 sof-nocodec sof-nocodec: ASoC: failed to instantiate card -2 sof-nocodec: probe of sof-nocodec failed with error -2
# lsmod Module Size Used by Not tainted sof_pci_dev 16384 0 snd_sof_intel_byt 20480 1 sof_pci_dev
Any sort of hints are appreciated.
Thanks, Sven
On 10/23/2017 06:31 AM, Pierre-Louis Bossart wrote:
On 10/22/17 10:28 PM, Sven Schwermer wrote:
Hi Liam,
today, I tried getting SOF to run on my Edison. Here's what I did:
- compiled the topic/sof-v4.13 branch - disabled everything SST related in the config - enabled the following: CONFIG_SND_SOC_SOF_PCI=m CONFIG_SND_SOC_SOF_ACPI=m CONFIG_SND_SOC_SOF_NOCODEC=y CONFIG_SND_SOC_SOF=y CONFIG_SND_SOC_SOF_INTEL=y CONFIG_SND_SOC_SOF_BAYTRAIL=m CONFIG_SND_SOC_SOF_APOLLOLAKE=m CONFIG_SND_SOC_SOF_CANNONLAKE=m
For the sake of simplicity, can you avoid enabling the last two, it seems to generate issues that we've not looked at yet.
- compiled the SOF from the 1.0-dev branch, following the instructions in the wiki
Upon bootup I made sure, that the fw is located at /lib/firmware/intel/reef-byt.ri. Then I did the following:
# insmod /mnt/snd-sof-intel-byt.ko # insmod /mnt/sof-pci-dev.ko sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) insmod: can't insert '/mnt/sof-pci-dev.ko': unknown symbol in module, or unknown parameter # insmod /mnt/snd-sof-intel-apl.ko # insmod /mnt/sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff29bfff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: error: invalid firmware signature sof-audio sof-audio: error: invalid FW header sof-audio sof-audio: error: failed to load DSP firmware -22 sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered
there was another report of a firmware issue signature issue that we are looking into, can you make sure you pull the last firmware (sof.git, soft.git) and Liam's branch?
FYI, both Liam and I will only be able to help with delayed emails this week, thanks for your understanding.
There seem to be at least two issues here: 1. There is a memory mapping that can not be completed. 2. The firmware seems to have an invalid format. 3. The sof-pci-dev module seems to require either the apollo or coffee lake modules. Is that intentional or a bug?
Does anyone know what could be wrong here?
Sven
On 10/18/2017 01:11 PM, Liam Girdwood wrote:
Hi Sven,
Btw, best to subscribe as non member posts are blocked and delayed.
On Tue, 2017-10-17 at 20:49 +0200, Sven Schwermer wrote:
Hi guys,
Thanks for your replies. I had tried a running a vanilla kernel on the Edison. There, the sst_pci driver is probed, but the platform data is not set and that’s basically where I got stuck because I couldn’t figure out where that’s supposed to be set. Is that usually ACPI’s job?
I dont think ACPI is used by the ADSP on Edison, I think it's purely a PCI device. Vanilla kernel wont work either atm, you will need my topic/sof-v4.13 branch from here :-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git
Note that this branch only works on the SOF 1.0-dev branches (that are not stable) and not the stable master branch.
The stable SOF master firmware branch has a different IPC ABI and only works with the topic/reef kernels (that unfortunately dont support PCI mode on Edison) :(
What exactly should happen once the mrfld_sst SFI IPC is enumerated? I am lacking the big picture and the order of events here. Is there an overview document somewhere available online?
There is also more than one driver upstream. The sst driver is for Intel's closed source FW. The open source FW uses different ABIs and APIs to the closed source version, currently you need to blacklist the old SST modules in order to load the SOF FW and driver (this is being fixed in upstream atm)
I guess, the nocodec mode would be fine as a start.
Yes.
Liam
Thanks, Sven
> On 16 Oct 2017, at 17:59, Pierre-Louis Bossart > <pierre-louis.bossart@linux.intel.com> wrote: > > On 10/16/17 10:19 AM, Liam Girdwood wrote: >> On Sun, 2017-10-15 at 19:51 +0200, Sven Schwermer wrote: >>> Hi. >>> >>> I was wondering if the Tangier SoC (Merrifield platform) is or >>> will be >>> supported by SOF? I have the Intel Edison compute module in mind. >>> >> Yes, it _should_ work on Merrifield, but I don't have Edison HW so >> some >> things on the driver side might need some work. >> The 1.0-dev branch and sof-v4.13 kernel will probably be better for >> Edison than the stable 0.95 branch atm (mainly due to driver >> updates), >> but 1.0-dev is still has a few issues prior to doing an rc1 tag. > > The main difference with Baytrail is pci/acpi enumeration, and > sfi/acpi for the firmware. I've been wanting to enable Tangier for > some time but could never figure out how to add a reference to an > audio codec, so it'd likely work in 'nocodec' mode, with just the > I2S signals on the connector.
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Sat, 2017-11-04 at 12:49 +0100, Sven Schwermer wrote:
Hi Liam,
I think, it works now. I had forgotten to copy the topology file to /lib/firmware/intel. I have now taken the reef-byt-nocodec.tplg file and renamed it to reef-byt.tplg.
The full verbosity dmesg log can be found here: https://pastebin.com/jnCxLMHm
I still get the error setting up the tracing, but I guess that's mostly for debugging: sof-audio sof-audio: dma_trace_pages: 16 sof-audio sof-audio: ipc: send 0x90010000 sof-audio sof-audio: error: ipc error for 0x90010000 size 0xc sof-audio sof-audio: error: cant set params for DMA for Trace-22 sof-audio sof-audio: error: failed to initialize trace -22
Yes, this is being fixed atm. We have reverted the DMA trace until the fix is ready though.
I got a couple more questions: 1. Do the SOF drivers take care of the pin multiplexing for the I2S pins?
Not atm, the pin muxing is usually set correctly by the BIOS for x86, but I guess this will need set somewhere in the kernel to enable your SSP port.
2. In the nocodec mode, is it possible to change sample frequency, DAI mode (I2S, PCM, ...) etc from userland? How?
The SSP settings are all set in the topology file. You will need to edit your reef-byt-nocodec.m4 and set the desired mode etc and rebuild the topology. Btw, the topology format is still WiP and missing proper docs, but it will generate a reef-byt-nocodec.conf file that can be used to help work out settings atm. The sample rate can be changed with aplay.
3. What's the best way to test this now (assuming the codec had been setup manually)?
Without a codec you should be able to see the audio position update correctly using aplay. If you have a scope you should see the BCLK, FRM etc toggling. 1.1. will add loopback support so you will be able to loopback the SSP and capture what you are playing. Liam
Thanks!
Sven
On 10/30/2017 06:12 PM, Liam Girdwood wrote:
Just back today.
On Tue, 2017-10-24 at 22:11 +0200, Sven Schwermer wrote:
Hi Pierre,
I did indeed compile the wrong SOFT branch. Using the 1.0-dev branch with alsa utils & lib fresh from git, I managed to produce a valid firmware file. I also modified the SOF Kconfig to also build the PCI driver for Baytrail devices. I still get the memory mapping error in addition to new errors:
# insmod snd-sof-intel-byt.ko # insmod sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: Firmware info: version 1:0- build 0 on Oct 22 2017:17:28:10 sof-audio sof-audio: firmware boot complete sof-audio sof-audio: error: ipc error for 0x90010000 size 0xc sof-audio sof-audio: error: cant set params for DMA for Trace-22 sof-audio sof-audio: error: failed to initialize trace -22
Can you check you have the latest kernel ? my HEAD is at :-
09376b5f404b5185f9e7732879821cf9dbb83dfe
sof-audio sof-audio: Direct firmware load for intel/reef-byt.tplg failed with error -2 sof-audio sof-audio: error: tplg intel/reef-byt.tplg load failed with -2
The topology files are generated using the latest alsa topology compiler in alsa-utils and alsa-lib.git. The topology sources are part of the SOF tools repo (alongside rimage)
Liam
sof-audio sof-audio: error: failed to load DSP topology -2 sof-audio sof-audio: ASoC: failed to probe component -2 sof-nocodec sof-nocodec: ASoC: failed to instantiate card -2 sof-nocodec: probe of sof-nocodec failed with error -2
# lsmod Module Size Used by Not tainted sof_pci_dev 16384 0 snd_sof_intel_byt 20480 1 sof_pci_dev
Any sort of hints are appreciated.
Thanks, Sven
On 10/23/2017 06:31 AM, Pierre-Louis Bossart wrote:
On 10/22/17 10:28 PM, Sven Schwermer wrote:
Hi Liam,
today, I tried getting SOF to run on my Edison. Here's what I did:
- compiled the topic/sof-v4.13 branch - disabled everything SST related in the config - enabled the following: CONFIG_SND_SOC_SOF_PCI=m CONFIG_SND_SOC_SOF_ACPI=m CONFIG_SND_SOC_SOF_NOCODEC=y CONFIG_SND_SOC_SOF=y CONFIG_SND_SOC_SOF_INTEL=y CONFIG_SND_SOC_SOF_BAYTRAIL=m CONFIG_SND_SOC_SOF_APOLLOLAKE=m CONFIG_SND_SOC_SOF_CANNONLAKE=m
For the sake of simplicity, can you avoid enabling the last two, it seems to generate issues that we've not looked at yet.
- compiled the SOF from the 1.0-dev branch, following the instructions in the wiki
Upon bootup I made sure, that the fw is located at /lib/firmware/intel/reef-byt.ri. Then I did the following:
# insmod /mnt/snd-sof-intel-byt.ko # insmod /mnt/sof-pci-dev.ko sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_cnl_ops (err 0) sof_pci_dev: Unknown symbol snd_sof_bxt_ops (err 0) insmod: can't insert '/mnt/sof-pci-dev.ko': unknown symbol in module, or unknown parameter # insmod /mnt/snd-sof-intel-apl.ko # insmod /mnt/sof-pci-dev.ko sof-audio-pci 0000:00:0d.0: No matching ASoC machine driver found - using nocodec sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered resource sanity check: requesting [mem 0xff200000-0xff3fffff], which spans more than 0000:00:0e.0 [mem 0xff298000-0xff29bfff] caller byt_probe+0xfb/0x1730 [snd_sof_intel_byt] mapping multiple BARs pmd_set_huge: Cannot satisfy [mem 0x05e00000-0x06000000] with a huge-page mapping due to MTRR override. sof-audio sof-audio: error: invalid firmware signature sof-audio sof-audio: error: invalid FW header sof-audio sof-audio: error: failed to load DSP firmware -22 sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered
there was another report of a firmware issue signature issue that we are looking into, can you make sure you pull the last firmware (sof.git, soft.git) and Liam's branch?
FYI, both Liam and I will only be able to help with delayed emails this week, thanks for your understanding.
There seem to be at least two issues here: 1. There is a memory mapping that can not be completed. 2. The firmware seems to have an invalid format. 3. The sof-pci-dev module seems to require either the apollo or coffee lake modules. Is that intentional or a bug?
Does anyone know what could be wrong here?
Sven
On 10/18/2017 01:11 PM, Liam Girdwood wrote:
Hi Sven,
Btw, best to subscribe as non member posts are blocked and delayed.
On Tue, 2017-10-17 at 20:49 +0200, Sven Schwermer wrote: > Hi guys, > > Thanks for your replies. I had tried a running a vanilla kernel on the > Edison. There, the sst_pci driver is probed, but the platform data is > not set and that’s basically where I got stuck because I couldn’t > figure out where that’s supposed to be set. Is that usually ACPI’s > job? >
I dont think ACPI is used by the ADSP on Edison, I think it's purely a PCI device. Vanilla kernel wont work either atm, you will need my topic/sof-v4.13 branch from here :-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git
Note that this branch only works on the SOF 1.0-dev branches (that are not stable) and not the stable master branch.
The stable SOF master firmware branch has a different IPC ABI and only works with the topic/reef kernels (that unfortunately dont support PCI mode on Edison) :(
> What exactly should happen once the mrfld_sst SFI IPC is enumerated? I > am lacking the big picture and the order of events here. Is there an > overview document somewhere available online? >
There is also more than one driver upstream. The sst driver is for Intel's closed source FW. The open source FW uses different ABIs and APIs to the closed source version, currently you need to blacklist the old SST modules in order to load the SOF FW and driver (this is being fixed in upstream atm)
> I guess, the nocodec mode would be fine as a start. >
Yes.
Liam
> Thanks, Sven > >> On 16 Oct 2017, at 17:59, Pierre-Louis Bossart >> <pierre-louis.bossart@linux.intel.com> wrote: >> >> On 10/16/17 10:19 AM, Liam Girdwood wrote: >>> On Sun, 2017-10-15 at 19:51 +0200, Sven Schwermer wrote: >>>> Hi. >>>> >>>> I was wondering if the Tangier SoC (Merrifield platform) is or >>>> will be >>>> supported by SOF? I have the Intel Edison compute module in mind. >>>> >>> Yes, it _should_ work on Merrifield, but I don't have Edison HW so >>> some >>> things on the driver side might need some work. >>> The 1.0-dev branch and sof-v4.13 kernel will probably be better for >>> Edison than the stable 0.95 branch atm (mainly due to driver >>> updates), >>> but 1.0-dev is still has a few issues prior to doing an rc1 tag. >> >> The main difference with Baytrail is pci/acpi enumeration, and >> sfi/acpi for the firmware. I've been wanting to enable Tangier for >> some time but could never figure out how to add a reference to an >> audio codec, so it'd likely work in 'nocodec' mode, with just the >> I2S signals on the connector. >
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
participants (4)
-
Liam Girdwood -
Liam Girdwood -
Pierre-Louis Bossart -
Sven Schwermer