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

added mmu support for k210 #206

Closed
wants to merge 2 commits into from

Conversation

lizhirui
Copy link

added mmu support for k210(Sv39 Mode,0x00000000~0xffffffff are directly mapped to physical address)
and set boot address to 0x80030000

added mmu support for k210
@pdp7
Copy link

pdp7 commented Apr 16, 2021

@damien-lemoal wow, would this help linux be able to use virtual memory?

if (!cold_boot)
return 0;

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

White line change

MMUTable[2] = 0x2000002fULL;
MMUTable[3] = 0x3000002fULL;
csr_write(sptbr,((u64)MMUTable) >> 12);

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes,the mmu is unconditionally enabled now and there's no any other control,maybe i can add a configuration item?

Copy link
Author

@lizhirui lizhirui Apr 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@damien-lemoal
Copy link
Collaborator

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 :)

@damien-lemoal
Copy link
Collaborator

@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.

@lizhirui
Copy link
Author

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 :)

OK,I will do this next time.

@parasew
Copy link

parasew commented May 1, 2021

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.

@damien-lemoal
Copy link
Collaborator

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
@JoyBed
Copy link

JoyBed commented Aug 3, 2022

I can compile with these changes and get MMU support on Linux?

@z3cko
Copy link

z3cko commented Jun 25, 2023

This never got accepted - so I guess there is no way to have MMU Linux on Sipeed Maixduino?

@lizhirui
Copy link
Author

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.

@damien-lemoal
Copy link
Collaborator

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.

@lizhirui
Copy link
Author

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

@z3cko
Copy link

z3cko commented Jun 28, 2023

@lizhirui did you ever send your patch to the e-mail list?

@z3cko
Copy link

z3cko commented Jun 28, 2023

There is a recent discussion on HN that I started, with some additional K210 context

@avpatel
Copy link
Collaborator

avpatel commented Aug 29, 2024

No activity hence closing.

@avpatel avpatel closed this Aug 29, 2024
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

Successfully merging this pull request may close these issues.

7 participants