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