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

[Gedare Bloom]

Based on this discussion, both should be available in the low level. Worry
how to choose later, but BAT is probably a good default on ppc for a normal
static map that defines some usual memory regions (code, rodata, data,
heap). "Extended" BAT should be investigated since it could be useful for
small systems to protect e.g. 4 task stacks along with code/data/heap
isolation.
-G
On Jun 22, 2013 3:16 PM, "Hesham Moustafa" <heshamelmatary at gmail.com> wrote:

>
>
>
> On Sat, Jun 22, 2013 at 12:15 PM, Thomas Dörfler <
> Thomas.Doerfler at embedded-brains.de> wrote:
>
>> Hi,
>>
>> please note that some PPC derivatives (especially those for embedded
>> projects) usually have eight DBATs and eight IBATs. This feature must be
>> enabled (e.g. in a 603e core) with a special bit in one of the HID
>> registers, but it will put the number of BAT ranges closer to what is
>> needed in embedded computing.
>>
>> The advantage of BATs versus pages is definitively, that they usually
>> get set up ONCE during startup and, due to their flexible size, will not
>> need to be reloaded. Note that the pages usually only cover 4K of
>> memory, and the "translation lookaside buffer" (TLB) only maintains the
>> last 16-64 used pages, so there is always code involed reloading the
>> required page info into the TLB. IMHO this reduces the realtime
>> performance of the system.
>>
>> In short: Supporting both (BATs and pages) in libmm would be a good
>> feature.
>>
>> Yes that's what I was thinking about. But how should I provide the user
> with the option of choosing which method to use: BAT or Pages ?
> Through a configuration option at build time? libmm should be general and
> abstract in the way that it provides memory protection. Only a developer
> who ports libmm should know about HW details like BAT and Pages.
>
>> wkr,
>>
>> Thomas.
>>
>> On 22.06.2013 04:11, Chris Johns wrote:
>> > Hesham Moustafa wrote:
>> >> Eight: 4 for data and 4 for instructions. BAT areas can not overlap.
>> >
>> > Then I suggest we support for pages as well. There may be a need for
>> > more areas in the future and I feel 4 may not be enough.
>> >
>> > Chris
>> > _______________________________________________
>> > rtems-devel mailing list
>> > rtems-devel at rtems.org
>> > http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>>
>> --
>> --------------------------------------------
>> Embedded Brains GmbH
>> Thomas Doerfler        Dornierstr. 4
>> D-82178 Puchheim       Germany
>> email: Thomas.Doerfler at embedded-brains.de
>> Phone: +49-89-18 94 741-12
>> Fax:   +49-89-18 94 741-09
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130622/6c1e257e/attachment-0001.html>