ARM MMU

Hi.

I'm working on a TI OMAP processor. My questions are as follows:

If I can work with an identity mapping between physical and virtual
address spaces, is there a benefit to using the MMU at all? Isn't it
better to leave it Disabled?

Is there a downside to using the MMU? Does it cause extra memory reads
from the Translation Table in memory?

Thanks,

s.

On 31 Mar 2005 07:40:18 -0800, <xss11@yahoo.com> wrote:

> If I can work with an identity mapping between physical and virtual
> address spaces, is there a benefit to using the MMU at all? Isn't it
> better to leave it Disabled?

Without MMU, your binary image should contain physical addresses and be 
placed in memory at some certain address (or be built as 
position-independent image, which has it's own drawbacks).  It would be 
more convenient to have the image starting at virtual address, say, 0, and 
be placed wherever you want it.

Another function of MMU it to check access permissions.  So, better have 
it enabled.


> Is there a downside to using the MMU? Does it cause extra memory reads
> from the Translation Table in memory?

Yes, on TLB miss.  After the TLB entry is loaded, no extra reads, until 
next TLB miss.


   Vadim Borshchev

<xss11@yahoo.com> skrev i meddelandet
news:1112283618.573671.98530@l41g2000cwc.googlegroups.com...
> Hi.
>
> I'm working on a TI OMAP processor. My questions are as follows:
>
> If I can work with an identity mapping between physical and virtual
> address spaces, is there a benefit to using the MMU at all? Isn't it
> better to leave it Disabled?
>
> Is there a downside to using the MMU? Does it cause extra memory reads
> from the Translation Table in memory?
>
> Thanks,
>


Disabling the MMU disables the datacache on the ARM9
It also means that you never get pagefaults.
I doubt that you gain anything by leaving it disabled.

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Vadim Borshchev wrote:
>
> > Is there a downside to using the MMU? Does it cause extra memory
reads
> > from the Translation Table in memory?
>
> Yes, on TLB miss.  After the TLB entry is loaded, no extra reads,
until
> next TLB miss.


Thanks for the replies. How big is the TLB typically?
Does an entry in the TLB correspond to a single address
or to a page?

Thanks again,
s.

On 4 Apr 2005 10:42:02 -0700, <xss11@yahoo.com> wrote:

> [...] How big is the TLB typically?

It can vary.  OMAP1510 has instruction TLB and data TLB, 64-entry each.


> Does an entry in the TLB correspond to a single address
> or to a page?

Page or section (they are different).


   Vadim Borshchev

This article
http://www.linuxdevices.com/articles/AT2598317046.htm
shows that linux (MMU activated)  is slower than uclinux (MM
desactivated) on ARM9 regarding context switches
So you will have to choose between Real Time performance and memor
protectio

In article <2uydnUEjHsSVNcbfRVn_vA@giganews.com>,
	pingouinshark@free-dot-fr.no-spam.invalid (pingouinshark) writes:
> This article 
> http://www.linuxdevices.com/articles/AT2598317046.html
> shows that linux (MMU activated)  is slower than uclinux (MMU
> desactivated) on ARM9 regarding context switches.
> So you will have to choose between Real Time performance and memory
> protection
> 

(This is a common misconception which refuses to die..)

Real Time != real fast

Real time performance is about determinism, not speed.

The problem with using the ARM9 MMU is that one has to flush
the caches when switching between address spaces. This does make
average context switch times slow, however, to evaluate a
system's real-time properties, you need to look at the worst
case: A cache speeds things up in the average case, but for the
worst case (i.e. only cache misses) it does not (it may even
slow things down sometimes).

Rob

-- 
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.com

Robert Kaiser said
> pingouinshark@free-dot-fr.no-spam.invalid (pingouinshark) writes:
> > 
> > This article 
> > http://www.linuxdevices.com/articles/AT2598317046.html
> > shows that linux (MMU activated)  is slower than uclinux (MMU
> > desactivated) on ARM9 regarding context switches.
> > So you will have to choose between Real Time performance and memory
> > protection
> > 
> 
> (This is a common misconception which refuses to die..)

Not necessarily a misconception - more like a common requirement.

> Real Time != real fast
> 
> Real time performance is about determinism, not speed.

True, but in most of the applications I've been involved in, speed was 
a critical issue in maintaining real-time status.  Determinism doesn't 
help much if you can't keep up with the real-time demands of your 
application.  

It just depends on the application.



Casey

> True, but in most of the applications I've been involved in, speed was
> a critical issue in maintaining real-time status.  Determinism doesn't
> help much if you can't keep up with the real-time demands of your
> application.

How do you know you are keeping up with real time demands if your system is
not deterministic?  You are agreeing with the previous post here.

Richard.

http://www.FreeRTOS.org

Richard wrote:
> > True, but in most of the applications I've been involved in, speed
was
> > a critical issue in maintaining real-time status.  Determinism
doesn't
> > help much if you can't keep up with the real-time demands of your
> > application.
>
> How do you know you are keeping up with real time demands if your
system is
> not deterministic?  You are agreeing with the previous post here.

This is the classic debate between soft realtime and hard realtime.
You sometimes need high throughput, but you can cope with not meeting
deadlines everytime depending upon the needs of the application.
TV broadcasting is one such example. Of course, a safety critical
device would not tolerate this.