Sound-open-firmware December 2019

sound-open-firmware@alsa-project.org

9 participants
6 discussions

[Sound-open-firmware] Generic panic handling
by Paul Olaru (OSS) 20 Dec '19

20 Dec '19

Hello, I would like panics on our DSP to actually be properly reported to the kernel. Currently on the Intel platforms for panic there is custom code for each platform to e.g. read from the shim area and check with the panic magic mask whether there is a panic. My suggestion is to instead craft a specific message type and a very short message (possibly only that one word with the panic mask, which will not be confused with a regular DSP request header) which is then handled in a generic fashion within snd_sof_ipc_msgs_rx. I am aware that such a change will affect several platforms so I'm currently just raising the issue as I want to know if it's a good idea before starting work on it. Also, does this qualify as a minor ABI bump?

2 1

[Sound-open-firmware] Status of ssp driver in Qemu
by Daniel Baluta 20 Dec '19

20 Dec '19

Hi Liam, I wonder what is the status of the SSP driver in Qemu. Particularly, I'm interested about ssp->tx.fd / ssp->rx.fd. It looks like these files are only opened and closed but never written to / read from. Can you explain what is your idea on emulating the DAIs on Qemu? thanks, Daniel.

3 3

[Sound-open-firmware] A kind reminder on writing commit messages
by Daniel Baluta 19 Dec '19

19 Dec '19

Hi all, I'm now trying to understand some changes related to notifiers and I would have really liked to see better commit description. A kind reminder that when you write a commit message that commit serves as documentation for poor readers that will later try to debug the code. Even if the code looks obvious to you that might not look obvious for others. So, please for non-trivial changes: * explain why the commit is needed * explain what is the problem that the commit tries to fix * explain why the current solution is better than the old approach * briefly explain how the new solution work thanks, Daniel.

1 0

Re: [Sound-open-firmware] Testing SOF firmware boot with Qemu
by Daniel Baluta 11 Dec '19

11 Dec '19

Hi Xiuli, Maybe this fall through the cracks 🙂. So, the question here is how do you check that booting dsp with Qemu works fine 🙂. Care to share the test scripts? Daniel. ________________________________ From: Daniel Baluta Sent: Wednesday, December 4, 2019 10:05 AM To: Pan, Xiuli <xiuli.pan(a)intel.com> Cc: Liam Girdwood <liam.r.girdwood(a)intel.com>; Diana Cretu <diana.cretu(a)nxp.com>; dl-sof <sof(a)nxp.com> Subject: Testing SOF firmware boot with Qemu Hi Xiuli, I want to understand the testcase for booting SOF firmware with Qemu. It seems the test is started like this: ./xtensa-softmmu/qemu-system-xtensa -cpu broxton -M adsp_skl -nographic -kernel ../sof.git/build_skl_gcc/src/arch/xtensa/sof-skl.ri -rom ../sof.git/build_skl_gcc/src/arch/xtensa/rom-skl.bin What I don't understand is how you figure out the boot is OK or not? Can you share the test script 🙂. thanks, Daniel.

3 3

[Sound-open-firmware] Issues with using qemu emulator
by Tomasz Duszynski 10 Dec '19

10 Dec '19

