- Sound-open-firmware - mailman.alsa-project.org

Re: [Sound-open-firmware] MinnowBoard FW fails to boot
by Guennadi Liakhovetski 25 Mar '19

25 Mar '19

Hi Xiuli, On Mon, Mar 25, 2019 at 03:52:21AM +0000, Pan, Xiuli wrote: > >-----Original Message----- > >From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa- > >project.org] On Behalf Of Ranjani Sridharan > >Sent: Saturday, March 23, 2019 04:40 > >To: Liam Girdwood <liam.r.girdwood(a)linux.intel.com>; Guennadi Liakhovetski > ><guennadi.liakhovetski(a)linux.intel.com>; sound-open-firmware@alsa- > >project.org > >Subject: Re: [Sound-open-firmware] MinnowBoard FW fails to boot > > > >On Fri, 2019-03-22 at 16:14 +0000, Liam Girdwood wrote: > >> On Fri, 2019-03-22 at 17:03 +0100, Guennadi Liakhovetski wrote: > >> > Hi, > >> > > >> > Is MinnowBoard supposed to work with the current sources? > >> > > >> > >> Yes. > >> > >> > I tried 2 boards: an older Max and a new Turbot with the same > >> > result. After upgrading the BIOS to 1.0 and configuring it as > >> > described on > >> > > >https://thesofproject.github.io/latest/getting_started/setup/setup_minnowboa > >rd_turbot.html > >> > and installing the ACPI scripts, I see the following in dmesg: > >> > > >> > [ 7.858284] sof-audio-acpi 80860F28:01: ACPI DSP detected > >> > [ 7.858293] sof-audio-acpi 80860F28:01: BYT-CR not detected > >> > [ 7.858417] sof-audio-acpi 80860F28:01: probing SOF DSP > >> > device.... > >> > [ 7.858437] sof-audio-acpi 80860F28:01: sof_probe_work entry > >> > [ 7.858442] sof-audio-acpi 80860F28:01: LPE PHY base at > >> > 0x90a00000 size > >> > 0x200000 > >> > [ 7.858495] sof-audio-acpi 80860F28:01: LPE VADDR > >> > 000000005df3cd39 > >> > [ 7.858498] sof-audio-acpi 80860F28:01: IMR base at 0x20000000 > >> > size > >> > 0x100000 > >> > [ 7.858525] sof-audio-acpi 80860F28:01: IMR VADDR > >> > 00000000c1d6001c > >> > [ 7.858530] sof-audio-acpi 80860F28:01: using IRQ 29 > >> > [ 7.861914] sof-audio-acpi 80860F28:01: loading firmware > >> > [ 7.903934] sof-audio-acpi 80860F28:01: header size=0xc9a4 > >> > modules=0x1 > >> > abi=0x1 size=16 > >> > [ 7.903980] sof-audio-acpi 80860F28:01: new module size 0xc998 > >> > blocks 0x11 > >> > type 0x0 > >> > [ 7.903984] sof-audio-acpi 80860F28:01: block 0 type 0x1 size > >> > 0xf0 > >> > ==> offset 0xc0000 > >> > [ 7.904148] sof-audio-acpi 80860F28:01: block 1 type 0x1 size > >> > 0x16c > >> > ==> offset 0xc0400 > >> > [ 7.904454] sof-audio-acpi 80860F28:01: block 2 type 0x1 size > >> > 0x8 > >> > ==> offset 0xc057c > >> > [ 7.904461] sof-audio-acpi 80860F28:01: block 3 type 0x1 size > >> > 0x8 > >> > ==> offset 0xc059c > >> > [ 7.904468] sof-audio-acpi 80860F28:01: block 4 type 0x1 size > >> > 0x8 > >> > ==> offset 0xc05bc > >> > [ 7.904475] sof-audio-acpi 80860F28:01: block 5 type 0x1 size > >> > 0x8 > >> > ==> offset 0xc05dc > >> > [ 7.904481] sof-audio-acpi 80860F28:01: block 6 type 0x1 size > >> > 0x8 > >> > ==> offset 0xc05fc > >> > [ 7.904488] sof-audio-acpi 80860F28:01: block 7 type 0x1 size > >> > 0x4 > >> > ==> offset 0xc061c > >> > [ 7.904492] sof-audio-acpi 80860F28:01: block 8 type 0x1 size > >> > 0x8 > >> > ==> offset 0xc063c > >> > [ 7.904498] sof-audio-acpi 80860F28:01: block 9 type 0x1 size > >> > 0x4 > >> > ==> offset 0xc0658 > >> > [ 7.904502] sof-audio-acpi 80860F28:01: block 10 type 0x1 size > >> > 0x18 > >> > ==> offset 0xc065c > >> > [ 7.904522] sof-audio-acpi 80860F28:01: block 11 type 0x1 size > >> > 0x8 > >> > ==> offset 0xc067c > >> > [ 7.904529] sof-audio-acpi 80860F28:01: block 12 type 0x1 size > >> > 0xad20 > >> > ==> offset 0xc06a0 > >> > [ 7.942341] sof-audio-acpi 80860F28:01: block 13 type 0x2 size > >> > 0xc34 > >> > ==> offset 0x100008 > >> > [ 7.945002] sof-audio-acpi 80860F28:01: block 14 type 0x2 size > >> > 0x8 > >> > ==> offset 0x100c3c > >> > [ 7.945009] sof-audio-acpi 80860F28:01: block 15 type 0x2 size > >> > 0xc50 > >> > ==> offset 0x100c48 > >> > [ 7.947695] sof-audio-acpi 80860F28:01: block 16 type 0x2 size > >> > 0x6c > >> > ==> offset 0x101f20 > >> > [ 7.947797] sof-audio-acpi 80860F28:01: booting DSP firmware > >> > [ 7.993488] intel_rapl: Found RAPL domain package > >> > [ 7.993491] intel_rapl: Found RAPL domain core > >> > [ 9.037666] sof-audio-acpi 80860F28:01: error: unable to run > >> > DSP firmware > >> > [ 9.038008] sof-audio-acpi 80860F28:01: error: unexpected fault > >> > 0xffffffff > >> > trace 0xffffffff > >> > [ 9.038094] sof-audio-acpi 80860F28:01: error: failed to reset > >> > DSP > >> > [ 9.038159] sof-audio-acpi 80860F28:01: error: failed to boot > >> > DSP firmware > >> > -19 > >> > [ 9.038266] sof-audio-acpi 80860F28:01: error: sof_probe_work > >> > failed err: > >> > -19 > >> > >> Looks like a driver regression, since 0xffffffff means PCI address > >> space is > >> powered OFF when it should be ON. > >> > >> Can you log as a regression on GH. > >Liam/Guennadi, > > > >I dont see this regression with my minnowboard + RT5651 set up. > > > Hi Guennadi, > > Please check if you do the following step. Most people ignored this, since they did not start with a blank one. > > Also enable LPE Audio Support in bios Yes, I've done this afteer every BIOS upgrade and it didn't help. Thanks Guennadi > path: Device Manager→ System Setup→ South Cluster Configuration→ Audio Configuration→ LPE Audio Support (LPE Audio ACPI mode) > > If this works, let us update in GitHub Wiki.

