Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Installation is a nightmare for the naive user #22

Closed
BrucePerens opened this issue Nov 2, 2020 · 17 comments
Closed

Installation is a nightmare for the naive user #22

BrucePerens opened this issue Nov 2, 2020 · 17 comments
Assignees
@marc-hb

Comments

@BrucePerens
Copy link

Hi,

I am currently running Debian stable with a bleeding-edge kernel. What does it take to get the SOF driver running?

  1. Look all over the net, and mostly get answers that you must turn off the digital microphone in the old HDA driver. Wrong.
  2. Look through dmesg and notice that a firmware file isn't loading. Look in /lib/firmware, it's not there.
  3. Install the latest firmware from the linux-firmware repository. Nope, not in there either.
  4. Find the SOF project.
  5. Look in the latest releases. Only source available.
  6. Find sof-bin. Download the master, because that's git's default.
  7. Run go.sh . Doesn't work with the master.
  8. Look for the name of the latest signed release. Can't find that.
  9. Checkout the arbitrary old release mentioned in an aside in the documentation.
  10. Run go.sh again. It works.

Why isn't this in the linux-firmware repository?

Thanks

Bruce
@plbossart
Copy link
Member

@BrucePerens using linux-firmware was the initial plan but there were disagreements on the 'debug tools (sof-logger and .ldc files), so we provided sof-bin as is and assumed distro maintainers would pick the firmware from there. that's the working model with Fedora and Ubuntu.
We've had email conversations with some Debian maintainers but no one picked up the task of doing the packaging.

That said you're right that we should do a better job advertising what the latest version is, and add more references on this in the documentation https://thesofproject.github.io/latest/getting_started/index.html#debugging-audio-issues-on-intel-platforms

@BrucePerens
Copy link
Author

For now, it would be nice if the internal disagreement could be resolved to the point that production firmware - not the debug tools - could be placed on the linux-firmware repository. People who build their own kernels can't really depend on distribution packagers to keep up with the kernel driver, but they have learned to update from the firmware repository.

@marc-hb
Copy link
Collaborator

marc-hb commented Dec 1, 2020

@plbossart does everyone need the sof-logger and .ldc files?

@plbossart
Copy link
Member

@marc-hb that'd be the first thing we ask if there is a complicated bug report where we need a trace... So not all users need this, but power users who report bugs need to have an 'apt install' way to getting these files.

@marc-hb
Copy link
Collaborator

marc-hb commented Dec 1, 2020

Totally understand the requirement for anapt install level of user friendliness but it sounds like we could release the firmware and .tplg files only to linux-firmware, no? Now this would assume a bulletproof way to match them to the corresponding logger files when needed and I guess we don't really have that yet.

@plbossart
Copy link
Member

plbossart commented Dec 1, 2020 •
edited

There was also the argument that topology files aren't binaries and as such not suitable for linux-firmware - they can be re-generated with alsa-lib (edit: and alsa-utils).

@marc-hb
Copy link
Collaborator

marc-hb commented Dec 2, 2020

Now that last bit about .tplg files sucks more, do you have a pointer, approx. date and/or some search keywords to that past argument?

hexdump -C shows many ASCII characters in .tplg files but for me they're binaries until someone demonstrates that cat can send them to some locale and terminal without wrecking the latter.

So linux-firmware would be only for binaries that can't be regenerated from open source? I don't see that in its README.

It would be error-prone to request all Linux distributions to match the version of the topology sources with the version of the firmware binary. It would also be a waste of effort to ask them to regenerate the (hopefully) exact same .tplg files independently...

cc: @lgirdwood

@BrucePerens
Copy link
Author

BrucePerens commented Dec 3, 2020 via email

@lgirdwood
Copy link
Member

@BrucePerens you are right, there was some pushback on including topology binaries and logger strings (the LDC files) alongside the firmware binaries in linux-firmware. The driver needs both the FW binary AND the topology binary to work. Only the logger needs the firmware string (LDC file).

@marc-hb topologies are binaries built from ASLA conf public sources, but you are right in that it's not easy for distro's to easily build the topologies (as may need ALSA lib/utils git versions from time to time) or easily build the firmware (may need proprietary compiler) and notwithstanding any code signing for platforms with private keys.

@marc-hb can we look at linux-firmware again for FW binary and topologies (not LDC files). @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 ?

I've also disabled force push rebasing in this repo.

@perexg
Copy link

perexg commented Dec 3, 2020

@marc-hb can we look at linux-firmware again for FW binary and topologies (not LDC files). @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]

@BrucePerens
Copy link
Author

BrucePerens commented Dec 3, 2020 via email

@lgirdwood lgirdwood mentioned this issue Dec 3, 2020
Closed
@plbossart
Copy link
Member

@marc-hb the notion of topology predates SOF, and there isn't a single topology file that was added to linux-firmware. I don't have a trace but a very good memory of a discussion with the Skylake driver owners a couple of years ago - but it doesn't hurt to ping the linux-firmware maintainers for confirmation.

I also want to mention that we have a ton of topology files, see [1], compared to a single firmware binary per hardware generation. I really don't see how we could possibly keep every version of topology file in linux-firmware, as currently done with the symbolic links.

[1] https://github.com/thesofproject/sof/blob/cc1cd8a4af1b4b6c87f9b9c1da055f96421dde28/tools/topology/CMakeLists.txt#L19

@marc-hb
Copy link
Collaborator

marc-hb commented Dec 17, 2020

Hi @BrucePerens

  • printing the URL when the firmware is missing has been queued, see above
  • We will submit firmware to linux-firmware and topologies if acceptable (afraid not)
  • I started work to simplify the go.sh and packaging experience.

Please let us know if I missed anything.

@marc-hb marc-hb self-assigned this Dec 17, 2020
@BrucePerens
Copy link
Author

BrucePerens commented Dec 17, 2020 via email

@mmokrejs

This comment has been minimized.

Sign in to view
@plbossart
Copy link
Member

@mmokrejs your question is unrelated to the firmware releases really, what people enable in their distributions is their choice entirely. We provide a list of configs that we used in our tests:
https://github.com/thesofproject/kconfig/blob/master/sof-defconfig
https://github.com/thesofproject/kconfig/blob/master/sof-dev-defconfig

and we provide guidelines here
https://thesofproject.github.io/latest/getting_started/setup/setup_ktest_environment.html#save-your-kernel-config-as-ktest-sof-dev-defconfig

@marc-hb
Copy link
Collaborator

marc-hb commented Sep 28, 2021

@BrucePerens no news is good news?

@marc-hb marc-hb closed this as completed Oct 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@marc-hb marc-hb

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@BrucePerens @plbossart @perexg @mmokrejs @lgirdwood @marc-hb