linux-kernel - Re: [PATCH 07/11] ASoC: SOF: core: Skip firmware test for undefined fw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 14 Dec 2023 18:58:28 +0530
From:   Venkata Prasad Potturu <venkataprasad.potturu@....com>
To:     Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
        Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Bard Liao <yung-chuan.liao@...ux.intel.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Daniel Baluta <daniel.baluta@....com>,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        Alper Nebi Yasak <alpernebiyasak@...il.com>,
        Syed Saba Kareem <Syed.SabaKareem@....com>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Marian Postevca <posteuca@...ex.one>,
        Vijendar Mukunda <Vijendar.Mukunda@....com>,
        V sujith kumar Reddy <Vsujithkumar.Reddy@....com>,
        Mastan Katragadda <Mastan.Katragadda@....com>,
        Ajit Kumar Pandey <AjitKumar.Pandey@....com>,
        "Hiregoudar, Basavaraj" <Basavaraj.Hiregoudar@....com>,
        "Dommati, Sunil-kumar" <Sunil-kumar.Dommati@....com>
Cc:     linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
        sound-open-firmware@...a-project.org, kernel@...labora.com
Subject: Re: [PATCH 07/11] ASoC: SOF: core: Skip firmware test for undefined
 fw_name


On 12/14/23 17:27, Péter Ujfalusi wrote:
>
> On 14/12/2023 12:58, Venkata Prasad Potturu wrote:
>> On 12/14/23 16:18, Péter Ujfalusi wrote:
>> Thanks for your time Peter!
>>> On 09/12/2023 22:53, Cristian Ciocaltea wrote:
>>>> Some SOF drivers like AMD ACP do not always rely on a single static
>>>> firmware file, but may require multiple files having their names
>>>> dynamically computed on probe time, e.g. based on chip name.
>>> I see, AMD vangogh needs two binary files to be loaded sometimes, it
>>> is not using the default name as it hints via the sof_dev_desc
>>> ("sof-vangogh.ri").
>>>
>>> The constructed names for the two files are just using different pattern:
>>> sof-%PLAT%.ri
>>> vs
>>> sof-%PLAT%-code.bin
>>> sof-%PLAT%-data.bin
>>>
>>> iow, instead of the combined .ri file which includes the code and data
>>> segment it has 'raw' bin files and cannot use the core for loading the
>>> firmware.
>>>
>>> What is the reason for this? an .ri file can have two 'modules' one to
>>> be written to IRAM the other to DRAM.
>>> sof_ipc3_load_fw_to_dsp()
>> For AMD Vangogh platform devices signed firmware image is required, so
>> split .ri image into code and data images.
>>
>> Only Code.bin will be signed and loaded into corresponding IRAM location.
> This is not different than what the Intel .ri files are made of. The
> module which is to be loaded to IRAM is signed code the module which
> goes to DRAM is not signed.
> The loader itself is not looking into the sections of the .ri image, it
> just parses the header and copies them where they belong.
>
> if the issue is name collision then you could try to put the signed
> firmware file under 'signed' folder (fw_path_postfix) of the platform
> like Intel does with the community signed ones?

We have a limitation that code image can't be signed during compilation.

So splitting the .ri image into code and data bin and sign the code bin
and load into IRAM.

>
> It would be great if somehow we can handle all of these in core, have
> shared code and familiar prints among vendors, platforms..
>
> Fwiw, I'm planning the path, filename creation to be moved to core for
> the current platforms, but it implies that they do use single firmware file.
> struct sof_dev_desc would only have two strings:
> vendor - AMD / iMX / Intel / Mediatek
> platform - tgl, vaggogh, etc
>
> I need to adjust it based on what I have learned today about vangogh.
>