2 4

[Sound-open-firmware] suspicious code in hda-ipc.c
by Guennadi Liakhovetski 20 Mar '19

20 Mar '19

Hi, This code in hda_dsp_ipc_get_reply() in hda-ipc.c looks suspicious to me: hdr = msg->msg_data; if (hdr->cmd == (SOF_IPC_GLB_PM_MSG | SOF_IPC_PM_CTX_SAVE)) { ... } else { /* get IPC reply from DSP in the mailbox */ sof_mailbox_read(sdev, sdev->host_box.offset, &reply, sizeof(reply)); } if (reply.error < 0) { size = sizeof(reply); ret = reply.error; } else { ... } /* read the message */ if (msg->msg_data && size > 0) sof_mailbox_read(sdev, sdev->host_box.offset, msg->reply_data, size); So, as far as I understand, first of all the first part of the "if (msg->msg_data && ...)" test is always true, since we've already dereferenced "hdr" above. Secondly if reply contains a negative error the reply struct will be read from the mailbox again, instead of just using "memcpy(msg->reply_data, &reply, sizeof(reply));" to copy it? The same pattern is also repeated in other IPC implementations. Thanks Guennadi

3 2

[Sound-open-firmware] Multiple configurations per DAI in topology
by Dragos Tarcatu 20 Mar '19

20 Mar '19

Hello All, Is there a way to create multiple configurations for an SSP DAI in a topology file? I see there's an open issue on the soft repo for that ( https://github.com/thesofproject/soft/issues/11 ), but soft is now archived. Issue #630: https://github.com/thesofproject/sof/issues/630 seems somewhat similar, but I'm not sure if that's the same thing. Thanks, Dragoș

