Hi Experts, We are trying to port sel4 to Shakti FPGA. It is similar to Rocket FPGA. The memory footprint is 256 mb [0x80000000 - 0x8fffffff]. Shakti support -march=imafd. A single core 64 bit design. The run in FPGA stops at *"memcpy((char *)dest_vaddr + phys_virt_offset, (char *)elf + data_offset, data_size);*" called in the function " *unpack_elf_to_paddr()".* Earlier it stopped just at the memset (one line above). I manually commented out memset part and made it to run till memcpy. So I doubt it has something to do with wrong memory access. can someone please explain me the above said function (blue color) ? what could be reasons for memcpy to hung ? Can someone please guide me to the area in code where memory related interrupts are coded ? We have the latest upstream of SEL4 (Aug 10). It has the dornerworks upstream changes. We are trying to load at 0x88000000. The image works well in spike simulation. *Commands to build:* ../init-build.sh -DPLATFORM=spike -DKernelPlatformSpikeRocketChip=ON -DSIMULATION=FALSE -DRISCV64=TRUE ninja *Snapshot of the run in FPGA:* DTB { #address-cells = <0x00000002>; #size-cells = <0x00000002>; compatible = "shakti,spike-bare-dev"; model = "shakti,spike-bare"; cpus { #address-cells = <0x00000001>; #size-cells = <0x00000000>; timebase-frequency = <0x00989680>; cpu@0 { device_type = "cpu"; reg = <0x00000000>; status = "okay"; compatible = "riscv"; riscv,isa = "rv64imafd"; mmu-type = "riscv,sv39"; clock-frequency = <0x3b9aca00>; interrupt-controller { #interrupt-cells = <0x00000001>; interrupt-controller; compatible = "riscv,cpu-intc"; linux,phandle = <0x00000001>; phandle = <0x00000001>; } } } memory@80000000 { device_type = "memory"; reg = <0x00000000 0x80000000 0x00000000 0x10000000>; } soc { #address-cells = <0x00000002>; #size-cells = <0x00000002>; compatible = "shakti,spike-bare-soc", "simple-bus"; ranges; } uart { compatible = "shakti,uart0"; reg = <0x00000000 0x00011200 0x00000000 0x00001000>; } htif { compatible = "ucb,htif0"; } } ELF-loader started on paddr=[80200000..8060e7d7] elf check file returned 1 elf check file returned 1 ELF-loading image 'kernel' paddr=[88000000..8802bfff] vaddr=[ffffffff80000000..ffffffff8002bfff] virt_entry=ffffffff80000000 configured page table levels = 3...... elf check file returned 1 image size 2b350 *(char *)dest_vaddr + phys_virt_offset = ffffffff88000000 * *phys_virt_offset = 8000000 * *(char *)elf + data_offset, = ffffffff8020f854* *started memcpy* ------------------------------------------------------------> *Hangs* -- regards, Sathya
Hi Sathya,
You need to debug on your HW what's happening inside memcpy i.e. are
you getting an exception? if yes, what's its cause and the address?
Exceptions in the elfloader will trap to riscv-pk, so you can catch
and print debug info there.
Just a note, when you're printing pointers, use %p instead of %x. If
you use %p and you still get an address of 0xffffffff88000000, that
would be wrong as it's not a valid physical address.
P.S. make sure elfloader/riscv-pk are not compiled with the C
extension. objdump memcpy from elfloader to assert it's not using any
On Tue, Aug 14, 2018 at 1:15 PM, Sathya Narayanan N
Hi Experts,
We are trying to port sel4 to Shakti FPGA. It is similar to Rocket FPGA. The memory footprint is 256 mb [0x80000000 - 0x8fffffff]. Shakti support -march=imafd. A single core 64 bit design.
The run in FPGA stops at "memcpy((char *)dest_vaddr + phys_virt_offset, (char *)elf + data_offset, data_size);" called in the function "unpack_elf_to_paddr()". Earlier it stopped just at the memset (one line above). I manually commented out memset part and made it to run till memcpy. So I doubt it has something to do with wrong memory access. can someone please explain me the above said function (blue color) ? what could be reasons for memcpy to hung ?
Can someone please guide me to the area in code where memory related interrupts are coded ?
We have the latest upstream of SEL4 (Aug 10). It has the dornerworks upstream changes. We are trying to load at 0x88000000. The image works well in spike simulation.
Commands to build:
../init-build.sh -DPLATFORM=spike -DKernelPlatformSpikeRocketChip=ON -DSIMULATION=FALSE -DRISCV64=TRUE ninja
Snapshot of the run in FPGA:
DTB { #address-cells = <0x00000002>; #size-cells = <0x00000002>; compatible = "shakti,spike-bare-dev"; model = "shakti,spike-bare"; cpus { #address-cells = <0x00000001>; #size-cells = <0x00000000>; timebase-frequency = <0x00989680>; cpu@0 { device_type = "cpu"; reg = <0x00000000>; status = "okay"; compatible = "riscv"; riscv,isa = "rv64imafd"; mmu-type = "riscv,sv39"; clock-frequency = <0x3b9aca00>; interrupt-controller { #interrupt-cells = <0x00000001>; interrupt-controller; compatible = "riscv,cpu-intc"; linux,phandle = <0x00000001>; phandle = <0x00000001>; } } } memory@80000000 { device_type = "memory"; reg = <0x00000000 0x80000000 0x00000000 0x10000000>; } soc { #address-cells = <0x00000002>; #size-cells = <0x00000002>; compatible = "shakti,spike-bare-soc", "simple-bus"; ranges; } uart { compatible = "shakti,uart0"; reg = <0x00000000 0x00011200 0x00000000 0x00001000>; } htif { compatible = "ucb,htif0"; } } ELF-loader started on paddr=[80200000..8060e7d7] elf check file returned 1 elf check file returned 1 ELF-loading image 'kernel' paddr=[88000000..8802bfff] vaddr=[ffffffff80000000..ffffffff8002bfff] virt_entry=ffffffff80000000 configured page table levels = 3...... elf check file returned 1 image size 2b350 (char *)dest_vaddr + phys_virt_offset = ffffffff88000000 phys_virt_offset = 8000000 (char *)elf + data_offset, = ffffffff8020f854 started memcpy ------------------------------------------------------------> Hangs
-- regards, Sathya
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
-- Hesham
Hi Hesham,
Thanks for the inputs.
I tried with "%p". I got valid physical address.
We will debug from hardware side.
regards,
Sathya
On Wed, Aug 15, 2018 at 3:23 PM, Hesham Almatary
Hi Sathya,
You need to debug on your HW what's happening inside memcpy i.e. are you getting an exception? if yes, what's its cause and the address? Exceptions in the elfloader will trap to riscv-pk, so you can catch and print debug info there.
Just a note, when you're printing pointers, use %p instead of %x. If you use %p and you still get an address of 0xffffffff88000000, that would be wrong as it's not a valid physical address.
P.S. make sure elfloader/riscv-pk are not compiled with the C extension. objdump memcpy from elfloader to assert it's not using any
On Tue, Aug 14, 2018 at 1:15 PM, Sathya Narayanan N
wrote: Hi Experts,
We are trying to port sel4 to Shakti FPGA. It is similar to Rocket FPGA. The memory footprint is 256 mb [0x80000000 - 0x8fffffff]. Shakti support -march=imafd. A single core 64 bit design.
The run in FPGA stops at "memcpy((char *)dest_vaddr + phys_virt_offset, (char *)elf + data_offset, data_size);" called in the function "unpack_elf_to_paddr()". Earlier it stopped just at the memset (one line above). I manually commented out memset part and made it to run till memcpy. So I doubt it has something to do with wrong memory access. can someone please explain me the above said function (blue color) ? what could be reasons for memcpy to hung ?
Can someone please guide me to the area in code where memory related interrupts are coded ?
We have the latest upstream of SEL4 (Aug 10). It has the dornerworks upstream changes. We are trying to load at 0x88000000. The image works well in spike simulation.
Commands to build:
../init-build.sh -DPLATFORM=spike -DKernelPlatformSpikeRocketChip=ON -DSIMULATION=FALSE -DRISCV64=TRUE ninja
Snapshot of the run in FPGA:
DTB { #address-cells = <0x00000002>; #size-cells = <0x00000002>; compatible = "shakti,spike-bare-dev"; model = "shakti,spike-bare"; cpus { #address-cells = <0x00000001>; #size-cells = <0x00000000>; timebase-frequency = <0x00989680>; cpu@0 { device_type = "cpu"; reg = <0x00000000>; status = "okay"; compatible = "riscv"; riscv,isa = "rv64imafd"; mmu-type = "riscv,sv39"; clock-frequency = <0x3b9aca00>; interrupt-controller { #interrupt-cells = <0x00000001>; interrupt-controller; compatible = "riscv,cpu-intc"; linux,phandle = <0x00000001>; phandle = <0x00000001>; } } } memory@80000000 { device_type = "memory"; reg = <0x00000000 0x80000000 0x00000000 0x10000000>; } soc { #address-cells = <0x00000002>; #size-cells = <0x00000002>; compatible = "shakti,spike-bare-soc", "simple-bus"; ranges; } uart { compatible = "shakti,uart0"; reg = <0x00000000 0x00011200 0x00000000 0x00001000>; } htif { compatible = "ucb,htif0"; } } ELF-loader started on paddr=[80200000..8060e7d7] elf check file returned 1 elf check file returned 1 ELF-loading image 'kernel' paddr=[88000000..8802bfff] vaddr=[ffffffff80000000..ffffffff8002bfff] virt_entry=ffffffff80000000 configured page table levels = 3...... elf check file returned 1 image size 2b350 (char *)dest_vaddr + phys_virt_offset = ffffffff88000000 phys_virt_offset = 8000000 (char *)elf + data_offset, = ffffffff8020f854 started memcpy ------------------------------ ------------------------------> Hangs
-- regards, Sathya
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
-- Hesham
-- regards, Sathya
participants (2)
-
Hesham Almatary
-
Sathya Narayanan N