added mmu support for k210 - #206
Conversation
added mmu support for k210
|
@damien-lemoal wow, would this help linux be able to use virtual memory? |
| if (!cold_boot) | ||
| return 0; | ||
|
|
||
| MMUTable[2] = 0x2000002fULL; | ||
| MMUTable[3] = 0x3000002fULL; | ||
| csr_write(sptbr,((u64)MMUTable) >> 12); | ||
|
|
There was a problem hiding this comment.
Does this mean that you are unconditionally enabling the MMU here if we jump to S-mode for the payload ? Where is the control for choosing which mode we will jump to ?
There was a problem hiding this comment.
Yes,the mmu is unconditionally enabled now and there's no any other control,maybe i can add a configuration item?
There was a problem hiding this comment.
But actually that,for K210,if user doesn't enable MMU,they must use the range of 0x00000000-0xffffffff which contains all available physical addresses,the default map pattern is one-to-one mapping for 0x00000000-0xffffffff, so maybe it doesn't cause any problem I think.
|
The patch title should be "Add ..." instead of "Added ...". It would also be nice if you could git send-email the patch to opensbi mailing list (opensbi@lists.infradead.org). That makes commenting easier for some... github web interface is not the preferred comment interface for many :) |
|
@pdp7 Yes, this would definitely allow running the regular MMU kernel. Sean is working on U-Boot improvements for the K210, and now that the kernel has SD card support for all K210 boards, swap could even be used :) So all the pieces are here for MMU kernel on K210. However, we are talking about a non-standard MMU here. So Anup (opensbi) and Palmer (kernel) will need some convincing to take patches to enable such non-standard HW support. My opinion is that if there is a valid use case for it, we should make an effort to take that support. In the case of the K210, it certainly would make things easier (c.f. my ongoing fight with elf2flt and flatbin support for NOMMU userspace...). But I am not entirely convinced that "it is easier" is a valid argument enough as a justification for the non-standard HW support. If we start opening that door, things could start getting ugly very quickly. C.f. Palmer comments recently on the kernel list about support for non-frozen ISA extensions. We (the risc-v dev community) need to carefully consider this and come up with a reasonable policy. |
OK,I will do this next time. |
|
If i understand correctly, the K210 quirks because of K210 being based on riscv-privileged-v1.9.1 specification are not tackled here, correct? This has been outlined by @wangrunji0408 in rcore-os/rCore. |
Yes, correct. The ISA v1.9 specifications are not the ratified version so generally not supported anywhere. Both OpenSBI and the kernel do not support this draft version. As a result, Linux support for the K210 is NOMMU only as the v1.9 mmu specifications are not compatible with the ratified version 2.0. |
add k210 interrupt support
|
I can compile with these changes and get MMU support on Linux? |
|
This never got accepted - so I guess there is no way to have MMU Linux on Sipeed Maixduino? |
In theory, that can be implemented, just it's a non-standard implementation. |
|
If you have code to enable mmu in opensbi and Linux, try submitting it and see what happens... The non-standard mmu may be a blocker, or not. In the past, it was. |
I just have an implementation with RT-Thread Smart |
|
@lizhirui did you ever send your patch to the e-mail list? |
|
There is a recent discussion on HN that I started, with some additional K210 context |
|
No activity hence closing. |
…uild (riscv-software-src#206) Sysroot changes were not picked up by CMake because add_custom_command does not run the dependent target. We change it to depend on an actual file, instead of target "sysroot"
7 participants
added mmu support for k210(Sv39 Mode,0x00000000~0xffffffff are directly mapped to physical address)
and set boot address to 0x80030000