[Sound-open-firmware] Using the Qemu DSP emulator
Hi,
I'm following the instruction on SOF wiki page on how to use the emulator [1] and both VM0 and VM1 are up, anyhow SOF DSP device isn't probed.
How do you do it in your qemu setup?
Are you using an ACPI file? (or DT?).
I'm running the following commands:
# ./xtensa-host.sh bxt # ./x86-host.sh bxt
and pointing qemu to load my bzimage.
thanks, Daniel.
[1] https://www.alsa-project.org/main/index.php/Firmware#Using_the_Qemu_DSP_emul...
On Fri, 2018-01-26 at 15:42 +0200, Daniel Baluta wrote:
Hi,
I'm following the instruction on SOF wiki page on how to use the emulator [1] and both VM0 and VM1 are up, anyhow SOF DSP device isn't probed.
How do you do it in your qemu setup?
So for host VM I usually install my favourite distro on a disk image and boot this image (including kernel) directly using the x86-host.sh scripts. There are quite a lot of tools that can help create this image, but it's bog standard Linux VM image with your custom kernel.
Btw, the kernel can be updated on this image using the normal methods within the VM.
Are you using an ACPI file? (or DT?).
The old Qemu release 2.7 and below used some imported ACPI files, but newer releases have the ACPI data coded in C and built into the qemu binary. I've recently updated qemu on the git repo to 2.9 so this will be using C based ACPI (you should be able to find these changes in git log for audio DSP ACPI device).
I'm running the following commands:
# ./xtensa-host.sh bxt
ok, you should see some output here.
# ./x86-host.sh bxt
and here too.
and pointing qemu to load my bzimage.
No need to point to a bzImage, just point it to your OS File system image (which will contain the kernel).
Liam
thanks, Daniel.
[1] https://www.alsa-project.org/main/index.php/Firmware#Using_the_Qe mu_DSP_emulator _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Hi Liam,
Thanks a lot for your answer. Still one question inline:
On Fri, Jan 26, 2018 at 4:07 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 15:42 +0200, Daniel Baluta wrote:
Hi,
I'm following the instruction on SOF wiki page on how to use the emulator [1] and both VM0 and VM1 are up, anyhow SOF DSP device isn't probed.
How do you do it in your qemu setup?
So for host VM I usually install my favourite distro on a disk image and boot this image (including kernel) directly using the x86-host.sh scripts. There are quite a lot of tools that can help create this image, but it's bog standard Linux VM image with your custom kernel.
Btw, the kernel can be updated on this image using the normal methods within the VM.
So, I think I have setup everything correct (btw I use SOF modules builtin in the kernel image, because I find it easier).
Anyhow, I expect that the function sof_probe from sound/soc/sof/core.c to be called but it isn't :).
Any idea why?
Now, this function should be called as a result of a platform device named "sof-audio" being somehow registered.
thanks, Daniel.
On Fri, 2018-01-26 at 17:54 +0200, Daniel Baluta wrote:
Hi Liam,
Thanks a lot for your answer. Still one question inline:
On Fri, Jan 26, 2018 at 4:07 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 15:42 +0200, Daniel Baluta wrote:
Hi,
I'm following the instruction on SOF wiki page on how to use the emulator [1] and both VM0 and VM1 are up, anyhow SOF DSP device isn't probed.
How do you do it in your qemu setup?
So for host VM I usually install my favourite distro on a disk image and boot this image (including kernel) directly using the x86-host.sh scripts. There are quite a lot of tools that can help create this image, but it's bog standard Linux VM image with your custom kernel.
Btw, the kernel can be updated on this image using the normal methods within the VM.
So, I think I have setup everything correct (btw I use SOF modules builtin in the kernel image, because I find it easier).
I recommend modules as the drivers need a mounted FS to load firmware and topologies. built-in can result in some races between driver and FS being ready....
Anyhow, I expect that the function sof_probe from sound/soc/sof/core.c to be called but it isn't :).
Any idea why?
I assume the ACPI device is registered ? Pls check sysfs and make sure the device ID is listed with the other ACPI devices and returns status 15.
Also pls check that the older SST drivers have not been loaded by default. If so, they can be blacklisted atm :-
cat /etc/modprobe.d/blacklist-dsp.conf blacklist snd_soc_sst_acpi blacklist snd_soc_sst_dsp blacklist snd_soc_sst_firmware blacklist snd_soc_sst_ipc blacklist snd_soc_sst_match blacklist snd_soc_sst_mfld-platform blacklist snd_soc_skl blacklist snd_hda_intel blacklist snd_soc_sst_byt_cht_nocodec blacklist snd_soc_sst_atom_hifi2_platform blacklist snd_intel_sst_core blacklist snd_intel_sst_acpi
Now, this function should be called as a result of a platform device named "sof-audio" being somehow registered.
You may want to attach the relevant part of your dmesg showing ASoC/ALSA probing.
Liam
thanks, Daniel. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Fri, Jan 26, 2018 at 6:24 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 17:54 +0200, Daniel Baluta wrote:
Hi Liam,
Thanks a lot for your answer. Still one question inline:
On Fri, Jan 26, 2018 at 4:07 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 15:42 +0200, Daniel Baluta wrote:
Hi,
I'm following the instruction on SOF wiki page on how to use the emulator [1] and both VM0 and VM1 are up, anyhow SOF DSP device isn't probed.
How do you do it in your qemu setup?
So for host VM I usually install my favourite distro on a disk image and boot this image (including kernel) directly using the x86-host.sh scripts. There are quite a lot of tools that can help create this image, but it's bog standard Linux VM image with your custom kernel.
Btw, the kernel can be updated on this image using the normal methods within the VM.
So, I think I have setup everything correct (btw I use SOF modules builtin in the kernel image, because I find it easier).
I recommend modules as the drivers need a mounted FS to load firmware and topologies. built-in can result in some races between driver and FS being ready....
Anyhow, I expect that the function sof_probe from sound/soc/sof/core.c to be called but it isn't :).
Any idea why?
I assume the ACPI device is registered ? Pls check sysfs and make sure the device ID is listed with the other ACPI devices and returns status 15.
Also pls check that the older SST drivers have not been loaded by default. If so, they can be blacklisted atm :-
cat /etc/modprobe.d/blacklist-dsp.conf blacklist snd_soc_sst_acpi blacklist snd_soc_sst_dsp blacklist snd_soc_sst_firmware blacklist snd_soc_sst_ipc blacklist snd_soc_sst_match blacklist snd_soc_sst_mfld-platform blacklist snd_soc_skl blacklist snd_hda_intel blacklist snd_soc_sst_byt_cht_nocodec blacklist snd_soc_sst_atom_hifi2_platform blacklist snd_intel_sst_core blacklist snd_intel_sst_acpi
Yes, this is the reason :) And it is even written on the wiki.
Sorry for the noise. It works now.
thanks, Daniel.
On Fri, Jan 26, 2018 at 6:24 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 17:54 +0200, Daniel Baluta wrote:
Hi Liam,
Thanks a lot for your answer. Still one question inline:
On Fri, Jan 26, 2018 at 4:07 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 15:42 +0200, Daniel Baluta wrote:
Hi,
I'm following the instruction on SOF wiki page on how to use the emulator [1] and both VM0 and VM1 are up, anyhow SOF DSP device isn't probed.
How do you do it in your qemu setup?
So for host VM I usually install my favourite distro on a disk image and boot this image (including kernel) directly using the x86-host.sh scripts. There are quite a lot of tools that can help create this image, but it's bog standard Linux VM image with your custom kernel.
Btw, the kernel can be updated on this image using the normal methods within the VM.
So, I think I have setup everything correct (btw I use SOF modules builtin in the kernel image, because I find it easier).
I recommend modules as the drivers need a mounted FS to load firmware and topologies. built-in can result in some races between driver and FS being ready....
Anyhow, I expect that the function sof_probe from sound/soc/sof/core.c to be called but it isn't :).
Any idea why?
I assume the ACPI device is registered ? Pls check sysfs and make sure the device ID is listed with the other ACPI devices and returns status 15.
Also pls check that the older SST drivers have not been loaded by default. If so, they can be blacklisted atm :-
cat /etc/modprobe.d/blacklist-dsp.conf blacklist snd_soc_sst_acpi blacklist snd_soc_sst_dsp blacklist snd_soc_sst_firmware blacklist snd_soc_sst_ipc blacklist snd_soc_sst_match blacklist snd_soc_sst_mfld-platform blacklist snd_soc_skl blacklist snd_hda_intel blacklist snd_soc_sst_byt_cht_nocodec blacklist snd_soc_sst_atom_hifi2_platform blacklist snd_intel_sst_core blacklist snd_intel_sst_acpi
Now, this function should be called as a result of a platform device named "sof-audio" being somehow registered.
You may want to attach the relevant part of your dmesg showing ASoC/ALSA probing.
Hi Liam,
So after compiling out SST drivers I can see the probe function from sof-pci-dev module called twice.
I use the command line from ./x86-host.sh bxt which tells qemu that there are two PCI sound devices:
1) -device bxt-intel-hda,id=sound0,bus=pci.0,addr=0xe 2) -device driver=adsp-bxt
After starting qemu indeed I can see those two pci devices:
$ cat /sys/bus/pci/devices/0000:00:04.0/device 0x5a98
$ cat /sys/bus/pci/devices/0000:00:04.0/config 0000000 8086 5a98 0103 0000 0001 0401 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 1af4 1100 0000030 0000 0000 0000 0000 0000 0000 020a 0000 0000040 0000 0000 0000 0000 0000 0000 0000 0000 * 0000100
$ cat /sys/bus/pci/devices/0000:00:0e.0/device 0x5a98
$ cat /sys/bus/pci/devices/0000:00:0e.0/config
0000000 8086 5a98 0103 0010 0003 0403 0000 0000 0000010 0000 fc07 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 1af4 1100 0000030 0000 0000 0060 0000 0000 0000 010a 0000 0000040 0001 0000 0000 0000 0000 0000 0000 0000 0000050 0000 0000 0000 0000 0000 0000 0000 0000 0000060 0005 0080 0000 0000 0000 0000 0000 0000 0000070 0000 0000 0000 0000 0000 0000 0000 0000 * 0000100
Anyhow, inserting the modules:
$ insmod /root/snd-sof-intel-apl.ko $ insmod /root/sof-pci-dev.ko
I notice the following error:
[ 720.726371] sof-audio-pci 0000:00:04.0: runtime IRQ mapping not provided by arch [ 720.726383] sof-audio-pci 0000:00:04.0: SOF PCI DSP detected [ 720.779223] sof-audio-pci 0000:00:04.0: No matching ASoC machine driver found - using nocodec [ 720.779710] sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered [ 720.780064] sof-audio-pci 0000:00:04.0: created machine sof-nocodec [ 720.780611] sof-audio sof-audio: probing SOF DSP device.... [ 720.780612] sof-audio sof-audio: using platform alias sof-platform [ 720.780615] sof-audio-pci 0000:00:04.0: can't ioremap BAR 0: [??? 0x00000000 flags 0x0] [ 720.780677] sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered [ 720.780711] sof-audio-pci 0000:00:0e.0: runtime IRQ mapping not provided by arch [ 720.780712] sof-audio-pci 0000:00:0e.0: SOF PCI DSP detected [ 720.781637] sof-audio-pci 0000:00:04.0: error: ioremap error [ 720.781924] sof-audio-pci 0000:00:04.0: can't ioremap BAR 4: [??? 0x00000000 flags 0x0] [ 720.782330] sof-audio-pci 0000:00:04.0: error: ioremap error [ 720.782625] sof-audio-pci 0000:00:04.0: enabling bus mastering [ 720.782895] sof-audio-pci 0000:00:04.0: 64 bit
Full dmesg can be found here: https://pastebin.com/BFXPCniE
Questions:
1) Is it OK to start qemu with two sound devices: bxt-intel-hda and adsp-bxt? 2) It looks like the kernel cannot find a space where to map PCI address space for these two devices. I also tried booting with just one audio device but the ioremap erros is the same.
Let me know if you ever encountered such issues.
thanks, Daniel.
On Tue, 2018-01-30 at 23:50 +0200, Daniel Baluta wrote:
On Fri, Jan 26, 2018 at 6:24 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 17:54 +0200, Daniel Baluta wrote:
Hi Liam,
Thanks a lot for your answer. Still one question inline:
On Fri, Jan 26, 2018 at 4:07 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 15:42 +0200, Daniel Baluta wrote:
Hi,
I'm following the instruction on SOF wiki page on how to use the emulator [1] and both VM0 and VM1 are up, anyhow SOF DSP device isn't probed.
How do you do it in your qemu setup?
So for host VM I usually install my favourite distro on a disk image and boot this image (including kernel) directly using the x86-host.sh scripts. There are quite a lot of tools that can help create this image, but it's bog standard Linux VM image with your custom kernel.
Btw, the kernel can be updated on this image using the normal methods within the VM.
So, I think I have setup everything correct (btw I use SOF modules builtin in the kernel image, because I find it easier).
I recommend modules as the drivers need a mounted FS to load firmware and topologies. built-in can result in some races between driver and FS being ready....
Anyhow, I expect that the function sof_probe from sound/soc/sof/core.c to be called but it isn't :).
Any idea why?
I assume the ACPI device is registered ? Pls check sysfs and make sure the device ID is listed with the other ACPI devices and returns status 15.
Also pls check that the older SST drivers have not been loaded by default. If so, they can be blacklisted atm :-
cat /etc/modprobe.d/blacklist-dsp.conf blacklist snd_soc_sst_acpi blacklist snd_soc_sst_dsp blacklist snd_soc_sst_firmware blacklist snd_soc_sst_ipc blacklist snd_soc_sst_match blacklist snd_soc_sst_mfld-platform blacklist snd_soc_skl blacklist snd_hda_intel blacklist snd_soc_sst_byt_cht_nocodec blacklist snd_soc_sst_atom_hifi2_platform blacklist snd_intel_sst_core blacklist snd_intel_sst_acpi
Now, this function should be called as a result of a platform device named "sof-audio" being somehow registered.
You may want to attach the relevant part of your dmesg showing ASoC/ALSA probing.
Hi Liam,
So after compiling out SST drivers I can see the probe function from sof-pci-dev module called twice.
I use the command line from ./x86-host.sh bxt which tells qemu that there are two PCI sound devices:
- -device bxt-intel-hda,id=sound0,bus=pci.0,addr=0xe
- -device driver=adsp-bxt
1
After starting qemu indeed I can see those two pci devices:
$ cat /sys/bus/pci/devices/0000:00:04.0/device 0x5a98
$ cat /sys/bus/pci/devices/0000:00:04.0/config 0000000 8086 5a98 0103 0000 0001 0401 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 1af4 1100 0000030 0000 0000 0000 0000 0000 0000 020a 0000 0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000100
$ cat /sys/bus/pci/devices/0000:00:0e.0/device 0x5a98
$ cat /sys/bus/pci/devices/0000:00:0e.0/config
0000000 8086 5a98 0103 0010 0003 0403 0000 0000 0000010 0000 fc07 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 1af4 1100 0000030 0000 0000 0060 0000 0000 0000 010a 0000 0000040 0001 0000 0000 0000 0000 0000 0000 0000 0000050 0000 0000 0000 0000 0000 0000 0000 0000 0000060 0005 0080 0000 0000 0000 0000 0000 0000 0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000100
Anyhow, inserting the modules:
$ insmod /root/snd-sof-intel-apl.ko $ insmod /root/sof-pci-dev.ko
I notice the following error:
[ 720.726371] sof-audio-pci 0000:00:04.0: runtime IRQ mapping not provided by arch [ 720.726383] sof-audio-pci 0000:00:04.0: SOF PCI DSP detected [ 720.779223] sof-audio-pci 0000:00:04.0: No matching ASoC machine driver found - using nocodec [ 720.779710] sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered [ 720.780064] sof-audio-pci 0000:00:04.0: created machine sof-nocodec [ 720.780611] sof-audio sof-audio: probing SOF DSP device.... [ 720.780612] sof-audio sof-audio: using platform alias sof-platform [ 720.780615] sof-audio-pci 0000:00:04.0: can't ioremap BAR 0: [??? 0x00000000 flags 0x0] [ 720.780677] sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered [ 720.780711] sof-audio-pci 0000:00:0e.0: runtime IRQ mapping not provided by arch [ 720.780712] sof-audio-pci 0000:00:0e.0: SOF PCI DSP detected [ 720.781637] sof-audio-pci 0000:00:04.0: error: ioremap error [ 720.781924] sof-audio-pci 0000:00:04.0: can't ioremap BAR 4: [??? 0x00000000 flags 0x0] [ 720.782330] sof-audio-pci 0000:00:04.0: error: ioremap error [ 720.782625] sof-audio-pci 0000:00:04.0: enabling bus mastering [ 720.782895] sof-audio-pci 0000:00:04.0: 64 bit
Full dmesg can be found here: https://pastebin.com/BFXPCniE
Questions:
- Is it OK to start qemu with two sound devices: bxt-intel-hda and adsp-bxt?
No, just one device for audio DSP. However, the log reminds me that the HDA DSP extensions are not fully virtualized yet for BXT/APL on host side. xtensa VM should boot BXT FW though, it's just the host side is missing parts of the HDA controller that are used for ADSP detection and boot..
I would recommend setting the target to BYT as host and DSP virtualization are code complete for Baytrail.
- It looks like the kernel cannot find a space where to map PCI
address space for these two devices. I also tried booting with just one audio device but the ioremap erros is the same.
Let me know if you ever encountered such issues.
If you need BXT target then it's maybe a few days effort to add in the necessary changes to alteast boot FW and send IPC.
On BXT/APL the HDA HW has a DSP specific memory region that is read back by driver when probing HDA device (the SOF driver shows this probing and detection of DSP capabilities). This region needs to be virtualized in order for driver to send FW boot (i.e sets bits to unstall xtensa VM as done on BYT xtensa VM), it's missing a few other bits too for stream DMA.
Liam
thanks, Daniel.
On Thu, Feb 1, 2018 at 12:29 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Tue, 2018-01-30 at 23:50 +0200, Daniel Baluta wrote:
On Fri, Jan 26, 2018 at 6:24 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 17:54 +0200, Daniel Baluta wrote:
Hi Liam,
Thanks a lot for your answer. Still one question inline:
On Fri, Jan 26, 2018 at 4:07 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2018-01-26 at 15:42 +0200, Daniel Baluta wrote:
Hi,
I'm following the instruction on SOF wiki page on how to use the emulator [1] and both VM0 and VM1 are up, anyhow SOF DSP device isn't probed.
How do you do it in your qemu setup?
So for host VM I usually install my favourite distro on a disk image and boot this image (including kernel) directly using the x86-host.sh scripts. There are quite a lot of tools that can help create this image, but it's bog standard Linux VM image with your custom kernel.
Btw, the kernel can be updated on this image using the normal methods within the VM.
So, I think I have setup everything correct (btw I use SOF modules builtin in the kernel image, because I find it easier).
I recommend modules as the drivers need a mounted FS to load firmware and topologies. built-in can result in some races between driver and FS being ready....
Anyhow, I expect that the function sof_probe from sound/soc/sof/core.c to be called but it isn't :).
Any idea why?
I assume the ACPI device is registered ? Pls check sysfs and make sure the device ID is listed with the other ACPI devices and returns status 15.
Also pls check that the older SST drivers have not been loaded by default. If so, they can be blacklisted atm :-
cat /etc/modprobe.d/blacklist-dsp.conf blacklist snd_soc_sst_acpi blacklist snd_soc_sst_dsp blacklist snd_soc_sst_firmware blacklist snd_soc_sst_ipc blacklist snd_soc_sst_match blacklist snd_soc_sst_mfld-platform blacklist snd_soc_skl blacklist snd_hda_intel blacklist snd_soc_sst_byt_cht_nocodec blacklist snd_soc_sst_atom_hifi2_platform blacklist snd_intel_sst_core blacklist snd_intel_sst_acpi
Now, this function should be called as a result of a platform device named "sof-audio" being somehow registered.
You may want to attach the relevant part of your dmesg showing ASoC/ALSA probing.
Hi Liam,
So after compiling out SST drivers I can see the probe function from sof-pci-dev module called twice.
I use the command line from ./x86-host.sh bxt which tells qemu that there are two PCI sound devices:
- -device bxt-intel-hda,id=sound0,bus=pci.0,addr=0xe
- -device driver=adsp-bxt
1
After starting qemu indeed I can see those two pci devices:
$ cat /sys/bus/pci/devices/0000:00:04.0/device 0x5a98
$ cat /sys/bus/pci/devices/0000:00:04.0/config 0000000 8086 5a98 0103 0000 0001 0401 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 1af4 1100 0000030 0000 0000 0000 0000 0000 0000 020a 0000 0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000100
$ cat /sys/bus/pci/devices/0000:00:0e.0/device 0x5a98
$ cat /sys/bus/pci/devices/0000:00:0e.0/config
0000000 8086 5a98 0103 0010 0003 0403 0000 0000 0000010 0000 fc07 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 1af4 1100 0000030 0000 0000 0060 0000 0000 0000 010a 0000 0000040 0001 0000 0000 0000 0000 0000 0000 0000 0000050 0000 0000 0000 0000 0000 0000 0000 0000 0000060 0005 0080 0000 0000 0000 0000 0000 0000 0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000100
Anyhow, inserting the modules:
$ insmod /root/snd-sof-intel-apl.ko $ insmod /root/sof-pci-dev.ko
I notice the following error:
[ 720.726371] sof-audio-pci 0000:00:04.0: runtime IRQ mapping not provided by arch [ 720.726383] sof-audio-pci 0000:00:04.0: SOF PCI DSP detected [ 720.779223] sof-audio-pci 0000:00:04.0: No matching ASoC machine driver found - using nocodec [ 720.779710] sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered [ 720.780064] sof-audio-pci 0000:00:04.0: created machine sof-nocodec [ 720.780611] sof-audio sof-audio: probing SOF DSP device.... [ 720.780612] sof-audio sof-audio: using platform alias sof-platform [ 720.780615] sof-audio-pci 0000:00:04.0: can't ioremap BAR 0: [??? 0x00000000 flags 0x0] [ 720.780677] sof-nocodec sof-nocodec: ASoC: CPU DAI sof-audio not registered [ 720.780711] sof-audio-pci 0000:00:0e.0: runtime IRQ mapping not provided by arch [ 720.780712] sof-audio-pci 0000:00:0e.0: SOF PCI DSP detected [ 720.781637] sof-audio-pci 0000:00:04.0: error: ioremap error [ 720.781924] sof-audio-pci 0000:00:04.0: can't ioremap BAR 4: [??? 0x00000000 flags 0x0] [ 720.782330] sof-audio-pci 0000:00:04.0: error: ioremap error [ 720.782625] sof-audio-pci 0000:00:04.0: enabling bus mastering [ 720.782895] sof-audio-pci 0000:00:04.0: 64 bit
Full dmesg can be found here: https://pastebin.com/BFXPCniE
Questions:
- Is it OK to start qemu with two sound devices: bxt-intel-hda and adsp-bxt?
No, just one device for audio DSP. However, the log reminds me that the HDA DSP extensions are not fully virtualized yet for BXT/APL on host side. xtensa VM should boot BXT FW though, it's just the host side is missing parts of the HDA controller that are used for ADSP detection and boot..
I would recommend setting the target to BYT as host and DSP virtualization are code complete for Baytrail.
I tried BYT target but i cannot get xtensa-host.sh script working.
$ bash -x ./xtensa-host.sh byt + '[' 1 -lt 1 ']' + case $1 in + CPU=baytrail + ADSP=adsp_byt + rm -fr /dev/shm/qemu-bridge-bxt-hp-sram /dev/shm/qemu-bridge-bxt-io /dev/shm/qemu-bridge-bxt-l2-sram /dev/shm/qemu-bridge-bxt-lp-sram /dev/shm/qemu-bridge-bxt-mbox /dev/shm/qemu-bridge-bxt-rom /dev/shm/qemu-bridge-bxt-shim + rm -fr /dev/mqueue/qemu-io-child-bxt /dev/mqueue/qemu-io-parent-bxt + ./xtensa-softmmu/qemu-system-xtensa -cpu baytrail -M adsp_byt -nographic -S ** ERROR:qom/object.c:488:object_new_with_type: assertion failed: (type != NULL) ./xtensa-host.sh: line 76: 17616 Aborted (core dumped) ./xtensa-softmmu/qemu-system-xtensa -cpu $CPU -M $ADSP -nographic -S
The same happens for all other targets expect BXT, that's why I asked about BXT.
I think there is something wrong with my dev environment.
Thanks a lot for your help. I will continue investigation.
Daniel.
On Thu, 2018-02-01 at 22:57 +0200, Daniel Baluta wrote:
I tried BYT target but i cannot get xtensa-host.sh script working.
$ bash -x ./xtensa-host.sh byt
- '[' 1 -lt 1 ']'
- case $1 in
- CPU=baytrail
- ADSP=adsp_byt
- rm -fr /dev/shm/qemu-bridge-bxt-hp-sram /dev/shm/qemu-bridge-bxt-io
/dev/shm/qemu-bridge-bxt-l2-sram /dev/shm/qemu-bridge-bxt-lp-sram /dev/shm/qemu-bridge-bxt-mbox /dev/shm/qemu-bridge-bxt-rom /dev/shm/qemu-bridge-bxt-shim
- rm -fr /dev/mqueue/qemu-io-child-bxt /dev/mqueue/qemu-io-parent-bxt
- ./xtensa-softmmu/qemu-system-xtensa -cpu baytrail -M adsp_byt -nographic -S
** ERROR:qom/object.c:488:object_new_with_type: assertion failed: (type != NULL) ./xtensa-host.sh: line 76: 17616 Aborted (core dumped) ./xtensa-softmmu/qemu-system-xtensa -cpu $CPU -M $ADSP -nographic -S
The same happens for all other targets expect BXT, that's why I asked about BXT.
I think there is something wrong with my dev environment.
Thanks a lot for your help. I will continue investigation.
Sorry for the delay, I was travelling last week. Turns out I missed some machine type setting in some of the machines when doing the forward port. Fix pushed.
Liam
On Tue, Feb 6, 2018 at 12:38 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Thu, 2018-02-01 at 22:57 +0200, Daniel Baluta wrote:
I tried BYT target but i cannot get xtensa-host.sh script working.
$ bash -x ./xtensa-host.sh byt
- '[' 1 -lt 1 ']'
- case $1 in
- CPU=baytrail
- ADSP=adsp_byt
- rm -fr /dev/shm/qemu-bridge-bxt-hp-sram /dev/shm/qemu-bridge-bxt-io
/dev/shm/qemu-bridge-bxt-l2-sram /dev/shm/qemu-bridge-bxt-lp-sram /dev/shm/qemu-bridge-bxt-mbox /dev/shm/qemu-bridge-bxt-rom /dev/shm/qemu-bridge-bxt-shim
- rm -fr /dev/mqueue/qemu-io-child-bxt /dev/mqueue/qemu-io-parent-bxt
- ./xtensa-softmmu/qemu-system-xtensa -cpu baytrail -M adsp_byt -nographic -S
** ERROR:qom/object.c:488:object_new_with_type: assertion failed: (type != NULL) ./xtensa-host.sh: line 76: 17616 Aborted (core dumped) ./xtensa-softmmu/qemu-system-xtensa -cpu $CPU -M $ADSP -nographic -S
The same happens for all other targets expect BXT, that's why I asked about BXT.
I think there is something wrong with my dev environment.
Thanks a lot for your help. I will continue investigation.
Sorry for the delay, I was travelling last week. Turns out I missed some machine type setting in some of the machines when doing the forward port. Fix pushed.
Thanks Liam for the updates. I forgot to reply, I've did some hacks and finally got qemu working.
Now I get a timeout when trying to boot the DSP, but will get back with more details once I have some spare time.
thanks, Daniel.
On Tue, 2018-02-06 at 10:14 +0200, Daniel Baluta wrote:
Sorry for the delay, I was travelling last week. Turns out I missed some machine type setting in some of the machines when doing the forward port. Fix pushed.
Thanks Liam for the updates. I forgot to reply, I've did some hacks and finally got qemu working.
Now I get a timeout when trying to boot the DSP, but will get back with more details once I have some spare time.
Fwiw, firmware will send a FW ready message to the host to indicate boot complete. This involves writing to a special shim register that causes an IRQ on the host side.
Liam
On Tue, Feb 6, 2018 at 6:38 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Tue, 2018-02-06 at 10:14 +0200, Daniel Baluta wrote:
Sorry for the delay, I was travelling last week. Turns out I missed some machine type setting in some of the machines when doing the forward port. Fix pushed.
Thanks Liam for the updates. I forgot to reply, I've did some hacks and finally got qemu working.
Now I get a timeout when trying to boot the DSP, but will get back with more details once I have some spare time.
Fwiw, firmware will send a FW ready message to the host to indicate boot complete. This involves writing to a special shim register that causes an IRQ on the host side.
Finally got a chance to get back to this.
First run I got a crash, which I think it's due to a race condition.
I'm using:
* sof.git/master - 19e48c5 Merge branch '1.1-stable' * osadsp-qemu/master - 771e78b FIXME: log: Support 64bit trace format. * asoc/sof-v4.15 - 130e9f7 0day warnings
Running
$ ./xtensa-host.sh byt $ ./x86-host.sh byt
I get the following crash: * https://pastebin.com/tDawwd5P
full log here:
* https://pastebin.com/dbjiimJx
I guess this is a race and fixed it with:
daniel@firefly:~/w/sof-sdk/asoc$ git diff diff --git a/sound/soc/sof/trace.c b/sound/soc/sof/trace.c index 744d75b..7f5bef9 100644 --- a/sound/soc/sof/trace.c +++ b/sound/soc/sof/trace.c @@ -245,6 +245,9 @@ int snd_sof_init_trace(struct snd_sof_dev *sdev) params.buffer.offset = 0; params.buffer.pages = sdev->dma_trace_pages;
+ + init_waitqueue_head(&sdev->trace_sleep); + /* send IPC to the DSP */ ret = sof_ipc_tx_message(sdev->ipc, params.hdr.cmd, ¶ms, sizeof(params), @@ -255,7 +258,6 @@ int snd_sof_init_trace(struct snd_sof_dev *sdev) goto table_err; }
- init_waitqueue_head(&sdev->trace_sleep); sdev->host_offset = 0; return 0;
After this, DSP firmware boots fine but then i get this error:
[ 11.264059] sof-audio sof-audio: error: ipc timed out for 0x90010000 size 0x18 [ 11.264458] sof-audio sof-audio: error: waking up any trace sleepers [ 11.264460] sof-audio sof-audio: error: cant set params for DMA for Trace-110 [ 11.264467] sof-audio sof-audio: error: failed to initialize trace -110
Full log here:
* https://pastebin.com/VffNxrXg
Any idea?
On Sat, 2018-03-17 at 11:29 +0200, Daniel Baluta wrote:
On Tue, Feb 6, 2018 at 6:38 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Tue, 2018-02-06 at 10:14 +0200, Daniel Baluta wrote:
Sorry for the delay, I was travelling last week. Turns out I missed some machine type setting in some of the machines when doing the forward port. Fix pushed.
Thanks Liam for the updates. I forgot to reply, I've did some hacks and finally got qemu working.
Now I get a timeout when trying to boot the DSP, but will get back with more details once I have some spare time.
Fwiw, firmware will send a FW ready message to the host to indicate boot complete. This involves writing to a special shim register that causes an IRQ on the host side.
Finally got a chance to get back to this.
First run I got a crash, which I think it's due to a race condition.
Yeah, I've not root caused that yet, had to hack around it when I upgraded to the latest qemu release.
I'm using:
- sof.git/master - 19e48c5 Merge branch '1.1-stable'
Can you also use the 1.1-stable branch for the sof tools and topology.
- osadsp-qemu/master - 771e78b FIXME: log: Support 64bit trace format.
- asoc/sof-v4.15 - 130e9f7 0day warnings
Best to use my Pierre's v4.14 stable branch here as we are in the middle of a release (meaning my branches have more experiment patches).
https://github.com/plbossart/sound.git #topic/sof-v4.14
Running
$ ./xtensa-host.sh byt $ ./x86-host.sh byt
I get the following crash:
full log here:
I guess this is a race and fixed it with:
great, thanks ! Can you send that as a patch with your SoB ?
daniel@firefly:~/w/sof-sdk/asoc$ git diff diff --git a/sound/soc/sof/trace.c b/sound/soc/sof/trace.c index 744d75b..7f5bef9 100644 --- a/sound/soc/sof/trace.c +++ b/sound/soc/sof/trace.c @@ -245,6 +245,9 @@ int snd_sof_init_trace(struct snd_sof_dev *sdev) params.buffer.offset = 0; params.buffer.pages = sdev->dma_trace_pages;
init_waitqueue_head(&sdev->trace_sleep);/* send IPC to the DSP */ ret = sof_ipc_tx_message(sdev->ipc, params.hdr.cmd, ¶ms, sizeof(params),@@ -255,7 +258,6 @@ int snd_sof_init_trace(struct snd_sof_dev *sdev) goto table_err; }
init_waitqueue_head(&sdev->trace_sleep); sdev->host_offset = 0; return 0;After this, DSP firmware boots fine but then i get this error:
[ 11.264059] sof-audio sof-audio: error: ipc timed out for 0x90010000 size 0x18 [ 11.264458] sof-audio sof-audio: error: waking up any trace sleepers [ 11.264460] sof-audio sof-audio: error: cant set params for DMA for Trace- 110 [ 11.264467] sof-audio sof-audio: error: failed to initialize trace -110
Full log here:
Any idea?
Firmware is crashing
[ 11.264202] sof-audio sof-audio: shim 0x40 value 0x0dead00670028800
But what does rmbox show ?
Liam
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Mon, Mar 19, 2018 at 1:33 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Sat, 2018-03-17 at 11:29 +0200, Daniel Baluta wrote:
On Tue, Feb 6, 2018 at 6:38 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Tue, 2018-02-06 at 10:14 +0200, Daniel Baluta wrote:
Sorry for the delay, I was travelling last week. Turns out I missed some machine type setting in some of the machines when doing the forward port. Fix pushed.
Thanks Liam for the updates. I forgot to reply, I've did some hacks and finally got qemu working.
Now I get a timeout when trying to boot the DSP, but will get back with more details once I have some spare time.
Fwiw, firmware will send a FW ready message to the host to indicate boot complete. This involves writing to a special shim register that causes an IRQ on the host side.
Finally got a chance to get back to this.
First run I got a crash, which I think it's due to a race condition.
Yeah, I've not root caused that yet, had to hack around it when I upgraded to the latest qemu release.
I'm using:
- sof.git/master - 19e48c5 Merge branch '1.1-stable'
Can you also use the 1.1-stable branch for the sof tools and topology.
Sure.
- osadsp-qemu/master - 771e78b FIXME: log: Support 64bit trace format.
- asoc/sof-v4.15 - 130e9f7 0day warnings
Best to use my Pierre's v4.14 stable branch here as we are in the middle of a release (meaning my branches have more experiment patches).
https://github.com/plbossart/sound.git #topic/sof-v4.14
All right. Will give it a try.
Running
$ ./xtensa-host.sh byt $ ./x86-host.sh byt
I get the following crash:
full log here:
I guess this is a race and fixed it with:
great, thanks ! Can you send that as a patch with your SoB ?
All right. Which branch should I base it on?
daniel@firefly:~/w/sof-sdk/asoc$ git diff diff --git a/sound/soc/sof/trace.c b/sound/soc/sof/trace.c index 744d75b..7f5bef9 100644 --- a/sound/soc/sof/trace.c +++ b/sound/soc/sof/trace.c @@ -245,6 +245,9 @@ int snd_sof_init_trace(struct snd_sof_dev *sdev) params.buffer.offset = 0; params.buffer.pages = sdev->dma_trace_pages;
init_waitqueue_head(&sdev->trace_sleep);/* send IPC to the DSP */ ret = sof_ipc_tx_message(sdev->ipc, params.hdr.cmd, ¶ms, sizeof(params),@@ -255,7 +258,6 @@ int snd_sof_init_trace(struct snd_sof_dev *sdev) goto table_err; }
init_waitqueue_head(&sdev->trace_sleep); sdev->host_offset = 0; return 0;After this, DSP firmware boots fine but then i get this error:
[ 11.264059] sof-audio sof-audio: error: ipc timed out for 0x90010000 size 0x18 [ 11.264458] sof-audio sof-audio: error: waking up any trace sleepers [ 11.264460] sof-audio sof-audio: error: cant set params for DMA for Trace- 110 [ 11.264467] sof-audio sof-audio: error: failed to initialize trace -110
Full log here:
Any idea?
Firmware is crashing
[ 11.264202] sof-audio sof-audio: shim 0x40 value 0x0dead00670028800
But what does rmbox show ?
Never used rmbox. Can you provide an example.
Another comment:
Can you let me know which configuration worked for you on Qemu?
Using default {xtensa|x86}-host.sh scripts with baytrail parameter i cannot get it working.
I have figured out that I also need a topology file.
I have used both byt-rt5640 machine Or hacked to used the nocodec but still at some point I get a timeout from
I expect that if everything works well a sound card device should be created and I can list it using arecord -l or aplay -l. Then I can use aplay/arecord to send a file to DSP for decoding.
thanks, Daniel.
On Mon, 2018-03-19 at 15:13 +0200, Daniel Baluta wrote:
On Mon, Mar 19, 2018 at 1:33 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Sat, 2018-03-17 at 11:29 +0200, Daniel Baluta wrote:
On Tue, Feb 6, 2018 at 6:38 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Tue, 2018-02-06 at 10:14 +0200, Daniel Baluta wrote:
Sorry for the delay, I was travelling last week. Turns out I missed some machine type setting in some of the machines when doing the forward port. Fix pushed.
Thanks Liam for the updates. I forgot to reply, I've did some hacks and finally got qemu working.
Now I get a timeout when trying to boot the DSP, but will get back with more details once I have some spare time.
Fwiw, firmware will send a FW ready message to the host to indicate boot complete. This involves writing to a special shim register that causes an IRQ on the host side.
Finally got a chance to get back to this.
First run I got a crash, which I think it's due to a race condition.
Yeah, I've not root caused that yet, had to hack around it when I upgraded to the latest qemu release.
I'm using:
- sof.git/master - 19e48c5 Merge branch '1.1-stable'
Can you also use the 1.1-stable branch for the sof tools and topology.
Sure.
- osadsp-qemu/master - 771e78b FIXME: log: Support 64bit trace format.
- asoc/sof-v4.15 - 130e9f7 0day warnings
Best to use my Pierre's v4.14 stable branch here as we are in the middle of a release (meaning my branches have more experiment patches).
https://github.com/plbossart/sound.git #topic/sof-v4.14
All right. Will give it a try.
Running
$ ./xtensa-host.sh byt $ ./x86-host.sh byt
I get the following crash:
full log here:
I guess this is a race and fixed it with:
great, thanks ! Can you send that as a patch with your SoB ?
All right. Which branch should I base it on?
Best to use Pierre's topic/sof-v4.14
daniel@firefly:~/w/sof-sdk/asoc$ git diff diff --git a/sound/soc/sof/trace.c b/sound/soc/sof/trace.c index 744d75b..7f5bef9 100644 --- a/sound/soc/sof/trace.c +++ b/sound/soc/sof/trace.c @@ -245,6 +245,9 @@ int snd_sof_init_trace(struct snd_sof_dev *sdev) params.buffer.offset = 0; params.buffer.pages = sdev->dma_trace_pages;
init_waitqueue_head(&sdev->trace_sleep);/* send IPC to the DSP */ ret = sof_ipc_tx_message(sdev->ipc, params.hdr.cmd, ¶ms, sizeof(params),@@ -255,7 +258,6 @@ int snd_sof_init_trace(struct snd_sof_dev *sdev) goto table_err; }
init_waitqueue_head(&sdev->trace_sleep); sdev->host_offset = 0; return 0;After this, DSP firmware boots fine but then i get this error:
[ 11.264059] sof-audio sof-audio: error: ipc timed out for 0x90010000 size 0x18 [ 11.264458] sof-audio sof-audio: error: waking up any trace sleepers [ 11.264460] sof-audio sof-audio: error: cant set params for DMA for Trace- 110 [ 11.264467] sof-audio sof-audio: error: failed to initialize trace -110
Full log here:
Any idea?
Firmware is crashing
[ 11.264202] sof-audio sof-audio: shim 0x40 value 0x0dead00670028800
But what does rmbox show ?
Never used rmbox. Can you provide an example.
rmbox is built as part of the tools repo. It can be installed on the guest OS and run from the cmd line to dump HW registers, trace data or errors.
rmbox alone will dump the error log, rmbox -t will dump trace. The HW dumps are priobably not that useful for VM use case.
Another comment:
Can you let me know which configuration worked for you on Qemu?
Using default {xtensa|x86}-host.sh scripts with baytrail parameter i cannot get it working.
I've updated xtensa-host.sh and fixed some bugs on byt.
Please run "xtensa-host.sh byt - c" and then "x86-host.sh byt" in another terminal.
I have figured out that I also need a topology file.
I have used both byt-rt5640 machine Or hacked to used the nocodec but still at some point I get a timeout from
I expect that if everything works well a sound card device should be created and I can list it using arecord -l or aplay -l. Then I can use aplay/arecord to send a file to DSP for decoding.
So I recommend using nocodec atm, using the default bytcr-rt5640 should give the same results, but I'm seeing the same resluts with that latest updates :-
[ 8.533234] sof-audio-acpi 80860F28:00: IOSF_MBI not enabled - can't determine CPU variant
This can be ignored atm, driver will default to BYT.
[ 8.533516] sof-audio-acpi 80860F28:00: info: loading firmware intel/reef-byt.ri [ 8.555381] sof-audio sof-audio: IMR not set by BIOS. Ignoring
Can also be ignored too.
[ 8.562720] snd_soc_sst_mfld_platform: disagrees about version of symbol module_layout
Old legacy driver, can be ignored.
[ 8.589873] random: crng init done [ 8.664129] sof-audio sof-audio: error: firmware boot timeout [ 8.664794] sof-audio sof-audio: error: unexpected fault 0x70028800 trace 0x00000000 [ 8.664855] sof-audio sof-audio: error: failed to boot DSP firmware -5
ok, seems we dont get the interrupt from the DSP......
[ 8.665462] sof-audio: probe of sof-audio failed with error -5 [ 9.036590] irq 10: nobody cared (try booting with the "irqpoll" option)
but *we* do get the interrupt going to a different IRQ !
It seems there is a mismatch between IRQ number in qemu ACPI and IRQ mapping in the kernel.
I've seen this before and I'm not 100% sue how qemu does these mappings. I also wont get time to look at this until after 1.1 is out.
[ 9.036669] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 4.16.0-rc5+ #64 [ 9.036670] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 [ 9.036671] Call Trace: [ 9.036673] <IRQ> [ 9.036679] dump_stack+0x85/0xc5 [ 9.036688] __report_bad_irq+0x30/0xc0 [ 9.036691] note_interrupt+0x23e/0x290 [ 9.036695] handle_irq_event_percpu+0x51/0x70 [ 9.036698] handle_irq_event+0x37/0x60 [ 9.036700] handle_fasteoi_irq+0x83/0x140 [ 9.036703] handle_irq+0xb2/0x120 [ 9.036706] do_IRQ+0x53/0x110 [ 9.036710] common_interrupt+0xf/0xf [ 9.036712] RIP: 0010:__do_softirq+0x9d/0x4f7 [ 9.036713] RSP: 0000:ffff9128ff903f70 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffd9 [ 9.036715] RAX: ffff9128fca00040 RBX: ffff9128fca00040 RCX: 0000000000000000 [ 9.036717] RDX: ffff9128fca00040 RSI: 0000000000000000 RDI: ffff9128fca00040 [ 9.036718] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 9.036719] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 9.036720] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000282 [ 9.036723] ? common_interrupt+0xa/0xf [ 9.036731] ? hrtimer_interrupt+0x118/0x240 [ 9.036736] irq_exit+0xc1/0xd0 [ 9.036737] smp_apic_timer_interrupt+0x9a/0x2b0 [ 9.036740] apic_timer_interrupt+0xf/0x20 [ 9.036742] </IRQ> [ 9.036743] RIP: 0010:native_safe_halt+0x2/0x10 [ 9.036745] RSP: 0000:ffffb7bf40377ec8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff12 [ 9.036747] RAX: ffff9128fca00040 RBX: 0000000000000001 RCX: 0000000000000000 [ 9.036748] RDX: ffff9128fca00040 RSI: 0000000000000001 RDI: ffff9128fca00040 [ 9.036749] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 9.036750] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 9.036752] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 9.036759] default_idle+0x1f/0x180 [ 9.036762] do_idle+0x16e/0x1f0 [ 9.036765] cpu_startup_entry+0x6f/0x80 [ 9.036768] start_secondary+0x1ab/0x200 [ 9.036771] secondary_startup_64+0xa5/0xb0 [ 9.036778] handlers: [ 9.036798] [<0000000033268a50>] qxl_irq_handler [qxl] [ 9.036842] Disabling IRQ #10 [ 9.133691] cryptd: max_cpu_qlen set to 1000 [ 9.157826] AVX version of gcm_enc/dec engaged. [ 9.157828] AES CTR mode by8 optimization enabled [ 9.993494] Adding 8386556k swap on /dev/sda5. Priority:-2 extents:1 across:8386556k FS [ 10.356963] bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled [ 10.356967] bytcr_rt5640 bytcr_rt5640: quirk DMIC enabled [ 10.356969] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled [ 10.357085] bytcr_rt5640 bytcr_rt5640: Failed to get MCLK from pmc_plt_clk_3: -2 [ 10.357304] bytcr_rt5640 bytcr_rt5640: ASoC: CPU DAI media-cpu-dai not registered [ 10.357427] bytcr_rt5640 bytcr_rt5640: devm_snd_soc_register_card failed -517
Liam
thanks, Daniel. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
participants (2)
-
Daniel Baluta -
Liam Girdwood