4 4

[Sound-open-firmware] automated audio testing
by Guennadi Liakhovetski 19 Mar '19

19 Mar '19

Hi, I'm bisecting a playback breakage on Up^2 and within just 122 commits I've allso found a second breakage, which however then has been fixed. My question is: how difficult would it be to implement an automated audio quality testing CI? Like real audio playback of an audio sample to an analog or a digital output with a subsequent capture and comparison? Potentially also with a similar capture test? I think it would be of a great help. Thanks Guennadi

2 1

[Sound-open-firmware] cache invalidation evicting wrong lines
by Guennadi Liakhovetski 18 Mar '19

18 Mar '19

Hi, Working on https://github.com/thesofproject/sof/pull/1053 I'm making sure all the DSP cores see the same data, which on Xtensa seems to require manual cache synchronisation. This is a painful task, it's actually even only practically possible because there aren't many objects in SOF that can be accessed by different cores. However, with that PR interrupt descriptors will also become accessible by multiple cores. On Sue Creek there are two kinds of cascading interrupt controllers: internal "level2" - "level5" and a DesignWare interrupt controller IP, used by several peripherals, uncliding the UART. With the addition of manual cache synchronisation UART interrupts stopped working. Debugging showed, that DW INTC interrupt descriptors lose their updates when other descriptors have their cache invalidated. And those descriptors aren't even immediately close to each other in RAM. Roughly the following is happening: dw_intc->irq = new_irq; list_for_item(list, descriptors) { desc = container_of(list, struct irq_desc, list); dcache_invalidate_region(desc, sizeof(*desc)); at which point dw_intc->irq loses its new_irq value and restores the initial -EINVAL value. If I either remove the invalidation line above or add a writeback for dw_intc between the first two lines, the problem goes away. Therefore questions: 1. am I using cache invalidation wrongly? 2. if the invalidated memory region isn't cache-line aligned, what happens then? Are all full lines invalidated, thus potentially erasing data? But even if this were handled wrongly, it wouldn't cause this problem, because those descriptors aren't adjacent in RAM. 3. is that a software or a hardware bug? 4. how to fix? Thanks Guennadi

2 7

[Sound-open-firmware] MinnowBoard FW fails to boot
by Guennadi Liakhovetski 11 Mar '19

11 Mar '19

