<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 23, 2013 at 3:46 AM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Thomas Dörfler wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
please note that some PPC derivatives (especially those for embedded<br>
projects) usually have eight DBATs and eight IBATs. This feature must be<br>
enabled (e.g. in a 603e core) with a special bit in one of the HID<br>
registers, but it will put the number of BAT ranges closer to what is<br>
needed in embedded computing.<br>
</blockquote>
<br></div>
Yes this is currently true. I also see an emerging range of applications where dynamic control of memory is important.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The advantage of BATs versus pages is definitively, that they usually<br>
get set up ONCE during startup and, due to their flexible size, will not<br>
need to be reloaded.<br>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note that the pages usually only cover 4K of<br>
memory, and the "translation lookaside buffer" (TLB) only maintains the<br>
last 16-64 used pages,<br>
</blockquote>
<br></div>
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.<div class="im"><br></div>
</blockquote><div style>Yes it ranges in ARM. Last year we implemented two-level page tables with set of possible page sizes, but it was discarded due to performance issue. The current libmm/ARM (arm920) code used one level 1 MB sections for protection. Also Sebastian implemented 1 MB sections for the new realview BSP. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
so there is always code involed reloading the<br>
required page info into the TLB.<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMHO this reduces the realtime performance of the system.<br>
</blockquote>
<br></div>
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).<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In short: Supporting both (BATs and pages) in libmm would be a good feature.<br>
<br>
</blockquote>
<br></div>
I agree with Gedare comments and approach, at the low level yes fine and what happens at the API I am not sure.<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div style>That's OK, there is already an interface for handling BAT. Now it's about how to choose between BAT and pages. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
Chris<br>
______________________________<u></u>_________________<br>
rtems-devel mailing list<br>
<a href="mailto:rtems-devel@rtems.org" target="_blank">rtems-devel@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/<u></u>listinfo/rtems-devel</a><br>
</div></div></blockquote></div><br></div></div>