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.
I would like to hear your comments or proposals.
Upstream discussions:
https://mailman.alsa-project.org/pipermail/sound-open-firmware/2020-January/... https://github.com/thesofproject/sof/issues/2200 https://github.com/thesofproject/sof-bin/pull/2 [Discussion]
Thank you, Jaroslav
Hi Jaroslav,
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.
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.
Regards,
Hans
p.s.
I guess if we go the also-sof-firmware pkg route we should coordinate the bodhi bits with the kernel-update which add the Requires, putting both the new pkg and that kernel update in a single bodhi update.
*) I'm not sure I like alsa-sof-bin, I know there is more then just firmware in there, but from a user's pov I think firmware is much clearer then bin, bin makes me think tools / ELF binaries. So I would prefer alsa-sof-firmware (just my 2 cents).
Dne 02. 03. 20 v 12:02 Hans de Goede napsal(a):
Hi Jaroslav,
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.
The review request: https://bugzilla.redhat.com/show_bug.cgi?id=1809303
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.
Regards,
Hans
p.s.
I guess if we go the also-sof-firmware pkg route we should coordinate the bodhi bits with the kernel-update which add the Requires, putting both the new pkg and that kernel update in a single bodhi update.
*) I'm not sure I like alsa-sof-bin, I know there is more then just firmware in there, but from a user's pov I think firmware is much clearer then bin, bin makes me think tools / ELF binaries. So I would prefer alsa-sof-firmware (just my 2 cents).
Yes, I also don't like sof-bin name so much. The alsa-sof-firmware looks much better.
Jaroslav
Hi,
On 3/3/20 9:11 AM, Jaroslav Kysela wrote:
Dne 02. 03. 20 v 12:02 Hans de Goede napsal(a):
Hi Jaroslav,
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.
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
On Tue, 3 Mar 2020 11:27:57 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 3/3/20 9:11 AM, Jaroslav Kysela wrote:
Dne 02. 03. 20 v 12:02 Hans de Goede napsal(a):
Hi Jaroslav,
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.
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.
could be this Requires more fine-graded? I guess the firmware is useful on Intel systems only (mainly?).
Dan
Hi,
On 3/3/20 11:48 AM, Dan HorĂ¡k wrote:
On Tue, 3 Mar 2020 11:27:57 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 3/3/20 9:11 AM, Jaroslav Kysela wrote:
Dne 02. 03. 20 v 12:02 Hans de Goede napsal(a):
Hi Jaroslav,
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.
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.
could be this Requires more fine-graded? I guess the firmware is useful on Intel systems only (mainly?).
Yes you are right, it should probably be something like the following:
%ifarch x86_64 Requires: alsa-sof-firmware %endif
(untested)
Regards,
Hans
Dne 03. 03. 20 v 12:44 Hans de Goede napsal(a):
Hi,
On 3/3/20 11:48 AM, Dan HorĂ¡k wrote:
On Tue, 3 Mar 2020 11:27:57 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 3/3/20 9:11 AM, Jaroslav Kysela wrote:
Dne 02. 03. 20 v 12:02 Hans de Goede napsal(a):
Hi Jaroslav,
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.
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.
could be this Requires more fine-graded? I guess the firmware is useful on Intel systems only (mainly?).
Yes you are right, it should probably be something like the following:
%ifarch x86_64 Requires: alsa-sof-firmware %endif
(untested)
Does anyone know, how the iwl*-firmware files are installed? I cannot find any dependency in kernel nor linux-firmware rpms. It's similar.
Also, SOF may be used on other architectures like i.MX ARM platforms. I can create packages with the different firmware files for specific architectures instead one noarch package.
Jaroslav
Regards,
Hans
On Tue, Mar 3, 2020 at 12:27 PM Jaroslav Kysela jkysela@redhat.com wrote:
Dne 03. 03. 20 v 12:44 Hans de Goede napsal(a):
Hi,
On 3/3/20 11:48 AM, Dan HorĂ¡k wrote:
On Tue, 3 Mar 2020 11:27:57 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 3/3/20 9:11 AM, Jaroslav Kysela wrote:
Dne 02. 03. 20 v 12:02 Hans de Goede napsal(a):
Hi Jaroslav,
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.
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.
could be this Requires more fine-graded? I guess the firmware is useful on Intel systems only (mainly?).
Yes you are right, it should probably be something like the following:
%ifarch x86_64 Requires: alsa-sof-firmware %endif
(untested)
Does anyone know, how the iwl*-firmware files are installed? I cannot find any dependency in kernel nor linux-firmware rpms. It's similar.
It's done via comps.
Also, SOF may be used on other architectures like i.MX ARM platforms. I can create packages with the different firmware files for specific architectures instead one noarch package.
I would split them up, I would probably still leave them as no-arch.
I was going to ask for the arm NXP firmwares but I hadn't got as far as investigating which SoCs they would be needed for.
Peter
Hi,
On 3/3/20 1:43 PM, Peter Robinson wrote:
On Tue, Mar 3, 2020 at 12:27 PM Jaroslav Kysela jkysela@redhat.com wrote:
Dne 03. 03. 20 v 12:44 Hans de Goede napsal(a):
Hi,
On 3/3/20 11:48 AM, Dan HorĂ¡k wrote:
On Tue, 3 Mar 2020 11:27:57 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 3/3/20 9:11 AM, Jaroslav Kysela wrote:
Dne 02. 03. 20 v 12:02 Hans de Goede napsal(a): > Hi Jaroslav, > > 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.
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.
could be this Requires more fine-graded? I guess the firmware is useful on Intel systems only (mainly?).
Yes you are right, it should probably be something like the following:
%ifarch x86_64 Requires: alsa-sof-firmware %endif
(untested)
Does anyone know, how the iwl*-firmware files are installed? I cannot find any dependency in kernel nor linux-firmware rpms. It's similar.
It's done via comps.
Hmm that does not really help here as the mean case we are trying to fix is F31 users upgrading from kernel 5.4 to 5.5.
Also, SOF may be used on other architectures like i.MX ARM platforms. I can create packages with the different firmware files for specific architectures instead one noarch package.
I would split them up, I would probably still leave them as no-arch.
I was going to ask for the arm NXP firmwares but I hadn't got as far as investigating which SoCs they would be needed for.
ATM the package is tiny, linux-firmware OTOH is not so tiny. Since we are happily installing linux-firmware everywhere I do not think that splitting this up is worthwhile.
If we want to spend effort on splitting out firmware files in generic (used on multiple archs) and per arch firmware files then that effort is probably best spend on the linux-firmware packgae itself for starters.
Regards,
Hans
Yes you are right, it should probably be something like the following:
%ifarch x86_64 Requires: alsa-sof-firmware %endif
(untested)
Does anyone know, how the iwl*-firmware files are installed? I cannot find any dependency in kernel nor linux-firmware rpms. It's similar.
It's done via comps.
Hmm that does not really help here as the mean case we are trying to fix is F31 users upgrading from kernel 5.4 to 5.5.
Also, SOF may be used on other architectures like i.MX ARM platforms. I can create packages with the different firmware files for specific architectures instead one noarch package.
I would split them up, I would probably still leave them as no-arch.
I was going to ask for the arm NXP firmwares but I hadn't got as far as investigating which SoCs they would be needed for.
ATM the package is tiny, linux-firmware OTOH is not so tiny. Since we are
I'd not looked at the actual size, if it's small that's fine. Also if it's just added to comps, like the various wireless firmware, it's easy enough to exclude for usecases like cloud that won't need it.
happily installing linux-firmware everywhere I do not think that splitting this up is worthwhile.
Well that's a completely different can of worms.... a lot don't install it happily ;-)
If we want to spend effort on splitting out firmware files in generic (used on multiple archs) and per arch firmware files then that effort is probably best spend on the linux-firmware packgae itself for starters.
If it's small leave it as one, it's easy enough to evolve later.
Hi,
On 3/3/20 3:29 PM, Peter Robinson wrote:
Yes you are right, it should probably be something like the following:
%ifarch x86_64 Requires: alsa-sof-firmware %endif
(untested)
Does anyone know, how the iwl*-firmware files are installed? I cannot find any dependency in kernel nor linux-firmware rpms. It's similar.
It's done via comps.
Hmm that does not really help here as the mean case we are trying to fix is F31 users upgrading from kernel 5.4 to 5.5.
So thinking more about this, I guess we should only add the explicit requires to the kernel package for F31 (and F30) and add it to comps for F32+, this way F30 / F31 users will get the package through the requires (and keep it on upgrade to F32+) and fresh F32 installs will also get it this way.
And this way we do not have to live forever with a Requires which will cause issues for efforts to make minimal installs as small as possible.
Regards,
Hans
On Tue, 2020-03-03 at 16:09 +0100, Hans de Goede wrote:
Hi,
On 3/3/20 3:29 PM, Peter Robinson wrote:
Yes you are right, it should probably be something like the following:
%ifarch x86_64 Requires: alsa-sof-firmware %endif
(untested)
Does anyone know, how the iwl*-firmware files are installed? I cannot find any dependency in kernel nor linux-firmware rpms. It's similar.
It's done via comps.
Hmm that does not really help here as the mean case we are trying to fix is F31 users upgrading from kernel 5.4 to 5.5.
So thinking more about this, I guess we should only add the explicit requires to the kernel package for F31 (and F30) and add it to comps for F32+, this way F30 / F31 users will get the package through the requires (and keep it on upgrade to F32+) and fresh F32 installs will also get it this way.
And this way we do not have to live forever with a Requires which will cause issues for efforts to make minimal installs as small as possible.
I think if we use Recommends dnf will install it by default, but it's not a dependency error if it's not installed[0].
[0] https://rpm.org/user_doc/dependencies.html
- Jeremy
Hi,
On 3/3/20 4:23 PM, Jeremy Cline wrote:
On Tue, 2020-03-03 at 16:09 +0100, Hans de Goede wrote:
Hi,
On 3/3/20 3:29 PM, Peter Robinson wrote:
> Yes you are right, it should probably be something like the > following: > > %ifarch x86_64 > Requires: alsa-sof-firmware > %endif > > (untested)
Does anyone know, how the iwl*-firmware files are installed? I cannot find any dependency in kernel nor linux-firmware rpms. It's similar.
It's done via comps.
Hmm that does not really help here as the mean case we are trying to fix is F31 users upgrading from kernel 5.4 to 5.5.
So thinking more about this, I guess we should only add the explicit requires to the kernel package for F31 (and F30) and add it to comps for F32+, this way F30 / F31 users will get the package through the requires (and keep it on upgrade to F32+) and fresh F32 installs will also get it this way.
And this way we do not have to live forever with a Requires which will cause issues for efforts to make minimal installs as small as possible.
I think if we use Recommends dnf will install it by default, but it's not a dependency error if it's not installed[0].
Right, that will work too and indeed is a better idea, at least for F30 + F31.
The question is what do we want to do for F32+ ?
1. Add alsa-sof-firmware to comps, similar to how iwlwifi is handled 2. Use the same Recommends as we are doing for F30 + F31 ?
I would personally prefer 2, but then we should probably consider doing the same for iwlwifi for consistency.
Regards,
Hans
On Tue, Mar 3, 2020 at 4:17 PM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 3/3/20 4:23 PM, Jeremy Cline wrote:
On Tue, 2020-03-03 at 16:09 +0100, Hans de Goede wrote:
Hi,
On 3/3/20 3:29 PM, Peter Robinson wrote:
>> Yes you are right, it should probably be something like the >> following: >> >> %ifarch x86_64 >> Requires: alsa-sof-firmware >> %endif >> >> (untested) > > Does anyone know, how the iwl*-firmware files are installed? > I cannot find any > dependency in kernel nor linux-firmware rpms. It's similar.
It's done via comps.
Hmm that does not really help here as the mean case we are trying to fix is F31 users upgrading from kernel 5.4 to 5.5.
So thinking more about this, I guess we should only add the explicit requires to the kernel package for F31 (and F30) and add it to comps for F32+, this way F30 / F31 users will get the package through the requires (and keep it on upgrade to F32+) and fresh F32 installs will also get it this way.
And this way we do not have to live forever with a Requires which will cause issues for efforts to make minimal installs as small as possible.
I think if we use Recommends dnf will install it by default, but it's not a dependency error if it's not installed[0].
Right, that will work too and indeed is a better idea, at least for F30 + F31.
The question is what do we want to do for F32+ ?
- Add alsa-sof-firmware to comps, similar to how iwlwifi is handled
I vote for this one as it's consistent.
- Use the same Recommends as we are doing for F30 + F31 ?
I would personally prefer 2, but then we should probably consider doing the same for iwlwifi for consistency.
Regards,
Hans
Dne 03. 03. 20 v 18:45 Peter Robinson napsal(a):
On Tue, Mar 3, 2020 at 4:17 PM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 3/3/20 4:23 PM, Jeremy Cline wrote:
On Tue, 2020-03-03 at 16:09 +0100, Hans de Goede wrote:
Hi,
On 3/3/20 3:29 PM, Peter Robinson wrote:
>>> Yes you are right, it should probably be something like the >>> following: >>> >>> %ifarch x86_64 >>> Requires: alsa-sof-firmware >>> %endif >>> >>> (untested) >> >> Does anyone know, how the iwl*-firmware files are installed? >> I cannot find any >> dependency in kernel nor linux-firmware rpms. It's similar. > > It's done via comps.
Hmm that does not really help here as the mean case we are trying to fix is F31 users upgrading from kernel 5.4 to 5.5.
So thinking more about this, I guess we should only add the explicit requires to the kernel package for F31 (and F30) and add it to comps for F32+, this way F30 / F31 users will get the package through the requires (and keep it on upgrade to F32+) and fresh F32 installs will also get it this way.
And this way we do not have to live forever with a Requires which will cause issues for efforts to make minimal installs as small as possible.
I think if we use Recommends dnf will install it by default, but it's not a dependency error if it's not installed[0].
Right, that will work too and indeed is a better idea, at least for F30 + F31.
The question is what do we want to do for F32+ ?
- Add alsa-sof-firmware to comps, similar to how iwlwifi is handled
I vote for this one as it's consistent.
- Use the same Recommends as we are doing for F30 + F31 ?
I would personally prefer 2, but then we should probably consider doing the same for iwlwifi for consistency.
Thank you for the feedback. Actually, I proposed to add alsa-sof-firmware to fedora-comps for F32/rawhide:
https://pagure.io/fedora-comps/pull-request/465
I built also packages for F31 (tested on Lenovo Carbon X1 7th):
alsa-firmware-1.2.1-7.fc31 alsa-sof-firmware-1.4.2-3.fc31
As Hans noted, the weak/hard dependency change should be added to kernel in sync with the update of those two packages. May I kindly ask someone to do it for the next kernel update? Thank you.
The most (all?) of our testers are using F31, so I'd skip the F30 for now.
Jaroslav
Hello Jaroslav,
On Tue, Mar 10, 2020 at 10:00 AM Jaroslav Kysela jkysela@redhat.com wrote:
[snip]
So thinking more about this, I guess we should only add the explicit requires to the kernel package for F31 (and F30) and add it to comps for F32+, this way F30 / F31 users will get the package through the requires (and keep it on upgrade to F32+) and fresh F32 installs will also get it this way.
I think we also need the requires in the kernel package for F32, since users could update their systems to F32 before it is released.
Best regards, Javier
On Fri, Mar 13, 2020 at 5:03 PM Javier Martinez Canillas javier@dowhile0.org wrote:
Hello Jaroslav,
On Tue, Mar 10, 2020 at 10:00 AM Jaroslav Kysela jkysela@redhat.com wrote:
[snip]
So thinking more about this, I guess we should only add the explicit requires to the kernel package for F31 (and F30) and add it to comps for F32+, this way F30 / F31 users will get the package through the requires (and keep it on upgrade to F32+) and fresh F32 installs will also get it this way.
I think we also need the requires in the kernel package for F32, since users could update their systems to F32 before it is released.
If they update using the recommended supported methods (upgrade and dnf distro-sync) it will pull in new additions to the installed comps groups so that should work fine with upgrades.
Hello Peter,
On Fri, Mar 13, 2020 at 7:37 PM Peter Robinson pbrobinson@gmail.com wrote:
[snip]
If they update using the recommended supported methods (upgrade and dnf distro-sync) it will pull in new additions to the installed comps groups so that should work fine with upgrades.
Yes, I meant if someone already did the upgrade to F32 or does it before Jaroslav's pull-request is merged.
Best regards, Javier
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 -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@lists.fedoraproject.org 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/kernel@lists.fedoraproject.org
kernel@lists.fedoraproject.org