Hi, Is MinnowBoard supposed to work with the current sources? I tried 2 boards: an older Max and a new Turbot with the same result. After upgrading the BIOS to 1.0 and configuring it as described on https://thesofproject.github.io/latest/getting_started/setup/setup_minnowbo… and installing the ACPI scripts, I see the following in dmesg: [ 7.858284] sof-audio-acpi 80860F28:01: ACPI DSP detected [ 7.858293] sof-audio-acpi 80860F28:01: BYT-CR not detected [ 7.858417] sof-audio-acpi 80860F28:01: probing SOF DSP device.... [ 7.858437] sof-audio-acpi 80860F28:01: sof_probe_work entry [ 7.858442] sof-audio-acpi 80860F28:01: LPE PHY base at 0x90a00000 size 0x200000 [ 7.858495] sof-audio-acpi 80860F28:01: LPE VADDR 000000005df3cd39 [ 7.858498] sof-audio-acpi 80860F28:01: IMR base at 0x20000000 size 0x100000 [ 7.858525] sof-audio-acpi 80860F28:01: IMR VADDR 00000000c1d6001c [ 7.858530] sof-audio-acpi 80860F28:01: using IRQ 29 [ 7.861914] sof-audio-acpi 80860F28:01: loading firmware [ 7.903934] sof-audio-acpi 80860F28:01: header size=0xc9a4 modules=0x1 abi=0x1 size=16 [ 7.903980] sof-audio-acpi 80860F28:01: new module size 0xc998 blocks 0x11 type 0x0 [ 7.903984] sof-audio-acpi 80860F28:01: block 0 type 0x1 size 0xf0 ==> offset 0xc0000 [ 7.904148] sof-audio-acpi 80860F28:01: block 1 type 0x1 size 0x16c ==> offset 0xc0400 [ 7.904454] sof-audio-acpi 80860F28:01: block 2 type 0x1 size 0x8 ==> offset 0xc057c [ 7.904461] sof-audio-acpi 80860F28:01: block 3 type 0x1 size 0x8 ==> offset 0xc059c [ 7.904468] sof-audio-acpi 80860F28:01: block 4 type 0x1 size 0x8 ==> offset 0xc05bc [ 7.904475] sof-audio-acpi 80860F28:01: block 5 type 0x1 size 0x8 ==> offset 0xc05dc [ 7.904481] sof-audio-acpi 80860F28:01: block 6 type 0x1 size 0x8 ==> offset 0xc05fc [ 7.904488] sof-audio-acpi 80860F28:01: block 7 type 0x1 size 0x4 ==> offset 0xc061c [ 7.904492] sof-audio-acpi 80860F28:01: block 8 type 0x1 size 0x8 ==> offset 0xc063c [ 7.904498] sof-audio-acpi 80860F28:01: block 9 type 0x1 size 0x4 ==> offset 0xc0658 [ 7.904502] sof-audio-acpi 80860F28:01: block 10 type 0x1 size 0x18 ==> offset 0xc065c [ 7.904522] sof-audio-acpi 80860F28:01: block 11 type 0x1 size 0x8 ==> offset 0xc067c [ 7.904529] sof-audio-acpi 80860F28:01: block 12 type 0x1 size 0xad20 ==> offset 0xc06a0 [ 7.942341] sof-audio-acpi 80860F28:01: block 13 type 0x2 size 0xc34 ==> offset 0x100008 [ 7.945002] sof-audio-acpi 80860F28:01: block 14 type 0x2 size 0x8 ==> offset 0x100c3c [ 7.945009] sof-audio-acpi 80860F28:01: block 15 type 0x2 size 0xc50 ==> offset 0x100c48 [ 7.947695] sof-audio-acpi 80860F28:01: block 16 type 0x2 size 0x6c ==> offset 0x101f20 [ 7.947797] sof-audio-acpi 80860F28:01: booting DSP firmware [ 7.993488] intel_rapl: Found RAPL domain package [ 7.993491] intel_rapl: Found RAPL domain core [ 9.037666] sof-audio-acpi 80860F28:01: error: unable to run DSP firmware [ 9.038008] sof-audio-acpi 80860F28:01: error: unexpected fault 0xffffffff trace 0xffffffff [ 9.038094] sof-audio-acpi 80860F28:01: error: failed to reset DSP [ 9.038159] sof-audio-acpi 80860F28:01: error: failed to boot DSP firmware -19 [ 9.038266] sof-audio-acpi 80860F28:01: error: sof_probe_work failed err: -19 Thanks Guennadi

3 3

[Sound-open-firmware] checkpatch.pl fixes
by Daniel Baluta 04 Mar '19

04 Mar '19

