MMU/Cache analysis for OpenRISC

[Gedare Bloom]

On Mon, Jul 28, 2014 at 1:20 PM, Hesham Moustafa <heshamelmatary at gmail.com>
wrote:

> Hi,
>
> I have read about MMU and Caches in OpenRISC to start implementing
> related managers in the new or1k port. Before beginning to write the
> code, I would like to introduce some of the architecture details
> regarding MMU and Caches.
>
> There are both; data and instruction MMU, TLBs, Caches.
> First, page tables there are divided into two levels; one level can be
> used with 32 GB or 16 MB pages, and two-levels for 8 KB pages. 32 GB
> and 16 MB would be too big for RTEMS, and that led us to two-level 8
> KB pages. Two-level pages would hurt the performance unless we setup
> TLBs at startup statically; there are 128 TLB entries. Other than
> defined run-time sections, the remaining pool of TLB entries can be
> used for dynamic page-table setup.
>
>
So you can only have a static setup of at most 1MB (128 entries by 8K)?

Is the only use case for the MMU / virtual memory to have memory protection?

Can the 16MB superpages be mixed with the 8K pages? This can accomodate
some user who might have more than 16MB of memory but wants memory
protection in a static configuration.

-Gedare



> Protection domains are set into a special purpose registers forming 7
> groups, and each PTE can associates its protection domain to one of
> them. Protection provides control over pages for read, write, and
> execute accesses.
>
> Christian, I would like to know more about or1ksim implementation. I
> guess TLB misses are handled in software and accordingly software
> look-up operation. Also I would say that PTE reloads are also handled
> in software. Please correct me if I am wrong.
>
> Cache is working with PTEs; each of of which has some control bits to
> define the Cache attributes for its page.
>
> Given the previous little piece of info, I would appreciate your
> opinion regarding implementation decisions for or1k RTEMS port.
>
> Thanks,
> Hesham
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140728/452ada22/attachment-0002.html>