On Tue, Mar 3, 2020 at 12:27 PM Jaroslav Kysela <jkysela(a)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(a)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.
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