Thomas Dörfler wrote:
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.
Yes this is currently true. I also see an emerging range of applications where dynamic control of memory is important.
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.
I understand this is important for some applications. I have used VM and MMU features in application specific ways dating back to the 68010 (68070) where the use was dynamic.
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.
so there is always code involed reloading the required page info into the TLB.
Are you sure ? I though this depended on the set up and configuration and if the entries are locked or not. My view is the API is to provide access to the available resources and if there is abuse it will result in the situation you are suggesting. If the fault handler generates an error the user will soon understand the limitation.
IMHO this reduces the realtime performance of the system.
Yes it will if we attempt to implemented a full VM with fault handling, however I am not sure this is the case if the number of TLB entries matches the number the device can manage (cache).
In short: Supporting both (BATs and pages) in libmm would be a good feature.
I agree with Gedare comments and approach, at the low level yes fine and what happens at the API I am not sure.
Chris _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
