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: <DU0PR04MB9417A9B81B86FAC0A477063D88DC9@DU0PR04MB9417.eurprd04.prod.outlook.com>
Date:   Sun, 12 Feb 2023 07:43:05 +0000
From:   Peng Fan <peng.fan@....com>
To:     Iuliana Prodan <iuliana.prodan@....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

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?

Thanks,
Peng.
> 
> Regards,
> 
> Iulia
>