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

[Fabien DESSENNE]

Hi Simon,


On 10/12/2019 4:18 PM, Simon Glass wrote:
> 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?

Please have a look to [STM32MP15_Flash_mapping] which describes how 
u-boot, linux and the coprocessor firmwares can be stored in flash memory.

Both U-boot and Linux use an EXT4 filesystem (eg bootfs partition) to 
read the coprocessor .elf firmware file.


When it is read (it is then in DDR), U-boot or Linux parses it, in order 
to copy the resource table and the different ELF segments into 
appropriate memory addresses.

[STM32MP15_Flash_mapping] 
https://wiki.st.com/stm32mpu/wiki/STM32MP15_Flash_mapping


>
>> 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.


As described above, an EXT4 filesystem is a good example.

This patch is not about filesystem but about how the .elf contents 
available in DDR memory (after is has been loaded from somewhere) is parsed.


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