Yann Sionneau | 3 Jun 2012 19:24
Gravatar

Milkymist MMU making progress

Hello Milkymisters (and milkymadams),

I'm proud to announce that the Milkymist MMU is making small progresses :)
It seems that phase 2 is in a good shape: it passes a few tests [0] in
ISim simulation as well as on real FPGA running MMU-enabled Milkymist SoC

Phase 2 was "allow MMU to generate a CPU exception upon a page fault".

The use case scenario is as follow :

The Operating System (Linux/RTEMS) keeps - somewhere in memory (DDR
SDRAM) - all virtual to physical memory mappings.
A small subset of those mappings is also stored in on-chip FPGA memory
in the TLB (Translation Lookaside Buffer [1]).
The TLB is a cache to speed up virtual address translations.

When MMU is enabled (in a Linux user space process for example), TLB is
checked on every memory load/store.
If the virtual address being accessed has it's physical page frame
number stored in the TLB then the translation is instantaneous.
If the mapping is not in the TLB, then MMU cannot translate it, it
therefore generates a CPU exception.

This exception makes the CPU run the "page fault handler" [2], a piece
of code which will walk through previously described virtual to physical
mappings stored in DDR SDRAM.
If the virtual address responsible for the page fault is indeed mapped
to a physical address, the page fault handler will find it, update the
TLB with this piece of information and then return to the code which
caused the page fault.
(Continue reading)

Jon Phillips | 4 Jun 2012 01:22
Favicon
Gravatar

Re: Milkymist MMU making progress

This is fabulous!

On Mon, Jun 4, 2012 at 1:24 AM, Yann Sionneau <yann <at> minet.net> wrote:
> Hello Milkymisters (and milkymadams),
>
> I'm proud to announce that the Milkymist MMU is making small progresses :)
> It seems that phase 2 is in a good shape: it passes a few tests [0] in
> ISim simulation as well as on real FPGA running MMU-enabled Milkymist SoC
>
> Phase 2 was "allow MMU to generate a CPU exception upon a page fault".
>
> The use case scenario is as follow :
>
> The Operating System (Linux/RTEMS) keeps - somewhere in memory (DDR
> SDRAM) - all virtual to physical memory mappings.
> A small subset of those mappings is also stored in on-chip FPGA memory
> in the TLB (Translation Lookaside Buffer [1]).
> The TLB is a cache to speed up virtual address translations.
>
> When MMU is enabled (in a Linux user space process for example), TLB is
> checked on every memory load/store.
> If the virtual address being accessed has it's physical page frame
> number stored in the TLB then the translation is instantaneous.
> If the mapping is not in the TLB, then MMU cannot translate it, it
> therefore generates a CPU exception.
>
> This exception makes the CPU run the "page fault handler" [2], a piece
> of code which will walk through previously described virtual to physical
> mappings stored in DDR SDRAM.
> If the virtual address responsible for the page fault is indeed mapped
(Continue reading)

Werner Almesberger | 4 Jun 2012 05:52
Favicon
Gravatar

Re: Milkymist MMU making progress

Yann Sionneau wrote:
> Phase 2 was "allow MMU to generate a CPU exception upon a page fault".

Very good !

One thing that we'll need is a way to track a page's "dirty"
status. There are two ways to do this:

1) have a "dirty" bit (in this case in the TLB) the gateware sets,
   or

2) initially make the page read-only and make the page fault
   handler turn it read-write on the first write fault.

Since we need read-only pages anyway, perhaps it's best to use
the second approach first and then consider whether the first
approach could help to accelerate things.

As far as I can tell, you haven't implemented dirty bits or
page access permissions yet. Do you foresee any difficulties ?

> ITLB will be very similar to DTLB, but it will be significantly harder
> to debug since it touches the execution flow: if the ITLB screws up, the
> CPU will jump to execute some random instructions in the SDRAM :/

Having the nicely debugged DTLB to start from will certainly
help with this ;-)

- Werner
(Continue reading)

Sébastien Bourdeauducq | 4 Jun 2012 11:59
Gravatar

