On Sat, Jun 22, 2013 at 12:15 PM, Thomas Dörfler < thomas.doerf...@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@rtems.org > > http://www.rtems.org/mailman/listinfo/rtems-devel > > > -- > -------------------------------------------- > Embedded Brains GmbH > Thomas Doerfler Dornierstr. 4 > D-82178 Puchheim Germany > email: thomas.doerf...@embedded-brains.de > Phone: +49-89-18 94 741-12 > Fax: +49-89-18 94 741-09 > _______________________________________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel >
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
