<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/2/2017 10:57 AM, Fabjan Sukalia
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPq_R_ceLjrGDKN6oCJFSg7++s5dTDHFf0AmV7nBb=8x6BVBpw@mail.gmail.com">
<div dir="ltr">
<div>
<div>Hello,<br>
<br>
</div>
I'm curious about the memory management unit in j2, as it is
needed to port <span class="" style="" id=":1te.10"
tabindex="-1">Debian</span> to j-core. The last I read on
this mailing list was that the design of the <span class=""
style="" id=":1te.11" tabindex="-1">MMU</span> will be
discussed during a meeting in Japan. <br>
</div>
<div>Are there any new information that can be shared with the
community? Will it have a soft-<span class="" style=""
id=":1te.12" tabindex="-1">mmu</span>, like MIPS and LM32
have, or a hard-<span class="" style="" id=":1te.13"
tabindex="-1">mmu</span> like in x86? Also, will the design
be compatible to the <span class="" style="" id=":1te.14"
tabindex="-1">MMU</span> in SH-4?<br>
</div>
<div><br>
</div>
</div>
</blockquote>
<br>
AFAIK:<br>
* J2 doesn't have an MMU ( and presumably wont? )<br>
* presumably, the MMU would likely be for different cores ( J4 /
etc... ).<br>
<br>
<br>
can't speak for J-Core here, but have noted:<br>
* for many use-cases, an x86 style hard-MMU is preferable;<br>
* however, a soft MMU is easier to implement in hardware (*1).<br>
* the existing OS's (such as Linux) seem to basically just emulate a
page table on SH4.<br>
* the existing SH4 MMU design has a lot of "unnecessary complexity".<br>
** in the form of features and memory-mapped structures which make
little sense to be visible.<br>
** Linux does not appear to make use of these, but I could be wrong
here.<br>
<br>
<br>
what seems like a sane option, at least, from my POV (as an
outsider):<br>
* optionally mandate the use of a conventional page-table style
layout;<br>
** only mandated if the use of a firmware or "hard" MMU is enabled.<br>
** left it as "undefined" if something different is done while
hard-MMU flag is set.<br>
** page table bit-layout is to be kept basically equivalent to the
Linux page-tables.<br>
* implemented as a soft MMU in hardware.<br>
** likely significantly stripped down vs the SH4 design.<br>
** presumably, the registers/... are basically the same as SH4, but
specifics differ.<br>
** likely omits MMIO visibility for the TLB and caches.<br>
* potentially, the MMU is (optionally) moved into firmware.<br>
** say, there is an MMU flag which indicates where TLB miss ISR's
go.<br>
*** say: Set=0xA0000400, Clear=VBR+0x400.<br>
** if there is an (optional) hardware MMU, this flag would also
enable its use.<br>
** an OS supplied TLB ISR could still exist as a fallback (if the
feature is not supported).<br>
** by extension, things built as ROM would need to supply a TLB ISR
though.<br>
** the firmware ISR or hard-MMU would instead generate a Page-fault
ISR.<br>
*** say, as using the TLBMISS exception code, but transferring
control to VBR+0x100<br>
* ...<br>
<br>
<br>
but, as noted, these are just outsider thoughts (from someone
working on an independent side-project...).<br>
<br>
*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... ).<br>
<br>
</body>
</html>