[FEATURE] kernel should print URL for FW binaries when FW is not found.

@marc-hb

If you absolutely can't put the required packages in linux-firmware right
now, please have the error message give the proper URL for the firmware
package when it can't load the firmware. It took me at least half an hour
to figure out where to get it, as detailed in the opening message.

On Thu, Dec 3, 2020 at 2:45 AM Jaroslav Kysela notifications@github.com
wrote:

@marc-hb https://github.com/marc-hb can we look at linux-firmware again
for FW binary and topologies (not LDC files). @perexg
https://github.com/perexg would this work for you, IIUC you had some
issues with the LDC files being present in linux-firmware but I can't
recall now if you had a similar issue with the topology binaries ?

We package the SOF firmware in the separate package alsa-sof-firmware at
the time using sof-bin. The linux-firmware is going to be so big anyway,
but it's probably out-of-scope to resolve this issue here.

It may make sense to mirror the latest necessary files to linux-firmware,
but our linux-firmware package will not use those files (keeping them in
the alsa-sof-firmware). Also, think about driver / topology / DSP code
compatibility issues. The linux-firmware is supposed to work with wide
range of kernel versions and the SOF is (or was?) under the heavy
development.

Past discussion:
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-May/149961.html
[last paragraph]

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
thesofproject/sof-bin#22 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAINM343WXDJ7WHVIJNIHSLSS5T5HANCNFSM4TH6EJHQ
.

--
Bruce Perens - CEO at stealth startup. I'll tell you what it is eventually
:-)

Originally posted by @BrucePerens in thesofproject/sof-bin#22 (comment)

@plbossart

@plbossart @kv2019i for some reason I could not assigned this as a kernel issue.

Even before considering a URL, I had a painful on-boarding experience trying to understand the drivers' logic for deciding which /lib/firmware/*/*.tplg filename(s) they are looking for. For that reason I've been carrying some local dev_dbg() hack in drivers/base/firmware_loader/main.c since forever.

So I'm not sure the solution should be audio-specific, should it? Or at least not entirely audio specific. It has been a long time since the Linux kernel has become a DSoC[*] bootloader, maybe it's time for the kernel to accept that fact and for drivers/base/firmware_loader/ to get more verbose logging matching the importance of that feature.

[*] Distributed System on Chip

@marc-hb

@marc-hb the logic is simple:

a) for each machine there's a descriptor of which topology is needed - the descriptor is identified based on codecs/DMI information:

https://github.com/thesofproject/linux/blob/25012df60c1ff8c43b989bfcb1e9690cfc7e8cf3/sound/soc/intel/common/soc-acpi-intel-tgl-match.c#L313

b) the driver loads a topology assuming an intel/sof-tplg prefix that can be overriden at will with a kernel parameter.
https://github.com/thesofproject/linux/blob/25012df60c1ff8c43b989bfcb1e9690cfc7e8cf3/sound/soc/sof/loader.c#L712
https://github.com/thesofproject/linux/blob/25012df60c1ff8c43b989bfcb1e9690cfc7e8cf3/sound/soc/sof/sof-pci-dev.c#L132
https://github.com/thesofproject/linux/blob/25012df60c1ff8c43b989bfcb1e9690cfc7e8cf3/sound/soc/sof/sof-pci-dev.c#L32

we've added logs to trace which firmware and topology are used. If it's not enough, file an issue and we'll make it better.

@lgirdwood

@lgirdwood I don't think there is a solution for this. The kernel has no idea where the firmware is supposed to come from, this depends on packaging. E.g. on Debian they have small packages for intel audio firmware, while others have larger packages with linux-firmware. This is completely distro-specific.

see e.g. https://packages.debian.org/sid/firmware-intel-sound

I think you're overthinking it again :-) You are not responsible for determining what distribution you are on and what their packages are. Just tell them the URL where they can find the firmware and topology files. If they want to file a bug with their distribution, that gives them all the information they need. If they want to get their system running by themselves, they have the information necessary to do that too. I want to stress how serious the situation is currently. Your driver breaks the sound system for essentially everybody who tries it. If a distribution installs it without careful testing or prior knowledge of the firmware, it breaks sound for all of their users and your driver will probably get blacklisted rather than fixed. There are already instructions online that recommend to users that your driver be blacklisted from runtime module loading. You're sort of on the way to it being widely known that people should not install your driver. Thanks Bruce

…

On Thu, Dec 3, 2020 at 3:40 PM Pierre-Louis Bossart < ***@***.***> wrote: see e.g. https://packages.debian.org/stretch/firmware-intel-sound — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3665 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAINM3ZANHNAUHOHCOT2JL3STAOV3ANCNFSM4UMP4ATA> .

-- Bruce Perens - CEO at stealth startup. I'll tell you what it is eventually :-)

@BrucePerens

@BrucePerens I've seen such recommendations but they have the side effect of removing capture (microphone) support or possibly all audio (SoundWire). we've reached out to Debian and Arch folks and it went nowhere. I will add a section on firmware installation in our documentation [1], and we'll add a message in the kernel when it's clear what the URL is.

[1] https://thesofproject.github.io/latest/getting_started/index.html#debugging-audio-issues-on-intel-platforms

Thank you. Presumably the URL is under your control and this can be updated before your next push to the kernel team? Arch and Debian have an insufficient volunteer maintainer issue. I don't know to what extent this is their fault. I know that being accepted as a Debian package maintainer is so much harder than when I was Debian project leader that I would not attempt it today. I assume this is the case for all non-commercial distributions, so making things easier for them is the only way driver support will happen. Thanks Bruce

…

On Thu, Dec 3, 2020 at 4:09 PM Pierre-Louis Bossart < ***@***.***> wrote: @BrucePerens <https://github.com/BrucePerens> I've seen such recommendations but they have the side effect of removing capture (microphone) support or possibly all audio (SoundWire). we've reached out to Debian and Arch folks and it went nowhere. I will add a section on firmware installation in our documentation [1], and we'll add a message in the kernel when it's clear what the URL is. [1] https://thesofproject.github.io/latest/getting_started/index.html#debugging-audio-issues-on-intel-platforms — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3665 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAINM3YCMSI23L3TTO2QI6TSTASDFANCNFSM4UMP4ATA> .

-- Bruce Perens - CEO at stealth startup. I'll tell you what it is eventually :-)

@lgirdwood

Thank you. Presumably the URL is under your control and this can be updated before your next push to the kernel team?

I will rely on @lgirdwood and @marc-hb to let me know what the decision is for the URL.

the 'push to kernel team' is subject to a pipeline effect (ASoC then mainline), it's likely already too late for v5.11 so unless we manage to convince the -stable team to pick the patch for 5.4+ it'd appear in 5.12.

I think the URL should point to the sof-bin repo where the Readme.md can provide the necessary links and instructions that even novice users should be able to copy and paste if needed. The Readme would also contain the Release information and instructions/links for the previous version.

Navigation Menu

Repository navigation

[FEATURE] kernel should print URL for FW binaries when FW is not found. #3665

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE] kernel should print URL for FW binaries when FW is not found. #3665

Description

Activity

lgirdwood commented on Dec 3, 2020

marc-hb commented on Dec 3, 2020

plbossart commented on Dec 3, 2020

plbossart commented on Dec 3, 2020

plbossart commented on Dec 3, 2020

BrucePerens commented on Dec 3, 2020

plbossart commented on Dec 4, 2020

BrucePerens commented on Dec 4, 2020

plbossart commented on Dec 4, 2020

lgirdwood commented on Dec 4, 2020

lgirdwood commented on Dec 17, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions