[J-core] MMU-Design

BGB cr88192 at gmail.com
Sat Dec 2 13:47:59 EST 2017


On 12/2/2017 10:57 AM, Fabjan Sukalia wrote:
> Hello,
>
> I'm curious about the memory management unit in j2, as it is needed to 
> port Debian to j-core. The last I read on this mailing list was that 
> the design of the MMU will be discussed during a meeting in Japan.
> Are there any new information that can be shared with the community? 
> Will it have a soft-mmu, like MIPS and LM32 have, or a hard-mmu like 
> in x86? Also, will the design be compatible to the MMU in SH-4?
>

AFAIK:
* J2 doesn't have an MMU ( and presumably wont? )
* presumably, the MMU would likely be for different cores ( J4 / etc... ).


can't speak for J-Core here, but have noted:
* for many use-cases, an x86 style hard-MMU is preferable;
* however, a soft MMU is easier to implement in hardware (*1).
* the existing OS's (such as Linux) seem to basically just emulate a 
page table on SH4.
* the existing SH4 MMU design has a lot of "unnecessary complexity".
** in the form of features and memory-mapped structures which make 
little sense to be visible.
** Linux does not appear to make use of these, but I could be wrong here.


what seems like a sane option, at least, from my POV (as an outsider):
* optionally mandate the use of a conventional page-table style layout;
** only mandated if the use of a firmware or "hard" MMU is enabled.
** left it as "undefined" if something different is done while hard-MMU 
flag is set.
** page table bit-layout is to be kept basically equivalent to the Linux 
page-tables.
* implemented as a soft MMU in hardware.
** likely significantly stripped down vs the SH4 design.
** presumably, the registers/... are basically the same as SH4, but 
specifics differ.
** likely omits MMIO visibility for the TLB and caches.
* potentially, the MMU is (optionally) moved into firmware.
** say, there is an MMU flag which indicates where TLB miss ISR's go.
*** say: Set=0xA0000400, Clear=VBR+0x400.
** if there is an (optional) hardware MMU, this flag would also enable 
its use.
** an OS supplied TLB ISR could still exist as a fallback (if the 
feature is not supported).
** by extension, things built as ROM would need to supply a TLB ISR though.
** the firmware ISR or hard-MMU would instead generate a Page-fault ISR.
*** say, as using the TLBMISS exception code, but transferring control 
to VBR+0x100
* ...


but, as noted, these are just outsider thoughts (from someone working on 
an independent side-project...).

*1: I was initially pretty much on the "do a hard MMU" side of the 
fence, but a very brief attempt at doing page-walking logic in Verilog 
pushed me over to the soft-MMU side of things ( pretty much anything 
that requires performing multiple sequential steps is a horrible PITA; 
and "microcode" ended up just sort of decaying into "just generate an 
ISR" and "casually overlook that using certain instructions within an 
ISR will effectively crash the CPU..."; but the "lame jokes" never end 
here, and this was by no means the worst of it... ).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20171202/3a1627a8/attachment.html>


More information about the J-core mailing list