Re: Milkymist MMU making progress

On 06/04/2012 05:52 AM, Werner Almesberger wrote:
> One thing that we'll need is a way to track a page's "dirty"
> status. There are two ways to do this:

The LM32 cache is write-through, so there should not be a need for this 
(unless we want to make it write-back at the same time).

S.
Werner Almesberger | 4 Jun 2012 15:20
Favicon
Gravatar

Re: Milkymist MMU making progress

S?bastien Bourdeauducq wrote:
> The LM32 cache is write-through, so there should not be a need for
> this (unless we want to make it write-back at the same time).

It's for memory management in the kernel: storage-backed pages
that are "clean" can be safely evicted while storage-backed
pages that are "dirty" need to be written back. (Unless the
storage is swap and you're about to kill the process anyway.)

So if Paccess is the probability that the page you're about to
evict will be accessed in the future of the process, you get
1+Paccess storage operations if it is dirty but only Paccess
storage operations if it is not. Paccess may be zero.

"Storage operations" can also simply mean to retrieve
read-only data from a library or an executable. So this also
applies if we don't have swap.

There may be other uses I don't recall at the moment. Memory
management is tricky :-)

- Werner
Yann Sionneau | 5 Jun 2012 23:03
Gravatar

Re: Milkymist MMU making progress

Le 03/06/12 19:24, Yann Sionneau a écrit :
> Hello Milkymisters (and milkymadams),
>
> I'm proud to announce that the Milkymist MMU is making small progresses :)
> It seems that phase 2 is in a good shape: it passes a few tests [0] in
> ISim simulation as well as on real FPGA running MMU-enabled Milkymist SoC
>
> Phase 2 was "allow MMU to generate a CPU exception upon a page fault".
>
> [...]
>
> Regards,
>
> [0] --
> https://github.com/fallen/milkymist-mmu/blob/mmu/software/bios/dtlb_exception_handling_tests.c
> [1] -- http://en.wikipedia.org/wiki/Translation_lookaside_buffer
> [2] --
> https://github.com/fallen/milkymist-mmu/blob/mmu/software/bios/dtlb_miss_handler.c
> [3] -- http://sionneau.net/mmu/page_fault_handling/
> [4] -- http://sionneau.net/mmu/page_fault_handling/tlb_tests_log.txt
>
Just because I find it nice when it runs in interactive BIOS :
http://pastebin.com/gtp1EtMR :-)

--

-- 
Yann Sionneau
Xiangfu Liu | 18 Jun 2012 11:14
Favicon
Gravatar

Re: Milkymist MMU making progress

On 06/04/2012 01:24 AM, Yann Sionneau wrote:
> Hello Milkymisters (and milkymadams),
>
> I'm proud to announce that the Milkymist MMU is making small progresses:)
> It seems that phase 2 is in a good shape: it passes a few tests [0] in
> ISim simulation as well as on real FPGA running MMU-enabled Milkymist SoC

Hi

Great. anyone want try MMU image soc/bios:
   http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-mmu-20120616-1504/

download the soc.fpg/bios.bin, reflash by 'm1nor'[1]
   m1nor soc.fpg
   m1nor bios.bin

[1]http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/tools/m1nor

Xiangfu
Yann Sionneau | 8 Jul 2012 14:22
Gravatar

Re: Milkymist MMU making progress

Le 03/06/12 19:24, Yann Sionneau a écrit :
> Hello Milkymisters (and milkymadams),
[...]
> What's next ?
>
> - Write more tests !
To be done.
> - Debugging whatever bug I can find
Done a few.
> - Write the ITLB (Instruction TLB) part
Done :)
It works very nicely in ISim simulation ( refer to
https://github.com/fallen/milkymist-mmu-simulation/commits/master )
It works in some situations on FPGA, and it crashes the SoC in some
other cases.
So maybe my software test case has bug, or the ITLB itself has bugs : I
don't know yet.
I guess I will find out when implementing MMU support in Linux :)
> - Implement Milkymist MMU support in Linux
To be done. I will start pretty soon to write things in Linux kernel.


Gmane