Hi, I heard about SOF some time ago but did not have time to take a closer look until now. I decided to start with Qemu and stumbled upon some problems. Would be great if someone could take a look at attached logs. Here's component stack I have at the moment: 1. Linux: branch topic/sof-dev, commit 3c39107 ASoC: topology: Check return value for soc_tplg_pcm_create() 2. SOF: branch sof-dev, commit c7d0149 pipeline: fix tasks initialization commit 3. Qemu: branch sof-v4.2 commit 8b66b81 qemu: io-bridge: remind users to start DSP first. I am starting VMs using provided helper scripts i.e xtensa-host.sh and x86-host.sh (run in that sequence). Here's what ./xtensa-host.sh shows: [tdu@home:~/workspace/sof/qemu]$ ./xtensa-host.sh byt ./xtensa-softmmu/qemu-system-xtensa -cpu baytrail -M adsp_byt -nographic -S bridge-io: qemu-bridge-iram-mem fd 9 region 1 at 0x7fa5d8fd2000 allocated 81920 bytes bridge-io: qemu-bridge-dram-mem fd 10 region 2 at 0x7fa5c988e000 allocated 163840 bytes bridge-io: qemu-bridge-dmac0-io fd 11 region 3 at 0x7fa5d900f000 allocated 4096 bytes bridge-io: qemu-bridge-dmac1-io fd 12 region 4 at 0x7fa5d8fd1000 allocated 4096 bytes bridge-io: qemu-bridge-ssp0-io fd 13 region 5 at 0x7fa5d8fd0000 allocated 4096 bytes bridge-io: qemu-bridge-ssp1-io fd 14 region 6 at 0x7fa5d8fcf000 allocated 4096 bytes bridge-io: qemu-bridge-ssp2-io fd 15 region 7 at 0x7fa5d8fce000 allocated 4096 bytes bridge-io: qemu-bridge-shim-io fd 16 region 8 at 0x7fa5d8fcd000 allocated 4096 bytes bridge-io: qemu-bridge-mbox-io fd 17 region 9 at 0x7fa5d8fcc000 allocated 4096 bytes 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 4.1.93 monitor - type 'help' for more information (qemu) bridge-io: msg recv 0 type 1 size 20 msg 32 msg: id 0 msg 32 size 20 type 1 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 irq: SHIM_IMRLPESC masking 0 mask 0 active 0 irq: SC send busy interrupt 0xc2 irq: SHIM_IMRLPESC masking 1 mask 1 active 0 irq: SHIM_IMRLPESC masking 0 mask 0 active 0 irq: SC send busy interrupt 0xc5 irq: SHIM_IMRLPESC masking 1 mask 1 active 0 irq: SHIM_IMRLPESC masking 0 mask 0 active 0 IRQ: from DMAC 0 status 0 block 0 tfr 0 IRQ: from DMAC 0 status 0 block 0 tfr 0 irq: IMRD masking 0 mask 0 active 0 irq: PIMR masking 0 mask 38 active 0 IRQ: from DMAC 1 status 0 block 0 tfr 0 IRQ: from DMAC 1 status 0 block 0 tfr 0 irq: send busy interrupt 0x80000000 bridge-io: msg send: 0 type 2 msg 64 size 16 ret 0 bridge-io: msg recv 3 type 2 size 16 msg 64 msg: id 3 msg 64 size 16 type 2 IRQ: from HOST status 1 mask 0 active 1 cmd 0 irq: IMRD masking 1 mask 1 active 0 irq: IMRD masking 1 mask 0 active 1 bridge-io: msg recv 4 type 2 size 16 msg 64 msg: id 4 msg 64 size 16 type 2 IRQ: from HOST status 2 mask 0 active 2 cmd 0 irq: IMRD masking 2 mask 2 active 0 dma: 0:0: start SAR 0xd8f7000 DAR 0xff30c338 size 0x28 DMA req: src 0xd8f7000 dest 0xff30c338 size 0x28 bridge-io: msg send: 1 type 5 msg 96 size 56 ret 0 bridge-io: msg recv 5 type 5 size 56 msg 97 msg: id 5 msg 97 size 56 type 5 bridge-io: qemu-bridge-dmac:0.0 fd 20 region 16 at 0x7fa5d8fcb000 allocated 40 bytes IRQ: from DMAC 0 status 2 block 1 tfr 0 IRQ: DMAC 0 set DMA req complete: src 0xd8f7000 dest 0xff30c338 size 0x38 bridge-io: msg send: 2 type 5 msg 98 size 56 ret 0 IRQ: from DMAC 0 status 3 block 1 tfr 1 IRQ: from DMAC 0 status 3 block 1 tfr 1 IRQ: from DMAC 0 status 3 block 1 tfr 1 irq: send done interrupt 0x40000000 bridge-io: msg send: 3 type 2 msg 64 size 16 ret 0 irq: IMRD masking 2 mask 0 active 2 bridge-io: msg recv 6 type 2 size 16 msg 64 msg: id 6 msg 64 size 16 type 2 IRQ: from HOST status 2 mask 0 active 2 cmd 0 irq: IMRD masking 2 mask 2 active 0 irq: send done interrupt 0x40000000 bridge-io: msg send: 4 type 2 msg 64 size 16 ret 0 irq: IMRD masking 2 mask 0 active 2 dma: 1:0: start SAR 0xff31c800 DAR 0x0 size 0x83c DMA req: src 0xff31c800 dest 0x0 size 0x83c bridge-io: msg send: 5 type 5 msg 96 size 56 ret 0 bridge-io: msg recv 7 type 5 size 56 msg 97 msg: id 7 msg 97 size 56 type 5 error: can't create SHM size 0x83c for DMAC 1 chan 0 While the companion x86-host.sh shows: [tdu@home:~/workspace/sof/qemu]$ ./x86-host.sh byt bridge-io: qemu-bridge-iram-mem fd 19 region 1 at 0x7f09d9cb7000 allocated 81920 bytes bridge-io: qemu-bridge-dram-mem fd 20 region 2 at 0x7f09cbfd8000 allocated 163840 bytes bridge-io: qemu-bridge-pci-io fd 21 region 3 at 0x7f09e93d1000 allocated 4096 bytes bridge-io: qemu-bridge-shim-io fd 22 region 4 at 0x7f09e93d0000 allocated 4096 bytes bridge-io: qemu-bridge-mbox-io fd 23 region 5 at 0x7f09e93cf000 allocated 4096 bytes bridge-io-mq: added /qemu-io-parent-byt bridge-io-mq: added /qemu-io-child-byt bridge-io: 0 messages are currently on parent queue. bridge-io: msg send: 0 type 1 msg 32 size 20 ret 0 bridge-io: msg send: 1 type 1 msg 32 size 20 ret 0 bridge-io: msg send: 2 type 1 msg 32 size 20 ret 0 bridge-io: msg recv 0 type 2 size 16 msg 64 msg: id 0 msg 64 size 16 type 2 DSP IRQ: status 2 mask 0 active 2 cmd 70028800 irq: masking 0 mask 0 active 0 irq: send done interrupt 0x40000000 bridge-io: msg send: 3 type 2 msg 64 size 16 ret 0 irq: masking 1 mask 0 active 2 irq: send busy interrupt 0x80000000 bridge-io: msg send: 4 type 2 msg 64 size 16 ret 0 bridge-io: msg recv 1 type 5 size 56 msg 96 msg: id 1 msg 96 size 56 type 5 bridge-io: qemu-bridge-(null) fd 31 region 16 at 0x7f09d9c9e000 allocated 40 bytes bridge-io: msg send: 5 type 5 msg 97 size 56 ret 0 bridge-io: msg recv 2 type 5 size 56 msg 98 msg: id 2 msg 98 size 56 type 5 bridge-io: msg recv 3 type 2 size 16 msg 64 msg: id 3 msg 64 size 16 type 2 DSP IRQ: status 1 mask 0 active 1 cmd 70028800 irq: masking 2 mask 0 active 0 irq: masking 0 mask 0 active 1 irq: send busy interrupt 0x80000000 bridge-io: msg send: 6 type 2 msg 64 size 16 ret 0 bridge-io: msg recv 4 type 2 size 16 msg 64 msg: id 4 msg 64 size 16 type 2 DSP IRQ: status 1 mask 0 active 1 cmd 70028800 bridge-io: msg recv 5 type 5 size 56 msg 96 msg: id 5 msg 96 size 56 type 5 error: cant alloc dma SHM -16 bridge-io: msg send: 7 type 5 msg 97 size 56 ret 0 irq: masking 2 mask 0 active 0 irq: masking 0 mask 0 active 1 So if I am not mistaken setup fails because some shared memory region cannot be allocated. Below a callstack leading to error present in logs. hw/dma/dw-dma-core.c: dw_dma_msg() dma_M2M_do_transfer() qemu_io_register_shm() <-- ADSP_IO_SHM_DMA(1, 0) region if (_iob.shm[region].fd) return -EBUSY; Now, if one goes back to xtensa logs it turns out that code wants region ADSP_IO_SHM_DMA(1, 0) which evaluates to 32. This means we are touching memory outside _iob.shm[] array (which has 32 entries). Any thoughts?

1 0

[Sound-open-firmware] How to check first frames on playback
by Paul Olaru 05 Dec '19

05 Dec '19

What is a good way to check that the first frames when starting playback with a file are correct and not reordered or repeated? I have tried to modify my host DMA driver to dump the frames as it transfers them and I see that the data transferred is the same as in the file but the first two frames are reordered and repeated, at least when I set the buffer size to be very small in aplay (--buffer-size=96). My test is to attempt to play a 768-byte raw file (2 channels, S16_LE) and dump all the data transferred by my host DMA driver. From the dumps (within the limits of etrace; I don't have DMA trace working as I didn't focus on that) I notice that several of the frames within the first period (first 384 bytes) end up being repeated and in the wrong ordering. The issue is unimportant with uncompressed playback as that would just be a small, 2ms glitch which is hardly audible, especially if you also have a volume ramp or the file is silent or mostly silent in the beginning. However, I want to implement support for compressed playback at some point which requires such glitches to not happen with the data before it even enters the pipeline (any bit change will cause corruption which is definitely audible or even failure of the decoding algorithm). So how should I check that the first few frames during playback are actually the correct ones?

3 3

2023

2022

2021

2020

2019

2018

2017

2016

Sound-open-firmware December 2019