Hi all, What is your take on checkpatch.pl fixes for SOF FW? Diana (CC'ed) is trying to get accustomed with SOF code and while at that she can fix some obvious checkpatch.pl warn / errors. Does it make sense to send some patches for that? I know that this kind of fixes can pollute the change history but on the other side code gets a little bit cleaner. thanks, Daniel.

3 3

Re: [Sound-open-firmware] help with unit tests
by Wilson, Danny 28 Feb '19

28 Feb '19

Hello, I am a new user from VeriSilicon, also trying to get unit tests to run. Thanks for bringing this project to GitHub. On 2/8/19 1:06 PM Jankowski, Janusz wrote: > TL;DR: Unit Tests are not supported for xtensa GCC toolchains at the moment (work in progress). You can run them only with xtensa xt-* toolchain that provides simulator (xt-run). On 2/8/19 8:24 PM, Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com worte: > FWIW, there is an alternate way of getting everything in one shot with > 'repo', there are build-scripts provided so that you can reproduce the > same setup as other developers. > > repo init -u https://github.com/thesofproject/sof-manifests > > repo sync -c My environment is: Ubuntu 18.04.2 LTS When trying the alternate method described by Pierre, I get the following permission denied error: ~/work/sof$ repo init -u https:://github.com/thesofproject/sof-manifests Traceback (most recent call last): File "/home/us9005/work/sof/.repo/repo/main.py", line 40, in <module> import event_log File "/home/us9005/work/sof/.repo/repo/event_log.py", line 165, in <module> _EVENT_ID = multiprocessing.Value('i', 1) File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/__init__.py", line 253, in Value return Value(typecode_or_type, *args, **kwds) File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/sharedctypes.py", line 108, in Value lock = RLock() File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/__init__.py", line 183, in RLock return RLock() File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/synchronize.py", line 172, in __init__ SemLock.__init__(self, RECURSIVE_MUTEX, 1, 1) File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/synchronize.py", line 75, in __init__ sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) OSError: [Errno 13] Permission denied Is this a repository permission I am lacking? Is there a particular build-script that includes the xtensa-xt* toolchain for unit tests? Regards, Danny Wilson

2 1

[Sound-open-firmware] [PATCH] topology: ssp: add polarity inversion option in SSP_CLOCK
by Dragos Tarcatu 25 Feb '19

25 Feb '19

alsatplg allows setting inverted bclk and fsync polarities by setting either bclk_invert or fsync_invert to "true". This patch adds a default parameter in the SSP_CLOCK m4 macro which allows setting inverted bclk and fsync polarities. Signed-off-by: Dragos Tarcatu <dragos_tarcatu(a)mentor.com> --- tools/topology/platform/common/ssp.m4 | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/topology/platform/common/ssp.m4 b/tools/topology/platform/common/ssp.m4 index f3c7862..76b2766 100644 --- a/tools/topology/platform/common/ssp.m4 +++ b/tools/topology/platform/common/ssp.m4 @@ -2,11 +2,12 @@ divert(-1) dnl SSP related macros -dnl SSP_CLOCK(clock, freq, codec_master) +dnl SSP_CLOCK(clock, freq, codec_master, polarity) +dnl polarity is optional define(`SSP_CLOCK', $1 STR($3) - $1_freq STR($2)) - + $1_freq STR($2) + `ifelse($4, `inverted', `$1_invert "true"',`')') dnl SSP_TDM(slots, width, tx_mask, rx_mask) define(`SSP_TDM', -- 2.7.4

2 1

Re: [Sound-open-firmware] [alsa-devel] [v4, 00/14] ASoC: Sound Open Firmware (SOF) core
by xiang xiao 25 Feb '19

25 Feb '19

On Tue, Feb 19, 2019 at 5:49 PM Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> wrote: > > > > On 18/02/2019 20:03, Xiang Xiao wrote: > > Should we utilize official IPC frameowrk instead reinverting the wheel? > > 1.Load firmware by drivers/remoteproc > > https://www.kernel.org/doc/Documentation/remoteproc.txt > > 2.Do the comunication through drivers/rpmsg > > https://www.kernel.org/doc/Documentation/rpmsg.txt > > Many vendor(TI, Qualcomm, ST, NXP, Xilinx...) migrate to remoteproc/rpmsg, why Intel provide an other IPC mechanism? > > It definitely makes more sense to use rpmsg for Generic IPC driver here. > > Qualcomm DSP audio drivers (non SOF) already use rpmsg. This will > definitely help everyone in future while immigrating to SOF. > Actually, Xiaomi also build DSP audio driver on top of rpmsg, but fully integrate with the ASoC topology framework, and the firmware is base on FreeRTOS and OpenMAX. SOF initiative is very good and exciting, our team members(include me) spend a couple weeks to study the current code base on both firmware and kernel side, we even port SOF to our DSP/MCU and make it run, but I have to point out that: SOF IPC is too simple and rigid, tightly couple with Intel platform and audio domain, which make: a.It's difficult to integrate with other vendor SoC, especially if other vendor already adopt remote/rpmsg(this is already a trend!). b.It's difficult to add other IPC services for example: i.Audio DSP talk to power MCU to adjust clock and voltage ii.Export ultrasonic distance measurement to IIO subsystem > > Actually, remoteproc/rpmsg is much better than SOF IPC because: > > 1.Completely isolate the firmware load and message transfer: > > The same rpmsg driver could run on any remote processor > > 2.Separate the application protocol from transfer layer: > > One remote processor could host many rpmsg services > > 3.Completely follow kernel driver model(rpsmg_bus, rpmsg_device and rpmsg_driver). > > 4.Support by many RTOS(Bare Metal, FreeRTOS, Zephyr, NuttX, Nucleus, uC/OS...) for remote side: > > https://github.com/OpenAMP/open-amp > > https://github.com/NXPmicro/rpmsg-lite > > 5.Maintained by the standard committee: > > https://www.multicore-association.org/workgroup/oamp.php > > https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio > > Since the keypoint of SOF is the platform agnostic and modular, please use the standard technique here. > > > > Thanks > > Xiang > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel(a)alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > --srini

6 13