linux-kernel - Re: [PATCH V3 0/6] remoteproc: imx

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]

Message-ID: <73d34c86-7c31-6530-0915-aa470af5d9ca@nxp.com>
Date:   Mon, 13 Feb 2023 12:15:59 +0200
From:   Iuliana Prodan <iuliana.prodan@....com>
To:     Peng Fan <peng.fan@....com>,
        "Peng Fan (OSS)" <peng.fan@....nxp.com>,
        "andersson@...nel.org" <andersson@...nel.org>,
        "mathieu.poirier@...aro.org" <mathieu.poirier@...aro.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "arnaud.pouliquen@...s.st.com" <arnaud.pouliquen@...s.st.com>,
        Daniel Baluta <daniel.baluta@....com>
Cc:     "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        dl-linux-imx <linux-imx@....com>,
        "linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3 0/6] remoteproc: imx_rproc: support firmware in DDR

On 2/12/2023 9:43 AM, Peng Fan wrote:
> Hi Iuliana,
>
>> Subject: Re: [PATCH V3 0/6] remoteproc: imx_rproc: support firmware in
>> DDR
>>
>>
>> On 2/9/2023 8:38 AM, Peng Fan (OSS) wrote:
>>> From: Peng Fan <peng.fan@....com>
>>>
>>> V3:
>>>
>>>    Daniel, Iuliana
>>>
>>>      Please help review this patchset per Mathieu's comments.
>>>
>>>    Thanks,
>>>    Peng.
>>>
>>>    Move patch 3 in v2 to 1st patch in v3 and add Fixes tag Per Daniel
>>>    IMX_RPROC_ANY in patch 3 Per Mathieu
>>>    Update comment and commit log in patch 5, 6.
>>>
>>>    NXP SDK provides ".interrupts" section, but I am not sure how others
>>>    build the firmware. So I still keep patch 6 as v2, return bootaddr
>>>    if there is no ".interrupts" section.
>>>
>>> V2:
>>>    patch 4 is introduced for sparse check warning fix
>>>
>>> This pachset is to support i.MX8M and i.MX93 Cortex-M core firmware
>>> could be in DDR, not just the default TCM.
>>>
>>> i.MX8M needs stack/pc value be stored in TCML entry address[0,4], the
>>> initial value could be got from firmware first section ".interrupts".
>>> i.MX93 is a bit different, it just needs the address of .interrupts
>>> section. NXP SDK always has .interrupts section.
>>>
>>> So first we need find the .interrupts section from firmware, so patch
>>> 1 is to reuse the code of find_table to introduce a new API
>>> rproc_elf_find_shdr to find shdr, the it could reused by i.MX driver.
>>>
>>> Patch 2 is introduce devtype for i.MX8M/93
>>>
>>> Although patch 3 is correct the mapping, but this area was never used
>>> by NXP SW team, we directly use the DDR region, not the alias region.
>>> Since this patchset is first to support firmware in DDR, mark this
>>> patch as a fix does not make much sense.
>>>
>>> patch 4 and 5 is support i.MX8M/93 firmware in DDR with parsing
>>> .interrupts section. Detailed information in each patch commit message.
>>>
>>> Patches were tested on i.MX8MQ-EVK i.MX8MP-EVK i.MX93-11x11-EVK
>> If one can build their firmware as they want, then the .interrupt section can
>> also be called differently.
>> I don't think is a good idea to base all your implementation on this
>> assumption.
>>
>> It's clear there's a limitation when linking firmware in DDR, so this should be
>> well documented so one can compile their firmware and put the needed
>> section (interrupt as we call it in NXP SDK) always in TCML - independently
>> where the other section go.
> Ok, so .interrupt section should be a must in elf file if I understand correctly.
>
> I could add a check in V4 that if .interrupt section is not there, driver will report
> failure.
>
> How do you think?

Peng, I stand by my opinion that the limitation of linking firmware in 
DDR should be documented in an Application Note, or maybe there are 
other documents where how to use imx_rproc is explained.

The implementation based on the .interrupt section is not robust.
Maybe a user linked his firmware correctly in TCML, but the section is 
not called .interrupt so the firmware loading will work.

So, instead of using the section name, you should use the address.

First, check whether there is a section linked to TCML.
If there is none, check for section name - as you did.
If there is no section called .interrupt, give an error message.

For all the above options please add comments in code, explaining each step.