Mapping Physical Memory
 

Greetings All,
I have a rather involved question to ask:
We are planning on using Embedded Linux on a new (ARM Based) device. The kernel will need to access various "hardware blocks", each of which occupies an address space of ~ 2Mbytes (contains RAM and registers). My question is:
Is there a way to "map" access to this hardware without loosing available memory address space? From my current experience, I use mmap() to map a chunk of memory that represents a log file (opened from /dev/shm). When I do this, my physical RAM (as reported by free()) will decrease. This makes sense to me.
Now, however, we desire to create "quick" access to these I/O areas by mapping them into user space (rather than have to access via as a "device" and using the file system layer). So the question is: Is there some other way to map this physical space into User virtual space that won't decrease my available RAM?
From some reading/research, I believe there is a way in the kernel to accomplish this, but we would like to access this from User Space.
Any ideas???

Thanks in Advance for your time.
Stephen

Yes, I have, up to a point, but I haven't got a very clear understanding of the question, in a couple of ways.

Do you have a memory manager and the normal, for Linux, style of virtual memory arrangement? Or do you have one of the simpler direct mapped memory arrangements? Both are possible (pretty sure that the ARM9s have MMUs and some of the low end ARMs don't; not sure exactly where the dividing line is).

If you have some hardware that is capable of remapping the memory, and the software that you are using is configured to use it, I am unclear why you would want to slow things down and make them more complex by mapping it again.

On the other hand, if you don't have the hardware or your software can't use it, you are stuck with whatever you do very directly in software. There is an overhead in doing this and its easy to do it badly. There are, though, some special cases in which it can be an almost trivial overhead, so it isn't necessarily all bad.

Now, this is the bit I really don't understand: the 'and registers' bit. Are you attempting to do something like duplicate the processor register set in normal memory? this doesn't have much meaning to me, except in the sense that, eg, an interrupt pushes register contents onto the stack, and the stack might be in external memory.

Back to the question. Virtual memory or similar arrangements really don't make that much sense, unless you have a memory hierarchy or you have more memory than addressing limitations of the processor allow you to have 'flat' access to at once. But, if there are address space limitations, paging blocks of memory in and out can be an efficient solution.

Mapping Physical Memory
 

Salasi,
CPU being used is an ARM11 type CPU, so yes, we have full MMU.
The reason to reamap (so I'm told) is to be able to dereference a pointer from User Space to the hardware for quick, direct access.
The registers in question are the "hardware" of the SoC we are building. They are physical entities mapped in the address space of the device. So if say I have "registers" located at physical address 0x0400_0000, I want to map them into my user space application for quick, easy access. Will doing so cause this space to be mapped over the existing physical RAM.
Since Linux sits in the upper 1G of address space (virtually), the question becomes: If I start mapping these areas, how much of my physical RAM will be used up (if any) for this mapping? Since we will have some memory constraints, my concern is: IF I map all of the HW into "visible" space, does it then decrease my "physical" RAM in which I have to run my application(s)??

Regards,
Stephen