[Sound-open-firmware] Using the Qemu DSP emulator

[Daniel Baluta]

On Thu, Feb 1, 2018 at 12:29 AM, Liam Girdwood
<liam.r.girdwood at 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 at 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 at 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
>
> 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:
>>
>> 1) 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.