[BYT][HOST+DSP] driver initiated boot fails if DSP emulation not in debug mode (-s -S)

[kv2019i]

In full emulation test setup with both host and DSP running QEMU, the boot flow fails unless DSP qemu is started in debug mode ("./xtensa-host.sh byt -d" or passing "-s -S" to qemu binary).

Tested versions:

57eac1725aa4c344fd8e236227a7cd7d8f305d1b (sof-stable) adsp: common: simple file parser needs to increment block on error.

[dragosht]

This problem only seems to occur when qemu-system-xtensa gets started without -S so that the DSP starts executing right away. If tracing gets enabled, the execution seems to end up somewhere in an exception handler and it does not recover after the cpu_reset(CPU(adsp->xtensa[0]->cpu)) from byt-shim.

./xtensa-softmmu/qemu-system-xtensa -cpu baytrail -M adsp_byt -d mmu,in_asm -nographic
...
bridge-io-mq: added /qemu-io-parent-byt
bridge-io-mq: added /qemu-io-child-byt
 ** Baytrail Xtensa HiFi2 EP DSP initialised.
 ** Waiting for host to load firmware...
bridge-io: 0 messages are currently on child queue.
QEMU 2.11.0 monitor - type 'help' for more information
(qemu) tlb_fill(ff2c0000, 2, 0) -> ff2c0000, ret = 0
----------------
IN: 
0xff2c0000:  
OBJD-T: 000000

----------------
IN: 
0xff2c067c:  
OBJD-T: 000000

bridge-io: msg recv 0 type 1 size 20 msg 32
msg: id 0 msg 32 size 20 type 1
cpu: reset
xtensa_cpu_do_interrupt(pc = ff2c067c) unknown exception_index: -1
tlb_fill(ff2c0000, 2, 0) -> ff2c0000, ret = 0
bridge-io: msg recv 1 type 1 size 20 msg 32
msg: id 1 msg 32 size 20 type 1
bridge-io: msg recv 2 type 1 size 20 msg 32
msg: id 2 msg 32 size 20 type 1
cpu: running

[lgirdwood]

When in heterogeneous mode, the DSP VM must start in "non executing" mode. i.e. it should not load any firmware or start fetching instructions. The host VM is responsible for copying the firmware and starting the DSP VM core instruction fetch. @kv2019i sound like we need this updated in docs ?

[kv2019i]

@lgirdwood wrote:

When in heterogeneous mode, the DSP VM must start in "non executing" mode. i.e. it should not load any firmware or start fetching instructions. The host VM is responsible for copying the firmware and starting the DSP VM core instruction fetch.

Thanks Liam, that explains it.

I think our documents are up-to-date, but the helper script has a bug(/feature). I believe it should impelment this policy by forcing "-S" whenever kernel is not given. So how about this as a fix: https://github.com/thesofproject/qemu/pull/16

Plasese @dragosht give it a go.

[lgirdwood]

16 merged.

[dragosht]

@kv2019i Yes, this fixes the issue, but I think there's been some side effects.

Namely, starting with the GDB option like this:

./xtensa-host.sh byt -d

would end up the qemu-system-xtensa to be called without '-s':

./xtensa-softmmu/qemu-system-xtensa -cpu baytrail -M adsp_byt -S -nographic

That's because DARGS now gets set to '-S' as no kernel is given. How about using CARGS for '-S' and DARGS for '-s' alone? I've created PR #17 for that purpose ...

Additionally if I run with a kernel, like this:

./xtensa-host.sh byt -k ../sof/build_byt/sof-byt.ri

I end up with -S, so the firmware doesn't start up:

./xtensa-softmmu/qemu-system-xtensa -cpu baytrail -M adsp_byt -S -nographic -kernel ../sof/build_byt/sof-byt.ri

PR #17 also fixes that.

[kv2019i]

@dragosht wrote:

@kv2019i Yes, this fixes the issue, but I think there's been some side effects.

Namely, starting with the GDB option like this:

D'oh, sorry, I meant to put the kernel check before the while loop start, so that if "-d/--debug" is passed, DARGS would be overwritten with the debug values.

PR #17 also fixes that.

This is even better, thanks!

[lgirdwood]

@kv2019i PR #17 now merged - can we close ?

[kv2019i]

@kv2019i PR #17 now merged - can we close ?

@lgirdwood Ack, this is good to close.