Sound-open-firmware June 2019

sound-open-firmware@alsa-project.org

5 participants
5 discussions

[Sound-open-firmware] Problems booting byt in qemu
by Dragos Tarcatu 03 Jul '19

03 Jul '19

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ș

4 9

[Sound-open-firmware] SOF dynamic module loading
by Daniel Baluta 28 Jun '19

28 Jun '19

Hi Liam / Pierre, I remember that at some point there was a branch in SOF with initial support for loading dynamic modules at runtime. Anyhow I don't remember the name, can you help? We have some decoding/encoding algorithms and we need to be able to dynamically load them and use them in a simple pipeline like this: -> Host0 -> Buffer0 \ Algorithm <-Host1 <- Buffer1 / Any pointers are welcomed. thanks, Daniel.

2 1

[Sound-open-firmware] Creating Pull Requests for specific issues
by Jankowski, Janusz 10 Jun '19

10 Jun '19

Hello, When you create PR that is aimed to solve some specific issue, please include in PR description sentence like "Closes #IssueNumber". This way issue will be closed automatically when PR is merged and we will not have dangling issues that got solved but forgotten and maintainers are not sure if they can be closed. Also please take care and don't write something like "Partially resolves #SomeIssue", because GitHub will catch it and it will close this issue, when author intention probably was not to do it. I recommend you to take a look at this: https://help.github.com/en/articles/closing-issues-using-keywords Thanks, Janusz

1 0

[Sound-open-firmware] SOF v1.3 released
by Liam Girdwood 07 Jun '19

07 Jun '19

I'd like to announce that SOF v1.3 has now been released and is available for download here. https://github.com/thesofproject/sof/releases/tag/v1.3 The big ticket items in v1.3 are o Kconfig build support - Individual features/components can be added or removed. o HDMI, HDA support. o Improved PM support on Intel platforms. o NXP iMX8 - Initial DSP support added for iMX8. o GDB - Initial support for debugging firmware via GDB. Alongside bug fixes and improved stability. This firmware version will be the first version to upstream binaries to the Linux firmware repository. This includes signed binaries for some Intel platforms. Thanks Liam

1 0

[Sound-open-firmware] Commits in SOF (part 2)
by Daniel Baluta 07 Jun '19

07 Jun '19

Hello all, This is a follow up of email thread started [1]. My major request in the first email was for the commit message to explain WHY the change is needed. Things are looking good! Patches are easier to review and understand. This will also help newcomers trying to understand the code and contribute. Next request: Better split of the code into separate patches. Please create a patch for each logical change. Do not put small fixes (e.g whitespaces, tabs, code removal) together with a bigger patch. Just create a separate patch. Make sure each individual patch compiles so that we don't break bisection! Thanks, Daniel. [1] https://mailman.alsa-project.org/pipermail/sound-open-firmware/2019-May/003…

1 0

2023

2022

2021

2020

2019

2018

2017

2016

Sound-open-firmware June 2019