Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regrading bring up RV64ILP32 on platform which DRAM start from 0x80000000 #17

Open
ismhong opened this issue Jun 4, 2024 · 0 comments

Comments

@ismhong
Copy link

ismhong commented Jun 4, 2024

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.

c0404bbe <setup_vm>:
c0404bbe:   f901011b            addiw   sp,sp,-112
c0404bc2:   f0a2                    sd  s0,96(sp)
^^^^^^^^^^^^^^^^^^^^^^^^^^^ EPC
c0404bc4:   e8ca                    sd  s2,80(sp)
c0404bc6:   f45e                    sd  s7,40(sp)
c0404bc8:   f486                    sd  ra,104(sp)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant