> >> Thank you for starting a discussion about this, we really need > >> to get this sorted out soon-ish as a lot of users are reporting > >> broken audio with 5.5.x because of the missing SOF firmware. > >> > >> On 3/2/20 11:10 AM, Jaroslav Kysela wrote: > >>> Hi all, > >>> > >>> I would like you to introduce the situation with the Intel's Sound > >>> Open Firmware. We have finally a stable version of the driver in the > >>> Fedora kernel (5.5.7), so it's time to discuss this. > >>> > >>> The issue is that Intel need to deal with three type of files. The > >>> first file is the firmware (binary instruction blob which is executed in > >>> DSP, suffix .ri). The second file is the topology and configuration for > >>> the ALSA's ASoC core / SOF driver (suffix .tplg). Those both files are > >>> loaded via the firmware load calls from the kernel. The names for those > >>> files are determined using the hardware probe. The .ri files are platform > >>> (Broadwell etc.) dependent. The topology files might differ more (HDMI > >>> configuration, codec configuration etc.). > >>> > >>> The third file is not loaded via the firmware call, it contains the > >>> debug strings (SOF firmware is stripped, thus only pointers are returned > >>> through the trace interface and there's utility sof-logger which converts > >>> those pointers back to the strings using those .ldc files). It's just for > >>> the debugging purposes and for the normal operation, it is not used at > >>> all. > >>> > >>> The last piece is the signing. Intel has a secure mechanism which is > >>> activated in DSP, so DSP doesn't accept the unsigned firmware, if the > >>> hardware vendor wants (and they usually wants this security). So, > >>> although, the SOF firmware is being developed as open source, we cannot > >>> do own modifications, because we don't have the signing keys. Of course, > >>> there is open hardware where the public keys are used (like UP^2 or some > >>> Chromebooks). But Lenovo, Dell and others requires firmware signed by > >>> Intel. > >>> > >>> Personally, I'm trying to convince Intel's people to release the > >>> stable signed firmware files to linux-firmware, but so far, I have not > >>> been successful so far. My opinion is that the tested and verified binary > >>> topology files should belong to the linux-firmware, too. Intel do not > >>> agree on this (distributions should compile the topology binaries from > >>> the sources). Unfortunately, the topology sources are not distributed > >>> separately from the SOF firmware, so we need to deal with the whole SOF > >>> tree. > >>> > >>> For Fedora, I'm packaging the SOF firmware, topology and debug (.ldc) > >>> bundle (https://www.alsa-project.org/files/pub/misc/sof/) via the > >>> alsa-firmware package for now (this package is not installed by default > >>> which causes another bug iteration 'install this package' for users). > >>> Note that this is not in the upstream alsa-firmware tar ball. It's an > >>> extra thing. > >>> > >>> The last activity from the Intel is the sof-bin repository: > >>> https://github.com/thesofproject/sof-bin/tree/stable-v1.4.2 . It's > >>> probably a good step forward to have this reference, but it's outside the > >>> linux-firmware repository. I don't know if they want to mirror this to > >>> linux-firmware. > >>> > >>> The objective: Fedora/RHEL users should have sound available after > >>> the initial installation, thus we need to find the way to add those files > >>> to linux-firmware or install alsa-firmware package by default. Maybe, the > >>> best way will be to create another alsa-sof-bin package for the Intel's > >>> sof-bin releases and install it by default like iwl*-firmware files for > >>> their WiFi chips. > >> > >> Since the SOF firmware files have a separate upstream I think > >> that creating a separate alsa-sof-bin (*) package is probably > >> the best approach, at least for now since upstream does not > >> seem to be moving to adding the signed DSP firmware files to > >> linux-firmware anytime soon. > >> > >> As for where the topology files go, inside alsa-sof-firmware or > >> inside alsa-ucm, both need to be installed for things to work > >> anyways, so I will leave that up to you. > > > > The topology files are bundled in sof-bin, too. Intel does some CI tests > > with them, so I'd prefer to keep them with the DSP firmware files. > > > >> If you can create such a package I would be happy to do the package > >> review ASAP and then we can add a Requires for this to the kernel-core > >> pkgs so that users will get it automatically when they install the > >> next kernel update.
It should not be kernel-core, the sounds drivers are packaged in kernel-modules, not -core, and it should probably be a soft requires so it gets there by default but isn't enforces, and should also be just for x86. > > The review request: https://bugzilla.redhat.com/show_bug.cgi?id=1809303 > > Ok, I've just reviewed it, a few minor remarks but I've approved it > regardless so you can move forward with this. > > > If accepted, I should probably add 'Conflicts: alsa-firmware <= 1.2.1-5' > > line and release alsa-firmware 1.2.1-6 without the SOF firmware files. > > Right, that is a good point and then put both in a combined update in > bodhi and once that combined update has hit updates-testing, add a > Requires for alsa-sof-firmware to the kernel-core package. > > Regards, > > Hans > _______________________________________________ > kernel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] _______________________________________________ kernel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
