Skip to content

Installation is a nightmare for the naive user #22

Closed
Closed
Installation is a nightmare for the naive user#22
Assignees
marc-hb

Description

@BrucePerens
BrucePerens
opened on Nov 2, 2020

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

Activity

  1. plbossart commented on Nov 2, 2020

    @plbossart
    plbossart
    on Nov 2, 2020
    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

  2. BrucePerens commented on Nov 2, 2020

    @BrucePerens
    BrucePerens
    on Nov 2, 2020
    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.

  3. marc-hb commented on Dec 1, 2020

    @marc-hb
    marc-hb
    on Dec 1, 2020
    Collaborator

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

  4. plbossart commented on Dec 1, 2020

    @plbossart
    plbossart
    on Dec 1, 2020
    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.

  5. marc-hb commented on Dec 1, 2020

    @marc-hb
    marc-hb
    on Dec 1, 2020
    Collaborator

    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.

  6. plbossart commented on Dec 1, 2020

    @plbossart
    plbossart
    on Dec 1, 2020
    Member

    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).

  7. marc-hb commented on Dec 2, 2020

    @marc-hb
    marc-hb
    on Dec 2, 2020
    Collaborator

    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

  8. BrucePerens commented on Dec 3, 2020

    @BrucePerens
    BrucePerens
    on Dec 3, 2020 via email
    Author

  9. lgirdwood commented on Dec 3, 2020

    @lgirdwood
    lgirdwood
    on Dec 3, 2020
    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.

  10. perexg commented on Dec 3, 2020

    @perexg
    perexg
    on 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]

  11. BrucePerens commented on Dec 3, 2020

    @BrucePerens
    BrucePerens
    on Dec 3, 2020 via email
    Author

  12. plbossart commented on Dec 3, 2020

    @plbossart
    plbossart
    on Dec 3, 2020
    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

  13. marc-hb commented on Dec 17, 2020

    @marc-hb
    marc-hb
    on Dec 17, 2020
    Collaborator

    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.

  14. marc-hb
    self-assigned this
    on Dec 17, 2020

  15. BrucePerens commented on Dec 17, 2020

    @BrucePerens
    BrucePerens
    on Dec 17, 2020 via email
    Author

  16. mmokrejs commented on Apr 9, 2021

    @mmokrejs
    mmokrejs
    on Apr 9, 2021 · Hidden as resolved

  17. plbossart commented on Apr 9, 2021

    @plbossart
    plbossart
    on Apr 9, 2021
    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

  18. marc-hb commented on Sep 28, 2021

    @marc-hb
    marc-hb
    on Sep 28, 2021
    Collaborator

    @BrucePerens no news is good news?

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions