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