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