[GSoC] BAT vs Pages on PowerPC [Please give a feedback]

[Gedare Bloom]

On Sun, Jun 23, 2013 at 6:55 AM, Chris Johns <chrisj at rtems.org> wrote:
> Thomas Doerfler wrote:
>>
>> Chris,
>>
>> Am 23.06.2013 03:46, schrieb Chris Johns:
>>>
>>> Thomas Dörfler wrote:
>>>>
>>>> Note that the pages usually only cover 4K of
>>>> memory, and the "translation lookaside buffer" (TLB) only maintains the
>>>> last 16-64 used pages,
>>>
>>> The ARM which I am currently using and have handy seems to support 1MB,
>>> 64K and 4K ranges depending on the TLB table level used. I would be
>>> surprised if an entry was needed for each page in use.
>>
>>
>> Classic PowerPC ist not that flexible. The 603(e) core, that is quite
>> often used in PPC controllers, has a fixed page table entry size of 4K,
>> so the number of TLB entries (the "page cache") will never cover the
>> whole lot of pages for a suitable memory size.
>
>
> Interesting and thanks. It is a difficult API to make because of these
> reasons. Hesham has some interesting challenges.
>
Yes. That is why we are now focusing from the bottom-up to try to
resolve the differences among MMU/MPU/processors support for memory
mapping both for translation and protection.

>
>>
>> So for this derivative (and many others) it's "Use (statically
>> initialized) BATs or (dynamically reloaded) TLB entries".
>>
>
> Agreed. Is this worth adding to the API ?
>
I'm not sure how to abstract the two cases out, although it seems like
many MMUs offer two useful alternatives for coarse-grained and
fine-grained memory mapping/protection.  For example, we have the
BAT/pages for some ppc, X86 has segmentation/pages, ARM has
large/small pages. So, it might be sensible to create a way to define
a coarse-grained mapping that uses for example
BAT/segments/superpages, and a fine-grained mapping using pages. I
would expect coarse-grained could be used in both static and dynamic
cases, and fine-grained would be primarily intended for dynamic
mapping/protection.

-Gedare

> Chris
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel