Closed UmairKhanUET closed 4 months ago
Yes, I will get back on this. I was wondering how its working without this patch.
@bentheredonethat FYI.
Yes, I will get back on this. I was wondering how its working without this patch.
@bentheredonethat FYI.
Probably because you have same memory mapping regarding the main and remote processor.
Yes, I will get back on this. I was wondering how its working without this patch.
@bentheredonethat FYI.
May be because generally when firmware runs out of RAM, the ELF sections are placed at same link and load addresses. But it doesn't stop one from having different addresses either. May be this is the first time we are seeing such a case.
LGTM, @tnmysh , @edmooring could you verify that this does not introduce regression on yopur platforms?
@tnmysh , @edmooring, @bentheredonethat : Gentle reminder
@arnopo I have been trying to look for history on when this code was used on Xilinx's platforms. I can't find it being used currently or anytime in near past. It's very hard to prepare setup for this atleast with 2023 petalinux.
The code looks okay for me, and we don't have any use case currently that is practicing this code. I am okay with code, and sure no regression will happen on xlnx platforms as it's not being used.
Thanks @edmooring and @tnmysh for the feedback.
We have to find a way to better test it. Look to me that the load code could be optimized to make this more simple with less footprint. let's add this in agenda of next open-amp meeting call.
Unlike the Linux rproc elf loader, the OpenAMP elf loader loads the remote elf program segments to their load addresses instead of their link addresses. This results in memory corruption when the remote firmware attempts to relocate segments from their link addresses to load addresses at runtime such as the data section.
Signed-off-by: Umair Khan umair_khan@mentor.com