Hi Sathya,
I'm familiar with the use of the elfloader on ARM platforms, but not so familiar with the RISC-V port. My bet is that the memcpy is overwriting some part of the elfloader code, data or stack sections. To resolve this, you could try to load/execute the elfloader from a higher address in memory.
Alternatively, the destination address range for the memcpy may not be to RAM. It might help to draw a diagram of where RAM lies, where the elfloader lies, and where the kernel and user images will be copied to.
- Alex
________________________________ From: Devel devel-bounces@sel4.systems on behalf of Sathya Narayanan N sathya281@gmail.com Sent: Friday, August 3, 2018 10:13 PM To: devel@sel4.systems Subject: [seL4] Porting SEL4 on RISCV FPGA
Hi,
I am porting SEL4 on RISCV FPGA. I am stuck midway in the kernel elf loader.
The function stuck is memcpy. I have added prints and I am not progressing after the last memcpy call in unpack_elf_to_paddr(). All kinds of input appreciated.
Function under review: static void unpack_elf_to_paddr(void *elf, paddr_t dest_paddr)
/* Parse size/length headers. */ dest_vaddr = elf_getProgramHeaderVaddr(elf, i); data_size = elf_getProgramHeaderFileSize(elf, i); data_offset = elf_getProgramHeaderOffset(elf, i);
/* Load data into memory. */
memcpy((char *)dest_vaddr + phys_virt_offset, (char *)elf + data_offset, data_size); printf("loaded data into memory \n"); -----> Stuck Here ! }
}
Can anyone give me a clue on whatsoever to check here ? It worked perfectly in spike simulation.
RISCV FPGA configuration - It supports IMAFD. It has already booted linux. Kernel is loaded at physical address 80 million.?
-- regards, Sathya