[J-core] j3/mmu and first silicon status.

[Tim Ansell]

I don't know much about MMUs, but you might want to chat with the M-Labs
guys. They adding a MMU to the lm32, see
https://github.com/m-labs/lm32/blob/master/doc/mmu.rst -- their
implementation is *super simple* but seems to be good enough to get OSes
running.

The lm32+MMU+Basic SoC (DDR, UART, Timer) easily fits inside a LX9 using
only about 50% of the resources.

Tim 'mithro' Ansell

On 23 March 2017 at 00:20, Rob Landley <rob at landley.net> wrote:

> Part of the reason we've been so quiet recently is that J2 development
> is now in feature freeze preparing for first silicon. We're happy enough
> with what we've got that we want to do a small initial proving run of
> actual ASICs. There's still some development on peripherals and bus size
> tweaks going on, but the SOC core you'd run on Numato or Turtle hasn't
> changed in a while and isn't expected to start changing again for a few
> months.
>
> That said, Jeff recently looked at the mmu design Hitachi did for the
> sh3, and it's very heavyweight. We'd rather do a simpler implementation
> for our first pass, and need to study what Linux actually wants out of
> an MMU first. And if we're doing a new mmu design, we'd rather not open
> that can of worms until after the ASIC tapes out. (Which is mostly
> testing work, not development work.)
>
> The problem with the existing sh3 MMU is there's no WAY you can fit it
> in an lx9, and probably not in an lx25. The problem is their MMU walks
> the page tables in software, which completely flushes a simple L1 cache
> like j-core has. To work around that they added L2 cache and made the L1
> 4-way associative, and which drives the FPGA routing nuts. A simple
> implementation of what they did would be several times larger than the
> existing j2 SOC implementation _combined_. (We talked about making our
> L1 2-way associative someday, but what the hitachi mmu needs is not a
> "sweet spot".)
>
> What we really want, to go along with our tiny processor implementation,
> is an mmu that walks the page tables in _hardware_, at least for simple
> faults where the TLB refill is just looking up the translation of an
> existing physical page address. This would avoid the need to run page
> fault handling code through the cache for "soft faults" (or run the same
> code uncached, which would suck about as badly).
>
> But what we really want is an mmu that's a good fit for Linux. Note that
> Linus has strong opinions about this sort of thing:
>
> http://yarchive.net/comp/powerpc_page_tables.html
> http://yarchive.net/comp/linux/page_tables.html
>
> And apparently wrote his master's thesis on it:
>
> ftp://ftp.polsl.pl/pub/linux/kernel/people/torvalds/thesis/torvalds97.pdf
>
> And so did Mel Gorman a few years later:
>
> https://www.kernel.org/doc/gorman/
>
> That said stuff's changed a lot since then (we're up to what, 5 levels
> now?) so we'd like to take the time and get the design right.
>
> We'd also want to have a patch ready to push into qemu to support the
> new design if it's not the existing one...
>
> So that's the current state of that work.
>
> Rob
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20170323/2524dc44/attachment.html>