Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi All,
Need to disable MMU in Linux. It needs a section of memory where virutal address=physical address in the memory mapping table. Is there any method to do the same dynamically(means to map a section of physical addresses to the same virutal addresses)
This is what we mainframers used to call a "V=R ('Virtual Equals Real') Region." (Also known as VEQR for those who don't like punctuation, or "page fixing.")
If Linux supports this, and I do not recall, then it will certainly remain a very difficult thing. There could be, for example, issues relating to where in the memory-space this buffer had to be: recall that the virtual address-space is segmented into "kernel" and "user" portions...
Is it not possible to design your program to permit the buffer to be (virtually) "anywhere," and to obtain the necessary addressing by means of offsets to that pointer? A simple #define macro could make the translation invisible to source-code readers.
Last edited by sundialsvcs; 06-22-2006 at 12:32 PM.
Hi, Thanks for the response.
My reqmnt is specific to the processor. I am doing some thing related to the system freq and i need to switch of the MMU for my implementation. I am doing the same with a kernel driver (assembly code is used for the actual cpu specific task)
Could you please provide any mech to do a 1:1 mapping dynamically inside my driver?
I know that you can't turn the MMU off. Perhaps you should explain more fully just what it is you are trying to do, and from what context (kernel, user, or both).
Some of the kernel memory space might already be mapped 1:1, such as memory-mapped I/O areas.
I know that you can't turn the MMU off. Perhaps you should explain more fully just what it is you are trying to do, and from what context (kernel, user, or both).
Some of the kernel memory space might already be mapped 1:1, such as memory-mapped I/O areas.
Actually in our kernel there is no space mapped 1:1. I need to do the same either from the kernel boot code or dynamically from my driver. Could you give any hints for the same?
Please explain, in detail, what you are trying to accomplish ... not "what your present intended path to get there" is, but "where do you intend to go with this?"
You're interfacing with .. what?
Your code needs to run .. when?
How exactly is this requirement so gosh-darned different from any other device driver whose code already exists in abundance?
looks like wini_g got it - uclinux has some options to run without mmu - but it's a complete rewrite of the mm layer - not trivial. You're far better off working off the uclinux base than trying to "switch the mmu off" in this case.
The thing with this is that uclinux is primarily intended for embedded devices. Is that what you're trying to do? What arch are you on?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.