General :: Dealing With NonVolatile Memory In Embedded Applications

I currently work within an RTOS environment without an MMU and thus have access to the entire memory map of whatever application I'm working on. As is common in the embedded world, different parts of the memory map relate to different peripherals or different types of memory. For our next generation hardware, my company is looking at moving to an MMU-enabled processor and using Linux in some shape or form. Most of us in the dept are familiar with Linux, but we are not Linux gurus by any means. So how to explicitly indicate to Linux that we need certain portions of an application to be stored in NVRam and other portions of the application to NOT be based in NVRam has us confused. None of us have a clear understanding of how user memory is delved out by Linux and how we can influence Linux to use specific portions of the memory map at specific times.

For example in this new application, we expect to have 2 memory chips, both that are DDR3 interfaces. One is a standard DDR3 chip. The other is a non-volatile MRAM with a DDR3 interface so it can be accessed by a DDR3 controller and coexist with conventional DDR3 memory. But because the portion of the memory map that the MRAM will represent will be the only portion of non-volatile memory, we are unclear how we explicitly access MRAM addresses in an MMU-controlled environment. My hail-mary guess was that we would want to somehow tell Linux that we want the MRAM's memory space to be mounted as a RAM Drive and then we access that memory as though it is a file on a HD, except it is much higher speed since it will be at DDR3/MRAM speeds. Is there a better, more straight forward way to do this? Coming from an RTOS world, Linux is going to pose some serious challenges for us, but I think it will be the right move once we are all up to speed and are thinking Linux-centric.