All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shengjiu Wang <shengjiu.wang@gmail.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Shengjiu Wang <shengjiu.wang@nxp.com>,
	Ohad Ben Cohen <ohad@wizery.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Sascha Hauer <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	"open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM" 
	<linux-remoteproc@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/4] remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX
Date: Fri, 17 Sep 2021 13:20:03 +0800	[thread overview]
Message-ID: <CAA+D8AN_ni_XmEFNfY0Z0qLAJX00XFSUP1RkJdNQd-MVY6pd4g@mail.gmail.com> (raw)
In-Reply-To: <20210916165957.GA1825273@p14s>

On Fri, Sep 17, 2021 at 1:00 AM Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> [...]
>
> > > > +
> > > > +/**
> > > > + * imx_dsp_rproc_elf_load_segments() - load firmware segments to memory
> > > > + * @rproc: remote processor which will be booted using these fw segments
> > > > + * @fw: the ELF firmware image
> > > > + *
> > > > + * This function specially checks if memsz is zero or not, otherwise it
> > > > + * is mostly same as rproc_elf_load_segments().
> > > > + */
> > > > +static int imx_dsp_rproc_elf_load_segments(struct rproc *rproc,
> > > > +                                        const struct firmware *fw)
> > > > +{
> > > > +     struct device *dev = &rproc->dev;
> > > > +     u8 class = fw_elf_get_class(fw);
> > > > +     u32 elf_phdr_get_size = elf_size_of_phdr(class);
> > > > +     const u8 *elf_data = fw->data;
> > > > +     const void *ehdr, *phdr;
> > > > +     int i, ret = 0;
> > > > +     u16 phnum;
> > > > +
> > > > +     ehdr = elf_data;
> > > > +     phnum = elf_hdr_get_e_phnum(class, ehdr);
> > > > +     phdr = elf_data + elf_hdr_get_e_phoff(class, ehdr);
> > > > +
> > > > +     /* go through the available ELF segments */
> > > > +     for (i = 0; i < phnum; i++, phdr += elf_phdr_get_size) {
> > > > +             u64 da = elf_phdr_get_p_paddr(class, phdr);
> > > > +             u64 memsz = elf_phdr_get_p_memsz(class, phdr);
> > > > +             u64 filesz = elf_phdr_get_p_filesz(class, phdr);
> > > > +             u64 offset = elf_phdr_get_p_offset(class, phdr);
> > > > +             u32 type = elf_phdr_get_p_type(class, phdr);
> > > > +             void *ptr;
> > > > +             bool is_iomem;
> > > > +
> > > > +             if (type != PT_LOAD || !memsz)
> > >
> > > You did a really good job with adding comments but this part is undocumented...
> > > If I read this correctly you need to check for !memsz because some part of
> > > the program segment may have a header but its memsz is zero, in which case it can
> > > be safely skipped.  So why is that segment in the image to start with, and why
> > > is it marked PT_LOAD if it is not needed?  This is very puzzling...
> >
> > Actually I have added comments in the header of this function.
>
> Indeed there is a mention of memsz in the function's header but it doesn't
> mention _why_ this is needed, and that is what I'm looking for.
>
> >
> > memsz= 0 with PT_LOAD issue, I have asked the toolchain's vendor,
> > they said that this case is allowed by elf spec...
> >
> > And in the "pru_rproc.c" and "mtk_scp.c", seems they met same problem
> > they also check the filesz in their internal xxx_elf_load_segments() function.
>
> In both cases they are skipping PT_LOAD sections where "filesz" is '0', which
> makes sense because we don't know how many bytes to copy.  But here you are
> skipping over a PT_LOAD section with a potentially valid filesz, and that is the
> part I don't understand.

Ok, I can use filesz instead. For my case, filesz = memsz = 0,
it is the same result I want.

The reason why I use "memsz '' is because there is  "if (filesz > memsz) "
check after this,  if memsz is zero, then "filesz" should be zero too, other
values are not allowed.

>
> >
> > >
> > >
> > > > +                     continue;
> > > > +
> > > > +             dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
> > > > +                     type, da, memsz, filesz);
> > > > +
> > > > +             if (filesz > memsz) {
> > > > +                     dev_err(dev, "bad phdr filesz 0x%llx memsz 0x%llx\n",
> > > > +                             filesz, memsz);
> > > > +                     ret = -EINVAL;
> > > > +                     break;
> > > > +             }
> > > > +
> > > > +             if (offset + filesz > fw->size) {
> > > > +                     dev_err(dev, "truncated fw: need 0x%llx avail 0x%zx\n",
> > > > +                             offset + filesz, fw->size);
> > > > +                     ret = -EINVAL;
> > > > +                     break;
> > > > +             }
> > > > +
> > > > +             if (!rproc_u64_fit_in_size_t(memsz)) {
> > > > +                     dev_err(dev, "size (%llx) does not fit in size_t type\n",
> > > > +                             memsz);
> > > > +                     ret = -EOVERFLOW;
> > > > +                     break;
> > > > +             }
> > > > +
> > > > +             /* grab the kernel address for this device address */
> > > > +             ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
> > >
> > >                 rproc_da_to_va(rproc, da, memsz, NULL);
> >
> > yes, will update it.
> >
> > >
> > > More comments to follow later today or tomorrow.
> >
> > Thanks.
> >
> > Best regards
> > Wang Shengjiu

WARNING: multiple messages have this Message-ID (diff)
From: Shengjiu Wang <shengjiu.wang@gmail.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Shengjiu Wang <shengjiu.wang@nxp.com>,
	Ohad Ben Cohen <ohad@wizery.com>,
	 Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	 Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	 Sascha Hauer <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	 Daniel Baluta <daniel.baluta@nxp.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	 "open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM"
	<linux-remoteproc@vger.kernel.org>,
	 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	 "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/4] remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX
Date: Fri, 17 Sep 2021 13:20:03 +0800	[thread overview]
Message-ID: <CAA+D8AN_ni_XmEFNfY0Z0qLAJX00XFSUP1RkJdNQd-MVY6pd4g@mail.gmail.com> (raw)
In-Reply-To: <20210916165957.GA1825273@p14s>

On Fri, Sep 17, 2021 at 1:00 AM Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> [...]
>
> > > > +
> > > > +/**
> > > > + * imx_dsp_rproc_elf_load_segments() - load firmware segments to memory
> > > > + * @rproc: remote processor which will be booted using these fw segments
> > > > + * @fw: the ELF firmware image
> > > > + *
> > > > + * This function specially checks if memsz is zero or not, otherwise it
> > > > + * is mostly same as rproc_elf_load_segments().
> > > > + */
> > > > +static int imx_dsp_rproc_elf_load_segments(struct rproc *rproc,
> > > > +                                        const struct firmware *fw)
> > > > +{
> > > > +     struct device *dev = &rproc->dev;
> > > > +     u8 class = fw_elf_get_class(fw);
> > > > +     u32 elf_phdr_get_size = elf_size_of_phdr(class);
> > > > +     const u8 *elf_data = fw->data;
> > > > +     const void *ehdr, *phdr;
> > > > +     int i, ret = 0;
> > > > +     u16 phnum;
> > > > +
> > > > +     ehdr = elf_data;
> > > > +     phnum = elf_hdr_get_e_phnum(class, ehdr);
> > > > +     phdr = elf_data + elf_hdr_get_e_phoff(class, ehdr);
> > > > +
> > > > +     /* go through the available ELF segments */
> > > > +     for (i = 0; i < phnum; i++, phdr += elf_phdr_get_size) {
> > > > +             u64 da = elf_phdr_get_p_paddr(class, phdr);
> > > > +             u64 memsz = elf_phdr_get_p_memsz(class, phdr);
> > > > +             u64 filesz = elf_phdr_get_p_filesz(class, phdr);
> > > > +             u64 offset = elf_phdr_get_p_offset(class, phdr);
> > > > +             u32 type = elf_phdr_get_p_type(class, phdr);
> > > > +             void *ptr;
> > > > +             bool is_iomem;
> > > > +
> > > > +             if (type != PT_LOAD || !memsz)
> > >
> > > You did a really good job with adding comments but this part is undocumented...
> > > If I read this correctly you need to check for !memsz because some part of
> > > the program segment may have a header but its memsz is zero, in which case it can
> > > be safely skipped.  So why is that segment in the image to start with, and why
> > > is it marked PT_LOAD if it is not needed?  This is very puzzling...
> >
> > Actually I have added comments in the header of this function.
>
> Indeed there is a mention of memsz in the function's header but it doesn't
> mention _why_ this is needed, and that is what I'm looking for.
>
> >
> > memsz= 0 with PT_LOAD issue, I have asked the toolchain's vendor,
> > they said that this case is allowed by elf spec...
> >
> > And in the "pru_rproc.c" and "mtk_scp.c", seems they met same problem
> > they also check the filesz in their internal xxx_elf_load_segments() function.
>
> In both cases they are skipping PT_LOAD sections where "filesz" is '0', which
> makes sense because we don't know how many bytes to copy.  But here you are
> skipping over a PT_LOAD section with a potentially valid filesz, and that is the
> part I don't understand.

Ok, I can use filesz instead. For my case, filesz = memsz = 0,
it is the same result I want.

The reason why I use "memsz '' is because there is  "if (filesz > memsz) "
check after this,  if memsz is zero, then "filesz" should be zero too, other
values are not allowed.

>
> >
> > >
> > >
> > > > +                     continue;
> > > > +
> > > > +             dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
> > > > +                     type, da, memsz, filesz);
> > > > +
> > > > +             if (filesz > memsz) {
> > > > +                     dev_err(dev, "bad phdr filesz 0x%llx memsz 0x%llx\n",
> > > > +                             filesz, memsz);
> > > > +                     ret = -EINVAL;
> > > > +                     break;
> > > > +             }
> > > > +
> > > > +             if (offset + filesz > fw->size) {
> > > > +                     dev_err(dev, "truncated fw: need 0x%llx avail 0x%zx\n",
> > > > +                             offset + filesz, fw->size);
> > > > +                     ret = -EINVAL;
> > > > +                     break;
> > > > +             }
> > > > +
> > > > +             if (!rproc_u64_fit_in_size_t(memsz)) {
> > > > +                     dev_err(dev, "size (%llx) does not fit in size_t type\n",
> > > > +                             memsz);
> > > > +                     ret = -EOVERFLOW;
> > > > +                     break;
> > > > +             }
> > > > +
> > > > +             /* grab the kernel address for this device address */
> > > > +             ptr = rproc_da_to_va(rproc, da, memsz, &is_iomem);
> > >
> > >                 rproc_da_to_va(rproc, da, memsz, NULL);
> >
> > yes, will update it.
> >
> > >
> > > More comments to follow later today or tomorrow.
> >
> > Thanks.
> >
> > Best regards
> > Wang Shengjiu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-09-17  5:20 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08  9:10 [PATCH v4 0/4] Add remoteproc driver for DSP on i.MX Shengjiu Wang
2021-09-08  9:10 ` Shengjiu Wang
2021-09-08  9:10 ` [PATCH v4 1/4] remoteproc: imx_rproc: Move common structure to header file Shengjiu Wang
2021-09-08  9:10   ` Shengjiu Wang
2021-09-14 17:46   ` Mathieu Poirier
2021-09-14 17:46     ` Mathieu Poirier
2021-09-08  9:10 ` [PATCH v4 2/4] remoteproc: imx_rproc: Add IMX_RPROC_SCU_API method Shengjiu Wang
2021-09-08  9:10   ` Shengjiu Wang
2021-09-14 17:47   ` Mathieu Poirier
2021-09-14 17:47     ` Mathieu Poirier
2021-09-08  9:10 ` [PATCH v4 3/4] remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX Shengjiu Wang
2021-09-08  9:10   ` Shengjiu Wang
2021-09-14 17:56   ` Mathieu Poirier
2021-09-14 17:56     ` Mathieu Poirier
2021-09-15  3:09     ` Shengjiu Wang
2021-09-15  3:09       ` Shengjiu Wang
2021-09-15 16:16   ` Mathieu Poirier
2021-09-15 16:16     ` Mathieu Poirier
2021-09-16 10:44     ` Shengjiu Wang
2021-09-16 10:44       ` Shengjiu Wang
2021-09-16 16:59       ` Mathieu Poirier
2021-09-16 16:59         ` Mathieu Poirier
2021-09-17  5:20         ` Shengjiu Wang [this message]
2021-09-17  5:20           ` Shengjiu Wang
2021-09-17  9:44           ` Shengjiu Wang
2021-09-17  9:44             ` Shengjiu Wang
2021-09-17 15:22             ` Mathieu Poirier
2021-09-17 15:22               ` Mathieu Poirier
2021-09-22  1:35               ` Shengjiu Wang
2021-09-22  1:35                 ` Shengjiu Wang
2021-09-22 17:55                 ` Mathieu Poirier
2021-09-22 17:55                   ` Mathieu Poirier
2021-09-23  1:48                   ` Shengjiu Wang
2021-09-23  1:48                     ` Shengjiu Wang
2021-09-16 17:23   ` Mathieu Poirier
2021-09-16 17:23     ` Mathieu Poirier
2021-09-17  6:04     ` Shengjiu Wang
2021-09-17  6:04       ` Shengjiu Wang
2021-09-08  9:10 ` [PATCH v4 4/4] dt-bindings: dsp: fsl: update binding document for remote proc driver Shengjiu Wang
2021-09-08  9:10   ` Shengjiu Wang
2021-09-10 12:51   ` Daniel Baluta
2021-09-10 12:51     ` Daniel Baluta
2021-09-10 21:43   ` Rob Herring
2021-09-10 21:43     ` Rob Herring
2021-09-13  2:49     ` Shengjiu Wang
2021-09-13  2:49       ` Shengjiu Wang
2021-09-13 17:08       ` Mathieu Poirier
2021-09-13 17:08         ` Mathieu Poirier
2021-09-14 11:45     ` Daniel Baluta
2021-09-14 11:45       ` Daniel Baluta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA+D8AN_ni_XmEFNfY0Z0qLAJX00XFSUP1RkJdNQd-MVY6pd4g@mail.gmail.com \
    --to=shengjiu.wang@gmail.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel.baluta@nxp.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=ohad@wizery.com \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=shengjiu.wang@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.