Btw, I sent a v2 for this patch: https://www.mail-archive.com/u-boot@lists.denx.de/msg346085.html
On 10/12/2019 4:18 PM, Simon Glass wrote: > Hi Fabien, > > On Wed, 30 Oct 2019 at 03:50, Fabien DESSENNE <fabien.desse...@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.desse...@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.desse...@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.desse...@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