[PATCH 1/5] remoteproc: elf_loader: Add elf resource table load support

Simon Glass sjg at chromium.org
Tue Dec 10 16:18:15 CET 2019


Hi Fabien,

On Wed, 30 Oct 2019 at 03:50, Fabien DESSENNE <fabien.dessenne at st.com> wrote:
>
> Hi Simon
>
> On 30/10/2019 2:49 AM, Simon Glass wrote:
> > Hi Fabien,
> >
> > On Tue, 22 Oct 2019 at 03:08, Fabien DESSENNE <fabien.dessenne at st.com> wrote:
> >> Hi Simon,
> >>
> >>
> >> On 22/10/2019 1:47 AM, Simon Glass wrote:
> >>> Hi Fabien,
> >>>
> >>> On Wed, 9 Oct 2019 at 09:36, Fabien Dessenne <fabien.dessenne at st.com> wrote:
> >>>> Add rproc_elf_load_rsc_table(), which searches for a resource table in
> >>>> an elf64/elf32 image, and if found, copies it to device memory.
> >>>> Add also the elf32 and elf64 variants of this API.
> >>>> Add a test for this.
> >>>>
> >>>> Signed-off-by: Fabien Dessenne <fabien.dessenne at st.com>
> >>>> ---
> >>>>    drivers/remoteproc/rproc-elf-loader.c | 269 ++++++++++++++++++++++++++++++++++
> >>>>    include/remoteproc.h                  |  70 +++++++++
> >>>>    test/dm/remoteproc.c                  |  91 ++++++++++--
> >>>>    3 files changed, 419 insertions(+), 11 deletions(-)
> >>>>
> >>> If you are putting stuff in the image, should you use binman to build
> >>> the image, then find the contents using the binman tables?
> >>
> >> The "resource table" may be located anywhere, there is no strict rule
> >> defining where it is expected to be.
> >>
> >> Nevertheless the Linux remoteproc[1] and OpenAmp (running RTOS) [2]
> >> frameworks expect the resource table to be stored in a dedicated ELF
> >> section. Both of them run some ELF scanning to find out this section.
> >>
> >> The proposed patch is for the "ELF section" variant of the resource table.
> >> Other variants like binman packing may be proposed as well, both
> >> implementations can coexist alongside.
> > So why not use binman to pack the image and find the components? This
> > is U-Boot, after all.
> >
>
> Packing the firmware together with the other U-Boot components is
> acceptable if the firmware is controlled only by U-Boot.
> My requirement is that the coprocessor firmware shall be loaded by
> U-Boot or by Linux.
>
> You can have a look at [1] for more details on the way this is handled
> on STM32 MPU. In that case, the .elf firmware is stored in a in File
> System that can be read by both U-Boot and Linux.
>

Where is the coprocessor firmware stored, then?

> If we have the firmware packed in the image (for U-Boot), we need to
> have a copy in the FileSystem (for Linux) which would not be a good idea.

What type of filesystem do you use? I don't see any filesystem access
in this patch though.

>
> BR
> Fabien
>
> [1] https://wiki.st.com/stm32mpu/index.php/Boot_chains_overview

Regards,
Simon


More information about the U-Boot mailing list