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" <heshamelmat...@gmail.com> wrote:
> > > > 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 > >
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
