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. The instruction which caused the page fault is executed again, but this time TLB has the needed information to do the translation and the MMU won't generate a CPU exception. If the virtual address responsible for the page fault is not mapped to any physical address, then this is an illegal access. The Operating System can decide to panic() (hang) or to send a deadly SIGSEGV (segmentation fault) signal to the user space process in order to kill the faulty program. Enough with theory, if you want to try out yourself the phase 2 result (MMU generating exceptions upon page fault) you can just download those binaries: [3]. You only need to flash bios.bin into your Milkymist One NAND using flash_bios.data script ($ sudo jtag flash_bios.data) and then upload the MMU-enabled bitstream (system.bit) into the FPGA through JTAG. Just use the UART console (over JTAG), you should see two new commands in the "help" command. Try "detest" and "dtlbtest" :-) - detest stands for "dtlb exception test", it tests the ability of MMU to generate CPU exceptions upon page fault. A small and basic page fault handler is there to handle errors and prevent the system from going madly into panic(). - dtlbtest stands for "dtlb tests" ;) it just tests the ability of the MMU to translate virtual addresses into physical addresses. Once you have played a bit with it and you want to go back to normal Milkymist One: just flash back your normal bios into the NAND (using xiangfu's script). For those who fear breaking their M1, they can just read a log of what they would have seen there [4]. What's next ? - Write more tests ! - Debugging whatever bug I can find - Write the ITLB (Instruction TLB) part - Implement Milkymist MMU support in Linux 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 :/ As always, I will keep you guys posted with any new interesting development ! Some of you may have noticed that from now on any commit I push on github is published on the IRC channel as well by github robots ! See ya ! 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 -- Yann Sionneau _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
