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