MMU/Cache analysis for OpenRISC
Hesham Moustafa
heshamelmatary at gmail.com
Tue Jul 29 06:42:05 UTC 2014
On Tue, Jul 29, 2014 at 3:18 AM, Gedare Bloom <gedare at rtems.org> wrote:
>
>
>
> 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)?
>
Yes if we only used 2 level page tables.
> Is the only use case for the MMU / virtual memory to have memory protection?
>
It provides address translation, memory protection, cahce and some
features to implement demand paging.
> 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.
>
I think yes they can be mixed as there is L (Last) flag in rach PTE
to decide whether it's in a page directory or it points to actual PTE
for translation.
This is [1] the related section at the OpenRISC architecture manual.
[1] http://openrisc.github.io/or1k.html#__RefHeading__504777_595890882
> -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
>
>
More information about the devel
mailing list