Sound-open-firmware February 2020

sound-open-firmware@alsa-project.org

10 participants
6 discussions

[Sound-open-firmware] [Re]: Make error when building topology and tools
by Mohana Datta Yelugoti 02 Mar '20

02 Mar '20

Hi all, I am trying to building SOF from scratch by following through the official documentation guide [0]. I am getting errors when trying to build Topology and tools [1]. I am providing pastebin links to topology_log [2] and topology_error_log [3]. topology_log contains output to stdout and topology_error_log contains the output to stderr. I was able to build in docker successfully before. But, when i am trying to build from scratch, i encountered this error. Can someone guide me in solving this error. The system i am building runs on Ubuntu 19.19 eoan. My kernel version is 5.3.0-40-generic. Please feel free to ask for any other information, if i am missing any. Thank you for your time. Regards, ymdatta. References: ---------- [0]: https://thesofproject.github.io/latest/getting_started/build-guide/build-fr… [1]: https://thesofproject.github.io/latest/getting_started/build-guide/build-fr… [2]: https://paste.gnome.org/pffxkrwjm/cvhcko [3]: https://paste.gnome.org/pg9mefnet/crqsix

3 5

Re: [Sound-open-firmware] Regarding SOF and contributing to it
by Akriti Verma 27 Feb '20

27 Feb '20

Hi Daniel I am trying to build the SOF project from scratch as per the build instructions given at *'https://thesofproject.github.io <https://thesofproject.github.io>*'. I was trying to build the '*alsa-utils*' when i got stuck at *./gitcompile* command giving the following error:- "configure: error: No linkable libatopology was found." For reference i have attached the screenshot as well. Request you to provide some insight as to what must be done here to get over the issue. Thanks On Wed, Feb 26, 2020 at 8:19 PM Akriti Verma <akriti.v10(a)gmail.com> wrote: > Hi Daniel > > Thanks for responding.. I'll surely start with the checkpatch.pl command > and start with the TODO list as well asap. > > Thanks and regards > Akriti > > On Wed, Feb 26, 2020, 7:45 PM Daniel Baluta <daniel.baluta(a)nxp.com> wrote: > >> Hi Akriti, >> >> Good news that you have some patches in the kernel. For start you can fix >> some trivial checkpatch.pl errors/warnings in SOF repo. >> >> Will try to add some sort of TODO list on the GSoC page this week. >> >> Thanks for your interest. >> >> On 26.02.2020 15:42, Akriti Verma wrote: >> >> Hi Daniel, >> >> I am Akriti Verma. I contribute to Linux Kernel. >> I recently came across the SOF project and I would like to start working >> on some bugs. Can you give me some pointers on how to start? >> >> P.S. I have already gone through the documentation provided on >> https://thesofproject.github.io/latest/index.html >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fthesofpro…> >> >> Thanks and Regards >> Akriti >> >> >> >>

2 1

[Sound-open-firmware] Question about DMA interrupts
by Paul Olaru 26 Feb '20

26 Feb '20

Hello, I'm currently working on implementing the driver for a new DMA controller on the i.MX platform. I'm currently looking at the interrupt handling part and I figure that there is nothing I could find in the documentation or prior code pointing at the ability to mask and unmask interrupts for the individual channels. Also, the interrupts go through a single IRQ line, if that is helpful. I figured I may be able to use the DMA single channel domain for this purpose, however I don't know what Implementation I should do in the dma_interrupt callback of the actual DMA driver. Can you chime in on this? Commit message says the single channel domain cannot be used with DMAs that require manual reload of the transfer descriptors, so what should I do? I mean I think I could do 2 descriptors to avoid manual reloading but if I can't what should I try next?

1 0

[Sound-open-firmware] [PATCH 0/3] ASoC: SOF: VirtIO: preparatory patches
by Guennadi Liakhovetski 10 Feb '20

10 Feb '20

This is the first set of patches for the SOF virtualisation work. We send these patches first because they touch the ASoC core. 2 of them are mostly cosmetic with no functional changes, but patch 2/3 might cause some discussions. Please review and comment. Thanks Guennadi Guennadi Liakhovetski (3): ASoC: (cosmetic) simplify dpcm_prune_paths() ASoC: add function parameters to enable forced path pruning ASoC: export DPCM runtime update functions include/sound/soc-dpcm.h | 30 +++++++++-- sound/soc/soc-compress.c | 2 +- sound/soc/soc-dapm.c | 8 +-- sound/soc/soc-pcm.c | 126 ++++++++++++++++++++++++++++++----------------- 4 files changed, 112 insertions(+), 54 deletions(-) -- 1.9.3

1 4

[Sound-open-firmware] Distribution of sof firmware and tplg files
by Daniel Baluta 07 Feb '20

07 Feb '20

Hi Liam, Pierre, Jaroslav, I know there were a lot of discussions about distribution of SOF firmware and tplg files and I would like to have a conclusion here and also validate that I understood it correctly. Simplified view: * sof firmware will go to https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git * tplg files will go to https://github.com/alsa-project/alsa-topology-conf/pull/1 Is that correct, right? I'm asking this in the context of integrating the binaries with Yocto where we have two options: * build everything from sources (1) * pull the binaries from repos mentioned above (2) Option (1) is a little bit trickier because of Xtensa toolchain license. So, the easiest option for us wuold be (2). Is there a versioning scheme for linux-firmware and alsa-topology? Daniel.

8 28

[Sound-open-firmware] Double exception when booting qemu with imx8
by Daniel Baluta 04 Feb '20

04 Feb '20

Hi Liam, We are working on integrating support for hifi4 DSP/imx8 with Qemu. I wonder if you had this problem when you did the work for Intel integration. It looks like we get an exception when qemu is trying to execute first line of code: 596f8000 <_ResetVector>: EXCCAUSE=0000000e (PIF address error during instruction fetch) We think that we are correctly setting memory zones: bridge-io: qemu-bridge-iram-mem fd 10 region 1 at 0x7fcbce733000 allocated 2048 bytes bridge-io: qemu-bridge-dram-mem fd 11 region 2 at 0x7fcbce72b000 allocated 32768 bytes bridge-io: qemu-bridge-sdram0-mem fd 12 region 3 at 0x7fcbbc6fc000 allocated 8388608 bytes Reading the memory from Qemu monitor or gdb connected to Qemu looks good. thanks, Daniel.

2 3

2023

2022

2021

2020

2019

2018

2017

2016

Sound-open-firmware February 2020