On Sun, Jun 23, 2013 at 6:55 AM, Chris Johns <chr...@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@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
