You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I encountered an issue while bring up RV64ILP32 on our own RV64 platform, and hope you can give me some advice to check this issue.
I saw Guo Ren's amazing RV64ILP32 presentation on RISC-V Summit China and LPC 2023, and thought it's a really valuable solution for low RAM embedded Linux devices, like Guo mentioned 64MB SiP IPCam SoC and others. So I tried to integrate the patchset 1 into our own Linux distribution with Linux kernel 6.6, and test on qemu and our own SystemC VM system. It works fine with qemu, but failed to boot Linux while running on SystemC VM, and VM raised exception 7 (Store/AMO access fault) while jumping to setup_vm() of Linux.
The start address of DRAM on our platform is 0x80000000, and the disassemble instructions of program occur exception 7 is shown below.
The root cause is the $sp setup in __start is 0x816011e0, and function prologue of setup_vm() "addiw sp,sp,-112" substract $sp with sign extenstion operation to make $sp become 0xffffffff816011e070. I keep in mind you mentioned this sign extension issue in the cover page of RV64ILP32 patchset, and your team invented a clever solution, double mapping by MMU. For the problem I encountered now, the sign extension issue is happened while Linux trying to setup page table and MMU, so double mapping solution can't help to deal with it yet.
I am wondering you have encountered similar issue before on platform which DRAM locate behind 0x80000000? It's much appreciated if you can give me some advise or gulidence on this, looking forward to hearing from you. Thank you. :)
BTW, I found your team kick off RUYISDK project with RV64ILP32 support 2 on Canaan K230 platform, it's good to see RISC-V Open Source comunity grows up. In the meantime, the DRAM start address of K230 EVB with NAND flash seems to located in 0x80000000 3, does RV64ILP32 works fine on this platform? Thanks.
The text was updated successfully, but these errors were encountered:
Hi,
I encountered an issue while bring up RV64ILP32 on our own RV64 platform, and hope you can give me some advice to check this issue.
I saw Guo Ren's amazing RV64ILP32 presentation on RISC-V Summit China and LPC 2023, and thought it's a really valuable solution for low RAM embedded Linux devices, like Guo mentioned 64MB SiP IPCam SoC and others. So I tried to integrate the patchset 1 into our own Linux distribution with Linux kernel 6.6, and test on qemu and our own SystemC VM system. It works fine with qemu, but failed to boot Linux while running on SystemC VM, and VM raised exception 7 (Store/AMO access fault) while jumping to setup_vm() of Linux.
The start address of DRAM on our platform is 0x80000000, and the disassemble instructions of program occur exception 7 is shown below.
The root cause is the $sp setup in __start is 0x816011e0, and function prologue of setup_vm() "addiw sp,sp,-112" substract $sp with sign extenstion operation to make $sp become 0xffffffff816011e070. I keep in mind you mentioned this sign extension issue in the cover page of RV64ILP32 patchset, and your team invented a clever solution, double mapping by MMU. For the problem I encountered now, the sign extension issue is happened while Linux trying to setup page table and MMU, so double mapping solution can't help to deal with it yet.
I am wondering you have encountered similar issue before on platform which DRAM locate behind 0x80000000? It's much appreciated if you can give me some advise or gulidence on this, looking forward to hearing from you. Thank you. :)
BTW, I found your team kick off RUYISDK project with RV64ILP32 support 2 on Canaan K230 platform, it's good to see RISC-V Open Source comunity grows up. In the meantime, the DRAM start address of K230 EVB with NAND flash seems to located in 0x80000000 3, does RV64ILP32 works fine on this platform? Thanks.
The text was updated successfully, but these errors were encountered: