[Sound-open-firmware] Problems booting byt in qemu
Hi,
I've been trying to put together a qemu test environment for byt but I'm struggling to get the firmware to properly boot up.
My setup is as following: - x86 host VM: Linux kernel from topic/sof-dev configured for x86_64_defconfig + sof for Baytrail (acpi) with forced nocodec mode, on top of some Ubuntu root file system - DSP VM: sof firmware from master built for byt according to the sof documentation - qemu from sof-stable - topology: sof-byt-nocodec
I'm launching the qemu VMs using: xtensa-host.sh byt -d and x86-host.sh byt <my-ubuntu-image>
Shortly after the x86 VM boots up, the DSP VM starts logging a lot of shim.io messages, but the linux driver fails after:
[ 3.054963] sof-audio-acpi 80860F28:00: ACPI DSP detected [ 3.054966] sof-audio-acpi 80860F28:00: IOSF_MBI not available, no BYT-CR detection [ 3.054967] sof-audio-acpi 80860F28:00: Force to use nocodec mode [ 3.054971] sof-audio-acpi 80860F28:00: LPE PHY base at 0xf1400000 size 0x200000 [ 3.054981] sof-audio-acpi 80860F28:00: LPE VADDR 000000009309825a [ 3.054982] sof-audio-acpi 80860F28:00: IMR not set by BIOS. Ignoring [ 3.054984] sof-audio-acpi 80860F28:00: using IRQ 11 [ 3.058424] sof-audio-acpi 80860F28:00: loading firmware [ 3.070402] sof-audio-acpi 80860F28:00: header size=0x15e60 modules=0x1 abi=0x1 size=16 [ 3.070504] sof-audio-acpi 80860F28:00: new module size 0x15e54 blocks 0x11 type 0x0 [ 3.070506] sof-audio-acpi 80860F28:00: block 0 type 0x1 size 0xf0 ==> offset 0xc0000 [ 3.070524] sof-audio-acpi 80860F28:00: block 1 type 0x1 size 0x16c ==> offset 0xc0400 [ 3.070525] sof-audio-acpi 80860F28:00: block 2 type 0x1 size 0x8 ==> offset 0xc057c [ 3.070527] sof-audio-acpi 80860F28:00: block 3 type 0x1 size 0x8 ==> offset 0xc059c [ 3.070528] sof-audio-acpi 80860F28:00: block 4 type 0x1 size 0x8 ==> offset 0xc05bc [ 3.070529] sof-audio-acpi 80860F28:00: block 5 type 0x1 size 0x8 ==> offset 0xc05dc [ 3.070530] sof-audio-acpi 80860F28:00: block 6 type 0x1 size 0x8 ==> offset 0xc05fc [ 3.070532] sof-audio-acpi 80860F28:00: block 7 type 0x1 size 0x4 ==> offset 0xc061c [ 3.070533] sof-audio-acpi 80860F28:00: block 8 type 0x1 size 0x8 ==> offset 0xc063c [ 3.070534] sof-audio-acpi 80860F28:00: block 9 type 0x1 size 0x4 ==> offset 0xc0658 [ 3.070536] sof-audio-acpi 80860F28:00: block 10 type 0x1 size 0x18 ==> offset 0xc065c [ 3.070537] sof-audio-acpi 80860F28:00: block 11 type 0x1 size 0x8 ==> offset 0xc067c [ 3.070539] sof-audio-acpi 80860F28:00: block 12 type 0x1 size 0x12660 ==> offset 0xc06c0 [ 3.070599] sof-audio-acpi 80860F28:00: block 13 type 0x2 size 0x21e8 ==> offset 0x100008 [ 3.070611] sof-audio-acpi 80860F28:00: block 14 type 0x2 size 0x28 ==> offset 0x1021f0 [ 3.070613] sof-audio-acpi 80860F28:00: block 15 type 0x2 size 0x11f8 ==> offset 0x102218 [ 3.070617] sof-audio-acpi 80860F28:00: block 16 type 0x2 size 0x6c ==> offset 0x103a98 [ 3.070623] sof-audio-acpi 80860F28:00: booting DSP firmware [ 3.172697] sof-audio-acpi 80860F28:00: error: firmware boot failure [ 3.176674] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000 [ 3.177125] sof-audio-acpi 80860F28:00: error: failed to boot DSP firmware -5 [ 3.181048] sof-audio-acpi 80860F28:00: error: failed to probe DSP hardware! [ 3.181477] sof-audio-acpi: probe of 80860F28:00 failed with error -5
Any idea what may be wrong?
Thanks, Dragoș
Hi Dragos,
On Wed, 5 Jun 2019, Dragos Tarcatu wrote:
My setup is as following:
- x86 host VM: Linux kernel from topic/sof-dev configured for
x86_64_defconfig + sof for Baytrail (acpi) with forced nocodec mode, on top of some Ubuntu root file system
- DSP VM: sof firmware from master built for byt according to the sof
documentation
- qemu from sof-stable
- topology: sof-byt-nocodec
ack, this all looks valid and should be a working combination.
[ 3.070623] sof-audio-acpi 80860F28:00: booting DSP firmware [ 3.172697] sof-audio-acpi 80860F28:00: error: firmware boot failure [ 3.176674] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000
First a simple test to do is to increase the boot timeout in driver loader.c:
» ret = wait_event_timeout(sdev->boot_wait, sdev->boot_complete, » » » » msecs_to_jiffies(sdev->boot_timeout));
I did hit occasionally that the DSP-side QEMU was too slow to respond and simply bumping this timeout help.
Hi Kai,
Thanks for the hint!
On 05.06.2019 14:29, Kai Vehmanen wrote:
[ 3.070623] sof-audio-acpi 80860F28:00: booting DSP firmware [ 3.172697] sof-audio-acpi 80860F28:00: error: firmware boot failure [ 3.176674] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000First a simple test to do is to increase the boot timeout in driver loader.c:
» ret = wait_event_timeout(sdev->boot_wait, sdev->boot_complete, » » » » msecs_to_jiffies(sdev->boot_timeout));
I did hit occasionally that the DSP-side QEMU was too slow to respond and simply bumping this timeout help.
Indeed, after increasing the values for the default ipc and boot timeouts (TIMEOUT_DEFAULT_IPC_MS, TIMEOUT_DEFAULT_BOOT_MS, IPC_TIMEOUT_MS) I got it it to boot. I'm still getting errors when loading the topology, though:
[ 6.143276] sof-audio-acpi 80860F28:00: Firmware: ABI 3:7:0 Kernel ABI 3:7:0 [ 6.143505] sof-audio-acpi 80860F28:00: found ext header type 1 size 0xa0 [ 6.143545] sof-audio-acpi 80860F28:00: mailbox upstream 0x144000 - size 0x400 [ 6.143547] sof-audio-acpi 80860F28:00: mailbox downstream 0x144400 - size 0x400 [ 6.143548] sof-audio-acpi 80860F28:00: stream region 0x144a00 - size 0x200 [ 6.143552] sof-audio-acpi 80860F28:00: ipc rx done: 0x70000000 [ 6.143600] sof-audio-acpi 80860F28:00: firmware boot complete [ 6.143611] sof-audio-acpi 80860F28:00: generating page table for 000000002b80db03 size 0x10000 pages 16 [ 6.143612] sof-audio-acpi 80860F28:00: dma_trace_pages: 16 [ 6.143616] sof-audio-acpi 80860F28:00: stream_tag: 0 [ 6.175313] sof-audio-acpi 80860F28:00: error: ipc error for 0x90030000 size 12 [ 6.175818] sof-audio-acpi 80860F28:00: error: can't set params for DMA for trace -22 [ 6.176265] sof-audio-acpi 80860F28:00: warning: failed to initialize trace -22 [ 6.176269] sof-audio-acpi 80860F28:00: ASoC: dai register 80860F28:00 #3 [ 6.176270] sof-audio-acpi 80860F28:00: ASoC: dynamically register DAI 80860F28:00 [ 6.176272] sof-audio-acpi 80860F28:00: ASoC: Registered DAI 'ssp0-port' [ 6.176273] sof-audio-acpi 80860F28:00: ASoC: dynamically register DAI 80860F28:00 [ 6.176274] sof-audio-acpi 80860F28:00: ASoC: Registered DAI 'ssp1-port' [ 6.176275] sof-audio-acpi 80860F28:00: ASoC: dynamically register DAI 80860F28:00 [ 6.176276] sof-audio-acpi 80860F28:00: ASoC: Registered DAI 'ssp2-port' [ 6.176325] sof-nocodec sof-nocodec: info: override FE DAI link NoCodec-0 [ 6.176326] sof-nocodec sof-nocodec: info: override FE DAI link NoCodec-1 [ 6.176327] sof-nocodec sof-nocodec: info: override FE DAI link NoCodec-2 [ 6.176328] sof-nocodec sof-nocodec: ASoC: binding NoCodec-0 [ 6.176332] sof-nocodec sof-nocodec: ASoC: binding NoCodec-1 [ 6.176333] sof-nocodec sof-nocodec: ASoC: binding NoCodec-2 [ 6.176358] sof-audio-acpi 80860F28:00: loading topology:intel/sof-tplg/sof-byt-nocodec.tplg [ 6.182808] sof-audio-acpi 80860F28:00: Topology: ABI 3:7:0 Kernel ABI 3:7:0 [ 6.182832] sof-audio-acpi 80860F28:00: ASoC: adding 11 DAPM widgets [ 6.182864] sof-audio-acpi 80860F28:00: ASoC: creating DAPM widget codec_out0 id 1 [ 6.182888] sof-audio-acpi 80860F28:00: tplg: ready widget id 0 pipe 1 type 1 name : codec_out0 stream none [ 6.182890] sof-audio-acpi 80860F28:00: warning: widget type 1 name codec_out0 not handled [ 6.182902] sof-audio-acpi 80860F28:00: ASoC: creating DAPM widget PCM0P id 11 [ 6.182925] sof-audio-acpi 80860F28:00: tplg: ready widget id 1 pipe 1 type 23 name : PCM0P stream Low Latency Playback 0 [ 6.182937] sof-audio-acpi 80860F28:00: loaded host PCM0P [ 6.182949] sof-audio-acpi 80860F28:00: config: periods snk 2 src 0 fmt 0 [ 6.183174] sof-audio-acpi 80860F28:00: ipc tx: 0x30010000 [ 8.216550] sof-audio-acpi 80860F28:00: error: ipc timed out for 0x30010000 size 76 [ 8.217275] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000 [ 8.217683] sof-audio-acpi 80860F28:00: error: DSP failed to add widget id 0 type 23 name : PCM0P stream Low Latency Playback 0 reply 0 [ 8.218139] sof-audio-acpi 80860F28:00: ASoC: failed to load widget PCM0P [ 8.218419] sof-audio-acpi 80860F28:00: error: tplg component load failed -110 [ 8.218810] sof-audio-acpi 80860F28:00: error: failed to load DSP topology -22 [ 8.219179] sof-audio-acpi 80860F28:00: ASoC: failed to probe component -22 [ 8.219472] sof-nocodec sof-nocodec: ASoC: failed to instantiate card -22
On Thu, 2019-06-06 at 09:39 +0300, Dragos Tarcatu wrote:
Hi Kai,
Thanks for the hint!
On 05.06.2019 14:29, Kai Vehmanen wrote:
[ 3.070623] sof-audio-acpi 80860F28:00: booting DSPfirmware [ 3.172697] sof-audio-acpi 80860F28:00: error: firmware boot failure [ 3.176674] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000
First a simple test to do is to increase the boot timeout in driver loader.c:
» ret = wait_event_timeout(sdev->boot_wait, sdev-
boot_complete,
» » » » msecs_to_jiffies(sdev-
boot_timeout));
I did hit occasionally that the DSP-side QEMU was too slow to respond and simply bumping this timeout help.
Indeed, after increasing the values for the default ipc and boot timeouts (TIMEOUT_DEFAULT_IPC_MS, TIMEOUT_DEFAULT_BOOT_MS, IPC_TIMEOUT_MS) I got it it to boot. I'm still getting errors when loading the topology, though:
Are the topology loading errors always at the same place or does it vary on each attempt ?
Btw, what kernel version are you using. Recent version of sof-dev branch will print out additional debug for IPC timeouts.
Liam
On 06.06.2019 11:55, Liam Girdwood wrote:
On Thu, 2019-06-06 at 09:39 +0300, Dragos Tarcatu wrote:
Hi Kai,
Thanks for the hint!
On 05.06.2019 14:29, Kai Vehmanen wrote:
[ 3.070623] sof-audio-acpi 80860F28:00: booting DSPfirmware [ 3.172697] sof-audio-acpi 80860F28:00: error: firmware boot failure [ 3.176674] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000
First a simple test to do is to increase the boot timeout in driver loader.c:
» ret = wait_event_timeout(sdev->boot_wait, sdev-
boot_complete,
» » » » msecs_to_jiffies(sdev-
boot_timeout));
I did hit occasionally that the DSP-side QEMU was too slow to respond and simply bumping this timeout help.
Indeed, after increasing the values for the default ipc and boot timeouts (TIMEOUT_DEFAULT_IPC_MS, TIMEOUT_DEFAULT_BOOT_MS, IPC_TIMEOUT_MS) I got it it to boot. I'm still getting errors when loading the topology, though:
Are the topology loading errors always at the same place or does it vary on each attempt ?
I've ran it several times now, and I haven't got PCM0P to load:
[ 7.608994] sof-audio-acpi 80860F28:00: loading topology:intel/sof-tplg/sof-byt-nocodec.tplg [ 7.634153] sof-audio-acpi 80860F28:00: Topology: ABI 3:7:0 Kernel ABI 3:7:0 [ 7.634156] sof-audio-acpi 80860F28:00: ASoC: adding 11 DAPM widgets [ 7.634157] sof-audio-acpi 80860F28:00: ASoC: creating DAPM widget codec_out0 id 1 [ 7.634162] sof-audio-acpi 80860F28:00: tplg: ready widget id 0 pipe 1 type 1 name : codec_out0 stream none [ 7.634170] sof-audio-acpi 80860F28:00: warning: widget type 1 name codec_out0 not handled [ 7.634172] sof-audio-acpi 80860F28:00: ASoC: creating DAPM widget PCM0P id 11 [ 7.634175] sof-audio-acpi 80860F28:00: tplg: ready widget id 1 pipe 1 type 23 name : PCM0P stream Low Latency Playback 0 [ 7.634177] sof-audio-acpi 80860F28:00: loaded host PCM0P [ 7.634178] sof-audio-acpi 80860F28:00: config: periods snk 2 src 0 fmt 0 [ 7.635249] sof-audio-acpi 80860F28:00: ipc tx: 0x30010000: GLB_TPLG_MSG: COMP_NEW [ 10.661694] sof-audio-acpi 80860F28:00: error: ipc timed out for 0x30010000 size 76 [ 10.665895] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000 [ 10.666200] sof-audio-acpi 80860F28:00: error: DSP failed to add widget id 0 type 23 name : PCM0P stream Low Latency Playback 0 reply 0 [ 10.666534] sof-audio-acpi 80860F28:00: ASoC: failed to load widget PCM0P [ 10.666783] sof-audio-acpi 80860F28:00: error: tplg component load failed -110 [ 10.667079] sof-audio-acpi 80860F28:00: error: failed to load DSP topology -22 [ 10.667321] sof-audio-acpi 80860F28:00: ASoC: failed to probe component -22 [ 10.667562] sof-nocodec sof-nocodec: ASoC: failed to instantiate card -22
Btw, what kernel version are you using. Recent version of sof-dev branch will print out additional debug for IPC timeouts.
I'm on top of sof-dev, but in my previous log I had the verbose IPC logging option off. I'm currently running with the timeout values set to:
core.c: #define TIMEOUT_DEFAULT_IPC_MS 3000 #define TIMEOUT_DEFAULT_BOOT_MS 10000
ipc.c: #define IPC_TIMEOUT_MS 3000
Those seem like pretty high values for me, compared to the initial ones, but I'll try to increase those even more - maybe that fixes it.
Dragoș
On Thu, 2019-06-06 at 13:06 +0300, Dragos Tarcatu wrote:
On 06.06.2019 11:55, Liam Girdwood wrote:
On Thu, 2019-06-06 at 09:39 +0300, Dragos Tarcatu wrote:
Hi Kai,
Thanks for the hint!
On 05.06.2019 14:29, Kai Vehmanen wrote:
[ 3.070623] sof-audio-acpi 80860F28:00: booting DSPfirmware [ 3.172697] sof-audio-acpi 80860F28:00: error: firmware boot failure [ 3.176674] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000
First a simple test to do is to increase the boot timeout in driver loader.c:
» ret = wait_event_timeout(sdev->boot_wait, sdev-
boot_complete,
» » » » msecs_to_jiffies(sdev-
boot_timeout));
I did hit occasionally that the DSP-side QEMU was too slow to respond and simply bumping this timeout help.
Indeed, after increasing the values for the default ipc and boot timeouts (TIMEOUT_DEFAULT_IPC_MS, TIMEOUT_DEFAULT_BOOT_MS, IPC_TIMEOUT_MS) I got it it to boot. I'm still getting errors when loading the topology, though:
Are the topology loading errors always at the same place or does it vary on each attempt ?
I've ran it several times now, and I haven't got PCM0P to load:
[ 7.608994] sof-audio-acpi 80860F28:00: loading topology:intel/sof-tplg/sof-byt-nocodec.tplg [ 7.634153] sof-audio-acpi 80860F28:00: Topology: ABI 3:7:0 Kernel ABI 3:7:0 [ 7.634156] sof-audio-acpi 80860F28:00: ASoC: adding 11 DAPM widgets [ 7.634157] sof-audio-acpi 80860F28:00: ASoC: creating DAPM widget codec_out0 id 1 [ 7.634162] sof-audio-acpi 80860F28:00: tplg: ready widget id 0 pipe 1 type 1 name : codec_out0 stream none [ 7.634170] sof-audio-acpi 80860F28:00: warning: widget type 1 name codec_out0 not handled [ 7.634172] sof-audio-acpi 80860F28:00: ASoC: creating DAPM widget PCM0P id 11 [ 7.634175] sof-audio-acpi 80860F28:00: tplg: ready widget id 1 pipe 1 type 23 name : PCM0P stream Low Latency Playback 0 [ 7.634177] sof-audio-acpi 80860F28:00: loaded host PCM0P [ 7.634178] sof-audio-acpi 80860F28:00: config: periods snk 2 src 0 fmt 0 [ 7.635249] sof-audio-acpi 80860F28:00: ipc tx: 0x30010000: GLB_TPLG_MSG: COMP_NEW [ 10.661694] sof-audio-acpi 80860F28:00: error: ipc timed out for 0x30010000 size 76 [ 10.665895] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000 [ 10.666200] sof-audio-acpi 80860F28:00: error: DSP failed to add widget id 0 type 23 name : PCM0P stream Low Latency Playback 0 reply 0 [ 10.666534] sof-audio-acpi 80860F28:00: ASoC: failed to load widget PCM0P [ 10.666783] sof-audio-acpi 80860F28:00: error: tplg component load failed -110 [ 10.667079] sof-audio-acpi 80860F28:00: error: failed to load DSP topology -22 [ 10.667321] sof-audio-acpi 80860F28:00: ASoC: failed to probe component -22 [ 10.667562] sof-nocodec sof-nocodec: ASoC: failed to instantiate card -22
Btw, what kernel version are you using. Recent version of sof-dev branch will print out additional debug for IPC timeouts.
I'm on top of sof-dev, but in my previous log I had the verbose IPC logging option off. I'm currently running with the timeout values set to:
core.c: #define TIMEOUT_DEFAULT_IPC_MS 3000 #define TIMEOUT_DEFAULT_BOOT_MS 10000
ipc.c: #define IPC_TIMEOUT_MS 3000
Those seem like pretty high values for me, compared to the initial ones, but I'll try to increase those even more - maybe that fixes it.
Ok, I'm suspicious here that we have hit a regression on the host qemu side. This previously worked and would load the whole topology and allow playback capture to/from file.
Fwiw, CI currently only tests the FW DSP qemu side (to FW boot today) and is not testing the host side yet. Xiuli will be working on adding host side qemu to the CI but I dont think he's started yet.
Can you add this to the bug tracker and we can resolve.
Thanks
Liam
Dragoș
Hi,
On Thu, 6 Jun 2019, Dragos Tarcatu wrote:
[ 10.667562] sof-nocodec sof-nocodec: ASoC: failed to instantiate card -22
I'm on top of sof-dev, but in my previous log I had the verbose IPC logging option off. I'm currently running with the timeout values set to:
core.c: #define TIMEOUT_DEFAULT_IPC_MS 3000 #define TIMEOUT_DEFAULT_BOOT_MS 10000
ipc.c: #define IPC_TIMEOUT_MS 3000
I could now reproduce the error you got with very latest driver (topic/sof-dev) and FW.
For me, simply bumping the timeouts did help. The separate timeout value in ipc.c is very misleading though -- I wasted some time today by just bumping the value in core.c and wondering why timeouts still happened. I made a pull-req to change to use the already defined default in core.c and to bump up the defaults, so that the driver would work out-of-the-box against a FW runnning under QEMU:
https://github.com/thesofproject/linux/pull/1038
... let's see what others think about that. If there is some good reason to keep small timeout values, then let's figure out how do we adjust these so that driver would work nicer with QEMU by default (maybe adjust the defaults just for nocodec mode or something similar).
For me, IPC timeout of 3sec and boot timeout of 5sec work out of the box (qemu running on a pretty low end desktop system). Trying to play a stream still fails as HW_PARAMS IPC times out, but the reason is probably similar -- did not try to debug this yet. E.g. alsamixer can be used, so the DSP is alive and well, but timeouts can be easily hit.
I also noted that we have some timing-related problem in the DSP boot. I had not noticed this before as I've run the xtensa qemu always with "-s -S" (or -d to the xtensa-host.sh script) flags. Today when I tried without, the firmware boot started failing systematically. But this is not related to FW/SW versions, but rather something to do with timing. When running with debugs enabled, DSP boot is pretty reliable for me.
There are definitely issues to iron out in this full setup where both host and DSP are emulated, but at least the basics are still working.
Br, Kai
For me, IPC timeout of 3sec and boot timeout of 5sec work out of the box (qemu running on a pretty low end desktop system). Trying to play a stream still fails as HW_PARAMS IPC times out, but the reason is probably similar -- did not try to debug this yet. E.g. alsamixer can be used, so the DSP is alive and well, but timeouts can be easily hit.
In my case, the topology only seem to get loaded successfully if I disable the firmware tracing in the driver. Otherwise it's failing no matter how much I increase the timeouts.
I also noted that we have some timing-related problem in the DSP boot. I had not noticed this before as I've run the xtensa qemu always with "-s -S" (or -d to the xtensa-host.sh script) flags. Today when I tried without, the firmware boot started failing systematically. But this is not related to FW/SW versions, but rather something to do with timing. When running with debugs enabled, DSP boot is pretty reliable for me.
I can confirm the firmware not booting up when started without the gdb option. However, on my machine hooking up with gdb to the qemu dsp host doesn't seem to work either:
dtarcatu@brick:/caddy/sof-latest/sof/build_byt$ xtensa-byt-elf-gdb sof GNU gdb (crosstool-NG 1.23.0.436-5311) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=xtensa-byt-elf". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from sof...done. (gdb) target remote :1234 Remote debugging using :1234 Remote 'g' packet reply is too long (expected 304 bytes, got 632 bytes): e31b2dff006830ff00000000303a30ff306930ff2b032dbf607f32fff015cc000000000020070600446930ff20070600506930ff05aa2cbf507f32ff0000000000000000000000000c4134ff0001000000080000b4be2cbfa07f32ff043a30ff300000000ad0ea0d342030ff000000000000000000000000807f32ffdc6930ffec2330ff0a2c2dff202c2dff0000000016000000000000000500000020000000fedbb3c23e48851c2007060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001500000000000000000000000000000000000000000000000000000000000000e31b2dff00000000e31b2dffe31b2dff26fa2cff0000000000000000000000000000000020070600200706002001060000000000000000000000000050252dff28262dff00272dffd8272dff000000000000000000000000000000000000000000000000488f000000042cff04000000000000008b9e9801000000000000000000000000000000000000000000000000000000000000000000000000b4be2cbfa07f32ff043a30ff300000000ad0ea0d342030ff000000000000000000000000807f32ffdc6930ffec2330ff006830ff00000000303a30ff306930ff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (gdb)
Regards, Dragoș
Hi,
On Sat, 15 Jun 2019, Tarcatu, Dragos wrote:
For me, IPC timeout of 3sec and boot timeout of 5sec work out of the box (qemu running on a pretty low end desktop system). Trying to play a stream
In my case, the topology only seem to get loaded successfully if I disable the firmware tracing in the driver. Otherwise it's failing no matter how much I increase the timeouts.
ack, that's a known thing, interface for firmware tracing is not fully implemented in the BYT qemu model, so you have to disable it in kernel config for now.
But it should not fail the boot completely, so this is still a bug, filed as: https://github.com/thesofproject/qemu/issues/14
I also noted that we have some timing-related problem in the DSP boot. I had not noticed this before as I've run the xtensa qemu always with "-s -S" (or -d to the xtensa-host.sh script) flags. Today when I tried
I can confirm the firmware not booting up when started without the gdb
Ok, let's file a bug for this: https://github.com/thesofproject/qemu/issues/13
option. However, on my machine hooking up with gdb to the qemu dsp host doesn't seem to work either:
[...]
(gdb) target remote :1234 Remote debugging using :1234 Remote 'g' packet reply is too long (expected 304 bytes, got 632 bytes): e31b2dff006830ff00000000303a30ff306930ff2b032dbf607f32fff015cc000000000020070600446930ff20070600506930ff05aa2cbf507f32ff0000000000000000000000000c4134ff0001000000080000b4be2cbfa07f32ff043a30ff300000000ad0ea0d342030ff000000000000000000000000807f32ffdc6930ffec2330ff0a2c2dff202c2dff0000000016000000000000000500000020000000fedbb3c23e48851c2007060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001500000000000000000000000000000000000000000000000000000000000000e31b2dff00000000e31b2dffe31b2dff26fa2cff0000000000000000000000000000000020070600200706002001060000000000000000000000000050252dff28262dff00272dffd8272dff000000000000000000000000000000000000000000000000488f000000042cff04000000000000008b9e9801000000000000000000000000000000000000000000000000000000000000000000000000b4be2cbfa07f32ff043a30ff300000000ad0ea0d342030ff000000000000000000000000807f32ffdc6930ffec2330ff006830ff00000000303a30ff306930ff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Aa, there's a fix for this. This just got merged to the 8.1 branch of sof crosstool-ng branch for sof-gcc8.1:
https://github.com/thesofproject/crosstool-ng/commits/sof-gcc8.1
Br, Kai
Hi,
following up on the list as well:
On Mon, 17 Jun 2019, Kai Vehmanen wrote:
had not noticed this before as I've run the xtensa qemu always with "-s -S" (or -d to the xtensa-host.sh script) flags. Today when I tried
I can confirm the firmware not booting up when started without the gdb
Ok, let's file a bug for this: https://github.com/thesofproject/qemu/issues/13
This is now fixed in sof-stable with merging of:
xtensa: adsp: xtensa-host.sh: start frozen if no kernel given https://github.com/thesofproject/qemu/pull/16
Without the debug prints, the emulation of course also runs faster and with the new IPC/boot defaults, vanilla driver boots up fine in hybrid host+DSP QEMU now, including topology parsing. The driver patch is still in review, but should go in soon'ish as well wit this:
# Fix IPC and boot timeouts https://github.com/thesofproject/linux/pull/1038
Br, Kai
participants (4)
-
Dragos Tarcatu -
Kai Vehmanen -
Liam Girdwood -
Tarcatu, Dragos